We make the requirements for `announcement_signatures` more clear. It
is important that both nodes are able to generate the corresponding
`channel_announcement` to allow them to create a new `channel_update`
using the `short_channel_id` of the confirmed splice.
We insist on exchanging `splice_locked` before generating signatures
to ensure compatibility with taproot channels, where nonces will be
exchanged in `splice_locked` messages. This means that we need to
retransmit `splice_locked` on reconnection if `announcement_signatures`
hasn't been fully exchanged.
Importantly, after announcing a splice, nodes must still allow payments
that use the previous `short_channel_id`, because remote nodes may not
have processed the `channel_announcement` and `channel_update`s yet.
If one side sent `splice_locked` and the other side is ready to send
its own `splice_locked` while they are disconnected, this creates a
race condition on reestablish because `splice_locked` is retransmitted
after `channel_reestablish`, and other channel updates can be inserted
by the other node before receiving `splice_locked`. This will be an
issue for taproot channels, because nonces will be missing.
This race condition is described in more details in #1223.
We fix this race condition by adding TLVs to `channel_reestablish`
that provide information about the latest locked transaction. This
additional information also makes it easier to detect when we need
to retransmit our previous `splice_locked`.
Splicing allows spending the current funding transaction to replace it
with a new one that changes the capacity of the channel, allowing both
peers to add or remove funds to/from their channel balance.
Splicing takes place while a channel is quiescent, to ensure that both
peers have the same view of the current commitments.
We don't want channels to be unusable while waiting for transactions to
confirm, so channel operation returns to normal once the splice tx has
been signed and we're waiting for it to confirm. The channel can then
be used for payments, as long as those payments are valid for every
pending splice transactions. Splice transactions can be RBF-ed to speed
up confirmation.
Once one of the pending splice transactions confirms and reaches
acceptable depth, peers exchange `splice_locked` to discard the other
pending splice transactions and the previous funding transaction. The
confirmed splice transaction becomes the channel funding transaction.
Nodes then advertize this spliced channel to the network, so that nodes
keep routing payments through it without any downtime.
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`.
