Skip to content

Conversation

@cozz
Copy link
Contributor

@cozz cozz commented Nov 3, 2014

By default a minimized label is shown. It updates automatically, if smartfee has been chosen.
smartfeegui1
Smartfee not initialized -> pay minfee
smartfeegui2
Smartfee initialized
smartfeegui4
smartfeegui3
smartfeegui5
smartfeegui6
smartfeegui7
Fee removed from optionsdialog
smartfeegui9

@laanwj
Copy link
Member

laanwj commented Nov 3, 2014

Whoa, great work

src/wallet.cpp Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing this core default is probably accidental?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the default for the wallet only, not the relay fee minimum. (just pointing out; not saying it's intentional or not).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, its intentional, we have reduced the minrelayfee from 10000 to 1000 satoshis in 0.9. But this did not make transactions cheaper for the people, because the wallet still paid 10000 (which is good, to ensure everybodys txs get relayed). After the 0.9 release there were even blogs about "How to make your bitcoin transactions cheaper", they told people to start bitcoin with -mintxfee=0.00001000 (1000 satoshis). Back then this was a little dangerous, as your tx may not be relayed, but now its safe. This is just the second step of staging.

So, yes, we should definitely reduce the mintxfee to 1000 satoshis for the 0.10 release,
See #3305.

Bitcoin transactions are super cheap these days as we also removed the rounding, a 192 bytes transaction only costs 192 satoshis. Its actually 1 satoshi per byte.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - agreed, although it could be argued this needs to be in a separate change from the GUI changes, as it affects the RPC wallet as well

@morcos morcos mentioned this pull request Nov 3, 2014
@morcos
Copy link
Contributor

morcos commented Nov 3, 2014

Agreed. This is a really nice change! I like how the slider starts at normal and you have to consciously select a lower confirm target. If we end up using #5159 or something similar, you might want to change the uninitialized error message. It's possible to consistently not get an answer for a very low confirmation target like 1, because there is no fee that is reliably high enough and it seems kind of easy to not notice that's whats happening and you're accidentally putting a very low fee. Could the slider even snap back to the lowest confirm target which works?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like it might be nice to move this call outside of the loops in updateLabels and updateView since its just the same call over and over again for each input.

@cozz
Copy link
Contributor Author

cozz commented Nov 5, 2014

update: addressed inline comments

@morcos Yes, if our estimation code has an answer for 25, but not for 1, it would be confusing to tell the user in order to get 'fast' confirmation, you need to pay a lower fee than for 'normal'.
But that can be changed once we switch to the new estimation code. The current GUI is supposed to work with the current master.

@laanwj laanwj added the GUI label Nov 7, 2014
@laanwj laanwj added this to the 0.10.0 milestone Nov 7, 2014
@laanwj
Copy link
Member

laanwj commented Nov 13, 2014

Looks good to me!

A question: "Send as free transaction if possible" - doesn't this toggle apply to all three settings equally, Recommended Minimum and Custom? That feels more logical to me.

Some minor nits:

  • SmartFee → smart fee
  • at least → total at least (after Custom:)
  • Confirmation dialog should show the size of the transaction in kB, so that people can verify that the fee they selected is actually used

@luke-jr
Copy link
Member

luke-jr commented Nov 13, 2014

Grammatical corrections:

  • "1 block" should not be plural
  • "Send as free transaction if possible" should be "Send as gratis transaction if possible"; "free" means something else.

What is the difference between "Send as free transaction if possible" and "Minimum"? They sound like the same thing to me...

@cozz
Copy link
Contributor Author

cozz commented Nov 13, 2014

@laanwj Yes, I had that checkbox apply to all three, but then I realized that this is not possible with the current logic of CreateTransaction. Its not a problem, but it requires CreateTransaction to be redesigned again. If you want that, I can do this, I just did not, to avoid critical changes. In the current master, if you pay a voluntary fee, you never send free.
I also vote for changing it, because its kind of obvious.

@luke-jr I never heard gratis transaction before in bitcoinland. According to the dictionary, free can be used as synonym. I dont see a problem with it.
"Minimum" means to pay the minimum fee, "free" means to pay nothing. But if its not clear to you, it may also not be clear to other people. I can add a tooltip to the free checkbox mentioning "gratis".

@luke-jr
Copy link
Member

luke-jr commented Nov 13, 2014

@cozz "free transaction relay" has been used for nodes that don't perform IsStandard filtering of transactions. It's better to use unambiguous terms, even if you accept the newer redefinition of "free" to include "gratis".

If gratis is possible, it would always be the minimum. So what is the difference?

@gavinandresen
Copy link
Contributor

"gratis" is an obscure word. How about "zero-fee".

@cozz
Copy link
Contributor Author

cozz commented Nov 13, 2014

So lets replace "free" with "zero-fee" then.

About the other thing, I can see that "minimum" may seem to imply "zero-fee", but its not. If we move the free-checkbox below, to apply to all three, this should become clearer.

@luke-jr
Copy link
Member

luke-jr commented Nov 13, 2014

So what would "Minimum" do if you uncheck it? O.o

@cozz
Copy link
Contributor Author

cozz commented Nov 13, 2014

minimum is a radio button. you must select 1 of 3.

@luke-jr
Copy link
Member

luke-jr commented Nov 13, 2014

I mean selected Minimum and unchecked "zero-fee" - it doesn't make sense... if zero-fee is possible, it's always the minimum.

@morcos
Copy link
Contributor

morcos commented Nov 14, 2014

Personally I think we're not addressing the biggest issue. Given that you are selecting the fee rate you want to pay before your inputs are selected (unless you're using coin control) you have very little control on the total fee you're paying. I think before we could have a really effective GUI for paying fees we'd have to address #4082. There is a complicated interaction between the inputs you use, the speed you desire for confirmation, and the fee you're paying. It makes a lot of sense to use your small inputs when you don't care about speed (b/c you have to use a lot of inputs for the same value tx, but get to pay less per input used) and to use your big inputs when you do care about the speed of your tx (since each input used has a high fee per / kb cost). This is without even taking into account coin age to use your old coins to take advantage of priority when it saves you the most in fees. But I don't know if optimizing all of this falls under the purview of the core wallet.

