Bolt 11: add a payment secret to invoice #671
Conversation
It is currently very easy for a forwarding node to discover if the next node is the recipient. Imagine for example that we use the following route: ``` Alice -> Bob -> Carol -> Dave ``` When Carol receives the HTLC from Bob, instead of normally forwarding the onion, she can instead create a new one-hop payment to Dave with the payment hash, amount and cltv that she would have forwarded. If Dave fulfills the HTLC, then he was the recipient and Carol can forward the HTLC fulfill, completing the payment normally. If Dave returns an error, he isn't the recipient and Carol resumes the normal payment flow by sending him the peeled onion received from Bob. This is a very cheap de-anonymization attack. Fortunately, it is also quite easy to fix by adding a payment secret in the invoice that the payer needs to include in the last hop payload. For backwards-compatibility with legacy payers, we use feature bits in the invoice to allow payees to generate both invoices that require this payment_secret and invoices that don't (but hopefully in a few releases we can make all implementations set this bit to mandatory by default).
04-onion-routing.md
Outdated
| 2. types: | ||
| 1. type: 1 (`payment_secret`) | ||
| 2. data: | ||
| * [`u16`:`payment_secret`] |
There was a problem hiding this comment.
This is a 16 bit field! You mean 16*bytes I think.
There was a problem hiding this comment.
Woops definitely, thanks for spotting this
|
@cfromknecht this should also cover the attack on 0-amount invoices (for both normal invoices and AMP). Let me know what you think. |
| `payment_hash` is incorrect or the CLTV expiry of the htlc is too close to the | ||
| current block height for safe handling. | ||
| The `payment_hash` is unknown to the final node, the `payment_secret` doesn't | ||
| match the `payment_hash`, the amount for that `payment_hash` is incorrect or |
There was a problem hiding this comment.
this is kind of confusing: "the payment_secret doesn't match the payment_hash"
I think what you really mean to convey is that the payment_secret corresponds with the expected secret for that payment_hash.
'match' implies equivalence, which isn't the exact case here.
There was a problem hiding this comment.
True, the wording isn't great. This PR is now included in the MPP once so I'll be closing it anyway ;)
|
This has been included in #643 and evolution is being done over there |
It is currently very easy for a forwarding node to discover if the next node is the recipient.
Imagine for example that we use the following route:
When Carol receives the HTLC from Bob, instead of normally forwarding the onion, she can instead
create a new one-hop payment to Dave with the payment hash, amount and cltv that she would have
forwarded.
If Dave fulfills the HTLC, then he was the recipient and Carol can forward the HTLC fulfill,
completing the payment normally.
If Dave returns an error, he isn't the recipient and Carol resumes the normal payment flow by
sending him the peeled onion received from Bob.
This is a very cheap de-anonymization attack. Fortunately, it is also quite easy to fix by adding
a payment secret in the invoice that the payer needs to include in the last hop payload.
For backwards-compatibility with legacy payers, we use feature bits in the invoice to allow payees
to generate both invoices that require this payment_secret and invoices that don't (but hopefully
in a few releases we can make all implementations set this bit to mandatory by default).