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

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.

Author: Roasbeef

02-peer-protocol.md

@@ -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.