As pointed out by @TheBlueMatt, we can greatly simplify the protocol
by removing the `shutdown` exchange entirely. The only piece of data
nodes must remember is the last script their peer sent. This can be
found in the last received `closing_complete`, or in `shutdown` if
`closing_complete` was never received. This doesn't even need to be
persisted, because on reconnection nodes will exchange `shutdown`
again with the last script they want to use for their output.
By doing that, the protocol becomes a trivial request/response protocol
where nodes send `closing_complete` and expect `closing_sig` back. This
creates a race condition when both nodes update their script at the same
time, but this will be extremely rare so we can simply resolve it by
reconnecting.
This protocol is compatible with taproot channels, with the following
additions:
- when sending `shutdown`, nodes will include two random nonces:
- `closer_nonce` that will be used in their `closing_complete`
- `closee_nonce` that will be used in their `closing_sig`
- when sending `closing_complete`, nodes will include a new random nonce
for their next `closing_complete` (`next_closer_nonce`)
- when sending `closing_sig`, nodes will include a new random nonce for
their next `closing_sig` (`next_closee_nonce`)
This ensures that nodes always have a pair of random nonces for their
next signing round.
It was previously unclear whether a node could send `shutdown` and
`closing_complete` immediately after that whenever RBF-ing their
previous closing transaction. While this worked for non-taproot
channels, it doesn't allow a clean exchange of fresh musig2 nonces
for taproot channels. We now require that whenever a node wants to
start a new signing round, `shutdown` must be sent *and* received
before sending `closing_complete`.
We always set `nSequence` to `0xFFFFFFFD`, but each node can choose the
`nLockTime` they want to use for the transactions for which they are
paying the fees.
Bitcoin Core version 25+ will not broadcast transactions containing
`OP_RETURN` outputs if their amount is greater than 0, because this
amount would then be unspendable. We thus require that the output
amount is set to 0 when using `OP_RETURN`.
We don't care, as long as it's RBF-able. This will be nicer for
Taproot when mutual closes are otherwise indistinguishable from normal
spends.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Make it clear why the OP_RETURN restrictions have two forms.
- Cross-reference existing dust threshold
- Lots of typo fixes
- Don't set closer_and_closee if we're larger/equal, and closee is dust.
- Remove Rationale on delete zero-output tx hack.
This gets around "but both our outputs are dust!" problems, as
recommended by Anthony Towns.
I hope I interpreted the standardness rules correctly (technically,
you can have multiple pushes in an OP_RETURN as long as the total is
under 83 bytes, but let's keep it simple).
Add an explicit note that "OP_RETURN" is never considered "uneconomic".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If both are dust, you should lowball fees. The next patch adds OP_RETURN
as a valid shutdown scriptpubkey though if you really want to do this.
This also addresses the case where people send a new `shutdown` with a *different* scriptpubkey. This could previously cause a race where you receive a bad signature (because it hasn't received the updated shutdown), so we ignore these cases.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The shutdown section says:
```
- MUST NOT send multiple `shutdown` messages.
```
But the reconnection section says:
```
- upon reconnection:
- if it has sent a previous `shutdown`:
- MUST retransmit `shutdown`.
```
So clearly, remove the former.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit doesn't change the logic at all, it simply:
- removes `realm` from onion test vector
- cleans-up markdown formatting and indents
- fixes typos and missing parenthesis
- consistently uses `_` instead of `-` for field names
- fixes math formatting (including changes from #1169 and #1158)
Sure, it's used to derive a secret for blinding, but it's also used to derive the key
for encrypted_recipient_data. It's not used as a blinding factor *directly*.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This ties it together, saying what to use as associated data, blinding, and what to do on failure.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'bolt_2__set_an_initiator_in_quiescence.patch':
BOLT #2: Set an initiator in quiescence.
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'option_quiesce__feature_to_support_stfu_method.patch':
option_quiesce: feature to support stfu method.
In practice, sftu is useless unless you have something (e.g. channel_upgrade)
which uses it, but adding a feature is best practice IMHO.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a follow-up to https://github.com/lightning/bolts/pull/1092
that fixes the following issues:
- fix a few typos
- remove non-zero-fee anchors test cases
- remove `remote_pubkey` rotation
Advertized as supported by all but 6 nodes (and those can no longer
route payments since people only send the modern onion these days)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These still have names and numbers, since they appear in `channel_type`. They are somewhat tangled with each other, so let's tie them together as assumed.
option_data_loss_protect is advertized by all by 11 nodes(*), and option_static_remotekey all but 16 nodes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[* there are 449 three-year old LND nodes which advertize `2200` as their features, which have already been trimmed from most gossip for not having htlc_maximum_msat in their channel_updates]
Moved up some rationale from the Rationale section and added a
bit of clarification to when you'd want to close/cancel an open.
Reported-By: @morehouse
`tx_abort`'s structure comes from the `warning`/`error` messages,
but we failed to port over the rationale/rules for the `data` field.
Suggested-By: @morehouse
If we only store state when sending `tx_signatures`, there are cases where
we cannot reconcile states if a disconnection occurs during the signing
steps: one side will have sent `tx_signatures` and thus must wait for the
transaction to be spent or double-spent, while the other side has already
forgotten that channel because they haven't sent `tx_signatures`.
This is fixed by storing state when sending `commitment_signed`, and
adding a `next_funding_txid` field to `channel_reestablish` to ask our
peer to retransmit signatures that we haven't received.
This issue is non-trivial and worth mentioning, otherwise implementations
may forget to handle this which would result in an easy way of attacking
node's on-chain liquidity, creating a large opportunity cost.
Prior versions of the v2 dual-funding protocol assumed a 'minimum fee'
payment for any witness stack of any input, as a way to simplify fee
checks.
The suggested min feerate didn't make sense for taproot spend paths etc;
instead we remove this check entirely.
While dual funding only needs unsigned funding amounts, other protocols
that leverage interactive-tx may use signed funding amounts, for example
to take funds out of an existing channel (splice-out).
It is thus more future-proof to use signed amounts in `tx_init_rbf` and
`tx_ack_rbf`.
This commit adds the interactive transaction construction protcol, as
well as the first practical example of using it, v2 of channel
establishment.
Note that for v2 we also update the channel_id, which now uses the hash
of the revocation_basepoints. We move away from using the funding
transaction id, as the introduction of RBF* makes it such that a single
channel may have many funding transaction id's over the course of
its lifetime.
*Later, also splicing
Prior wording of the description of this parameter left room for
ambiguity around whether it capped the total value offered by both
channel peers combined or if it was solely capping the total value
of HTLCs offered by the remote.
Since "reject" isn't defined anywhere in the spec and "fail" does
have a definition laid out in BOLT1 that includes special
provisions for channels that have not yet been established, BOLT2
is amended to clarify the requirements for the receiver of
`accept_channel`
