mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-10 09:10:07 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 02: add a chain-hash field to the open_channel msg (#135)

Browse source 
This commit adds a `chain-hash` field to message that commences a
funding workflow. This field is used to specify a _target_ chain for the
proposed channel. In order to uniquely identity blockchains in a manner
that doesn't require strict coordination between developers, the genesis
hash of the target chain is used. For channels opened on the Bitcoin
blockchain, the `chain-hash` field should _always_ be set to:
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.

Introducing this new field _immediately_ allows nodes within the network
to open a channel within any Satoshi-derived blockchain. Nodes can have
channels open across different blockchains globally, but also have many
channels open across distinct blockchains with the same peer.
This commit is contained in:
Olaoluwa Osuntokun 2017-03-23 18:39:41 -07:00 • committed by Rusty Russell
parent 351ea92a6b
commit 9e0a0e893d
1 changed files with 14 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
02-peer-protocol.md
View file

@ -83,6 +83,7 @@ desire to set up a new channel.
1. type: 32 (`open_channel`)
2. data:
* [32:chain-hash]
* [32:temporary-channel-id]
* [8:funding-satoshis]
* [8:push-msat]
@ -100,6 +101,12 @@ desire to set up a new channel.
* [33:first-per-commitment-point]
The chain-hash value denotes the exact blockchain the opened channel will
reside within. This is usually the genesis hash of the respective blockchain.
The existence of the chain-hash allows nodes to open channel
across many distinct blockchains as well as have channels within multiple
blockchains opened to the same peer (if they support the target chains).
The `temporary-channel-id` is used to identify this channel until the funding transaction is established. `funding-satoshis` is the amount the sender is putting into the channel. `dust-limit-satoshis` is the threshold below which output should be generated for this node's commitment or HTLC transaction; ie. HTLCs below this amount plus HTLC transaction fees are not enforceable on-chain. This reflects the reality that tiny outputs are not considered standard transactions and will not propagate through the Bitcoin network.
`max-htlc-value-in-inflight-msat` is a cap on total value of outstanding HTLCs, which allows a node to limit its exposure to HTLCs; similarly `max-accepted-htlcs` limits the number of outstanding HTLCs the other node can offer. `channel-reserve-satoshis` is the minimum amount that the other node is to keep as a direct payment. `htlc-minimum-msat` indicates the smallest value HTLC this node will accept.
@ -113,6 +120,10 @@ FIXME: Describe Dangerous feature bit for larger channel amounts.
#### Requirements
A sending node MUST ensure that the chain-hash value identifies the chain they
they wish to open the channel within. For the Bitcoin blockchain, the
chain-hash value MUST be (encoded in hex):
`000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f`.
A sending node MUST ensure `temporary-channel-id` is unique from any other
channel id with the same peer. The sender MUST set `funding-satoshis`
@ -198,6 +209,9 @@ acceptance of the new channel.
#### Requirements
The receiving MUST reject the channel if the `chain-hash` value within the
`open_channel` message is set to a hash of a chain unknown to the receiver.
The `temporary-channel-id` MUST be the same as the `temporary-channel-id` in the `open_channel` message. The sender SHOULD set `minimum-depth` to a number of blocks it considers reasonable to avoid double-spending of the funding transaction.
The receiver MAY reject the `minimum-depth` if it considers it unreasonably large.