BOLT 2: differing channel-id fails channel

[cjamthagen]

What if two peers who want to open a channel with each other sets minimum-depth to 1 and there are two blocks created simultaneously (same height) with the funding transaction in both of them, and each peer receives a different block. They will send the funding_locked message with (most likely) different channel-id, and they must now fail the channel according to the spec. Should the protocol not handle this case?

[pm47]

This is a duplicate of #6, but AFAICT the minconf=6 didn't actually make it to the spec. I'd be in favor of adding it to BOLT 2.

[rustyrussell]

Christopher Jämthagen <notifications@github.com> writes:

What if two peers who want to open a channel with each other sets `minimum-depth` to 1 and there are two blocks created simultaneously (same height) with the funding transaction in both of them, and each peer receives a different block. They will send the `funding_locked` message with (most likely) different `channel-id`, and they must now fail the channel according to the spec. Should the protocol not handle this case?

It does; as you said: they will fail the channel :) blockchain.info shows 27 orphans in the last 3 months, or ~ one every 3 days. We could change the spec to allow retransmissions, instead, such instead of failing, you may wait for agreement. How's this? diff --git a/02-peer-protocol.md b/02-peer-protocol.md index b91a3ec..56d3bdd 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -263,14 +263,20 @@ The sender MUST wait until the funding transaction has reached `minimum-depth` before sending this message. The sender MUST encode the block position of the funding transaction into `channel-id`. If the sender has already received `funding_locked` from the other node, -it MUST fail the channel if its own `channel-id` does not match the -received. The sender MUST set `next-per-commitment-point` to the +it MAY fail the channel if its own `channel-id` does not match the +received: otherwise it MUST ignore the `funding_locked` message. +The sender MAY re-transmit `funding_locked` if the `channel-id` changes. + +The sender MUST set `next-per-commitment-point` to the per-commitment point to be used for the following commitment transaction, derived as specified in [BOLT #3](03-transactions.md#per-commitment-secret-requirements).

…

-If the recipient has already sent `funding_locked` it MUST fail the -channel if `channel-id` does not match the `channel-id` it sent. +If the recipient has already sent `funding_locked` it MAY fail the +channel if `channel-id` does not match the `channel-id` it sent, +otherwise it SHOULD ignore the `funding_locked` message. If the +recipient has received previous `funding_locked` message, it MUST +ignore it in favor of the new `funding_locked`. The sender MUST set `announcement-node-signature` and `announcement-bitcoin-signature` to the signatures for the `channel_announcement` message, or all zeroes if it does not want the @@ -280,6 +286,18 @@ The recipient SHOULD fail the channel if the `announcement-node-signature` and ` The recipient SHOULD queue the `channel_announcement` message for its peers if it has sent and received a non-zero `announcement-node-signature` and `announcement-bitcoin-signature`. +#### Rationale + +If the `minimum-depth` is very low (such as 1), it's possible that +both nodes see different blocks containing the transaction: current +evidence suggests that this would happen once every three days. Thus +we allow implementations to retransmit in this case, and even wait for +such retransmissions in the case where both `minimum-depth` were too +low for a canonical answer. + +Such waiting is optional, as it is extremely unlikely for +`minimum-depth` values of 2 or more. + #### Future We could add an SPV proof, and route block hashes in separate

[cdecker]

I'm afraid that blockchain.info has a terrible track record of finding orphans, they are far more frequent. That being said the probability of a fork decreases exponentially with the length of the fork, and we should encourage 3-4 confirmations for the channel setup. So I'm happy with failing the channel as a occasional slap on the wrist for people who go against this and try to create a low-conf channel.

[rustyrussell]

Agreed their detection is not great, but it's probably a fair basis to estimate how often two random nodes will see different blocks.

I think low-conf channels are a usability win though, so I think weakening the spec a little to allow workarounds if people want that is a good thing. I'll turn it into a formal PR for discussion, though...