Skip to content

Clarify simple_close and upfront_shutdown_script compatibility #1348

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tnull wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Clarify simple_close and upfront_shutdown_script compatibility #1348

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 21 additions & 4 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2160,7 +2160,11 @@ A sending node:
- MUST NOT send any `update` message after that point.
- 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`.
- if both nodes advertised `option_simple_close`:
- MUST set `scriptpubkey` to either the same value or an `OP_RETURN`
script in one of the following forms.
- otherwise:
- MUST send the same value in `scriptpubkey`.
- MUST set `scriptpubkey` in one of the following forms:

1. `OP_0` `20` 20-bytes (version 0 pay to witness pubkey hash), OR
Expand All @@ -2182,9 +2186,17 @@ A receiving node:
- 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`:
- MAY send a `warning`.
- MUST fail the connection.
- 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`:
- if both nodes advertised `option_simple_close`:
- if `scriptpubkey` is not an `OP_RETURN` script in one of the above forms:
- MAY send a `warning`.
- MUST fail the connection.
- otherwise:
- MAY send a `warning`.
- MUST fail the connection.

#### Rationale

Expand Down Expand Up @@ -2214,6 +2226,11 @@ 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`.

When `option_simple_close` is negotiated, a node may instead use a valid
`OP_RETURN` script if it considers its output uneconomical. The corresponding
output amount is zero, as specified in [BOLT 3](03-transactions.md#closing-transaction),
so this exception does not allow funds to be redirected to another address.

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.

`OP_RETURN` is only standard if followed by PUSH opcodes, and the total script
Expand Down