With AMP, we'll effectively be probing for channel
capacity. Returning how far out a payment was provides
a hint.
You can determine the order required, then fuzz it a
little, eg:
switch(rand(8)):
case 0: increase, retry;
case 1: decrease, retry;
case 2-8: stop;
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We might argue this does not apply if you set `minimum_depth` to 0, since
you're assuming trust (TurboChannels-style), but it needs to be specified.
See: CVE-2019-12998 / CVE-2019-12999 / CVE-2019-13000
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 7: fix cut & paste typo.
This is `reply_channel_range_tlvs`: `query_channel_range_tlvs` is defined
above. Somehow this fix got lost in the merge process, and breaks
our spec parsing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 7: add missing `encoding_type` field in query_short_channel_ids_tlvs / reply_channel_range_tlvs
The implementations have it, and the requirements refer to it,
but it's not actually in the description!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT 7: clarify specification.
As agreed in http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-08-05-20.03.html,
checksums are not encoded as encoding_type + byte, but as a straight
array. Referring to them as `*byte` is thus underspecifying them:
they are literally `*channel_update_checksums`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This separates out the static remotekey changes from the more ambitious
option_simplified_commitment (which also included pushme outputs and
bring-your-own-fee for HTLC outputs).
As per http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-09-02-20.06.html
Thanks to everyone for feedback: @araspitzu @roasbeef @bitconner
Suggested-by: @roasbeef
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Do not reply with a node_announcement if the query includes an optional query flag that does not request it.
The current wording could be interpreted as "always follow with node announcements whenever
you reply with a channel announcements" which defeats the point of using query flags (if you want the node
announcements just set the corresponding bits).
We use the more tool-friendly `...*` description for TLV extensions.
Checksums are now serialized as raw arrays, as using zlib compression here would not help.
Since some can be zero (missing updates), it's probably worth
doing the compression thing optionally.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Formatting changes only.
This make tools/extract-formats.py work (well, it misses some stuff
until the tlv-testcases merge, but then it's OK).
We use `tlvs` (for tlv stream), and we refer to TLV records as "being
included" rather than re-using the TLV name.
We even use subtypes for the pairs of checksums and timestamps.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Nodes that support extended queries will append an additional extended query flag to
their `query_channel_range` queries. If the receiver supports extended queries and
understands this flag, it will append the required additional data to its
`reply_channel_range` message.
There is currently only one type of additional data: one timestamp and one checksum
per `channel_update`.
The checksum is a CRC32 checksum computed over the `channel_update`
with `timestamp` and `signature` omitted.
Along with query_short_channel_ids extension, this can be used to
avoid querying `channel_updates` that are older than the ones you
already have, or that are newer but don't include new information.
Nodes can append additional data to their `query_short_channel_ids`
messages, which consists in one flag per short channel id and
specifies what they would like to receive (`node_announcement`,
`channel_announcement`, or/and one `channel_update` or both).
The specification currently doesn't specify the case where the onion per-hop
payload can't be correctly decoded.
This is somewhat fine with the fixed frames because every field of the payload
can always be interpreted as a numeric value from the input bytes, so it leads
to application errors in upper layers when those values are actually
interpreted (and we realize that for instance we have an invalid
short_channel_id` value).
With variable-length tlv streams in the onion payloads, we will encounter
decoding errors (duplicate tlv types, invalid ordering, etc) and the spec
should define the failure code to use in that case.
Most obviously, we want this for BASE AMP, but it's useful in future.
Even though even bits won't cause existing implementations to know
they can't pay the invoice, it will allow it in future once everyone
has upgraded.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If a node sends its own `channel_update` to a peer node before receiving a `funding_lock`, the peer node may discard because it has not `short_channel_id` yet.
* Added descriptions of how a 2-of-2 multisignature verification is used for enforcing timelocks when timing out on-chain offered HTLCs as well as spending on-chain received HTLCs in the success case.
In commit 914ebab908 the
incorrect_payment_amount error was merged into
incorrect_or_unknown_payment_details to prevent a probing attack
that allowed intermediate nodes to learn the final destination of
a payment.
A similar attack is possible using the htlc expiry value. By trying
payments with the correct amount but low expiry values to candidate
destinations, an incorrect_or_unknown_payment_details error can be
elicited. This would signal that the probe payment was sent to the
final destination.
For the intermediate node to determine the correct amount, an estimate
must be calculated. A logical choice would be the outgoing amount of the
intermediate node plus some allowance for routing fees that would
otherwise be paid to subsequent nodes along the path.
Picking a low enough - but not too low - expiry value is more tricky.
A reasonable guess could be made using external knowledge of the
final destination's implementation defaults or the type of invoice that
is paid to. Especially in the case of an hodl invoice that typically has
a large expiry delta, it is easier to make a correct guess.
This form of attack is arguably harder to realize than the amount probe
that was previously possible. The attacker may accidentally
pay the invoice if the expiry value guess satisfies the invoice
final cltv requirement. In that case, the attacker still has the
incoming htlc to pull which limits the loss.
In practice, using '...*type' is the clearest and simplest way to specify
the common case of "the rest of the TLV is an array of 'type'", rather
than some arbitrary expression with a made-up length field.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The format for TLV types looked pretty, but @ZmnSCPxj points out that
successive ordered lists in markdown get merged into one megalist.
If we allow ordered or unordered lists, we're a bit more futureproof
against formatting changes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Thanks to feedback from @t-bast and @ariard, and Michael Kerrisk
who helped me find the 1999(!) man page text.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As discussed during the IRC meeting on 2019-07-22 this would have been a
duplication of signals. It was decided to use one for now, with the option of
coming back should we ever need the last 32 bytes of the onion.
The tables were a bit unreadable in the source view, and the globalfeatures
table was not rendering correctly. This is just a minor cleanup pass.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Suggested-by: Janus Troelsen <@ysangkok>
As discussed during the spec meeting this allows us not to use the 32 byte
HMAC to identify the last hop, and use a 2-byte signal instead.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The clarifications were tacked on after the fact, but they should really be
part of the conventions. I also updated the links to use the reference style,
which results in better text flow and makes it easier to read the source.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
These are based on @t-bast's vectors from #607, with a few more
cases:
1. Explicitly test encodings for 253, 254 and 255.
2. Use BigSize and make sure tests break badly if endian parsing is wrong.'
3. Test wrap-around of type encodings in stream.
Many thanks to @t-bast and @cfromknecht for their contributions and testing
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We didn't explicitly say that the TLV is bad if length exceeds
the message length!
We didn't specify whether to ignore extra bytes: we should.
Similarly, contents of values must be minimal (i.e. tu64 etc).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
