1
0
mirror of https://github.com/lightning/bolts.git synced 2025-01-18 21:32:31 +01:00

BOLT 4: don't allow a "fee" for the final node.

I recently made a cut & paste bug with the protocol tests, and
paid an HTLC of amount 100M msat, but with only a 1M msat `amt_to_forward`
in the hop_data.  To my surprise, it was accepted.

This is because we allow overpaying the routing fee (considered 0
for the final hop).  This doesn't make sense for the final hop: anything
but exact equality implies a bug, or that the previous node took the
wrong amount from the payment.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2019-12-03 14:19:40 +10:30
parent 0fb66ca6cc
commit 2422630274

View File

@ -198,7 +198,7 @@ Field descriptions:
* `amt_to_forward`: The amount, in millisatoshis, to forward to the next
receiving peer specified within the routing information.
This value amount MUST include the origin node's computed _fee_ for the
For non-final nodes, this value amount MUST include the origin node's computed _fee_ for the
receiving peer. When processing an incoming Sphinx packet and the HTLC
message that it is encapsulated within, if the following inequality doesn't hold,
then the HTLC should be rejected as it would indicate that a prior hop has
@ -206,9 +206,11 @@ Field descriptions:
incoming_htlc_amt - fee >= amt_to_forward
Where `fee` is either calculated according to the receiving peer's advertised fee
schema (as described in [BOLT #7](07-routing-gossip.md#htlc-fees))
or is 0, if the processing node is the final node.
Where `fee` is calculated according to the receiving peer's advertised fee
schema (as described in [BOLT #7](07-routing-gossip.md#htlc-fees).
For the final node, this value MUST be exactly equal to the incoming htlc
amount, otherwise the HTLC should be rejected.
* `outgoing_cltv_value`: The CLTV value that the _outgoing_ HTLC carrying
the packet should have.