Skip to content
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

Jump to bottom

BOLT 2: send channel_type in open/accept #880

Merged
merged 1 commit into from
Aug 31, 2021
Merged

BOLT 2: send channel_type in open/accept #880

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
56 changes: 45 additions & 11 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -130,6 +130,9 @@ the funding transaction and both versions of the commitment transaction.
1. type: 0 (`upfront_shutdown_script`)
2. data:
* [`...*byte`:`shutdown_scriptpubkey`]
1. type: 1 (`channel_type`)
2. data:
* [`...*byte`:`type`]

The `chain_hash` value denotes the exact blockchain that the opened channel will
reside within. This is usually the genesis hash of the respective blockchain.
Expand Down Expand Up @@ -197,6 +200,19 @@ know this node will accept `funding_satoshis` greater than or equal to 2^24.
Since it's broadcast in the `node_announcement` message other nodes can use it to identify peers
willing to accept large channel even before exchanging the `init` message with them.

#### Defined Channel Types

Channel types are an explicit enumeration: for convenience of future
definitions they reuse even feature bits, but they are not an
arbitrary combination (they represent the persistent features which
affect the channel operation).

The currently defined types are:
- no features (no bits set)
Roasbeef marked this conversation as resolved.
Show resolved Hide resolved
- `option_static_remotekey` (bit 12)
- `option_anchor_outputs` and `option_static_remotekey` (bits 20 and 12)
- `option_anchors_zero_fee_htlc_tx` and `option_static_remotekey` (bits 22 and 12)
Roasbeef marked this conversation as resolved.
Show resolved Hide resolved

#### Requirements

The sending node:
Expand All @@ -217,6 +233,10 @@ The sending node:
- MAY include `upfront_shutdown_script`.
- if it includes `open_channel_tlvs`:
- MUST include `upfront_shutdown_script`.
- if it includes `channel_type`:
- MUST set it to a defined type representing the type it wants.
- MUST use the smallest bitmap possible to represent the channel type.
- SHOULD NOT set it to a type containing a feature which was not negotiated.

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.
Expand Down Expand Up @@ -252,6 +272,7 @@ are not valid secp256k1 pubkeys in compressed format.
- the funder's amount for the initial commitment transaction is not sufficient for full [fee payment](03-transactions.md#fee-payment).
- both `to_local` and `to_remote` amounts for the initial commitment transaction are less than or equal to `channel_reserve_satoshis` (see [BOLT 3](03-transactions.md#commitment-transaction-outputs)).
- `funding_satoshis` is greater than or equal to 2^24 and the receiver does not support `option_support_large_channel`.
- It supports `channel_type`, `channel_type` was set, and the `type` is not suitable.
Copy link
Contributor

@ariard ariard Aug 30, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

" - channel type is set to a type containing a feature which was not negotiated" ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need to do additional checks: having "MUST" here (above) implies you should be testing features.

It's weird, but you should only be policing your own options, not theirs. So if they offer you something you understand, you can take it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related comment: lightningnetwork/lnd#5373 (comment)

If we added a feature bit for something like upfront shutdown (that modified the chan negotiation messages to add new behavior), why wouldn't we add one here for something that revamps the channel type selection negotiation entirely?

This simply allows downgrade from "all the features we negotiated". If we want to make this required for some new feature we add, that's cool (I think it should be for stuff like option_simplified_commitment, which you might want to support, but not prefer), but we can add that when we add the feature.

I think it's gonna be moot since everyone wants this and in 12 months it'll be compulsory anyway.... (hope)!


The receiving node MUST NOT:
- consider funds received, using `push_msat`, to be received until the funding transaction has reached sufficient depth.
Expand Down Expand Up @@ -305,6 +326,9 @@ funding transaction and both versions of the commitment transaction.
1. type: 0 (`upfront_shutdown_script`)
2. data:
* [`...*byte`:`shutdown_scriptpubkey`]
1. type: 1 (`channel_type`)
2. data:
* [`...*byte`:`type`]

#### Requirements

Expand All @@ -316,14 +340,20 @@ The sender:
avoid double-spending of the funding transaction.
- MUST set `channel_reserve_satoshis` greater than or equal to `dust_limit_satoshis` from the `open_channel` message.
- MUST set `dust_limit_satoshis` less than or equal to `channel_reserve_satoshis` from the `open_channel` message.
- if it sets `channel_type`:
- MUST set it to the `channel_type` from `open_channel`

The receiver:
- if `minimum_depth` is unreasonably large:
- MAY reject the channel.
- if `channel_reserve_satoshis` is less than `dust_limit_satoshis` within the `open_channel` message:
- MUST reject the channel.
- MUST reject the channel.
- if `channel_reserve_satoshis` from the `open_channel` message is less than `dust_limit_satoshis`:
- MUST reject the channel.
- MUST reject the channel.
- if `channel_type` is set, and `channel_type` was set in `open_channel`, and they are not equal types:
- MUST reject the channel.


Other fields have the same requirements as their counterparts in `open_channel`.

### The `funding_created` Message
Expand Down Expand Up @@ -382,14 +412,18 @@ This message introduces the `channel_id` to identify the channel. It's derived f
#### Requirements

Both peers:
- if `option_static_remotekey`, `option_anchor_outputs` or
`option_anchors_zero_fee_htlc_tx` was negotiated:
- `option_static_remotekey`, `option_anchor_outputs` or
`option_anchors_zero_fee_htlc_tx` applies to all commitment transactions
- if `channel_type` was present in both `open_channel` and `accept_channel`:
- This is the `channel_type` (they must be equal, required above)
- otherwise:
- `option_static_remotekey`, `option_anchor_outputs` or
`option_anchors_zero_fee_htlc_tx` does not apply to any commitment
transactions
- if `option_anchors_zero_fee_htlc_tx` was negotiated:
- the `channel_type` is `option_anchors_zero_fee_htlc_tx` and `option_static_remotekey` (bits 22 and 12)
- otherwise, if `option_anchor_outputs` was negotiated:
- the `channel_type` is `option_anchor_outputs` and `option_static_remotekey` (bits 20 and 12)
- otherwise, if `option_static_remotekey` was negotiated:
- the `channel_type` is `option_static_remotekey` (bit 12)
- otherwise:
- the `channel_type` is empty
- MUST use that `channel_type` for all commitment transactions.

The sender MUST set:
- `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created` message.
Expand Down Expand Up @@ -503,7 +537,7 @@ A sending node:
- 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`.
- 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`.
Expand All @@ -516,7 +550,7 @@ A sending node:
4. `OP_0` `32` 32-bytes (version 0 pay to witness script hash), OR
5. if (and only if) `option_shutdown_anysegwit` is negotiated:
* `OP_1` through `OP_16` inclusive, followed by a single push of 2 to 40 bytes
(witness program versions 1 through 16)
(witness program versions 1 through 16)

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):
Expand Down