This reduces failure codes to 2 bytes, places them into data itself.
Now we can use the same parsing code for them as we use for normal packets.
BOLT 2 is adjusted to match, and order of args changed to restore sha256
alignment to a nice 8 bytes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The most significant byte of the locktime in a commitment transaction
must be set to 0x20. This is to make sure that the locktime value
is always higher than 500,000,000, making it interpreted as a Unix
epoch timestamp, and not a block height. It also makes sure that the
locktime is below the current time, allowing the commitment transaction
to be included in a block.
Since the sequence field in the input of the commitment transaction is
used for the other half of the obscured commitment transaction number,
it will never assume the maxInt value (0xFFFFFFFF) which would disable
locktime checking.
The previous test vectors were using the btcec variant corresponding
to RFC5903 Section 9, only using the X-coord of the result of the
scalar multiplication, whereas libsecp256k1 uses the compressed
serialization format, which includes the sign bit.
* BOLT 2: allow more leniancy with forks during channel establishment.
Christoper points out that two nodes with aggressive minimum-depth settings
may see different blocks and the protocol requires they close the channel
since their funding_locked messages will disagree.
This can also happen when only one side has an aggressive minimum-depth
setting: if it sends funding_locked referring to a block which is orphaned,
it can't update it.
There are three changes here, two optional.
- Allow sending of an updated funding_locked. This fixes this case where
one side is on an orphan and uses a v. low minimum-depth.
- Require accepting of an updated funding_locked.
- Allow waiting instead of immediate failure if funding_lock disagrees.
eg. you might wait another block or two to see if one side reorgs.
Reported-by: Christopher Jämthagen
Closes: #73
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For now I just generated the wrapping direction since the unwrapping
relies on the steps in reverse. It's a 5-hop onion packet, padded to
the standard 20 hop size. Associated data and per-hop-payloads are
filled with dummy values, not the format described in the bolt.
This commit fixes an oversight within the spec that details the
encryption nonces as being encoded in a big-endian form rather an a
little-endian for as is intended.
Since our internal nonces are 64-bit in order to match with the Noise
spec, we encoded the 96-bit nonce as 32-bits of leading zeroes followed
by the 64-bit little-endian value.
Christian points out that we lost our fixed sizedness when we included
more information in failure messages. Add some padding to get that
back; by my calculations that gives us room for 30 bytes of expansion
before we'll see some odd-length packets again.
We can actually stash a message in here (hence contents unspecified),
but we shouldn't need to if our codes work.
Reported-by: Christian Decker <decker.christian@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
