-
Notifications
You must be signed in to change notification settings - Fork 36.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Take the training wheels off anti-fee-sniping #6216
Take the training wheels off anti-fee-sniping #6216
Conversation
Now that the off-by-one error w/nLockTime txs issue has been fixed by 87550ee (75a4d51 in the 0.11 branch) we can make the anti-fee-sniping protection create transactions with nLockTime set such that they're only valid in the next block, rather than an earlier block. There was also a concern about poor propagation, however testing with transactions with nLockTime = GetAdjustedTime()+1 as a proxy for nLockTime propagation, as well as a few transactions sent the moment blocks were received, has turned up no detectable issues with propagation. If you have a block at a given height you certainly have at least one peer with that block who will accept the transaction. That peer will certainly have other peers who will accept it, and soon essentially the whole network has the transaction. In particular, if a node recives a transaction that it rejects due to the tx being non-final, it will be accepted again later as it winds its way around the network.
08a4245
to
db6047d
Compare
Rebased now that Travis is fixed. |
Trivial-code-change ACK. |
It is time. ACK |
concept ACK |
Untested ACK |
@jtimon FWIW this isn't actually a trivial change - the possible relay issue with txs right when a new block is broadcast is real. If I could get one more person confirming my logic/testing showing that it isn't a problem that'd be great. |
@petertodd But the change in the code is trivial (1 line apart from the documentation) and by that I mean that I trust my review enough that I don't think I need to test this. If I felt I need to test it I would have said ut ACK (or test it and say tested ACK). If you prefer, ut ACK. |
@jtimon Well, to be clear, imagine if this "trivial" change had a +1 in it, or if I hadn't gone to the trouble of fixing the (multiple!) off-by-one errors we've seen re: nLockTime in #6183 and #2342 - in Bitcoin it's common for seemingly trivial changes to actually have remarkably far-reaching effects. After all, if this really was a trivial change, I wouldn't have written a fifteen line git commit description! That said... one good thing about merging it at the beginning of the v0.12.0 development cycle, is that it's a change that's highly unlikely to lead to actual loss of funds, so we'll give the whole ecosystem plenty of time to find and fix the off-by-one type errors that are probably still out there in various wallets. (and in that sense, yeah, from just a loss-of-funds point of view I agree it's a trivial change, but knowing that requires a surprisingly good understanding of how the whole system works!) |
I'm not saying it is trivial to understand or make. I'm not disregarding
|
@jtimon Ah! Sorry, trivial to review is quite different than what I thought you meant. :) Thanks for clearing that up. |
utACK |
ACK. I can confirm that older versions (like v0.9.5) have issues with such transactions, just as expected: My bitcoin-qt-v0.9.5 shows them in the transaction tab but they don't appear in After applying this commit, |
@MarcoFalke Thanks! @laanwj Be good to get this merged and done with... |
utACK |
Please see #6595 (comment); perhaps we should consider improving the way we handle transactions that are invalid in the mempool during reorgs prior to merging this? |
@sdaftuar I don't think that particular issue should block this from being merged. |
Yea, I agree with @sdaftuar...#6595 kinda breaks this...it should be easy to fix though (#6595 (comment)) |
Looks like a reasonable concern; let's leave this unmerged until #6595 is resolved. |
Should be addressed by #6656 On 09/09/15 20:32, Peter Todd wrote:
|
@petertodd Where are we on this? |
looks like it's pending #6915 |
ping |
Can someone remind me why we're not also doing this for createrawtransaction? |
@gmaxwell Basically to avoid breaking things. Rather start with just wallet txs until this stuff is more well-known. |
Now that #6915 has been merged, which fixes the invalid txs in mempool issue, I feel comfortable merging this as well. Specifically, #6915 removes txs from the mempool after the reorg is finished, which means txs with nLockTime-by-height right at the edge of acceptance will no longer be removed during the reorg so long as the blockheight after the reorg doesn't go down. (an incredibly rare event!) |
ACK with nit; (sorry found the typo when I was about to merge.) |
Right now, |
Going to merge this, typo be damned, can be fixed later. |
db6047d Take the training wheels off anti-fee-sniping (Peter Todd)
ACK |
Now that the off-by-one error w/nLockTime txs issue has been fixed by 87550ee (75a4d51 in the 0.11 branch) we can make the anti-fee-sniping protection create transactions with nLockTime set such that they're only valid in the next block, rather than an earlier block. This makes the protection actually effective for its intended purpose.
There was also a concern about poor propagation, however testing with transactions with nLockTime = GetAdjustedTime()+1 as a proxy for nLockTime propagation, as well as a few transactions sent the moment blocks were received, has turned up no detectable issues with propagation. If you have a block at a given height you certainly have at least one peer with that block who will accept the transaction. That peer will certainly have other peers who will accept it, and soon essentially the whole network has the transaction. In particular, if a node recives a transaction that it rejects due to the tx being non-final, it will be accepted again later as it winds its way around the network.
I do not think this should go in v0.11 Rather by including this in the devel branch for v0.12 we have an opportunity to continually remind wallet authors and the like about how the anti-fee-sniping protection is supposed to work, and remind them that nLockTime = next block transactions should be accepted. My testing turned up only blockchain.info and Bitcoin Core itself as having issues with nLockTime at the limit transactions; hopefully by the time v0.12 is released these wallets will all be fixed.