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

Projects
None yet
8 participants
@harding
Member

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

This comment has been minimized.

Show comment
Hide comment
@sdaftuar

sdaftuar Dec 11, 2015

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?

Member

sdaftuar commented Dec 11, 2015

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

This comment has been minimized.

@amacneil

amacneil Dec 11, 2015

Perhaps add a clarification that all BIP68/BIP112 transactions will by definition now be opting into RBF?

@amacneil

amacneil Dec 11, 2015

Perhaps add a clarification that all BIP68/BIP112 transactions will by definition now be opting into RBF?

This comment has been minimized.

@dabura667

dabura667 Dec 13, 2015

nSequence of 0xfffffffe will not opt-in to RBF but will still be valid for BIP68/BIP112 (as it is not 0xffffffff)

@dabura667

dabura667 Dec 13, 2015

nSequence of 0xfffffffe will not opt-in to RBF but will still be valid for BIP68/BIP112 (as it is not 0xffffffff)

This comment has been minimized.

@sdaftuar

sdaftuar Dec 17, 2015

Member

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

@sdaftuar

sdaftuar Dec 17, 2015

Member

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

This comment has been minimized.

@petertodd

petertodd Dec 18, 2015

Contributor

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

@petertodd

petertodd Dec 18, 2015

Contributor

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

This comment has been minimized.

@sdaftuar

sdaftuar Dec 18, 2015

Member

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

@sdaftuar

sdaftuar Dec 18, 2015

Member

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

* Nodes may allow transactions containing this signal to be replaced in their mempools.
* The recipient or recipients of a transaction containing this signal may choose not to treat it as payment until it has been confirmed, eliminating the risk that the spender will use allowed replacements to defraud them.

This comment has been minimized.

@luke-jr

luke-jr Dec 12, 2015

Member

This erroneously implies non-signalling transactions are significantly safer.

@luke-jr

luke-jr Dec 12, 2015

Member

This erroneously implies non-signalling transactions are significantly safer.

This comment has been minimized.

@harding

harding Dec 12, 2015

Member

@luke-jr I don't think it implies that, but I agree that it doesn't stop people from making that inference. And why should it? There seem to be plenty of people who do think non-replaceable transactions are safer than replaceable transactions, and the purpose of this document isn't to challenge their preconceptions but rather to inform them about a new policy which will make creating transaction replacements easier.

@harding

harding Dec 12, 2015

Member

@luke-jr I don't think it implies that, but I agree that it doesn't stop people from making that inference. And why should it? There seem to be plenty of people who do think non-replaceable transactions are safer than replaceable transactions, and the purpose of this document isn't to challenge their preconceptions but rather to inform them about a new policy which will make creating transaction replacements easier.

This comment has been minimized.

@petertodd

petertodd Dec 18, 2015

Contributor

Agreed - it's not acceptable to give the impression that non-signalling txs are any safer.

In fact, I think it'd be good if we make it clear that opt-in RBF was created for political reasons, not technical.

@petertodd

petertodd Dec 18, 2015

Contributor

Agreed - it's not acceptable to give the impression that non-signalling txs are any safer.

In fact, I think it'd be good if we make it clear that opt-in RBF was created for political reasons, not technical.

This comment has been minimized.

@voisine

voisine Dec 19, 2015

Contributor

Non-signalling txs can potentially be safer. With non-signaling tx you potentially only need to trust miners not to reverse them if you can get miners to report that they've accepted them. With RBF, you must trust the signer not to reverse them while they remain unconfirmed. That's a technical difference.

@voisine

voisine Dec 19, 2015

Contributor

Non-signalling txs can potentially be safer. With non-signaling tx you potentially only need to trust miners not to reverse them if you can get miners to report that they've accepted them. With RBF, you must trust the signer not to reverse them while they remain unconfirmed. That's a technical difference.

This comment has been minimized.

@petertodd

petertodd Dec 19, 2015

Contributor

Miners are not in a position where they can provide those kinds of guarantees in a decentralized environment, and we should not be encouraging it.

@petertodd

petertodd Dec 19, 2015

Contributor

Miners are not in a position where they can provide those kinds of guarantees in a decentralized environment, and we should not be encouraging it.

This comment has been minimized.

@voisine

voisine Dec 19, 2015

Contributor

What about by broadcasting partial block solutions? This is a decentralized way to indicate how much hashing power is being expended attempting to mine any given transaction.

@voisine

voisine Dec 19, 2015

Contributor

What about by broadcasting partial block solutions? This is a decentralized way to indicate how much hashing power is being expended attempting to mine any given transaction.

This comment has been minimized.

@petertodd

petertodd Dec 19, 2015

Contributor

There aren't any incentive compatible partial block proposals yet; not relevant to the current ecosystem.

