* 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>
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>
