They were cluttering the spec document, and not easily integrated into the
tests for implementations. This just cleans up the spec and allows automated
testing going forward.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Introduces `frame`s and all related concepts such as `FRAME_SIZE`. It also
fixes a conceptual issue where `hops_data` would be used both for the section
of the overall packet as well as the wire format for individual payloads. This
separation now lends itself better to the incremental wrapping of the onion.
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>
Saying "the risk is only to the node *accepting* the HTLC" is confusing
because merely accepting an HTLC is risk-free. The risk comes from
accepting *responsibility to route the payment*, i.e. offering an HTLC
of your own in the next channel on the path, where a too-small
difference in the HTLC values could end up with you cheated out of a
payment.
This revised paragraph hopefully makes that clearer.
Uses more specific and consistent language ("the"/"that" instead of "an"
where possible). Also helps avoid confusion with unrelated HTLCs that
serve other payments but are shared by the same two nodes.
914ebab908 effectively deprecated this, but
left it for "reject if more than 2x expected amount" case.
Leaving it for gross overpayment still leaves an attack on the current
network in practice (all implementations I know of reject grossly excessive
payments), and removing it causes our code to nicely break when regenerating,
since that error code is now not defined anywhere.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We express it has how the outputs are ordered, but the only way you can
detect that is by the htlc_signatures order, which is the part which really
matters.
I finally reproduced this, BTW, which is why I'm digging it up!
Closes: #448
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Because the errors are separate, if an intermediate node sees a
payment hash for relay and has several guesses as to the
destination of the payment, they can check their guesses by sending
HTLCs with the same payment hashes first and seeing the error sent
back.
By adding the htlc_msat that the final node received to
unknown_or_incorrect_payment_details, origin nodes can still
identify bad value-relaying peers.
This seems to be a cause of stuck HTLCs on the network: c-lightning has
done this for a while now (since 0.6.1).
[ Minor wording clarification merged --RR ]
Decided-at: Adelaide Summit 2018
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
