You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 02-peer-protocol.md
+11-4Lines changed: 11 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -187,12 +187,20 @@ The `shutdown_scriptpubkey` allows the sending node to commit to where
187
187
funds will go on mutual close, which the remote node should enforce
188
188
even if a node is compromised later.
189
189
190
+
The `option_support_large_channel` is a feature used to let everyone
191
+
know this node will accept `funding_satoshis` greater than or equal to 2^24.
192
+
Since it's broadcast in the `node_announcement` message other nodes can use it to identify peers
193
+
willing to accept large channel even before exchanging the `init` message with them.
194
+
190
195
#### Requirements
191
196
192
197
The sending node:
193
198
- MUST ensure the `chain_hash` value identifies the chain it wishes to open the channel within.
194
199
- MUST ensure `temporary_channel_id` is unique from any other channel ID with the same peer.
195
-
- MUST set `funding_satoshis` to less than 2^24 satoshi.
200
+
- if both nodes advertised `option_support_large_channel`:
201
+
- MAY set `funding_satoshis` greater than or equal to 2^24 satoshi.
202
+
- otherwise:
203
+
- MUST set `funding_satoshis` to less than 2^24 satoshi.
196
204
- MUST set `push_msat` to equal or less than 1000 * `funding_satoshis`.
197
205
- MUST set `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, and `delayed_payment_basepoint` to valid secp256k1 pubkeys in compressed format.
198
206
- 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).
@@ -236,15 +244,14 @@ are not valid secp256k1 pubkeys in compressed format.
236
244
-`dust_limit_satoshis` is greater than `channel_reserve_satoshis`.
237
245
- the funder's amount for the initial commitment transaction is not sufficient for full [fee payment](03-transactions.md#fee-payment).
238
246
- 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)).
247
+
-`funding_satoshis` is greater than or equal to 2^24 and the receiver does not support `option_support_large_channel`.
239
248
240
249
The receiving node MUST NOT:
241
250
- consider funds received, using `push_msat`, to be received until the funding transaction has reached sufficient depth.
242
251
243
252
#### Rationale
244
253
245
-
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.
246
-
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.
247
-
Specifically, [the routing gossip protocol](07-routing-gossip.md) does not discard channels that have a larger capacity.
254
+
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`.
248
255
249
256
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.
0 commit comments