BOLT 4: add minitramp support. #1292
Conversation
We use the same "encrypted blob inside onion" trick as blinded paths, but using TLV 1, so it's ignored for backward compatibility. In this case, we need to tell the trampoline the `payment_secret` (and optional `payment_metadata`) to put in the onion, which gives it the possibility of probing, or even underpaying amountless invoices. However, if the final hop *does* support TLV 1, it can detect interference and refuse attempts to pay that same invoice (since there's a dishonest trampoline), providing *some* honesty incentive. Signed-off-by: Rusty Russell <[email protected]>
…itramp field. We use the trick that the payload `payment_secret` we tell the final trampoline is actually the hash of the real payment secret. This means the final node (if it understands minitramp) *knows* that minitramp is being used, and can penalize that case too. Signed-off-by: Rusty Russell <[email protected]>
It doesn't seem anyone actually uses this, so specify it more simply. Signed-off-by: Rusty Russell <[email protected]>
And steal @t-bast's trampoline error codes. Signed-off-by: Rusty Russell <[email protected]>
rustyrussell
force-pushed
the
guilt/minitramp
branch
from
92553fb to
c5d5219
Compare
|
There's still an issue with errors being visible to the trampolines. One option is to have forwarding trampolines double-encrypt their error returns (using a key in |
Since this requires a change in the recipient's software, isn't it just simpler if that change adds support for decrypting a trampoline onion? The "official" trampoline encryption is very simple to implement since it directly re-uses the existing onion encryption scheme without any tweaks, compared to this proposal... To be honest I don't understand why we'd want something that can be rushed slightly faster than trampoline (and I'm not even sure this would be quicker to rollout since trampoline is already implemented in eclair and almost fully implemented in LDK), rather than starting to rollout the full trampoline feature, which will take whatever time is needed (it's been more than 5 years since it was proposed, which shows we're not in a rush to get it deployed in the next 6 months)? |
|
For reference, the temporary way to route trampoline payments to non-trampoline recipients is specified here: lightning/blips#60 |
|
I think this is much simpler, though? But I'll know more once I've implemented it... |
|
I'm honestly not sure it is, or just marginally simpler, trampoline is much simpler to implement than people who haven't tried it usually think! |
We use the same "encrypted blob inside onion" trick as blinded paths, but using TLV 1, so it's ignored for backward compatibility. In this case, we need to tell the trampoline the
payment_secret(and optionalpayment_metadata) to put in the onion, which gives it the possibility of probing, or even underpaying amountless invoices. However, if the final hop does support TLV 1, it can detect interference and refuse attempts to pay that same invoice (since there's a dishonest trampoline), providing some honesty incentive.