Transaction confirm target needs to be settable when sending #4866

laanwj commented at 6:55 AM on September 8, 2014: member

Currently the transaction confirm target - how many blocks to aim for until confirmation - is taken from a global setting nTxConfirmTarget (settable with -txconfirmtarget).

This setting should be settable in the GUI
But even more important: it needs to be possible to deviate from this per transaction. A donation may have very little priority, and it'd be a pity to pay more fees than necessary, but an urgent payment would have high priority

I find the current automatic fee determination very opaque from a user angle. There needs to be a way to gain more insight into what the fee computation is doing and why a certain fee was chosen

laanwj added the label GUI on Sep 8, 2014

laanwj added the label Wallet on Sep 8, 2014

laanwj commented at 9:09 AM on September 8, 2014: member

A possible idea would be to show the user a table, either before submitting the transaction or after, where they can select their fee based on estimated confirmation time:

Est. confirmation time	Fee
10 minutes	xxx.xxx BTC
20 minutes	...
...	...

laanwj added this to the milestone 0.10.0 on Sep 8, 2014

cozz commented at 4:56 AM on October 25, 2014: contributor

I have thought about on how to bring this to the GUI. After all, I cannot think of something which I consider as an improvement for the user. I have several concerns here:

most important, smartfee can not tell the minFee. smartfee just recommends what other people are paying. Even if you set -txconfirmtarget to 25, it is higher than the minFee. Me, as a "smart" user,
I know that the minFee is 1000 per kb, so I just look at the daily transaction volume, then I know that sending the minFee is just fine. For example estimateFee(25) was returning 5081. Then I sended a low-priority transaction with only 300 satoshis in fee. (txsize < 300 bytes). Guess how long it took to confirm? 8 minutes. So smartfees recommendation, calling it with 25, in this case was not so smart. I wouldnt recommend people to use smartfee, instead I would recommend: "Ignore smartFee, as long as there is enough space in the blocks, always only send the minFee of 1000/kb" One of the most important questions to users is, What is the minFee? smartFee doesnt know.
smartFee estimations are not inaccurate, they are just wrong. In the example above smartFee was telling me

"If you pay 44444/kb it will take 1 block to confirm"

"If you pay 5081/kb it will take 25 block to confirm"

Well, I paid 1000/kb and it took 1 block to confirm. (300 for a <300 bytes transaction)
I am not convinced by the bucket-algorithm: I added a tab which shows the buckets in the debug-window (the first row shows result of estimatefee(x)):

If you ask me, all buckets look kinda the same. So we are claiming, we can predict how much you have to pay to get confirmed in e.g. 13 blocks, from buckets which look all the same?
Even if all miners would set their minFee to 1 satoshi, smartFee would still recommend what other people are paying, regardless of miners minFee setting.
smartFee does not know, whether there is lots of space in the blocks or not. But in order to be an actually smart smartFee, we would need to know.
Unrelated to smartfee: we cant even show an absolute fee in the gui, even if we know the inputs and outputs. Showing only a per kb value to the user is more confusing than helping. Thats bitcoin design, but it doesnt help, when thinking about the GUI feature: "choose fee per transaction"

I am not claiming to know better and really appreciate the work being done on smartFee, but after all I think its trying to solve something which cant be solved with bitcoins current design.

For now, I would rather remove the estimations from 1 to 25 completely and only have an estimateFee() that answers the question "How much to get in now for sure?". At least this can be used for a floating free-priority-threshold as we already do.

laanwj commented at 6:31 AM on October 25, 2014: member

@cozz Thanks for looking into this.

The reason I'd like to give the user some control and transparency over the fee on a per-transaction basis is that the estimation for -txconfirmtarget=1 can be quite high! And users may not always care at all about fast incorporation of their transaction into blocks, so the fee is essentially wasted. And this gives Bitcoin an 'expensive' name, even though it doesn't have to be (but now you have to fiddle with command line arguments to avoid this).

Adding the estimates to the debug window is a nice idea, at least it provides some more transparency into what is happening, for developers. That's a step forward.