On 19 December 2015 09:54:25 GMT-08:00, Aaron Voisine notifications@github.com wrote:

+==Abstract==
+
+Many nodes today will not replace any transaction in their mempool
with
+another transaction that spends the same inputs, making it difficult
for
+spenders to adjust their previously-sent transactions to deal with
+unexpected confirmation delays or to perform other useful
replacements.
+
+The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy
+described here allows spenders to add a signal to a transaction
indicating
+that they want to be able to replace that transaction in the future.
+In response to this signal,
+
+* Nodes may allow transactions containing this signal to be replaced
in their mempools.
+
+* The recipient or recipients of a transaction containing this
signal may choose not to treat it as payment until it has been
confirmed, eliminating the risk that the spender will use allowed
replacements to defraud them.

What about by broadcasting partial block solutions? This is a
decentralized way to indicate how much hashing power is being expended
attempting to mine any given transaction.


Reply to this email directly or view it on GitHub:
https://github.com/bitcoin/bips/pull/261/files#r48095057

@petertodd

petertodd Dec 19, 2015

Contributor

There aren't any incentive compatible partial block proposals yet; not relevant to the current ecosystem.

On 19 December 2015 09:54:25 GMT-08:00, Aaron Voisine notifications@github.com wrote:

+==Abstract==
+
+Many nodes today will not replace any transaction in their mempool
with
+another transaction that spends the same inputs, making it difficult
for
+spenders to adjust their previously-sent transactions to deal with
+unexpected confirmation delays or to perform other useful
replacements.
+
+The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy
+described here allows spenders to add a signal to a transaction
indicating
+that they want to be able to replace that transaction in the future.
+In response to this signal,
+
+* Nodes may allow transactions containing this signal to be replaced
in their mempools.
+
+* The recipient or recipients of a transaction containing this
signal may choose not to treat it as payment until it has been
confirmed, eliminating the risk that the spender will use allowed
replacements to defraud them.

What about by broadcasting partial block solutions? This is a
decentralized way to indicate how much hashing power is being expended
attempting to mine any given transaction.


Reply to this email directly or view it on GitHub:
https://github.com/bitcoin/bips/pull/261/files#r48095057

This comment has been minimized.

@voisine

voisine Dec 20, 2015

Contributor

The cost is close to zero. If it's built into bitcoin-core and other mining software, then we have an incentive compatible solution since it would take additional effort to disable it. It's relevant to the RBF discussion, since RBF transactions preclude any future improvements to 0-conf safety that would make them practical in more situations.

@voisine

voisine Dec 20, 2015

Contributor

The cost is close to zero. If it's built into bitcoin-core and other mining software, then we have an incentive compatible solution since it would take additional effort to disable it. It's relevant to the RBF discussion, since RBF transactions preclude any future improvements to 0-conf safety that would make them practical in more situations.

Nodes and recipients may continue to treat transactions without the
signal the same way they treated them before, preserving the existing
status quo.

This comment has been minimized.

@luke-jr

luke-jr Dec 12, 2015

Member

They may also opt not to.

@luke-jr

luke-jr Dec 12, 2015

Member

They may also opt not to.

This comment has been minimized.

@harding

harding Dec 12, 2015

Member

Agreed; I think that's implied by the word "may" on line 26. Is there a specific text change you're advocating for here?

@harding

harding Dec 12, 2015

Member

Agreed; I think that's implied by the word "may" on line 26. Is there a specific text change you're advocating for here?

# Conveying additional suspicion about opt-in full-RBF transactions to the user or data consumer.
# Ignoring the opt-in transaction until it has been confirmed.

This comment has been minimized.

@luke-jr

luke-jr Dec 12, 2015

Member

IMO wallets should not treat these any differently.

@luke-jr

luke-jr Dec 12, 2015

Member

IMO wallets should not treat these any differently.

This comment has been minimized.

@harding

harding Dec 12, 2015

Member

I think the UX is really hard here. Unconfirmed transactions of any kind are insecure compared to even 1-conf transactions, however because most users mostly deal with reliable partners, they will only rarely ever have a transaction fail to confirm---so they are lulled into a false belief that unconfirmed transactions are fundamentally reliable.

Although I don't think opt-in full-RBF doesn't significantly changes the dynamics for serious double spenders, it does make it possible for people with less technical knowledge and fewer resources to execute successful double spends. That's a change from the current status quo, and I think it should be communicated to users.

However, I agree that we don't want to imply that wallets must do anything differently. If there's a phrasing change you have in mind, perhaps changing "should consider" to "may want to consider", I'd be happy to hear it.

@harding

harding Dec 12, 2015

Member

I think the UX is really hard here. Unconfirmed transactions of any kind are insecure compared to even 1-conf transactions, however because most users mostly deal with reliable partners, they will only rarely ever have a transaction fail to confirm---so they are lulled into a false belief that unconfirmed transactions are fundamentally reliable.

