1
0
mirror of https://github.com/lightning/bolts.git synced 2025-01-18 13:22:35 +01:00

BOLT 2: add precommitment to scriptpubkey for mutual close.

This is Fabrice's #243 "BOLT2, BOLT3: reduce attack surface", split
out with minor polishing:

- Made it an optional feature (we can insist on it if we choose even bit).
- Rename from "final_scriptpubkey" to "shutdown_scriptpubkey".
- Make requirements the same as shutdown's scriptpubkey, or zero-len.
- Leave shutdown's scriptpubkey, just make sure it's the same or fail.
- Add to accept_channel as well as open_channel.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-10-31 12:08:24 +10:30
parent 005372c11a
commit 963b103113
2 changed files with 32 additions and 9 deletions

View File

@ -98,7 +98,8 @@ desire to set up a new channel.
* [`33`:`htlc_basepoint`]
* [`33`:`first_per_commitment_point`]
* [`1`:`channel_flags`]
* [`2`:`shutdown_len`] (`option_upfront_shutdown_script`)
* [`shutdown_len`: `shutdown_scriptpubkey`] (`option_upfront_shutdown_script`)
The `chain_hash` value denotes the exact blockchain the opened channel will
reside within. This is usually the genesis hash of the respective blockchain.
@ -120,18 +121,26 @@ as detailed within
The `funding_pubkey` is the public key in the 2-of-2 multisig script of the funding transaction output. The `revocation_basepoint` is combined with the revocation preimage for this commitment transaction to generate a unique revocation key for this commitment transaction. The `payment_basepoint`, `htlc_basepoint`, and `delayed_payment_basepoint` are similarly used to generate a series of keys for any payments to this node: `delayed_payment_basepoint` is used for payments encumbered by a delay. Varying these keys ensures that the transaction ID of each commitment transaction is unpredictable by an external observer, even if one commitment transaction is seen — this property is very useful for preserving privacy when outsourcing penalty transactions to third parties.
The `shutdown_scriptpubkey` allows the sending node to commit to where
funds will go on mutual close, which the remote node should enforce
even if a node is compromised later.
[ FIXME: Describe dangerous feature bit for larger channel amounts. ]
#### Requirements
The sending node MUST:
- ensure that the `chain_hash` value identifies the chain it wishes to open the channel within.
- ensure `temporary_channel_id` is unique from any other channel ID with the same peer.
- set `funding_satoshis` to less than 2^24 satoshi.
- set `push_msat` to equal or less than 1000 * `funding_satoshis`.
- set `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, and `delayed_payment_basepoint` to valid DER-encoded, compressed, secp256k1 pubkeys.
- set `first_per_commitment_point` to the per-commitment point to be used for the initial commitment transaction, derived as specified in [BOLT #3](03-transactions.md#per-commitment-secret-requirements).
- set undefined bits in `channel_flags` to 0.
The sending node:
- MUST ensure that the `chain_hash` value identifies the chain it wishes to open the channel within.
- MUST ensure `temporary_channel_id` is unique from any other channel ID with the same peer.
- MUST set `funding_satoshis` to less than 2^24 satoshi.
- MUST set `push_msat` to equal or less than 1000 * `funding_satoshis`.
- MUST set `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, and `delayed_payment_basepoint` to valid DER-encoded, compressed, secp256k1 pubkeys.
- MUST set `first_per_commitment_point` to the per-commitment point to be used for the initial commitment transaction, derived as specified in [BOLT #3](03-transactions.md#per-commitment-secret-requirements).
- MUST set undefined bits in `channel_flags` to 0.
- if both nodes advertised the `option_upfront_shutdown_script` feature:
- MUST include either a valid `shutdown_scriptpubkey` as required by `shutdown` `scriptpubkey`, or a zero-length `shutdown_scriptpubkey`.
- otherwise:
- MAY include a`shutdown_scriptpubkey`.
The sending node SHOULD:
- set `to_self_delay` sufficient to ensure the sender can irreversibly spend a commitment transaction output, in case of misbehavior by the receiver.
@ -202,6 +211,8 @@ acceptance of the new channel.
* [`33`:`delayed_payment_basepoint`]
* [`33`:`htlc_basepoint`]
* [`33`:`first_per_commitment_point`]
* [`2`:`shutdown_len`] (`option_upfront_shutdown_script`)
* [`shutdown_len`: `shutdown_scriptpubkey`] (`option_upfront_shutdown_script`)
#### Requirements
@ -363,6 +374,8 @@ A sending node:
- MUST NOT send a `shutdown`.
- MUST NOT send an `update_add_htlc` after a `shutdown`.
- SHOULD fail to route any HTLC added after it 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:
1. `OP_DUP` `OP_HASH160` `20` 20-bytes `OP_EQUALVERIFY` `OP_CHECKSIG`
@ -376,6 +389,8 @@ A receiving node:
- SHOULD fail the connection.
- once there are no outstanding updates on the peer:
- MUST reply to a `shutdown` message with a `shutdown`, unless it has already sent 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
@ -390,6 +405,13 @@ 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
provides an incremental improvement in security by requiring 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.
### Closing Negotiation: `closing_signed`

View File

@ -18,6 +18,7 @@ These flags may only be used in the `init` message:
| Bits | Name |Description | Link |
|------|------------------|------------------------------------------------|---------------------------------------------------------------------|
| 3 | `initial_routing_sync` | The sending node needs a complete routing information dump | [BOLT #7](07-routing-gossip.md#initial-sync) |
| 4/5 | `option_upfront_shutdown_script` | Commit to a shutdown scriptpubkey when opening | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
## Assigned `globalfeatures` flags