search

bitcoin-core / gui

Bitcoin Core GUI staging repository
https://github.com/bitcoin/bitcoin
MIT License
603 stars 262 forks source link

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

Open fanquake opened 4 years ago

fanquake commented 4 years ago

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.

schermafbeelding 2017-10-26 om 18 06 10

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.

ghost commented 4 years ago

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 4 years ago

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 4 years ago

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

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

Sjors commented 4 years ago

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

Schermafbeelding 2020-10-23 om 10 55 20
jonatack commented 4 years ago

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

michaelfolkson commented 4 years ago

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 4 years ago

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 3 years ago

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 3 years ago

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

viaj3ro commented 3 years ago

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)

jb55 commented 2 years ago

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

jonatack commented 2 years ago

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

hebasto commented 2 years ago

@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 2 years ago

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 2 years ago

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 2 years ago

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 2 years ago

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.