Although I don't think opt-in full-RBF doesn't significantly changes the dynamics for serious double spenders, it does make it possible for people with less technical knowledge and fewer resources to execute successful double spends. That's a change from the current status quo, and I think it should be communicated to users.

However, I agree that we don't want to imply that wallets must do anything differently. If there's a phrasing change you have in mind, perhaps changing "should consider" to "may want to consider", I'd be happy to hear it.

This comment has been minimized.

@voisine

voisine Dec 12, 2015

Contributor

@luke-jr Double-spending a non-RBF transaction (lets say with all inputs confirmed) does require more resources and is less likely to succeed than with RBF, wouldn't you agree? And if miners and pools in future were to communicate which transactions they have accepted into their block templates, and/or broadcast partial block solutions proving they've expended hashing power attempting to mine them, that would raise the cost and difficulty of a successful 0-conf double-spend even further.

I think we can solve the problem of 0-conf security well enough to make it practical for the majority of typical use cases.

@voisine

voisine Dec 12, 2015

Contributor

@luke-jr Double-spending a non-RBF transaction (lets say with all inputs confirmed) does require more resources and is less likely to succeed than with RBF, wouldn't you agree? And if miners and pools in future were to communicate which transactions they have accepted into their block templates, and/or broadcast partial block solutions proving they've expended hashing power attempting to mine them, that would raise the cost and difficulty of a successful 0-conf double-spend even further.

I think we can solve the problem of 0-conf security well enough to make it practical for the majority of typical use cases.

This comment has been minimized.

@luke-jr

luke-jr Dec 12, 2015

Member

@harding That still sounds too much like a recommendation.

@voisine It doesn't require more resources, and isn't much less likely to succeed if you do it right.

@luke-jr

luke-jr Dec 12, 2015

Member

@harding That still sounds too much like a recommendation.

@voisine It doesn't require more resources, and isn't much less likely to succeed if you do it right.

This comment has been minimized.

@voisine

voisine Dec 12, 2015

Contributor

@luke-jr to double spend a 0-conf with a high rate of success, you would need to broadcast your double spend directly to a large portion of hashing power while simultaneously getting the legitimate tx to the victim. If we assume the victim is listening to random nodes on the network, then this does seem to have a not-insignificantly lower chance of success than with RBF. Please disabuse me of this notion if I'm missing something. We want to accurately communicate the risks while keeping the user experience competitive with other payment methods to the greatest extent possible.

@voisine

voisine Dec 12, 2015

Contributor

@luke-jr to double spend a 0-conf with a high rate of success, you would need to broadcast your double spend directly to a large portion of hashing power while simultaneously getting the legitimate tx to the victim. If we assume the victim is listening to random nodes on the network, then this does seem to have a not-insignificantly lower chance of success than with RBF. Please disabuse me of this notion if I'm missing something. We want to accurately communicate the risks while keeping the user experience competitive with other payment methods to the greatest extent possible.

This comment has been minimized.

@luke-jr

luke-jr Dec 12, 2015

Member

If we assume the victim is listening to random nodes on the network,

This assumption does not usually hold. Furthermore, the legitimate tx could be tiny and quick to propagate the non-mining nodes, while the miners could receive large transactions that are slow to move beyond them.

Additionally, you are assuming a naive case of legitimate-vs-fraud competition. If an attacker simply spends the same coins with N merchants at once, all N transactions are legitimate and N-1 are guaranteed to lose out.

@luke-jr

luke-jr Dec 12, 2015

Member

If we assume the victim is listening to random nodes on the network,

This assumption does not usually hold. Furthermore, the legitimate tx could be tiny and quick to propagate the non-mining nodes, while the miners could receive large transactions that are slow to move beyond them.

Additionally, you are assuming a naive case of legitimate-vs-fraud competition. If an attacker simply spends the same coins with N merchants at once, all N transactions are legitimate and N-1 are guaranteed to lose out.

mines transactions using opt-in full-RBF semantics (sequence less than
(0xffffffff - 1)).
Opt-in full-RBF as a default mempool replacement policy among nodes

This comment has been minimized.

@luke-jr

luke-jr Dec 12, 2015

Member

Perhaps this ought to mention how nodes can disable the signalling (either to never-RBF or always-RBF)?

@luke-jr

luke-jr Dec 12, 2015

Member

Perhaps this ought to mention how nodes can disable the signalling (either to never-RBF or always-RBF)?

@luke-jr luke-jr assigned luke-jr and unassigned gmaxwell Jan 8, 2016

@luke-jr luke-jr changed the title from Add opt-in full-RBF signaling BIP to 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

BOLT 2,4: allow an error for HTLCs which expire too far away. (#265)
Fixes: #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