2021-12-01 15:08:33
Closing Initiation: shutdown
Either node (or both) can send a shutdown message to initiate closing, along with the scriptpubkey it wants to be paid to.
type: 38 (shutdown)
data:
[32:channel_id]
[2:len]
[len:scriptpubkey]
Requirements
A sending node:
if it hasn't sent a funding_created (if it is a funder) or a funding_signed (if it is a fundee):
MUST NOT send a shutdown
MAY send a shutdown before a funding_locked, i.e. before the funding transaction has reached minimum_depth.
if there are updates pending on the receiving node's commitment transaction:
MUST NOT send a shutdown.
MUST NOT send an update_add_htlc after a shutdown.
if no HTLCs remain in either commitment transaction:
MUST NOT send any update message after a shutdown.
SHOULD fail to route any HTLC added after it has sent shutdown.
if it sent a non-zero-length shutdown_scriptpubkey in open_channel or accept_channel:
MUST send the same value in scriptpubkey.
MUST set scriptpubkey in one of the following forms:
OP_DUP OP_HASH160 20 20-bytes OP_EQUALVERIFY OP_CHECKSIG (pay to pubkey hash), OR
OP_HASH160 20 20-bytes OP_EQUAL (pay to script hash), OR
OP_0 20 20-bytes (version 0 pay to witness pubkey), OR
OP_0 32 32-bytes (version 0 pay to witness script hash)
A receiving node:
if it hasn't received a funding_signed (if it is a funder) or a funding_created (if it is a fundee):
SHOULD fail the connection
if the scriptpubkey is not in one of the above forms:
SHOULD fail the connection.
if it hasn't sent a funding_locked yet:
MAY reply to a shutdown message with a shutdown
once there are no outstanding updates on the peer, UNLESS it has already sent a shutdown:
MUST reply to a shutdown message with a shutdown
if both nodes advertised the option_upfront_shutdown_script feature, and the receiving node received a non-zero-length shutdown_scriptpubkey in open_channel or accept_channel, and that shutdown_scriptpubkey is not equal to scriptpubkey:
MUST fail the connection.
Rationale
If channel state is always "clean" (no pending changes) when a shutdown starts, the question of how to behave if it wasn't is avoided: the sender always sends a commitment_signed first.
As shutdown implies a desire to terminate, it implies that no new HTLCs will be added or accepted. Once any HTLCs are cleared, the peer may immediately begin closing negotiation, so we ban further updates to the commitment transaction (in particular, update_fee would be possible otherwise).
The scriptpubkey forms include only standard forms accepted by the Bitcoin network, which ensures the resulting transaction will propagate to miners.
The option_upfront_shutdown_script feature means that the node wanted to pre-commit to shutdown_scriptpubkey in case it was compromised somehow. This is a weak commitment (a malevolent implementation tends to ignore specifications like this one!), but it provides an incremental improvement in security by requiring the cooperation of the receiving node to change the scriptpubkey.
The shutdown response requirement implies that the node sends commitment_signed to commit any outstanding changes before replying; however, it could theoretically reconnect instead, which would simply erase all outstanding uncommitted changes.
Will continue...
400 views12:08
B
