Connections between nodes within the network may be very long lived as
payment channels have an indefinite lifetime. However, it’s likely that
for a significant portion of the life-time of a connection, no new data
will be exchanged. Additionally, on several platforms it’s possible that
Lightning clients will be put to sleep without prior warning. As a
result, we use a distinct ping message in order to probe for the
liveness of the connection on the other side, and also to keep the
established connection active.
This commit adds two new control messages to the protocol: `ping` and
`pong`. Their usage within the network is similar to the usage of such
message within other established protocols: `ping` messages specify a
number of bytes to be contained in the payload of a `pong` message, and
`pong` messages are to be sent in response to receiving a `ping` message.
Additionally, the ability for a sender to request that the receiver send
a response with a particular number of bytes enables nodes on the
network to create synthetic traffic. Such traffic can be used to
partially defend against packet and timing analysis as nodes can fake
the traffic patterns of typical exchanges, without applying any true
updates to their respective channels.
When combined with the onion routing protocol defined in BOLT#4, careful
statistically driven synthetic traffic can serve to further bolster the
privacy of participants within the network.
As a bonus, the usage of periodic `ping` message ensures frequent key
rotation between connected nodes.
[ The result is a bikeshed of every possible color! -- RR ]
At cost of a few extra bytes between peers, this avoids the whole "oops, we were on a chain fork" problem, and simplifies generation of temporary channel-ids (just pick a random one).
Now we move the announcement_signature exchange to at least 6 confirms, which makes re-xmit tricky; I resolved that by insisting on reconnect that we send if we haven't received, and reply to the first one.
The term "channel shortid" wasn't used anywhere, so I removed it; it's now a gossip-only thing anyway.
One subtle change: pkt_error on unknown channels is now "MUST ignore"; this section was reworked anyway, and we'll want this if the #120 goes through, where one side might have forgotten unformed channels).
Closes: #114
Suggested-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Two bytes for funding-output-index.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Channel-id rework, temp ids, 32 bits only.
Re-add the idea of temporary channel ids: far simpler since they're now
big enough we can just fill with noise.
Remove the alignment issues by combining txid and outnum using XOR; we
could reduce to 128 bit if we really wanted to, but we don't.
Error handling is now simple again, but while editing I changed the
behaviour for unknown channels to MUST ignore (this is important for
Change the 8-byte gossip channel id to `short-channel-id`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIXUP! Minor text tweaks from Pierre-Marie and Christian
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1) Make it clear that `init` needs to be sent every time.
- This means if you upgrade and no longer support an old connection, it's
clear, plus it simplifies the question of re-transmission of `init`.
2) Spell out the retransmission requirements for reconnection.
- We agreed in Milan to simply use retransmit and ignore-dups.
- This needs actual testing by implementations, but this is my best guess
on exactly how far back to retransmit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 1: recommend full tx in error pkt if signature fails.
This will usually be the commitment tx, but could also be the HTLC
tx.
Reported-by: pm47 <pm.padiou@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* FIX: Feedback
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 1: tighten error message `len` requirement.
Of course it has to match data length exactly.
Reported-by: pm47 <pm.padiou@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 1, BOLT 2, BOLT 5: commitsig -> commitment_signed.
Consistency FTW.
Reported-by: pm47 <pm.padiou@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Further separating the two specs by pointing to bolt08 for transport
details and deduplicating some of the information. Also fixed some
markup while I'm at it :-)
So far we had both the transport layer, with its initialization details,
and part of the base protocol, with some generic messages like `init`
and `error` in a single spec. I propose we split the spec into two, one
for the transport layer and one for the communication on top of that
layer. This should make the independence of the two layers even clearer.
This commit is the first step towards that goal and simply moves blocks
of text into the new spec file. It should not change any semantics.
