Skip to content
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

Merged
merged 1 commit into from Jan 8, 2016

Conversation

harding
Copy link
Member

@harding harding commented Dec 11, 2015

@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.

@sdaftuar
Copy link
Member

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).

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?

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)

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member

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).

@luke-jr luke-jr assigned luke-jr and unassigned gmaxwell Jan 8, 2016
@luke-jr luke-jr changed the title Add opt-in full-RBF signaling BIP BIP 125: Opt-in Full Replace-by-Fee Signaling Jan 8, 2016
@luke-jr luke-jr merged commit b57eea4 into bitcoin:master Jan 8, 2016
luke-jr pushed a commit to luke-jr/bips that referenced this pull request Jan 20, 2018
…n#265)

Fixes: bitcoin#261

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
8 participants