If we get sent junk (or unknown version), we can't encrypt the
failure. Currently that's only if the onion version is non-zero, or
the ephemeral key is malformed.
We do check the BADONION bit so the origin can tell that we're
reporting it on the next peer's behalf, in case that ever matters.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'fix__feedback_from_roasbeef.patch':
FIX: Feedback from roasbeef.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I looked through the error cases in our current prototype, and this
seems to cover most of them. I classed them using bits, which
indicate how the origin should respond.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'fixes__renumber_failure_codes_for_consistency.patch':
FIXES: renumber failure codes for consistency.
Done as separate patch for now because it merely adds noise.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'fix__`failure-code`_and_`additional`_are_literal_field_names,_be_consistent.patch':
FIX: `failure-code` and `additional` are literal field names, be consistent.
Also, put HMAC fail before keyparse fail, since that's the first check.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'bolt_2__add_another_method_of_failing_htlcs.patch':
Added an `additional` field to the return message, so that we can
include any protocol level message to inform the sender about the
cause of the failure. This could for example be a `channel_update` if
the channel has become unusable. The message is no longer fixed size,
as hopefully the failure is a rare event, in which case timing
analysis becomes easy anyway.
Closes#53
If a node is being malicious, we get an error from the next hop either
way. But if we've simply advertised a new cltv-expiry-delta, we
want to send our own error.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They're not reliable, so we can't count on them. We also don't have a place
for forwarding them in BOLT 2's update_fulfill_htlc.
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>
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.