TBH: I personally used -txconfirmtarget=10000 and it still confirmed in 10-15 minutes.

laanwj commented at 6:41 AM on October 25, 2014: member

Unrelated to smartfee: we cant even show an absolute fee in the gui, even if we know the inputs and outputs.

Indeed - this is a complicated because adding fees may add further inputs, which increases the necessary fee again.

Personally I'd prefer transparency here too, to let the user know when he's generating a very large transaction (in bytes). After all the data size is what you're paying for when you send a transaction. Maybe we could show some accounting for that in the 'confirm' window... People understand having to pay for data in other contexts, so it would give at least some clue at how the client comes up with a certain number, that it doesn't look completely random.

gavinandresen commented at 1:23 PM on October 26, 2014: contributor

At the risk of sounding like a broken record: @cozz: "Well, I paid 1000/kb and it took 1 block to confirm. (300 for a <300 bytes transaction)" Are you sure it got confirmed because of fee and not priority?

Even if it was 0-priority, you can get lucky-- there is at least one miner prouducing ~1MB maxsize blocks, if he happens to produce a block just before or after you send a low-fee transaction it will confirm very quickly.

Alex Morcos is working on improved fee estimation code that uses a different approach (and is running a real-world, send-a-bunch-of-transactions-and-see-how-long-they-take-to-confirm experiment with his code and the current code to compare which is better).

cozz commented at 11:29 PM on October 26, 2014: contributor

I am sure that coincontrol said "lowest", but I didnt do the math, sure I got a little lucky with that transaction.

It did another test, sending 2 transactions at the same time, one with 40000/kb, one with 1000/kb. The first was confirmed within 1 block. The second within 3 blocks, block got orphaned, confirmed again within another 3 blocks (according to blockchain.info). So again smartfees estimation was a little off.

Smartfees estimation implies, that if you only pay the minfee, your transaction will take more than 25 blocks to confirm. With the current transaction volume, from my tests, this is not really true.

The way I see this, is that our estimation code works better the closer we get to max out the blocks.

The problem I have with the code is, that it doesnt tell the user, when its safe to just send the minfee. (Because it doesnt know and we are only basing our decision on what other people are paying)

But after all, I just want to help development here and not do the opposite.

The estimations are very vague, but at least they seem to be able to correctly differ between

"get confirmed now"
"get confirmed",
"get confirmed probably not so quick/maybe never" (hardcoded minfee)

Initially I was thinking, that if the fee-slider ends before the minfee, it doesnt make sense to bring this to the GUI, but if we have a checkbox "pay the minfee, but use at own risk" I would be fine with this.

I am unsure myself, about a good way to put this in the GUI. I just would like to get the minfee in somehow (if possible).

Just clicked an ugly mockup screenshot together, what do you think of the content? I thought maybe put this in the sendcoinsdialog, similar to where the coincontrol features are. We could make this fee-setting show/hidable, so that you have full space for the recipients. Maybe move the minfee-disclaimer to the tooltip, and just say (Warning: read the tooltip!!)

For default, I would say estimatefee(25)=normal, not estimatefee(1).

I could also replace normal with "Within 25 blocks" and fast with "Within 1 block". But then again 25 is catch-all, so unsure about claiming that it will confirm in 25 blocks for sure.

If we are sure, that our estimations are accurate, it would be easy to say in the slider 1 block, 2 blocks, ... 25 blocks. smartfee4

laanwj commented at 8:59 AM on October 27, 2014: member

@cozz I like that mockup. Indeed it doesn't make sense to really precise in statements (as it is an estimate), though in addition to the opaque slider from normal to fast it could say something like "estimated to be within N blocks".

cozz commented at 2:10 PM on October 27, 2014: contributor

ok, so I am going to work on this anytime soon.

laanwj commented at 10:18 AM on November 19, 2014: member

Closing as #5200 addresses this. Thanks @cozz.

laanwj closed this on Nov 19, 2014

DrahtBot locked this on Sep 8, 2021