@cozz
Copy link
Contributor Author

cozz commented Nov 14, 2014

@morcos yes, I agree to what you say, there is a lot of room for improvement.
But lets not make more of this pull request than what its supposed to do.

The point is that the current fee/priority selection, selects something thats confirms. And floats. Thats good. Even if way too high in some edge cases, its better than the hardcoded fee/priority values we had before. And people who know better than our smartfee, they can use coin control/custom fee.

Of course its bad, that sophisticated users may end up paying less fee than others in bitcoinland, but I guess there is not much we can do here in regards to the 0.10 release.

@cozz
Copy link
Contributor Author

cozz commented Nov 15, 2014

update:

  • make minfee a checkbox as part of custom
  • move zero-fee checkbox below to apply independent of "recommended" or "custom"
  • nits

Added as separate commit for easier review. Should be squashed before merge. There were less changes to CreateTransaction required than
I thought, but I introduced a "-sendfreetransactions" (default=false) command line parameter to have bitcoind behavior compatible.

smartfeegui10
smartfeegui11
smartfeegui12
smartfeegui13

@luke-jr
Copy link
Member

luke-jr commented Nov 15, 2014

When this says "to be confirmed within 25 blocks", what metric is it using for confirmation? The usual 6 blocks? If it's just 25 blocks to be mined, perhaps "to begin confirmation within 25 blocks" would be better.

It might be desirable to see the Smart-Fee estimate for mining/confirmation time even for Custom fee selection (move it outside the options?).

What does the new "Minimize" button do, since we still have the checkbox under Custom?

Does this under any conditions allow sending with a lower fee than the "minimum"? We still don't have a mechanism for getting "unstuck" :/

@morcos
Copy link
Contributor

morcos commented Nov 15, 2014

I think having the "zero-fee" option apply to both is confusing, because I think it still uses the txConfirmTarget you set in the top section. I like the idea of having a top section which uses smart fee-logic (and has the zero-fee checkbox) and a bottom custom section (which either has the min-fee checkbox or makes it easy to set the min fee as the custom fee).

@cozz
Copy link
Contributor Author

cozz commented Nov 15, 2014

@luke-jr
I can change it to "included in a block within 25 blocks".

Our estimation API is supposed to take a target (like 11 blocks) and returns the fee, not the other way round. Also the estimations are not really good at the moment. As morcos said, even if you just pay the minfee, you get almost always included after 8 blocks. But our estimation code tells you 25 blocks, for a even higher fee. So I'll leave that for the future, once our estimations are better.

Minimize button minimizes, see initial screenshots, the button is not new.

Its not possible to send a non-sense (like 1 satoshi): 0 < fee < minRelayFee

@morcos yes, but txConfirmTarget is set to 25 internally for custom. I think thats fine. So you can choose to send a free transaction for both, recommended and custom.

@cozz
Copy link
Contributor Author

cozz commented Nov 15, 2014

ok, changed to "Estimated to begin confirmation within x block(s)."

@laanwj
Copy link
Member

laanwj commented Nov 18, 2014

ACK after squash
commithash 6bfa31feae0c731ab52777bafdd3cbda41522d76
https://dev.visucore.com/bitcoin/acks/5200
(see below)

@cozz
Copy link
Contributor Author

cozz commented Nov 18, 2014

squashed

src/wallet.cpp Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought you moved this change to #5209 so that it has its own discussion. You should remove it here.

@cozz
Copy link
Contributor Author

cozz commented Nov 19, 2014

@laanwj ok, I just rebased and skipped that commit

@laanwj laanwj merged commit c1c9d5b into bitcoin:master Nov 19, 2014
laanwj added a commit that referenced this pull request Nov 19, 2014
c1c9d5b [Qt] Add Smartfee to GUI (Cozz Lovan)
e7876b2 [Wallet] Prevent user from paying a non-sense fee (Cozz Lovan)
ed3e5e4 [Wallet] Add global boolean whether to pay at least the custom fee (default=true) (Cozz Lovan)
0ed9675 [Wallet] Add global boolean whether to send free transactions (default=true) (Cozz Lovan)
@rebroad
Copy link
Contributor

rebroad commented Dec 11, 2014

This doesn't seem to work well with #5159 currently...

@cozz
Copy link
Contributor Author

cozz commented Dec 11, 2014

The GUI slider just shows what estimatefee returns. You can test the estimatefee rpc-call to check.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants