display fees in Sat / vByte instead of (μ/m)BTC/kB

fanquake commented at 2:24 am on August 15, 2020: member

Moved from https://github.com/bitcoin/bitcoin/issues/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.

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.

fanquake added the label Brainstorming on Aug 15, 2020

ghost commented at 10:19 am on August 21, 2020: none

Yes sat/vbyte makes sense. Even I was planning to create an issue or submit PR related to same thing. Most of the tools use sat/vbyte. If a newbie tries bitcoin core wallet, he will have to Google conversion of sat/kilobyte to sat/byte and also understand the difference between byte and vbyte.

Sjors commented at 12:55 pm on August 28, 2020: member

Using “sat/byte” instead of “sat/vbyte” is fine; we make that shortcut in other places. As of bitcoin/bitcoin#11413 the RPC supports this too.

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

I no longer plan to do this myself :-)

jonatack commented at 6:32 pm on October 22, 2020: contributor

The results of these informal twitter polls yesterday seem heavily in favor of sat/vB.

https://twitter.com/jonatack/status/1318890833131823104

Sjors commented at 8:56 am on October 23, 2020: member

That’s good to hear. I would still drop the v though.

jonatack commented at 9:03 am on October 23, 2020: contributor

Standardizing on a unit is a proposed meeting topic at today’s wallet meeting: sat/B, sat/vB, sat/kvB, etc. :)

michaelfolkson commented at 9:19 am on October 23, 2020: member

I don’t agree with getting rid of the v in vbyte. Non-technical people will just ignore the v (no downside for them) but it gives technical people a stepping stone to understanding what fee they are setting. If it is just byte there will need to be docs saying “when we said byte we actually meant vbyte”. Not ideal

Sjors commented at 11:30 am on October 26, 2020: member

We currently don’t use vbyte anywhere in the RPC or GUI. Switching to that is orthogonal to adding satoshi support (and it’s been tried in before: https://github.com/bitcoin/bitcoin/pull/12180).

andrasfuchs commented at 10:39 am on November 24, 2020: none

I think it’s a good idea, I would love to see this implemented. @fanquake , would you still be open to work on this PR?

jonatack commented at 10:53 am on November 24, 2020: contributor

Moving to sat/vB is now starting to happen in the RPC, so :+1: on doing it in the GUI.

viaj3ro commented at 3:30 pm on March 23, 2021: none

I’d also love to see this implemented in the GUI. Preferably s/vb. The respective fee should also be shown for incoming and outgoing transactions and not just when creating a new transaction (as described in #255)

hebasto added the label UX on May 1, 2021

jb55 commented at 12:14 pm on October 10, 2022: contributor

needed this today… anyone working on this or should I take a stab?

jonatack commented at 12:47 pm on October 10, 2022: contributor

@hebasto is gui dev still taking place here or has it moved to the qemu repo? This repo seems fairly quiet.

hebasto commented at 1:06 pm on October 10, 2022: member

@hebasto is gui dev still taking place here or has it moved to the qemu repo?

QML-based GUI repo indeed combines efforts of designers and developers.

This repo seems fairly quiet.

There are always a plenty of PRs to review and issues to fix…

jb55 commented at 3:05 pm on October 10, 2022: contributor

On Mon, Oct 10, 2022 at 06:06:44AM -0700, Hennadii Stepanov wrote:

@hebasto is gui dev still taking place here or has it moved to the qemu repo?

QML-based GUI repo indeed combines efforts of designers and developers.

TIL, I’ll check this out

jb55 commented at 3:27 pm on October 10, 2022: contributor

hmm it looks like it might be awhile until that experimental fork is merged? might be good to still do this in the meantime.

hebasto commented at 3:47 pm on October 10, 2022: member

hmm it looks like it might be awhile until that experimental fork is merged?

That’s true.

might be good to still do this in the meantime.

A PR is always welcome.

Sjors commented at 8:04 am on October 21, 2022: member

Moving to sat/vB is now starting to happen in the RPC, so 👍 on doing it in the GUI.

It even landed in the RPC (one or two major releases ago), so this change shouldn’t be too controversial for the GUI at this point.

The installation “wizard” could even set the default to sat/byte for new users.

display fees in Sat / vByte instead of (μ/m)BTC/kB #64