mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 2: make opening retransmissions atomic and better specified.

Browse Source 
1. Tell the node when to broadcast the funding tx (we didn't do this!).
2. Allow timeouts generally if no progress is made (originally this
   was just when waiting for funding_locked, but it applies generally).
3. Use `funding_signed` as the commitment point: before this, we forget,
   after this, we remember.  If lost, we'll timeout.
4. The core of the retransmission requirements now only applies to
   the normal and shutdown states, and will be revised separately
   depending on #172

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-05-16 11:24:03 +09:30
parent 41790a9cd7
commit 5801656c6d
1 changed files with 34 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
02-peer-protocol.md
View File

@ -261,6 +261,8 @@ The sender MUST set `channel_id` by exclusive-OR of the `funding_txid` and the `
The recipient MUST fail the channel if `signature` is incorrect.
The recipient SHOULD broadcast the funding transaction on receipt of a valid `funding_signed` and MUST NOT broadcast the funding transaction earlier.
### The `funding_locked` message
This message indicates that the funding transaction has reached the `minimum_depth` asked for in `accept_channel`. Once both nodes have sent this, the channel enters normal operating mode.
@ -280,6 +282,20 @@ per-commitment point to be used for the following commitment
transaction, derived as specified in
[BOLT #3](03-transactions.md#per-commitment-secret-requirements).
A non-funding node SHOULD forget the channel if it does not see the
funding transaction after a reasonable timeout.
From the point of waiting for `funding_locked` onward, a node MAY
fail the channel if it does not receive a required response from the
other node after a reasonable timeout.
#### Rationale
The non-funder can simply forget the channel ever existed, since no
funds are at risk; even if `push_msat` is significant, if it remembers
the channel forever on the promise of the funding transaction finally
appearing, there is a denial of service risk.
#### Future
We could add an SPV proof, and route block hashes in separate
@ -894,9 +910,15 @@ any message), they are independent of requirements here.
### Requirements
A node MUST handle continuing a previous channel on a new encrypted
transport. On disconnection, a node MAY forget nodes which have not
sent or received an `accept_channel` message, and MAY forget nodes
which have not sent `funding_locked` after a reasonable timeout.
transport.
On disconnection, the funder MUST remember the channel for
reconnection if it has broadcast the funding transaction, otherwise it
MUST NOT.
On disconnection, the non-funding node MUST remember the channel for
reconnection if it has sent the `funding_signed` message, otherwise
it MUST NOT.
On disconnection, a node MUST reverse any uncommitted updates sent by
the other side (ie. all messages beginning with `update_` for which no
@ -909,15 +931,11 @@ retransmit the error packet and ignore any other packets for that
channel, or if the channel has entered closing negotiation, the node
MUST retransmit the last `closing_signed`.
Otherwise, on reconnection, a node MUST retransmit old messages which may not
Otherwise, on reconnection, a node MUST retransmit old messages after `funding_signed` which may not
have been received, and MUST NOT retransmit old messages which have
been explicitly or implicitly acknowledged. The following table
lists the acknowledgment conditions for each message:
* `open_channel`: acknowledged by `accept_channel`.
* `accept_channel`: acknowledged by `funding_created`.
* `funding_created`: acknowledged by `funding_signed`.
* `funding_signed`: acknowledged by `funding_locked`.
* `funding_locked`: acknowledged by `update_` messages, `commitment_signed`, `revoke_and_ack` or `shutdown` messages.
* `update_` messages: acknowledged by `revoke_and_ack`.
* `commitment_signed`: acknowledged by `revoke_and_ack`.
@ -942,6 +960,14 @@ fail the channel if they occur.
### Rationale
The effect of requirements above are that the opening phase is almost
atomic: if it doesn't complete, it starts again. The only exception
is where the `funding_signed` message is sent and not received: in
this case, the funder will forget the channel and presumably open
a new one on reconnect; the other node will eventually forget the
original channel due to never receiving `funding_locked` or seeing
the funding transaction on-chain.
There's no acknowledgment for `error`, so if a reconnect occurs it's
polite to retransmit before disconnecting again, but it's not a MUST
because there are also occasions where a node can simply forget the