Bluewallet: Creating lightning invoice in local currency

[jensamunch]

Again a UX point. I can only create an invoice in Satoshis. This means if I want a friend to pay me £5 I have to try multiple times to find the right number of satoshis. Can’t you let me just put the £ in for the invoice and make it the right number of Satoshis.

[issue-label-bot[bot]]

Issue Label Bot is not confident enough to auto-label this issue. See dashboard for more details.

[dalebewan]

I'd like to propose this issue more generally as:
Any field where an amount can be entered by the user - e.g. Lightning Invoice creation; amount on base-layer send; etc - should default to the currency used for display.
That is, if the user is showing their balance in BTC, the entry field should be BTC. If the user is showing their balance in sats, the entry field should be sats. If the user is showing their balance in £, the entry field should be £.
The user can switch between entry types by touching the exchange value shown below the entry field.

Note that current behaviour is that a base layer send/receive requires the user enter a value in BTC, and a Lightning invoice requires the user enter a value in sats. Aside from the main problem of not allowing entry in local currency, this itself is a UX concern.

[Overtorment]

@dalebewan great idea! cc @marcosrdz @ncoelho

[marcosrdz]

Working on this..

[jensamunch]

Now that BlueWallet has fee functionality this should apply there as well?

If we want BTC to be easily available and used by "normal" we, at least initially, need to let them think in their own currencies.

I'd love to be able to say I want to transfer £5 and choose to pay £0.3 in fees. Satoshis per byte is not helpful for me in making a transfer.

[dalebewan]

Now that BlueWallet has fee functionality this should apply there as well?

I think it should. Fees aren't actually "sats/byte" anyway - they're a specific number of sats. Sat/b is a good way to understand how it'll likely be prioritised by miners since they're the ones that care about that metric. Users only care about it in terms of priority.
I really like the existing slider for fee selection and hope that doesn't get killed in some future update. I'd like to see it improved a bit further though whereby:

1. It has "sticky points" for estimated fee times. That is, you can go below or above, but the slider sticks on the fee that the estimator gives for specific times such as next-block, 1 hour, 24 hours.
2. It allows for values that aren't round sats/byte (a miner will take a 1.1sat/b fee over a 1sat/b fee; there's no need to go straight up to 2sat/b).
3. It displays the amount in the selected currency (this request), with the actual fee in sats and sat/byte value in smaller text nearby. e.g. "€0.04 (270sat, 1.2sat/byte)". When the selected currency is sats, obviously it can be simplified, e.g. "270sat, 1.2sat/byte".
4. The steps are in the selected currency. If you're in UKP, the lowest point on the slider may be £0.01 and the next step up is £0.02. If you're in sats, the lowest point is the equivalent of 1sat/b (for relay purposes) e.g. 270sat, but the next step is 271sat, then 272sat, etc. Practically speaking, the steps may be forced larger since the slider would have more steps than pixels at that point but the idea is that there should be no forced larger granularity (it's a slider control after all).

[jensamunch]

Good additions.

Key question for UX: who is the user/persona? What insight is the user expected to get from sat/b? You said its mostly relevant to miners. Who else?

I would imagine most users will be interested in speed and total cost of tx.

For example: £0.5 fee & estimated completion ~3 hours

[dalebewan]

This might sound a bit self-centred, but the user/persona is myself. More generally, it's a recognition of the fact that we're still in the early days and most regular Bitcoin users (i.e. those who send/receive regularly) are technically aware of fee settings. I always want to know the sats/byte that I'm sending a transaction as so that I can manually compare it with the mempool to get an idea of priority. I regularly send transactions at around 1.1sat/byte precisely, because it gets priority over the 1sat/byte "pile" and isn't significantly more expensive. However, if I see that the mempool really is quite full and I have a high priority transaction, I trust my own judgement for the fee setting far more than that provided by the software.
(on my personal to-do list is to define a better fee estimation algorithm given how terrible every existing one is)

[ncoelho]

The fee estimation algorithm recently was changed from our own to bitcoinJS one. Any feedback on that?

(need to double check this)

[marcosrdz]

Theres currently a branch for this. Its called fiatinput. Work in progress but UI is done.

[dalebewan]

The fee estimation algorithm recently was changed from our own to bitcoinJS one. Any feedback on that?

It still seems unnecessarily high. I think the problem with existing fee estimation is that it doesn't take mass behaviour in to account. That is, there are "trends" you can see in mempool usage that aren't accounted for by the algorithms (but perhaps making it more difficult, some of these trends are probably BECAUSE of the mass use of similar algorithms).
In general though, if you take any random point in history and run the fee estimation for that point in time then compare it to how reality played out, the estimation was unnecessarily high. It's occasionally correct or low, but nowhere near as much as too high.
I don't have a good solution yet, but the problem is relatively clear.

[jensamunch]

Any news on this one?

Think it’s pretty critical for UX that it’s possible to consistently see amounts in currency of ones choice:

• balances
• transfers
• network fee

[Overtorment]

work being done on this in https://github.com/BlueWallet/BlueWallet/pull/1138
will be out probably in next release

[Overtorment]

merged to master. will be out in next release