Skip to content

Commit 7f85200

Browse files
t-bastt-bast
committed
Fix @tnull's comments
Clarify strict `shutdown` exchange requirements and fix typos.
1 parent 37fa862 commit 7f85200

File tree

3 files changed

+35
-32
lines changed

3 files changed

+35
-32
lines changed

‎02-peer-protocol.md

+10-7
Original file line numberDiff line numberDiff line change
@@ -1765,7 +1765,7 @@ the closing transaction will likely never reach miners.
17651765
`OP_RETURN` is only standard if followed by PUSH opcodes, and the total script
17661766
is 83 bytes or less. We are slightly stricter, to only allow a single PUSH, but
17671767
there are two forms in script: one which pushes up to 75 bytes, and a longer
1768-
one (OP_PUSHDATA1) which is needed for 76-80 bytes.
1768+
one (`OP_PUSHDATA1`) which is needed for 76-80 bytes.
17691769

17701770
### Closing Negotiation: `closing_complete` and `closing_sig`
17711771

@@ -1819,6 +1819,7 @@ The sender of `closing_complete` (aka. "the closer"):
18191819
- MUST set `fee_satoshis` to a fee less than or equal to its outstanding balance, rounded down to whole satoshis.
18201820
- MUST set `fee_satoshis` so that at least one output is not dust.
18211821
- MUST use the last sent and received `shutdown.scriptpubkey` to generate the closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction).
1822+
- MUST set `locktime` to the desired `nLockTime` of the closing transaction.
18221823
- MUST set `signature` fields as valid signature using its `funding_pubkey` of:
18231824
- `closer_output_only`: closing transaction with only the local ("closer") output.
18241825
- `closee_output_only`: closing transaction with only the remote ("closee") output.
@@ -1858,12 +1859,12 @@ The receiver of `closing_complete` (aka. "the closee"):
18581859
- If the signature field is non-compliant with LOW-S-standard rule<sup>[LOWS](https://github.com/bitcoin/bitcoin/pull/6769)</sup>:
18591860
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
18601861
- MUST sign and broadcast the corresponding closing transaction.
1861-
- MUST send `closing_sig` with a single valid signature in the same tlv field as the `closing_complete`.
1862+
- MUST send `closing_sig` with a single valid signature in the same TLV field as the `closing_complete`.
18621863

18631864
The receiver of `closing_sig`:
18641865
- if `tlvs` does not contain exactly one signature:
18651866
- MUST either send a `warning` and close the connection, or send an `error` and fail the channel.
1866-
- if `tlvs` does not contain one of the tlv fields sent in `closing_complete`:
1867+
- if `tlvs` does not contain one of the TLV fields sent in `closing_complete`:
18671868
- MUST ignore `closing_sig`.
18681869
- if the signature field is not valid for the corresponding closing transaction specified in [BOLT #3](03-transactions.md#closing-transaction):
18691870
- 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,
18811882
dust MUST be omitted, to ensure that the resulting transaction can be broadcast.
18821883

18831884
The corner case where fees are so high that both outputs are dust is addressed in two ways: paying
1884-
a low fee to avoid the problem, or using an OP_RETURN (which is never "dust"). If one side chooses
1885-
to use an `OP_RETURN` output, its amount must be 0 to ensure that the resulting transaction can be
1886-
broadcast.
1885+
a low fee to avoid the problem, or using an `OP_RETURN` (which is never "dust"). If one side
1886+
chooses to use an `OP_RETURN` output, its amount must be 0 to ensure that the resulting transaction
1887+
can be broadcast.
18871888

18881889
Note that there is usually no reason to pay a high fee for rapid processing, since an urgent child
18891890
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.
19001901
When sending a new `shutdown`, we must receive a new `shutdown` from the remote node before
19011902
sending `closing_complete`. This is necessary to be compatible with future taproot channels
19021903
that use musig2 and need to exchange random nonces every time a transaction spending the channel
1903-
output is signed.
1904+
output is signed. Note that the remote `shutdown` doesn't need to be an explicit response to the
1905+
local `shutdown` that was sent: if both nodes concurrently send `shutdown`, they can exchange
1906+
`closing_complete` immediately after receiving the remote `shutdown`.
19041907

19051908
If the closer proposes a transaction which will not relay (an output is dust, or the fee rate it
19061909
proposes is too low), it doesn't harm the closee to sign the transaction.

‎03-transactions.md

+2-1
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,7 @@ This details the exact format of on-chain transactions, which both sides need to
1717
* [Received HTLC Outputs](#received-htlc-outputs)
1818
* [Trimmed Outputs](#trimmed-outputs)
1919
* [HTLC-timeout and HTLC-success Transactions](#htlc-timeout-and-htlc-success-transactions)
20+
* [Legacy Closing Transaction](#legacy-closing-transaction)
2021
* [Closing Transaction](#closing-transaction)
2122
* [Fees](#fees)
2223
* [Fee Calculation](#fee-calculation)
@@ -349,7 +350,7 @@ The witness script for the output is:
349350

350351
To spend this via penalty, the remote node uses a witness stack `<revocationsig> 1`, and to collect the output, the local node uses an input with nSequence `to_self_delay` and a witness stack `<local_delayedsig> 0`.
351352

352-
## Classic Closing Transaction
353+
## Legacy Closing Transaction
353354

354355
This variant is used for `closing_signed` messages (i.e. where `option_simple_close` is not negotiated).
355356

‎09-features.md

+23-24
Original file line numberDiff line numberDiff line change
@@ -30,30 +30,29 @@ The Context column decodes as follows:
3030
* `9`: presented in [BOLT 11](11-payment-encoding.md) invoices.
3131
* `B`: presented in the `allowed_features` field of a blinded path.
3232

33-
| Bits | Name | Description | Context | Dependencies | Link |
34-
|-------|-----------------------------------|-----------------------------------------------------------|----------|---------------------------|-----------------------------------------------------------------------|
35-
| 0/1 | `option_data_loss_protect` | ASSUMED | | | |
36-
| 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | IN | | [BOLT #2][bolt02-open] |
37-
| 6/7 | `gossip_queries` | Peer has useful gossip to share | | | |
38-
| 8/9 | `var_onion_optin` | ASSUMED | | | |
39-
| 10/11 | `gossip_queries_ex` | Gossip queries can include additional information | IN | | [BOLT #7][bolt07-query] |
40-
| 12/13 | `option_static_remotekey` | ASSUMED | | | |
41-
| 14/15 | `payment_secret` | Node supports `payment_secret` field | IN9 | | [Routing Onion Specification][bolt04] |
42-
| 16/17 | `basic_mpp` | Node can receive basic multi-part payments | IN9 | `payment_secret` | [BOLT #4][bolt04-mpp] |
43-
| 18/19 | `option_support_large_channel` | Can create large channels | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
44-
| 22/23 | `option_anchors` | Anchor commitment type with zero fee HTLC transactions | IN | | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful] |
45-
| 24/25 | `option_route_blinding` | Node supports blinded paths | IN9 | | [BOLT #4][bolt04-route-blinding] |
46-
| 26/27 | `option_shutdown_anysegwit` | Future segwit versions allowed in `shutdown` | IN | | [BOLT #2][bolt02-shutdown] |
47-
| 28/29 | `option_dual_fund` | Use v2 of channel open, enables dual funding | IN | | [BOLT #2](02-peer-protocol.md) |
48-
| 34/35 | `option_quiesce` | Support for `stfu` message | IN | | [BOLT #2][bolt02-quiescence] |
49-
| 38/39 | `option_onion_messages` | Can forward onion messages | IN | | [BOLT #7](04-onion-routing.md#onion-messages) |
50-
| 42/43 | `option_provide_storage` | Can store other nodes' encrypted backup data | IN | | [BOLT #1](01-messaging.md#peer-storage) |
51-
| 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) |
52-
| 46/47 | `option_scid_alias` | Supply channel aliases for routing | IN | | [BOLT #2][bolt02-channel-ready] |
53-
| 48/49 | `option_payment_metadata` | Payment metadata in tlv record | 9 | | [BOLT #11](11-payment-encoding.md#tagged-fields) |
54-
| 50/51 | `option_zeroconf` | Understands zeroconf channel types | IN | `option_scid_alias` | [BOLT #2][bolt02-channel-ready] |
55-
| 60/61 | `option_simple_close` | Simplified closing negotiation | IN | `option_shutdown_anysegwit` | [BOLT #2][bolt02-simple-close] |
56-
33+
| Bits | Name | Description | Context | Dependencies | Link |
34+
|-------|-----------------------------------|-----------------------------------------------------------|----------|-----------------------------|-----------------------------------------------------------------------|
35+
| 0/1 | `option_data_loss_protect` | ASSUMED | | | |
36+
| 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | IN | | [BOLT #2][bolt02-open] |
37+
| 6/7 | `gossip_queries` | Peer has useful gossip to share | | | |
38+
| 8/9 | `var_onion_optin` | ASSUMED | | | |
39+
| 10/11 | `gossip_queries_ex` | Gossip queries can include additional information | IN | | [BOLT #7][bolt07-query] |
40+
| 12/13 | `option_static_remotekey` | ASSUMED | | | |
41+
| 14/15 | `payment_secret` | Node supports `payment_secret` field | IN9 | | [Routing Onion Specification][bolt04] |
42+
| 16/17 | `basic_mpp` | Node can receive basic multi-part payments | IN9 | `payment_secret` | [BOLT #4][bolt04-mpp] |
43+
| 18/19 | `option_support_large_channel` | Can create large channels | IN | | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
44+
| 22/23 | `option_anchors` | Anchor commitment type with zero fee HTLC transactions | IN | | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful] |
45+
| 24/25 | `option_route_blinding` | Node supports blinded paths | IN9 | | [BOLT #4][bolt04-route-blinding] |
46+
| 26/27 | `option_shutdown_anysegwit` | Future segwit versions allowed in `shutdown` | IN | | [BOLT #2][bolt02-shutdown] |
47+
| 28/29 | `option_dual_fund` | Use v2 of channel open, enables dual funding | IN | | [BOLT #2](02-peer-protocol.md) |
48+
| 34/35 | `option_quiesce` | Support for `stfu` message | IN | | [BOLT #2][bolt02-quiescence] |
49+
| 38/39 | `option_onion_messages` | Can forward onion messages | IN | | [BOLT #7](04-onion-routing.md#onion-messages) |
50+
| 42/43 | `option_provide_storage` | Can store other nodes' encrypted backup data | IN | | [BOLT #1](01-messaging.md#peer-storage) |
51+
| 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) |
52+
| 46/47 | `option_scid_alias` | Supply channel aliases for routing | IN | | [BOLT #2][bolt02-channel-ready] |
53+
| 48/49 | `option_payment_metadata` | Payment metadata in tlv record | 9 | | [BOLT #11](11-payment-encoding.md#tagged-fields) |
54+
| 50/51 | `option_zeroconf` | Understands zeroconf channel types | IN | `option_scid_alias` | [BOLT #2][bolt02-channel-ready] |
55+
| 60/61 | `option_simple_close` | Simplified closing negotiation | IN | `option_shutdown_anysegwit` | [BOLT #2][bolt02-simple-close] |
5756

5857
## Requirements
5958

0 commit comments

Comments
 (0)