mirror of
https://github.com/lightning/bolts.git
synced 2025-03-13 11:35:41 +01:00
Fix @tnull's comments
Clarify strict `shutdown` exchange requirements and fix typos.
This commit is contained in:
t-bast
parent
3c80dc3b1d
commit
c64edfe633
3 changed files with 35 additions and 32 deletions
|
|
@ -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<sup>[LOWS](https://github.com/bitcoin/bitcoin/pull/6769)</sup>:
|
||||
- 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.
|
||||
|
|
|
|||
|
|
@ -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 `<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`.
|
||||
|
||||
## Classic Closing Transaction
|
||||
## Legacy Closing Transaction
|
||||
|
||||
This variant is used for `closing_signed` messages (i.e. where `option_simple_close` is not negotiated).
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue