Topic: Bitcoin transaction fee dialog mockup (Read 1288 times)

Good idea, though that dialog looks a bit intimidating 

The fee (as well as total) is already always shown in the confirmation dialog in the current master.

It is indeed the intention to add a priority/urgency choice that determines the fee, this will be part of the smartfee work.

I recommend using the term "urgency" rather than "priority", since priority already has a specific meaning with regard to transaction fee rules and I guarantee this will result in confusion every time someone asks for help because their transactions aren't confirming. ("What do you mean, it's a low-priority transaction? I specifically selected high prioirty! ")

This is the right approach. I would suggest an even simpler dialog box which is color-coded, and has an "advanced options" check box for those that want full control.

Select the priority urgency of your transaction:

[ ] Fast
[ ] Normal
[ ] Slow
[ ] Advanced options

The software calculates the appropriate fee and displays it for the final confirm/cancel.

If the user thinks the fee is too much they can change it before confirming. The slow option will select zero fee if appropriate, or a small fee if it is unlikely to be processed at a zero fee. Advanced options are more like the dialog box in the OP and has system metrics / network statistics / pending transactions.
(edit: urgency)

Thought I'd give this thread a mega-bump just because I'd still like my mockup to magically come true (some fee guesstimation work is in progress for 0.9). I recently tried to export particular private keys into a new wallet, even calculated in Excel using UTXO, and still ended up with an unspent dust that wasn't grabbed out of my wallet thanks to the opaque fee calculations in Bitcoin-Qt.

Comments invited, from those who intimately know what Bitcoin already does.


This is generally what I was indicating in my mockup where "network statistics" are listed. With current statistics it might look like:

Since the local client won't know all transactions miners could be considering, and it's hard to educate about block variance, being non-specific but informative about the estimated time is hard. A "percentile" might not be accurate, because a lot of what's pending is a big backlog of zero-fee junk that will take many blocks of 27k priority-based space to clear.

Fee per kB is actually more important than total fee, the mockup should indicate "Per kB" optional fee, just like Bitcoin-Qt does now, and then calculate total fee amount live.

Yes, that's exactly what I meant that the language could be cleaned up. The crux of the proposal is that the user should be able to indicate to the software whether they would like to pay the recommended fee, above recommended fee, or below recommended fee by just pressing a button (or for experts, just set the number into the edit box).

It would be nice if there was an "Advanced" button that expands the dialog to include a line by line summary of how the recommended fee was calculated. This would include revealing to the user the computation of the "age" of the inputs, showing the measured median / average fee based on the last N blocks (or whatever, I'm referring to the code Gavin is planning to write).

If the user puts a value into the edit box which is sufficiently low (or zero) and presses OK then a dialog should pop up saying that "A transaction with insufficient fees may never get processed, are you sure you want to do this?"

I think that "Optimize transaction for..." and "Network Statistics..." should be part of the Advanced version of this dialog. There's no need to see all that every time, and it only creates anxiety for the user when they are presented with a bulky transaction fee confirmation dialog every time they want to send.

To Bitcoin, your transaction already has something else that is is called priority - the age of the coin inputs being sent multiplied by the value of the transaction in BTC. When this priority is high enough, a transaction qualifies to be free if it has no spammy payment outputs in it, and it qualifies to be placed in the area of a block reserved for free transactions (although this might not be big enough for all the free high priority transactions).

If a transaction is not calculated high priority, than sending a transaction with less than the minimum per-kb fee will guarantee a transaction that takes hours or days or is just ignored by miners and not relayed by other nodes. A no-fee option is no option unless you want to guarantee a forum with dozens more people a week that need to manually edit transactions out of their wallet that will never confirm.

That makes the fee the minimum (required and included) + the optional fee. Transactions go through relatively quickly now if they include just the minimum fee (when required), usually the next block. In a future when many fee-paying transactions are waiting for block inclusion, any recommendation for a "good" optional fee amount might not be what an experienced user would have typed in themselves.

You are in the right frame of mind, how to recommend more fee in the user interface without a constant flood of questions of how to use it - "what's the minimum optional fee that will work for me?"... "I paid more but it still took 20 minutes"..."Why does it recommend such a big fee when it's not required", etc.

isn't it better to look at the current pool of transactions, and check what fee would be required to get the transaction above a certain percentile?

yeah, this language needs to be cleaned up to indicate that a long time might mean months or even longer

I think that there should be FOUR buttons to choose the fee, in addition to an edit box. Pressing a button will fill in the edit box with the appropriate value. Assuming that Gavin adds some client code to analyze the block chain and calculate the "median" expected transaction fee per kilobyte, these four buttons would be handy:

"Most transactions require a fee for quick processing. What priority do you want to give your transaction?"

Button: "Normal Priority" (fills in the edit box with the median fee)
Button: "High Priority" (fills in the edit box with double the median fee)
Button: "Low Priority" (fills in the edit box with half the median fee)
Button: "No Fee (may take a long time)" (fills in the edit box with zero)

I'm sure the language could be cleaned up and I'm sure there are a zillion alternate ways to scale the median for "low" and "high" but you get the idea. The user need only press a button to indicate the relative priority of the transaction.

Good job.
I don't know if you were expecting feedback, but I'll provide some if you don't mind

My first thought was that it's a pretty large dialog for such a simple question. I think that by default, only the top part should be shown - up to and including 'make this the default'. The rest should be optionally viewable by clicking something like 'show advanced'. It's useful if you know a little about how things really work under-the-hood, but the majority of users shouldn't have to ever know about, and aren't going to understand it if someone tried to explain. My benchmark for these things is 'would my dad understand?'

Having said that, I like the transaction statistics - but maybe for the default view, don't display number of inputs/outputs or transaction size. Secondly, maybe lay it out so that the values are aligned, like you would if calculating a sum on a piece of paper - so it makes it crystal clear how everything is calculated  eg

    1234        Payment amount
+     56        Transaction fee
----------
    1290        Total Payment
----------

    2000        Current Balance
-   1290        Total Payment
----------
      710        Final Balance after payment
----------

Also, I like the 'spam prevention measures' explanation - most people know what spam is, or at least, more people know about that than know about transaction inputs and outputs.

I thought I would inspire the developers, with a a mockup of a possible fee dialog when sending a payment, instead of the confusing one that only comes up when a fee is required.



The top line could change to "This transaction requires a minimum fee of xxx BTC due to spam-prevention measures (transaction contains payments below 0.01 BTC)" if applicable.
Additional information could be "This transaction would be eligible for no minimum fee in xxx blocks"

High priority bug:
https://github.com/bitcoin/bitcoin/issues/1714#issuecomment-13478408

Confusion:
https://bitcointalksearch.org/topic/exceeds-size-limit-129128
https://bitcointalksearch.org/topic/this-transaction-is-over-the-size-limit-34948

Currently: