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.

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

Single-option large channel proposal #596

Merged
merged 19 commits into from
Feb 18, 2020
Merged
Show file tree
Hide file tree
Changes from 17 commits
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
bb479a8
BOLT 1, 7, 9: rename feature bits, combine in gossip.
rustyrussell May 6, 2019
733428e
BOLT 9: Note that features share the same number space.
rustyrussell May 6, 2019
0f1f7c6
BOLT 1: don't need to disconnect on unknown `channelfeatures`.
rustyrussell May 6, 2019
783790a
BOLT 7: Explicitly mirror channelfeatures in channel_announcement.
rustyrussell May 6, 2019
14ced3b
BOLT 7: advertize both feature sets in node_announcement.
rustyrussell May 6, 2019
a41e33e
Rebase on feature bits unification, use bits 8/9, move rationale to B…
rsbondi Jan 22, 2019
b6573ee
Move `option_support_large_channel` rationale to BOLT-2
araspitzu Jul 3, 2019
0c78b3d
Remove 'channel_update.htlc_maximum_msat' max value restriction
araspitzu Aug 6, 2019
e35b70a
BOLT 9: flatten feature fields.
rustyrussell Sep 17, 2019
a3889b5
fixup! BOLT 9: flatten feature fields.
rustyrussell Sep 17, 2019
2f5176e
BOLT 7: always propagate announcements with unknown features.
rustyrussell Sep 17, 2019
2003ec8
Fix-up!
rustyrussell Sep 18, 2019
bd74d03
Merge remote-tracking branch 'rusty/guilt/flat-features' into large_c…
araspitzu Oct 3, 2019
8af0535
Rephrase to use flat features
araspitzu Oct 3, 2019
e6157a9
Restrict option_support_large_channel to even bits in channel_announc…
araspitzu Oct 4, 2019
6f08b6e
Merge remote-tracking branch 'origin/master' into large_channel_support
araspitzu Nov 26, 2019
d5a8978
Merge branch 'master' into large_channel_support
araspitzu Jan 27, 2020
a067f23
Update 09-features.md
araspitzu Feb 3, 2020
660dd2e
Use feature bits 18/19 for option_support_large_channel
araspitzu Feb 4, 2020
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
15 changes: 11 additions & 4 deletions 02-peer-protocol.md
Original file line number Diff line number Diff line change
Expand Up @@ -187,12 +187,20 @@ 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.

The `option_support_large_channel` is a feature used to let everyone
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.

#### Requirements

The sending node:
- MUST ensure 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.
- if both nodes advertised `option_support_large_channel`:
- MAY set `funding_satoshis` greater than or equal to 2^24 satoshi.
- otherwise:
- 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).
Expand Down Expand Up @@ -236,15 +244,14 @@ are not valid DER-encoded compressed secp256k1 pubkeys.
- `dust_limit_satoshis` is greater than `channel_reserve_satoshis`.
- 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`.

The receiving node MUST NOT:
- consider funds received, using `push_msat`, to be received until the funding transaction has reached sufficient depth.

#### Rationale

The requirement for `funding_satoshi` to be less than 2^24 satoshi is a temporary self-imposed limit while implementations are not yet considered stable.
It can be lifted at any point in time, or adjusted for other currencies, since it is solely enforced by the endpoints of a channel.
Specifically, [the routing gossip protocol](07-routing-gossip.md) does not discard channels that have a larger capacity.
The requirement for `funding_satoshis` to be less than 2^24 satoshi was a temporary self-imposed limit while implementations were not yet considered stable, it can be lifted by advertising `option_support_large_channel`.

The *channel reserve* is specified by the peer's `channel_reserve_satoshis`: 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially, this reserve may not be met, as only one side has funds; but the protocol ensures that there is always progress toward meeting this reserve, and once met, it is maintained.

Expand Down
1 change: 1 addition & 0 deletions 09-features.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,7 @@ The Context column decodes as follows:
| 12/13 | `option_static_remotekey` | Static key for remote output | IN | | [BOLT #3](03-transactions.md) |
| 14/15 | `payment_secret` | Node supports `payment_secret` field | IN9 | `var_onion_optin` | [Routing Onion Specification][bolt04] |
| 16/17 | `basic_mpp` | Node can receive basic multi-part payments | IN9 | `payment_secret` | [BOLT #4][bolt04-mpp] |
| 48/49 | `option_support_large_channel` | Can create large channels | INC+ | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
araspitzu marked this conversation as resolved.
Show resolved Hide resolved

## Requirements

Expand Down