[qt] Improved "custom fee" explanation in tooltip #12501

Thanks to @dooglus for asking about this tooltip in Issue 12500. Reference: https://www.github.com/bitcoin/bitcoin/issues/12500

I would also appreciate it if someone can confirm that 1 kilobyte in this field indeed represents 1,000 bytes rather than 1,024 bytes (if it's supposed to be 1,024, then I'll gladly make the necessary changes to reflect this).

It's 1000 bytes.

But I don't think there's any logic about "transactions larger than 1 kilobyte". It's a simple BTC-per-1000-bytes calculation, as follows:

The value in the field is used to construct a CFeeRate object:

ctrl.m_feerate = CFeeRate(ui->customFee->value());

The constructor sets nSatoshisPerK:

CFeeRate(const I _nSatoshisPerK): nSatoshisPerK(_nSatoshisPerK) {

nSatoshisPerK is multiplied by the tx size and divided by 1000:

CAmount nFee = nSatoshisPerK * nSize / 1000;

So the tooltip really doesn't need to say anything other than that it's per 1000 bytes I guess.

Although, it might make sense to also mention that it's not really per 1000 bytes, but per 4000 weight units. Or in other words per 1000 bytes of virtual transaction size.

@dooglus Thanks for the clarification. I think it's important to mention 1 kilobyte in the tooltip since the field's label mentions "per kilobyte" specifically.

My feeling on weight units is that since they're not mentioned in the field's label that inclusion in the tooltip would be more likely to introduce confusion for those less-knowledgeable users, and so I'm inclined to think that this concept is probably best left in documentation.

Fair enough, but mention that it's per 1000 bytes of virtual transaction size, not actual transaction size.

int64_t GetVirtualTransactionSize(int64_t nWeight, int64_t nSigOpCost)
{
    return (std::max(nWeight, nSigOpCost * nBytesPerSigOp) + WITNESS_SCALE_FACTOR - 1) / WITNESS_SCALE_FACTOR;
}

@dooglus Thanks, I like the more condensed sentence you suggested and so I added a new commit to reflect that. (For a tooltip, simpler is usually better too.)

Note: It appears that @dooglus' suggestion disappeared since I added the new commit.

utACK, seems like an improvement.

Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits

@MarcoFalke The squash/rebase is complete. Thanks.

The tooltip is not clear. It can be understood that the fee is per every 1000 bytes virtual transaction size to mean a transaction of 1001 bytes virtual transaction size will pay 2x the entered fee, the same as 2000 bytes virtual transaction size.

It would be better IMHO to say something like Specify a custom fee per 1,000 bytes of the virtual transaction's size. If the custom fee is set to 1000 satoshis and the transaction is only 250 bytes virtual size, then "per kilobyte" only pays 250 satoshis in fee.

Specify a custom fee per 1,000 bytes of the virtual transaction's size.

@Willtech We did have some wording describing the apportioned amount, but @MarcoFalke explained that this isn't how it works anymore so I removed it (I don't know where his comments disappeared to though as it seems that GitHub is losing parts of the conversation here a few times now).

So, I'd be happy to put the wording back in, but I would like consensus first on whether there is support for an apportioned amount (e.g., a transaction size of 250 bytes reduces the fee to one quarter).

By the way, the wording I added (then later removed) was:

For the transaction fee, you can specify the exact number of "satoshis per kilobyte (1,000 bytes)." For transactions larger than 1 kilobyte, the fee will be calculated on a per-kilobyte basis. For transactions smaller than 1 kilobyte, the fee will be apportioned according to the size of the transaction (e.g., for a transaction that is 500 bytes {half of 1 kilobyte}, a fee of 0.00000010 would therefore be reduced to 0.00000005).

It might also be worth noting that if you specify a value that is less than either of the -mintxfee or -minrelaytxfee values, then the greater of those two values will silently be used instead:

CAmount GetRequiredFee(unsigned int nTxBytes)
{
    return std::max(CWallet::minTxFee.GetFee(nTxBytes), ::minRelayTxFee.GetFee(nTxBytes));
}

I only found this out accidentally when I tried to make a transaction that pays 333 satoshis per 1000 bytes, but it silently changed my custom fee to 1000 satoshis per 1000 bytes, due to those two settings both defaulting to 1000 satoshis.

So, I'd be happy to put the wording back in

We don't need that wording back in - it was talking about how things behave differently if the tx size is less than 1000 bytes, and that's no longer the case.

The point that maybe needs clarifying is that the feerate of x per 1000 bytes applies on a pro rata basis. If the fee is x per 1000 bytes, and the tx is y bytes, then the fee is x*y/1000. That seems pretty intuitive to me. If a tx that was 1001 bytes cost 2x, then that would be described as "x per 1000 bytes or part thereof", I should think. The fees work the same way as buying cheese or gasoline. If the cheese costs $x per pound, and you're buying 1.1 pounds of it, you pay $1.1x, not $2x.

@dooglus I discussed this a few days ago in irc.freenode.net#bitcoin-core-dev and based on that conversation I added some "Notes" to this tooltip. Now the full text reads as follows, and I would like to know if this looks reasonable (this is my current attempt at trying to make it easier to understand):

Specify a custom fee per kB (1,000 bytes) of the virtual transaction's size.

Note: Since the fee is calculated on a per-byte basis, a fee of "100 satoshis per kB" for a transaction size of 500 bytes (half of 1 kB) would ultimately yield a fee of only 50 satoshis.

