BOLT 2: differing channel-id fails channel #73
Comments
|
This is a duplicate of #6, but AFAICT the |
|
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
|
|
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. |
|
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... |
rustyrussell
added a commit
to rustyrussell/lightning-rfc
that referenced
this issue
Jan 5, 2017
Christoper points out that two nodes with aggressive minimum-depth settings may see different blocks and the protocol requires they close the channel since their funding_locked messages will disagree. This can also happen when only one side has an aggressive minimum-depth setting: if it sends funding_locked referring to a block which is orphaned, it can't update it. There are three changes here, two optional. - Allow sending of an updated funding_locked. This fixes this case where one side is on an orphan and uses a v. low minimum-depth. - Require accepting of an updated funding_locked. - Allow waiting instead of immediate failure if funding_lock disagrees. eg. you might wait another block or two to see if one side reorgs. Reported-by: Christopher Jämthagen Closes: lightning#73 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell
added a commit
to rustyrussell/lightning-rfc
that referenced
this issue
Jan 5, 2017
Christoper points out that two nodes with aggressive minimum-depth settings may see different blocks and the protocol requires they close the channel since their funding_locked messages will disagree. This can also happen when only one side has an aggressive minimum-depth setting: if it sends funding_locked referring to a block which is orphaned, it can't update it. There are three changes here, two optional. - Allow sending of an updated funding_locked. This fixes this case where one side is on an orphan and uses a v. low minimum-depth. - Require accepting of an updated funding_locked. - Allow waiting instead of immediate failure if funding_lock disagrees. eg. you might wait another block or two to see if one side reorgs. Reported-by: Christopher Jämthagen Closes: lightning#73 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell
added a commit
that referenced
this issue
Jan 13, 2017
…77) * BOLT 2: allow more leniancy with forks during channel establishment. Christoper points out that two nodes with aggressive minimum-depth settings may see different blocks and the protocol requires they close the channel since their funding_locked messages will disagree. This can also happen when only one side has an aggressive minimum-depth setting: if it sends funding_locked referring to a block which is orphaned, it can't update it. There are three changes here, two optional. - Allow sending of an updated funding_locked. This fixes this case where one side is on an orphan and uses a v. low minimum-depth. - Require accepting of an updated funding_locked. - Allow waiting instead of immediate failure if funding_lock disagrees. eg. you might wait another block or two to see if one side reorgs. Reported-by: Christopher Jämthagen Closes: #73 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What if two peers who want to open a channel with each other sets
minimum-depthto 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 thefunding_lockedmessage with (most likely) differentchannel-id, and they must now fail the channel according to the spec. Should the protocol not handle this case?The text was updated successfully, but these errors were encountered: