WIP: Use Sat/WU instead of (μ/m)BTC/kB #11557

I thought this would be a simple UI change, but it turns out to be more involved. So first I'd like to find out if these changes are considered useful, non contentious and if I'm using the right approach. @gmaxwell recently refactored the consensus code to emphasize block weight over block size (#10618). My idea was to make the fee UI consistent with this, by using weight units (WU) instead of bytes.

In addition, 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. Because the fee is per unit of size / weight, it makes more sense to me to express this in Sat / WU.

If people agree, then I'd like to remove the (μ/m)BTC dropdown from the fee UI: <img width="820" alt="schermafbeelding 2017-10-25 om 18 19 58" src="https://user-images.githubusercontent.com/10217/31994345-e907a71c-b9b2-11e7-9794-8f08b3c2bfb2.png">

This also frees up some space which I'd like to use (different PR) to show the fee as a percentage of the transaction amount, which should help prevent unintentionally large fees.

I think Sat/WU makes for more readable numbers than BTC/kWU would. 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/Byte, where 1 is the minimum relay fee, 10-100 is the usual range, people start complaining when it goes over. Assuming fees in dollar terms stay in the same range, or even a factor ten more, Sat/WU produces easy to read numbers for a price range of $500 (100 - 1000 sat/WU) to $5 million (0.01 - 0.10 sat/WU).

It looks like CFeeRate shouldn't be used with floats. This creates a problem, because 1 Sat/B is 0.25 Sat/WU. Bumping this to 1 Sat/WU doesn't seem unreasonable with current typical fee levels, but this would change functionality at more levels than just the UI.

This WIP is completely broken; changing CFeeRate to be in terms of sat/WU means I'd have to make more changes. There might be lighter tough way to change the UI.

Showing fees as percentage of the transaction is a good idea.

@Bluethf thanks. I think it's more suited for a separate PR, so I changed the title. I would probably move the "Estimated to begin ..." text to above the Recommended / Custom selection, and then add the absolute + percentage values there. Ideally this would be horizontally aligned with the Amount input field.

using WU instead of vsize changes the scale of the numbers by a factor of 4... not quite ideal.

vsize makes sense.

Just found a Stack Overflow article on vsize vs. weight, where @sipa says:

The advantage of using vsize is that it is a smooth transition from size; every non-witness transaction has vsize equal to size.

All code and infrastructure that used satoshi/byte before, will keep working when substituting size with vsize, and give consistent results. Switching to weight would be confusing - would we be talking about satoshi/weightbyte?

This fee estimation article is also useful.

"Virtual size in bytes" has the additional benefit of being more intuitive than "weight units" in a UI.

Do I understand correctly that the current fee estimator doesn't use vsize yet? Changing that sounds a bit too daunting for me at this point. I can open a separate issue / PR, once vsize is implemented, to suggest using Sat / Virtual Byte.

Everything uses vsize already, including fee estimation, block construction, ...

Closing this in favor of the more simple #11564, to discuss if Sat / vByte is a good replacement for (μ/m)BTC/kB.