These are based on @t-bast's vectors from #607, with a few more
cases:
1. Explicitly test encodings for 253, 254 and 255.
2. Use BigSize and make sure tests break badly if endian parsing is wrong.'
3. Test wrap-around of type encodings in stream.
Many thanks to @t-bast and @cfromknecht for their contributions and testing
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't explicitly say that the TLV is bad if length exceeds
the message length!
We didn't specify whether to ignore extra bytes: we should.
Similarly, contents of values must be minimal (i.e. tu64 etc).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit modifies the varint encoding used for TLV types and lengths
to use a custom format called BigSize. The format is identical to
bitcoin's CompactSize, except it replaces the use of little-endian
encodings for multi-byte values with big-endian. This is done to prevent
mixing endianness within the protocol, since otherwise CompactSize would
be the first introduction of little-endian encodings.
It's trivial to make types->lengths, but not so much the other way.
The types I used here are the ones I found useful in implementation, and
I think add some clarity, though we can certainly argue about them.
There's no normative changes to the spec in here.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Obviously you can't include fields you don't understand, but importantly
if the other side doesn't agree, you don't need to include them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I named the first option `option209` but that was too ugly to live.
Nonetheless, this wording lived on.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
