paytxfee behavior changed without warning #7633
Comments
|
It has had that meaning for as long as I can remember.
|
|
Well that's pretty darned surprising: |
|
Ah, the transaction size may have been rounded up to a multiple of
kilobytes in the past.
|
|
I don't think so. It always sent fees exactly equal to the paytxfee config variable |
|
I can assure you that the paytxfee configuration parameter has been a value
in BTC/kilobyte at least since 0.3.15, and has always been advertized as
such.
In earlier versions however the size of a transaction was rounded up to a
multiple of 1000, as that is how the mining code used to sort transaction
years ago. In 0.12, it was finally changed to the accurate formula that
works at an accuracy per byte. If the paytxfee value was always exactly
what you saw as resulting fee, that must mean all your transactions were 1
kB in size.
I do agree this should have been mentioned in the release notes.
|
|
It's a breaking change. It should have been announced and documented. Very frustrating. |
|
Put another way, it's not a breaking change. It's evidence of a missing set of tests. |
|
Also, people need to be notified of this. I doubt I'm the only person affected, with transactions stuck in limbo hoping that the average block size drops a bit so that these get included. There's a 16,000 unconfirmed tx backlog right now. |
|
The description in issue is incorrect. Could you revise it based on the discussion here, since you've now promoted it? |
|
Done! |
|
same issue with me #7634 |
|
@sipa is correct; |
|
OK. Thank you @sipa and @MarcoFalke for clarifying the nature of this issue. If either of you or @gmaxwell is unsatisfied with the current issue description, would you please suggest how to improve it? |
|
Is there any way to communicate this even though the release notes are impossible to change now? (E.g. add a section to the 0.12.1 release notes?) |
|
I agree that this change of behavior should have been documented in the release notes, as it will result in - on average - in paying less fee if
I cannot find the commit/pull request that removed the rounding. Anyone?
I agree that the wallet fee logic doesn't have very good testing. |
What would help a lot, I think, would be to have documentation for the fee system - e.g. a user manual that describes how it is supposed to work, what the expectations should be for the fee computation. There are a lot of knobs, and it is far from clear from the This causes both developers and users to make mistakes in that regard. |
|
@laanwj > I cannot find the commit/pull request that removed the rounding. Anyone? Is this it?
Edit: incidentally I only yesterday noticed that I had |
|
Or ecc7c82? |
In case you mean "removed the rounding in 0.12", it is a couple of pull request: #6649 (not merged), #6708 (not merged), #7103 (merged), #7096 (merged but not related to this issue, as it was rebased onto 7103)
I tried to do exactly this in the release notes. Unfortunately I did not receive any feedback on the content, but I am happy to extend this. Maybe the website is a better place to curate such documentation? |
Timeline:
So all in all, rounding was already disabled in 0.10. It makes sense for this not to be mentioned in the release notes for 0.12. However what seems to have changed multiple times is the behavior for small transactions, due to fPayAtLeastCustomFee. This should have been mentioned.
I don't really mind where, could just be some file in |
This reverts commit 7d0a05f. This change in fee behavior was unexpected to users and shouldn't be in a backport release. See detailed timeline in #7633 (comment) for details. People can upgrade to 0.12 if they want this new behavior.
|
Reverted these changes on the 0.11.x branch, so that they're not inadvertently imported there:
I take this back, actually we did have to update the tests for this, see #7103 (a775182). So it isn't a testing problem, just a documentation one. |
|
Maybe a more permanent solution to the whole fee problem would be to simplify the transaction creation into preparesendfrom (because accounts are the only "off-chain" solution working today)/preparesendto that returns the transaction so that the user can see how much the total cost is going to be, then submittransaction that actually sends the transaction. All in easy to read JSON instead of raw hex. Hiding the transaction fees is confusing users and developers! |
|
@tinspin Well, you can already do that... with |
|
Yes but the raw stuff is a bit, how can I put this, offputting. Specially when you are dealing with real money. Edit: ok fundrawtransaction really helps alot... and this did to: Even better: But I'm surprised you can't know how large a transaction will be in bytes in advance?!
You need to be able to put a fixed fee on a transaction in advance if the system is supposed to be usable?!
Ok, I get it! So it has to be http://bitcoin.stackexchange.com/questions/24516/bitcoind-multisig-and-the-default-account Ok, nm, I have to build my own account stuff or use sendfrom and suffer from the fee problem. Or I hack my bitcoind to either take a fixed fee on sendfrom or I add a sendrawtransactionfrom method... Edit; I tried looking at the code and it seems sendfrom uses a completely different implementation than sendrawtransaction? Edit 2: #7729 but labels do not keep track of balances which is what we need accounts for. |
|
Dam. Is there a way to with out reverting back to v11 to set a fixed fee amount ? |
|
There never ever was an option for an absolute fee amount. What 0.11 and
before had, was fee per kilobyte with the size rounded up to at least one
kilobyte.
Relying on that being an absolute fee is just as wrong as assuming the
currently behaviour results in an absolute fee, just less frequently
visible.
If you need to predict the total fee, use the raw transaction API to
inspect it before signing and sending.
|
|
Hmm that's just not an option right now, I have an upstream system written to work with what ever version of core we had 4 years ago. It deducts a set fee before sending the transaction and expects that to be the fee. I need a way to set a default fee, with out re-writing the upstream system to play whit transactions and its breaking a live system now by setting the fees too low... If I remember correctly back then there was a version of core when the fee was actually a fixed value. |
|
I'm telling that is not the case. It was pay per kilobyte, rounded up to kilobytes. Your upstream system makes incorrect assumptions, fix them. |
|
Yeah well, however it was doing. re writing the upstream system is just not a feasible option right now. Will have to push it back to v11 for the moment. |
|
@AbelGO If you just want to pay a fixed fee, regardless of the size of
the transaction, probably the only way to do this is to use the raw
transaction interface. (Though, for obvious reasons, not taking the
size of the transaction into account when calculating the fees, is not
advised)
|
|
When I get the chance I will look as some other apis. Ideally you want to give your end user the option of deciding what fee they want to pay. But you have the difficulty of not being able to provide any certainty to your end user as you cant calculate that with out first building the transaction first. The other issue is dealing with the average end user. Some are not going to accept that there 1c transaction is going to cost more than there $1000 transaction because its ... "bigger" What you really want in terms of a API is to provide a simple, Send XXXX amount with fee of YYYY. An end users wants to know how much something will cost them before they do it. |
|
An API to send amount X with fee Y makes no sense at all, as you can't predict the size of the transaction. What matters to the network is the fee/byte of the transaction. If the transaction to send X ends up being
unexpectedly large, a fixed fee Y may make it very slow to confirm or unacceptable to the network entirely.
What does make sense is ask the user whether to want to send quickly or slowly, then build a candidate transaction with the estimated feerate for that speed, and then let the user accept the resulting fee or not before sending. And that's exactly what the raw transaction API offers you.
|
|
Yeah I get that this is part of the nature of the design of the system. This problem is while it makes no sense to "the network" and is understandable to a developer. Its still something a novice end users wants and requests. The average user on my site wouldn't know the difference between a KB and a kb, and they don't know how many "blocks" they want there transaction confirmed in. They just want to know what it costs. This is one of the many disconnects that stops bitcoin becoming more mainstream. An API that thinks like the end user can help that. But yeah I get it. |
|
This looks like a really major problem, I have transactions from my local exchange have remained unconfirmed for nearly a week. The number of unconfirmed transactions is climbing at an alarming rate: |
That's just how the system works: fees do not depend on amounts sent but on tx size. It may be counter-intuitive for people used to legacy systems, but it is actually an advantage in Bitcoin and we should simply educate users about it.
You can present them only with the total fee before signing as suggested by sipa.
You should try higher fees, maybe consider using opt-in RBF. But this is not for technical support. I suggest IRC, maybe the bitcoin-discuss mailing list. |
|
|
Just got caught with my pants down. Created a transaction in a pinch; |
|
Closing this now. I think improved our process in the last two years to do a better job at documenting such changes in the release notes. Hopefully this will not happen again. |
and others
(updated with new information)
Calculation of the transaction fee when "paytxfee" is set has changed, without announcement or documentation.
Per @sipa :
In earlier versions however the size of a transaction was rounded up to a multiple of 1000, as that is how the mining code used to sort transaction years ago. In 0.12, it was finally changed to the accurate formula that works at an accuracy per byte. If the paytxfee value was always exactly what you saw as resulting fee, that must mean all your transactions were 1 kB in size.In bitcoin.conf, I had
paytxfee=0.0001In 0.11, that meant that BTC 0.0001 would be added to every outbound tx as a fee.
in 0.12, it means every tx will have added to it a fee of BTC 0.0001 per kilobyte
This is not documented in the release notes. As a result of this, I've got 3 days worth of spend transactions caught in unconfirmed limbo, having gone out with fees like 0.00002260 instead of 0.0001.
The text was updated successfully, but these errors were encountered: