diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 6b58d54..6ba527e 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -1765,7 +1765,7 @@ the closing transaction will likely never reach miners. `OP_RETURN` is only standard if followed by PUSH opcodes, and the total script is 83 bytes or less. We are slightly stricter, to only allow a single PUSH, but there are two forms in script: one which pushes up to 75 bytes, and a longer -one (OP_PUSHDATA1) which is needed for 76-80 bytes. +one (`OP_PUSHDATA1`) which is needed for 76-80 bytes. ### Closing Negotiation: `closing_complete` and `closing_sig` @@ -1819,6 +1819,7 @@ The sender of `closing_complete` (aka. "the closer"): - MUST set `fee_satoshis` to a fee less than or equal to its outstanding balance, rounded down to whole satoshis. - MUST set `fee_satoshis` so that at least one output is not dust. - MUST use the last sent and received `shutdown.scriptpubkey` to generate the closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction). + - MUST set `locktime` to the desired `nLockTime` of the closing transaction. - MUST set `signature` fields as valid signature using its `funding_pubkey` of: - `closer_output_only`: closing transaction with only the local ("closer") output. - `closee_output_only`: closing transaction with only the remote ("closee") output. @@ -1858,12 +1859,12 @@ The receiver of `closing_complete` (aka. "the closee"): - If the signature field is non-compliant with LOW-S-standard rule[LOWS](https://github.com/bitcoin/bitcoin/pull/6769): - MUST either send a `warning` and close the connection, or send an `error` and fail the channel. - MUST sign and broadcast the corresponding closing transaction. - - MUST send `closing_sig` with a single valid signature in the same tlv field as the `closing_complete`. + - MUST send `closing_sig` with a single valid signature in the same TLV field as the `closing_complete`. The receiver of `closing_sig`: - if `tlvs` does not contain exactly one signature: - MUST either send a `warning` and close the connection, or send an `error` and fail the channel. - - if `tlvs` does not contain one of the tlv fields sent in `closing_complete`: + - if `tlvs` does not contain one of the TLV fields sent in `closing_complete`: - MUST ignore `closing_sig`. - if the signature field is not valid for the corresponding closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction): - MUST ignore `closing_sig`. @@ -1881,9 +1882,9 @@ If one side has less funds than the other, it may choose to omit its own output, dust MUST be omitted, to ensure that the resulting transaction can be broadcast. The corner case where fees are so high that both outputs are dust is addressed in two ways: paying -a low fee to avoid the problem, or using an OP_RETURN (which is never "dust"). If one side chooses -to use an `OP_RETURN` output, its amount must be 0 to ensure that the resulting transaction can be -broadcast. +a low fee to avoid the problem, or using an `OP_RETURN` (which is never "dust"). If one side +chooses to use an `OP_RETURN` output, its amount must be 0 to ensure that the resulting transaction +can be broadcast. Note that there is usually no reason to pay a high fee for rapid processing, since an urgent child could pay the fee on the closing transactions' behalf. If rapid processing is desired and CPFP is @@ -1900,7 +1901,9 @@ signatures are simply ignored. When sending a new `shutdown`, we must receive a new `shutdown` from the remote node before sending `closing_complete`. This is necessary to be compatible with future taproot channels that use musig2 and need to exchange random nonces every time a transaction spending the channel -output is signed. +output is signed. Note that the remote `shutdown` doesn't need to be an explicit response to the +local `shutdown` that was sent: if both nodes concurrently send `shutdown`, they can exchange +`closing_complete` immediately after receiving the remote `shutdown`. If the closer proposes a transaction which will not relay (an output is dust, or the fee rate it proposes is too low), it doesn't harm the closee to sign the transaction. diff --git a/03-transactions.md b/03-transactions.md index 6dcc3bd..ddc6876 100644 --- a/03-transactions.md +++ b/03-transactions.md @@ -17,6 +17,7 @@ This details the exact format of on-chain transactions, which both sides need to * [Received HTLC Outputs](#received-htlc-outputs) * [Trimmed Outputs](#trimmed-outputs) * [HTLC-timeout and HTLC-success Transactions](#htlc-timeout-and-htlc-success-transactions) + * [Legacy Closing Transaction](#legacy-closing-transaction) * [Closing Transaction](#closing-transaction) * [Fees](#fees) * [Fee Calculation](#fee-calculation) @@ -349,7 +350,7 @@ The witness script for the output is: To spend this via penalty, the remote node uses a witness stack ` 1`, and to collect the output, the local node uses an input with nSequence `to_self_delay` and a witness stack ` 0`. -## Classic Closing Transaction +## Legacy Closing Transaction This variant is used for `closing_signed` messages (i.e. where `option_simple_close` is not negotiated). diff --git a/09-features.md b/09-features.md index 0125f0e..5aa651b 100644 --- a/09-features.md +++ b/09-features.md @@ -30,30 +30,29 @@ The Context column decodes as follows: * `9`: presented in [BOLT 11](11-payment-encoding.md) invoices. * `B`: presented in the `allowed_features` field of a blinded path. -| Bits | Name | Description | Context | Dependencies | Link | -|-------|-----------------------------------|-----------------------------------------------------------|----------|---------------------------|-----------------------------------------------------------------------| -| 0/1 | `option_data_loss_protect` | ASSUMED | | | | -| 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | IN | | [BOLT #2][bolt02-open] | -| 6/7 | `gossip_queries` | Peer has useful gossip to share | | | | -| 8/9 | `var_onion_optin` | ASSUMED | | | | -| 10/11 | `gossip_queries_ex` | Gossip queries can include additional information | IN | | [BOLT #7][bolt07-query] | -| 12/13 | `option_static_remotekey` | ASSUMED | | | | -| 14/15 | `payment_secret` | Node supports `payment_secret` field | IN9 | | [Routing Onion Specification][bolt04] | -| 16/17 | `basic_mpp` | Node can receive basic multi-part payments | IN9 | `payment_secret` | [BOLT #4][bolt04-mpp] | -| 18/19 | `option_support_large_channel` | Can create large channels | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) | -| 22/23 | `option_anchors` | Anchor commitment type with zero fee HTLC transactions | IN | | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful] | -| 24/25 | `option_route_blinding` | Node supports blinded paths | IN9 | | [BOLT #4][bolt04-route-blinding] | -| 26/27 | `option_shutdown_anysegwit` | Future segwit versions allowed in `shutdown` | IN | | [BOLT #2][bolt02-shutdown] | -| 28/29 | `option_dual_fund` | Use v2 of channel open, enables dual funding | IN | | [BOLT #2](02-peer-protocol.md) | -| 34/35 | `option_quiesce` | Support for `stfu` message | IN | | [BOLT #2][bolt02-quiescence] | -| 38/39 | `option_onion_messages` | Can forward onion messages | IN | | [BOLT #7](04-onion-routing.md#onion-messages) | -| 42/43 | `option_provide_storage` | Can store other nodes' encrypted backup data | IN | | [BOLT #1](01-messaging.md#peer-storage) | -| 44/45 | `option_channel_type` | Node supports the `channel_type` field in open/accept | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) | -| 46/47 | `option_scid_alias` | Supply channel aliases for routing | IN | | [BOLT #2][bolt02-channel-ready] | -| 48/49 | `option_payment_metadata` | Payment metadata in tlv record | 9 | | [BOLT #11](11-payment-encoding.md#tagged-fields) | -| 50/51 | `option_zeroconf` | Understands zeroconf channel types | IN | `option_scid_alias` | [BOLT #2][bolt02-channel-ready] | -| 60/61 | `option_simple_close` | Simplified closing negotiation | IN | `option_shutdown_anysegwit` | [BOLT #2][bolt02-simple-close] | - +| Bits | Name | Description | Context | Dependencies | Link | +|-------|-----------------------------------|-----------------------------------------------------------|----------|-----------------------------|-----------------------------------------------------------------------| +| 0/1 | `option_data_loss_protect` | ASSUMED | | | | +| 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | IN | | [BOLT #2][bolt02-open] | +| 6/7 | `gossip_queries` | Peer has useful gossip to share | | | | +| 8/9 | `var_onion_optin` | ASSUMED | | | | +| 10/11 | `gossip_queries_ex` | Gossip queries can include additional information | IN | | [BOLT #7][bolt07-query] | +| 12/13 | `option_static_remotekey` | ASSUMED | | | | +| 14/15 | `payment_secret` | Node supports `payment_secret` field | IN9 | | [Routing Onion Specification][bolt04] | +| 16/17 | `basic_mpp` | Node can receive basic multi-part payments | IN9 | `payment_secret` | [BOLT #4][bolt04-mpp] | +| 18/19 | `option_support_large_channel` | Can create large channels | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) | +| 22/23 | `option_anchors` | Anchor commitment type with zero fee HTLC transactions | IN | | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful] | +| 24/25 | `option_route_blinding` | Node supports blinded paths | IN9 | | [BOLT #4][bolt04-route-blinding] | +| 26/27 | `option_shutdown_anysegwit` | Future segwit versions allowed in `shutdown` | IN | | [BOLT #2][bolt02-shutdown] | +| 28/29 | `option_dual_fund` | Use v2 of channel open, enables dual funding | IN | | [BOLT #2](02-peer-protocol.md) | +| 34/35 | `option_quiesce` | Support for `stfu` message | IN | | [BOLT #2][bolt02-quiescence] | +| 38/39 | `option_onion_messages` | Can forward onion messages | IN | | [BOLT #7](04-onion-routing.md#onion-messages) | +| 42/43 | `option_provide_storage` | Can store other nodes' encrypted backup data | IN | | [BOLT #1](01-messaging.md#peer-storage) | +| 44/45 | `option_channel_type` | Node supports the `channel_type` field in open/accept | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) | +| 46/47 | `option_scid_alias` | Supply channel aliases for routing | IN | | [BOLT #2][bolt02-channel-ready] | +| 48/49 | `option_payment_metadata` | Payment metadata in tlv record | 9 | | [BOLT #11](11-payment-encoding.md#tagged-fields) | +| 50/51 | `option_zeroconf` | Understands zeroconf channel types | IN | `option_scid_alias` | [BOLT #2][bolt02-channel-ready] | +| 60/61 | `option_simple_close` | Simplified closing negotiation | IN | `option_shutdown_anysegwit` | [BOLT #2][bolt02-simple-close] | ## Requirements