[Qt] display fees in Sat / vByte instead of (μ/m)BTC/kB #11564

Currently the send screen displays the fee in terms of (μ/m)BTC/kB, depending on a global preference. When entering a custom fee the user can select (μ/m)BTC using a dropdown. The resulting numbers are quite hard to read, often with five leading zeros.

<img width="589" alt="schermafbeelding 2017-10-26 om 18 06 10" src="https://user-images.githubusercontent.com/10217/32047392-62ff7c5a-ba78-11e7-9505-a08580e7e7a3.png">

This makes it too easy to make an off-by-ten mistake, especially because the wallet doesn't display fiat values.

I think Sat per Virtual Byte (vByte?) makes for more readable numbers. People generally find numbers between 0.01 and 100 easy to work with, because they're used to cents and dollars. Several fee estimators currently use Sat/vByte, where 1 is the minimum relay fee, 10-100 is the usual range, people start complaining when it goes over.

I also think this choice is quite durable, even if the price increases by orders of magnitude and fees get worse (low fees would not really be a UX issue). Assuming fees in dollar terms stay in the same range, or even a factor ten more, Sat/vByte produces easy to read numbers for a price range of $500 (100 - 1000 sat/vByte) to $5 million (0.01 - 0.10 sat/vByte).

In this case the (μ/m)BTC dropdown could be removed from the fee UI; I don't think the users currency preference (μBTC / mBTC / BTC) should be applied to the fee UI. This preference makes sense for the users balance, for a transaction amount and the absolute fee value.

There would still some confusion if people look at other fee estimators on the web which currently often user fee per byte, based on non-segwit transactions.

Hopefully the industry will trend towards a single metric for fees, so people can develop an intuition for them, decreasing the likeliness of mistakes.

I can make a PR is people think this is a good idea.

I am also in favor of having the option of entering the transaction fee in satoshis per virtual size byte.

Recent IRC discussion. @laanwj pointed out:

were it to be redesigned from scratch I'd agree with you. I think changing it now is too dangerous. for the RPC interface people already have software that uses the current convention, for the GUI people already have the habit of entering /kb numbers, it's kind of a fight upstream to change it

This suggest we need a setting for this as well. The setting could default to sat/vbyte for new installs (or not, it's not that hard to change a setting).

sat/vbyte is the standard of how people reason about fees. sat/wu would be the most logical though. If there was a default, I would vote for sat/vbyte though.

This blog posts compares various block explorers. Note also the comment by @matsjj making a case for weight units.

In light of BIP-0176 perhaps bits / kb is better. Values would be somewhere in the 10 - 5000 range.

1 sat / byte = 10 bits / kb. So in that case we could just remove the dropdown here:

<img width="548" alt="schermafbeelding 2017-12-28 om 17 08 21" src="https://user-images.githubusercontent.com/10217/34416014-bd2bcab2-ebf1-11e7-852c-46b05f001075.png">

Or if we do want to keep the dropdown, it should probably only offer bits / kilobyte, sat / byte, bits / wu or sat / wu. The latter two only make sense if we switch the whole wallet to use weight units, which isn't trivial (see e.g. #11557 (comment)).

Assuming "bits" get some traction, bits / kilobyte introduces the fewest new words to a new users vocabulary, while still being readable. Whereas both sat and wu need explaining.

I am a sucker for satoshis per byte, I see them as the base units that "everything refers back to", so . . . so I can't help but, want / like having, that as an option.

How about two drops downs? One for the unit (sat, bits, ...) and the other one for the denominator (byte, kbyte, ...) ?

@julien-lecomte let's not clutter the UI more that it already is... it's not that many combinations, so should fit in one dropdown if we can't resolve the bike-shedding.

Please note that the command line parsing always assumes BTC or BTC per kB, which is also currently displayed for fee rates in the gui. Having a different unit for the options than what is displayed could be confusing.

You could argue the cli feerate as BTC per KB is more confusing, vs the more commonly used sat/(v)byte. I'm not saying that we should change the cli, but to recognize that most people using the GUI are not the same people using the cli (generally).

Why not be configurable via config file ? If a user is savvy enough to change it in the config file, he is savvy enough to know what he is doing.

The Default Config would be dependent of the current trend at a given time.

it should probably only offer bits / kilobyte, sat / byte, bits / wu or sat / wu

I agree with this, and I think it would be much better in the GUI than in the config file, as you may need to change it on the fly.

Moved to the GUI repo: https://github.com/bitcoin-core/gui/issues/64.