Nit that "virtual transaction" is not currently a concept in the UI, and I don't think it has value for the user. I think in the source code "virtual transaction" refers to a transaction that has not been broadcast, which is potentially meaningful if you're distinguishing between transaction states in-flight but adds unnecessary complexity for the user. To be clear, I would drop "virtual".

Also how are translations dealt with? There are ~30 translations of this string that would need to be updated. Maybe it's better to go with a simple removal so that the translation work would be negligible? Note I'm a noob so not knowledgeable on this point.

As said here (click 'show outdated'), it should be "transaction's virtual size", not "virtual transaction's size".

Should "virtual size" be revealed to the end user? It shows up in the transaction unival but IMO the end-user interface should be higher-level, where distinctions between "serialized size" and "virtual size" are not relevant.

@Empact How is the user meant to decide how much to pay per virtual byte if they don't know what a virtual byte is? If I ask to pay 1000 satoshis "per 1000 bytes", then later see that the transaction's size is reported to be 216 bytes, but I only paid 134 satoshis aren't I going to think that the GUI got it wrong and paid less than I asked it to?

We should report the serialized and the virtual size so the user at least has a chance of making an informed decision.

@dooglus I'm glad that @Empact raised the point about the transaction's virtual size possibly being confusing to end-users. Your point that it needs to be mentioned seems to make sense, which leads me to ask this question: Is the GUI showing the transaction's total (non-virtual?) size while instead the code is calculating the "transaction's virtual size" behind-the-scenes?

IMO the difference between virtual and serialized size is an implementation detail irrelevant to users. Here are a few blockchain explorer transaction views - they include "size" and sometimes "weight" but never a separate "virtual size". https://blockchain.info/tx/ee72a85ab4ced151bf26d3317c3ec41ace4e523cd2f8764dc089ac94383eae74 https://blockexplorer.com/tx/ee72a85ab4ced151bf26d3317c3ec41ace4e523cd2f8764dc089ac94383eae74 https://live.blockcypher.com/btc/tx/ee72a85ab4ced151bf26d3317c3ec41ace4e523cd2f8764dc089ac94383eae74/ https://www.blocktrail.com/BTC/tx/ee72a85ab4ced151bf26d3317c3ec41ace4e523cd2f8764dc089ac94383eae74

Where is virtual size exposed in your experience? The important thing in my experience is having a value that can be compared with mempool viewers for informed fee selection: https://jochen-hoenicke.de/queue/#1,24h

Where is virtual size exposed in your experience? The important thing in my experience is having a value that can be compared with mempool viewers for informed fee selection: https://jochen-hoenicke.de/queue/#1,24h

That's a good example. All the sizes and rates shown there are virtual sizes, and fee per virtual byte. He doesn't use the word "virtual", but talks about how "sizes include the segwit discount". That's just another way of saying they are the virtual sizes.

the lower diagram already shows the size minus three quarter of the witness size. The segwit discount is also included when computing the fee level for a transaction

So the very site you mention is exposing the virtual size (only).

Great, so if the virtual size is the meaningful value, shared everywhere as the size, why not just refer to it as the size as it's the only relevant size to the user?

@Empact Because the GUI itself already refers to the serialization size as the size.

Double-click on any transaction and it reports only the serialization size, not the virtual size.

For example, this is a transaction where I asked to pay 1000 satoshis per 1000 bytes:

Transaction fee: -0.00000134 BTC [...] Transaction total size: 216 bytes

The virtual size was 134 bytes, but that isn't reported anywhere.

(I'm not sure why the fee shows up as a negative amount, but that's a separate issue).

@dooglus It seems that perhaps you've discovered a bug. Although this clearly is not a detrimental bug given that the resulting transaction fee is lower than what you expected it to be (which I suspect is unlikely to yield negative complaints), it still should probably be addressed at the very least.

Updating the tooltip may not the ideal way of going about remedying this discrepancy though, and so perhaps raising a separate issue entitled "transaction fee discrepancies" that focuses on getting the underlying mechanics of this sorted out would be better? (Feel free to reference this PR if you do raise this as a separate issue.)

I'm favouring what @Empact suggested because I do think that specifying "virtual size" is likely to be confusing to at least some end users (particularly those who aren't technical). If the tooltip were to reference documentation in a "see also ... for more detailed information" manner, I certainly think that would be a good option as it would not detract from keeping the tooltip text simple, straight-forward, and easy to understand, while also satisfying those who do want more technical detail.

@dooglus Thanks again for raising this issue. I just rebased all the commits after reviewing the "virtual size" wording in today's Bitcoin Core Developer meeting...

The consensus seems to be that we're going to "bite the bullet" so-to-speak and simply use the wording in the current commit which refers to the "virtual size" of transactions. It was also noted that this is a term that people can search for on Google to find out more if they need/want to (we considered possibly using other ways to describe this, which we did not favour because that would be introducing newer terminology, which in turn would create confusion).

Thanks for letting me know.

I just made a pull request (#12580) to add the virtual size to the details modal.

@MarcoFalke just merged my PR, so the transaction details dialog shows both total size and virtual size.

Example tx spending a SegWit utxo:

Example tx spending legacy utxos:

So now it makes sense to refer to a transaction's virtual size and have some expectation that the user knows what this means.

utACK 0bc095efd8dd25770af398cb2b73cd65b3bc9f89, this is a clear improvement, I think it's been bikeshedded enough.