update stylesheet to reflect appropriate structure of Requirement sub-items and format of digits, numerations, and quantities;
copy edit BOLTs 0,1,2 to adhere to these changes;
We've always specified that fields can be appended, and we're about to
do our first. Make it clear that you can't just send one if we add several
fields as part of the same option.
Change extract-formats to have an optional new field appended: the
input format is to simply add ' (optionname)' in the data
specification.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Implement changes requested by @rustyrussell: wording change, structure requirements according to whether nodes are sending or receiving;
Correct grammar, punctuation, capitalization, and style for correctness, concision, clarity, comprehension, and consistency;
Edit 01-messaging copy for clarity (minor rephrasing, punctuation),
correctness (grammar, capitalization, punctuation),
consision (minimizing wordiness, redundancy),
and consistency (document style, e.g. 1 space between sentences,
capitalization of headers, etc.)
This is based on a series of patches from @EmelyanenkoK which makes the treatment of feature bits clearer and adds rationale so that future extensions can be made wisely.
Thanks to all involved!
Closes: #156
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
