This lets us have both IPv4 and IPv6 (and Tor etc in future) address,
while still preserving the ability to add other fields to the message
in future.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Inspired by Andrew Samokhvalov's PR, this makes the relationship
between the signatures in `channel_announcement` explicit.
Closes: #27
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We could spam the network with 64k announcements, and each node has to
rememeber them for rebroadcasting. There's a tradeoff between
allowing future expansions and this potential DoS, so allow nodes to
choose.
My current implementation thinking is: each extra byte reduces chance
of rebroadcast by a small amount, such that if you're twice the
minimum size your chance of rebroadcast hits 0.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The sending side says it needs to bitcoin-style sign double-SHA, but the
receiving side doesn't. Make it clear.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From BIP 68:
If bit (1 << 31) of the sequence number is set, then no consensus
meaning is applied to the sequence number and can be included in any
block under all currently possible circumstances.
Which is what we want.
Reported-by: Olaoluwa Osuntokun <laolu32@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
FIPS 198 is based on RFC 2104, but further restricts the hashing
functions to the SHA-family, so this is a bit redundant, but my hope
is to avoid confusion about whether there is a difference.
Thanks @rustyrussell for pointing this one out.
Now using `<>` on inline code only when part of a script and extra
emphasis is warranted. Outside of scripts the variable names are
already highlighted, so no need to add further emphasis.
Specifying that the `onion-routing-packet` commits to the
`payment-key` by setting the associated data. This avoids replay
attacks and specifying it here keeps the onion-routing spec clean.
Spell out the send/receive nonces for the normal message transport;
they're 0 except in one place where Act3 re-uses temp_k from Act2.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'typo-fixes.patch':
Typo fixes to squash.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. Note that we're using the IETF chachapoly variant, which has 96 bit nonces.
2. Note that we send over the serialization of the pubkey on the wire.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. More than three variables.
2. Make nonce encoding explicit (Big-endian, like everything else).
3. `e` is a keypair in this context; use `re` for their pubkey.
4. Explicitly note `re` and `le` notation.
5. Fix RFC reference.
6. Close `` around HKDF.
7. Use `ss` for the shared secret; `s` is already taken.
8. Use `re` for their pubkey.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit updates the opening paragraph in the channel establishment
section. The messages referenced are were from the prior iteration of
the funding messages and naming scheme. The section has been updated to
properly reference the latest messages and also to give a bit more
context to the reader to start with.
