bolt02: clarify tx_init_rbf must ensure conflict with all prior attempts

[SomberNight]

The current text is phrased in an ambiguous way.
This rephrases it without changing its intent.

I guess what is meant is:

MUST send tx_add_input with at least one input from each previous transaction construction attempt

For example, if

• the original tx1 attempt has inputs A and B,
• and then replacement tx2 has inputs B and C,
• then replacement tx3 should not use inputs C and D,

as tx1 and tx3 would not conflict. tx3 satisfies one interpretation of the current text: it shares at least one input it used in a previous attempt (C was used in tx2).

ref https://github.com/lightning/bolts/pull/1236/changes#r2833500599

[t-bast]

ACK d797241, thanks!

@jkczyz does that work for you?

[jkczyz]

The current text is phrased in an ambiguous way. This rephrases it without changing its intent.

I guess what is meant is:

MUST send tx_add_input with at least one input from each previous transaction construction attempt

For example, if

• the original tx1 attempt has inputs A and B,
• and then replacement tx2 has inputs B and C,
• then replacement tx3 should not use inputs C and D,

as tx1 and tx3 would not conflict. tx3 satisfies one interpretation of the current text: it shares at least one input it used in a previous attempt (C was used in tx2).

ref https://github.com/lightning/bolts/pull/1236/changes#r2833500599

Well, it can use C, but if it does it would have to use either A or B, too. And if it uses B, then it doesn't need to use C but could.

Where does D come into play?

[jkczyz]

I'd drop "for example" since it isn't really an example but in fact defining how to double spend all previous attempts.

[SomberNight]

It could be the case that some earlier attempts already (~deeply) conflict with the blockchain, as the node might have used some of the same UTXOs in other txs, in which case you don't need to send tx_add_input for any input of those earlier attempts.

EDIT: although in that case perhaps even my current suggested phrasing is not precise enough :)

[SomberNight]

Perhaps the intent is to disallow such risky cleverness... in which case I can keep it simple and just drop the "for example".

[SomberNight]

Well, it can use C, but if it does it would have to use either A or B, too. And if it uses B, then it doesn't need to use C but could.

Where does D come into play?

The current phrasing in master:

MUST send tx_add_input with at least one input that it used in previous
transaction construction attempts

My original reading of that was:

MUST send tx_add_input with at least one input that it used in some previous
transaction construction attempt

Clearly that is not what is meant, and that becomes implicitly clear when reading the next part of that sentence.
But I think it is a sensible reading and a potential implementation mistake to make.
The (A, B), (B, C), (C, D) example is just an example with that reading, which is unsafe.

Another reading of the text in master is:

MUST send tx_add_input with at least one input that it used in all previous
transaction construction attempts

which would mean that there needs to be a single specific sticky UTXO that is present in all attempts.
(which would be a reasonable and safe implementation!) However even that is too strict if the true goal is pairwise-conflicts. E.g. (A, B), (B, C), (A, C) is a safe example that lacks a sticky UTXO.

---

The intent of the PR is to rephrase the text so that it is less ambiguous.

Actually I came across the original PR when reading the optech newsletter, which paraphrased the text from master:

The PR also adds a requirement that both the senders of tx_init_rbf and tx_ack_rbf must reuse at least one input from a previous attempt, ensuring that the new transaction double-spends all prior attempts.

Now that phrasing is clearly incorrect. :) Then I saw even the original text in the spec is ambiguous.

I concede it is difficult to be concise and precise in English (as opposed to code) here.