Skip to content

BOLT 2: allow more leniancy with forks during channel establishment. #77

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rustyrussell merged 2 commits into from
Jan 13, 2017
Merged

BOLT 2: allow more leniancy with forks during channel establishment. #77

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2b39906
BOLT 2: allow more leniancy with forks during channel establishment.
rustyrussell Jan 5, 2017
83e04bf
FIX: require retransmission if we're allowing timeouts.
rustyrussell Jan 8, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 28 additions & 4 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -263,14 +263,25 @@ 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
and its own `channel-id` does not match that received, it MUST either
fail the channel or ignore the `funding_locked` message. If it
ignores the `funding_locked` message it MUST re-transmit
`funding_locked` if the `channel-id` changes, otherwise it 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` with `channel-id`
which does not match the `channel-id` it sent, it MUST either fail the
channel or ignore the `funding_locked` message. If it
ignores the `funding_locked` message it MUST re-transmit
`funding_locked` if the `channel-id` changes, otherwise it MAY
re-transmit `funding_locked` if the `channel-id` changes.
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
Expand All @@ -280,6 +291,19 @@ 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
there are two modes: one in which we simply fail, should that happen,
and a more flexible mode in which nodes wait for updated
`funding_locked` if there's disagreement. In this mode, we require
that they send updates to avoid relying on timeouts.

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
Expand Down