Make payment_secret mandatory #1810
Conversation
This is a security feature that has been introduced a long time ago and is widely supported across the network. We can safely make it mandatory which closes probing attack vectors.
|
cc @dpad85 may have some impact on old Eclair Mobile IIUC |
There was a problem hiding this comment.
Should we make our onion type stricter and simplify the relayers at the same time? #1770 (comment). Or do you think we should wait because there may be pre-existing payment requests that have not yet expired?
I'd rather do it in a separate PR, in the release after we make |
Support for |
The `payment_secret` feature was made mandatory in #1810 and is the default in other implementations as well. We can thus force it to be available when decoding onion payloads, which simplifies downstream components (no need to handle the case where a `payment_secret` may be missing anymore).
The `payment_secret` feature was made mandatory in #1810 and is the default in other implementations as well. We can thus force it to be available when decoding onion payloads, which simplifies downstream components (no need to handle the case where a `payment_secret` may be missing anymore). We also rename messages in `PaymentInitiator` to remove the confusion with Bolt 11 payment requests.
|
@t-bast could it be that I am running into |
|
Yes that's exactly it. We set the feature bit as mandatory in invoices (because that's where this feature bit makes sense) but not in our Depending on what library you're probing with, this may already be fixed if you upgrade (see #1913). |
|
Why don't you set the feature bit as mandatory in the |
|
Because there's no reason to yet (as a relaying-only node you don't care at all about |
we now require payment_secret both for sending and for receiving (previously was optional for both) see lightning/bolts#898 ACINQ/eclair#1810 ElementsProject/lightning#4646 note: payment_secret depends on var_onion_optin, so that becomes mandatory as well, however this commit does not yet remove the ability of creating legacy onions
we now require payment_secret both for sending and for receiving (previously was optional for both) see lightning/bolts#898 ACINQ/eclair#1810 ElementsProject/lightning#4646 note: payment_secret depends on var_onion_optin, so that becomes mandatory as well, however this commit does not yet remove the ability of creating legacy onions
This is a security feature that has been introduced a long time ago and is widely supported across the network.
We can safely make it mandatory which closes probing attack vectors.
A separate follow-up PR will remove some legacy code that handled cases where
payment_secretcould be missing.I'd rather first release the activation bits and then remove that legacy code instead of bundling the two together.