Task: Upgrade to LDK v0.1 #174
Description
Description
LDK has released v0.0.124 🎊 We should upgrade at some point.
Steps to Complete
- Our integration tests won't pass unless our fork of ldk-sample is also upgraded to LDK v124 so this is a good place to start. (We use a separate fork of ldk-sample to test that we are able to successfully send payments to another node. The main difference is that instead of using the CLI, we turn it into a library so that we can call the functions directly in Rust.)
- Upgrade LNDK.
Notes
Copying some notes over from @jkczyz in case these are helpful for whoever takes this issue. :)
Heads up! The upcoming LDK 0.0.124 release adds authentication to BOLT12 messages in order to mitigate de-anonymization attacks. Essentially, this means blinded paths will contain information that allows LDK to check if they are being used in the appropriate context.
In LDK, ChannelManager's implementation of OffersMessageHandler is responsible for authentication. It is now given an OffersContext to use when verifying an InvoiceRequest. The data used for verification has moved from InvoiceRequest::payer_metadata to the InvoiceRequest's reply path. So when the Bolt12Invoice is received, the handler will be given the OffersContext that was included in the reply path for use in authentication.
What does this means for LNDK?
When creating a reply path for your InvoiceRequest you will need to include an OffersContext::OutboundPayment (example).
When receiving a Bolt12Invoice you must use the provided OffersContext when verifying it (example).
When receiving an InvoiceError you should check the OffersContext before taking any action (example).
Any Bolt12Invoice received using an older reply path can still be verified using a different method, but there is a de-anonymization risk when paying. We'd advise ignoring any invoices received without an OffersContext given a new InvoiceRequest can be sent instead.
There's sure to be other minor API changes, so don't hesitate reaching out if you have any questions or concerns!
Note that with v124 we should be able to fix #123 because advance_path_by_one for messages and payments are now exposed. But this perhaps could go in a different PR.