-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
BIP 125: Opt-in Full Replace-by-Fee Signaling #261
Conversation
Thanks for writing this up! This looks good to me. @petertodd How should wallet authors be checking if a new transaction has an ancestor that has signaled RBF? That seems like something we ought to expose more easily via RPC somehow, perhaps? |
other uses of nSequence. Specifically, opt-in full-RBF is compatible | ||
with consensus-enforced locktime as provided in the Bitcoin 0.1 | ||
implementation, draft BIP68 (Relative lock-time using consensus-enforced | ||
sequence numbers), and draft BIP112 (CHECKSEQUENCEVERIFY). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps add a clarification that all BIP68/BIP112 transactions will by definition now be opting into RBF?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nSequence of 0xfffffffe will not opt-in to RBF but will still be valid for BIP68/BIP112 (as it is not 0xffffffff)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dabura667 If the leading bit is set, then that disables BIP68 semantics for nSequence. So anything that is using BIP68 necessarily has a 0 in the leading bit and therefore will also be opting-in to RBF.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sdaftuar BIP68 doesn't exist yet... As part of the soft-fork, the opt-in conditions for RBF can be modified if there's demand to do so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw I wasn't trying to imply any need to change; the behavior seems reasonable to me as-is (including taking into account the draft BIPs).
…n#265) Fixes: bitcoin#261 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@petertodd and I present the following proposed BIP describing opt-in full-RBF signaling, as requested in the 2015-12-03 bitcoin-dev IRC meeting.
Opt-in full-RBF has previously been discussed on the mailing list and support for it has been added to Bitcoin Core, so I humbly request the assignment of a BIP number from the BIP editor, @gmaxwell.
Upon receipt of the number assignment and fixing any initial issues found with this proposed text, I will post a copy of this BIP to the mailing list for interested developers to read.