Closed gre closed 5 years ago
we can't implement it easily in 1.1.0, will have to postpone it for later.
one of the reason is, our Ethereum api returns json and uses JSNumber for the balance field. We can't rely on JavaScript to be precise enough to have this field right. We'll need to do #1110 and then, either we would have to implement our own JSON parser (that i would not recommend taking that path 🐰🕳), or we'll wait libcore to support Ethereum (not sure about ETA on this @pollastri-pierre ?)
The question is do we want to have it :100: reliable or do we want an escape hatch that will leave some micro amount in accounts you left / sometimes will actually fail (before number imprecision). I think we prefer option #1 and ship a bug-free experience.
status update:
BigNumber is here, and libcore have a built in way to "empty everything" so we'll give a try to this. We should be able to reliably implement MAX for all coins except Ethereum and Ethereum Classic, because these still have imprecision due to our API, but as soon as it gets backed by libcore, we should be able to do it as well.
I suggest we ship it as experimental (with a env variable) for all libcore backed coin for now and turn it on only when it's available everywhere.
Any progress? I always use the old Ledger Wallet Bitcoin to transfer full amount, because I don't know what size will be the transaction to calculate the network fee and discount from my balance. Thanks :)
Probably expect it around Q1 2019. Relatively easy to add but we're waiting on shipping Ethereum with libcore to have it reliable as said above
Please make sure to make the fee adjustable for this scenario also. I.e. send MAX given an entered fee.
Yeah I think MAX toggles a mode that locks the amount field and fee remains "free". That's how I would imagine it but we'll discuss it internally and have good ux for this.
Is it now possible to do this, with some env var set, as suggested? If not, is it targeted for a particular release milestone? My case is not using eth, if that matters.
Any update regarding this feature? It should be at MVP from the start imo.
I regret buying Nano Ledger S now
@AndydeCleyre @alexkyse1 @AcidRaZor this will be available soon as an experimental feature. It is already the case in our develop branch.
It's fine, transferring my crypto over to something else and selling this 2nd hand. cant wait for this long and not have a feature that is the most basic ever that was included in the old chrome apps. don't get me wrong, I love math. but in terms of UX, and you "concentrating" on that? naw man, tell me lies somewhere else
@AcidRaZor You do realize that you can use other wallets, right? E.g. on Android, Mycelium supports Ledger Nano.
Regarding UX, the destination tag for sending XRP is well-hidden, totally screwed up my transaction.
@nilskp Why bother with ledger live at all then? they should just partner with a better known wallet software in that case, don't you think?
The destination tag position problem is known and will get addressed in the future. We listen to our users feedback and address things but unfortunately we have a limited bandwidth. The project is open source and open for contributions.
Please let's stay on topic which is the Send Max.
@AcidRaZor You do realize that you can use other wallets, right? E.g. on Android, Mycelium supports Ledger Nano.
But other wallets doesn't allow us to use Segwit address :/
With Ledger Nano S and Firmware 1.5.5 it is not possible to send Max... When this issue were fixed?
when fixeD?
when fixeD?
i'm closing this task because it's already implemented. + see #2164
Part of the application
Send > step1
Description
Allow to use the Maximum available balance in the amount field (Send>step1).