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.
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.
There was talk of using a simple increment, but it was removed after
Tadge educated me. Somehow this didn't get updated.
Reported-by: Tadge Dryja <tdryja@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Inspired by Andrew Shvv's work, this expands the HTLC weight calculation
and fixes the gross errors (the witness program itself wasn't counted in
the weights!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Commit a0c4f7cfd1 "BOLT 3: add more detailed commitment transaction
estimation (#26)" simplified the weight formula to assume there was a
to-remote output.
This worst-case 18% error, but it's simple. Document it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
