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? |
There was a problem hiding this comment.
Perhaps add a clarification that all BIP68/BIP112 transactions will by definition now be opting into RBF?
There was a problem hiding this comment.
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.
@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.
@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.
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).
luke-jr
changed the title
…n#265) Fixes: bitcoin#261 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8 participants
@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.