mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 10:00:04 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 2: allow peers to conditionally signal channel announcement in open_channel

Browse Source 
This commit gives peers the ability to signal their intent to make a
channel private in the `open_channel` message. This differs from the
current method as now peers are able to create multiple channels with
heterogeneous announcement policies _without_ disconnecting and
re-connecting in-between each channel funding. The prior requirement
for the nodes to re-connect was burdensome and unnecessary.

[ Minor tweaks from feedback folded in -- RR ]
This commit is contained in:
Olaoluwa Osuntokun 2017-05-15 12:30:30 -07:00 committed by Rusty Russell
parent 38601f6edb
commit 667ca1fdd6
2 changed files with 12 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
02-peer-protocol.md
View File

@ -99,6 +99,7 @@ desire to set up a new channel.
* [`33`:`payment_basepoint`] * [`33`:`payment_basepoint`]
* [`33`:`delayed_payment_basepoint`] * [`33`:`delayed_payment_basepoint`]
* [`33`:`first_per_commitment_point`] * [`33`:`first_per_commitment_point`]
* [`1`:`channel_flags`]
The `chain_hash` value denotes the exact blockchain the opened channel will The `chain_hash` value denotes the exact blockchain the opened channel will
@ -113,6 +114,12 @@ The `temporary_channel_id` is used to identify this channel until the funding tr
`feerate_per_kw` indicates the initial fee rate by 1000-weight (ie. 1/4 the more normally-used 'feerate per kilobyte') which this side will pay for commitment and HTLC transactions as described in [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted later with an `update_fee` message). `to_self_delay` is the number of blocks that the other nodes to-self outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this is how long it will have to wait in case of breakdown before redeeming its own funds. `feerate_per_kw` indicates the initial fee rate by 1000-weight (ie. 1/4 the more normally-used 'feerate per kilobyte') which this side will pay for commitment and HTLC transactions as described in [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted later with an `update_fee` message). `to_self_delay` is the number of blocks that the other nodes to-self outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this is how long it will have to wait in case of breakdown before redeeming its own funds.
Only the least-significant bit of `channel_flags` is currently
defined: `announce_channel`. This indicates whether the initiator of the
funding flow wishes to advertise this channel publicly to the network
as detailed within
[BOLT #7](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#bolt-7-p2p-node-and-channel-discovery).
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` and `delayed_payment_basepoint` are similarly used to generate a series of keys for any payments to this node: `delayed_payment_basepoint` is used to 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 `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` and `delayed_payment_basepoint` are similarly used to generate a series of keys for any payments to this node: `delayed_payment_basepoint` is used to 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.
FIXME: Describe Dangerous feature bit for larger channel amounts. FIXME: Describe Dangerous feature bit for larger channel amounts.
@ -142,6 +149,10 @@ allow commitment transactions to propagate through the Bitcoin
network. It SHOULD set `htlc_minimum_msat` to the minimum network. It SHOULD set `htlc_minimum_msat` to the minimum
amount HTLC it is willing to accept from this peer. amount HTLC it is willing to accept from this peer.
The receiving node MAY fail the channel if `announce_channel` is
`false` (`0`), yet they wish to publicly announce the channel. The
receiving node MUST ignore undefined bits in `channel_flags`.
The receiving node MUST accept a new `open_channel` message if the The receiving node MUST accept a new `open_channel` message if the
connection has been re-established after receiving a previous connection has been re-established after receiving a previous
`open_channel` and before receiving a `funding_created` message. In `open_channel` and before receiving a `funding_created` message. In

2
07-routing-gossip.md
View File

@ -28,7 +28,7 @@ The willingness of the endpoints to announce the channel is signaled during the
### Requirements ### Requirements
If both endpoints have signaled that they'd like to publish the channel then the `announcement_signatures` message MUST be sent, otherwise they MUST NOT be sent. If the `open_channel` message had the `announce_channel` bit set, then both nodes must send the `announcement_signatures` message, otherwise they MUST NOT.
If sent, `announcement_signatures` messages MUST NOT be sent until `funding_locked` has been sent, and the funding transaction is has at least 6 confirmations. If sent, `announcement_signatures` messages MUST NOT be sent until `funding_locked` has been sent, and the funding transaction is has at least 6 confirmations.