BIP 125: Opt-in Full Replace-by-Fee Signaling #261

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

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

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

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

This erroneously implies non-signalling transactions are significantly safer.

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

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.

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.

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.

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.

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

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.

They may also opt not to.

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

IMO wallets should not treat these any differently.

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.

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

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

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.

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