-
Notifications
You must be signed in to change notification settings - Fork 411
Provide Bolt12Invoice
used for inbound payment
#2929
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
0f8f48a
eec6822
1be1630
3a0d0ff
35c408f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,6 +25,7 @@ use crate::ln::features::ChannelTypeFeatures; | |
use crate::ln::msgs; | ||
use crate::ln::{ChannelId, PaymentPreimage, PaymentHash, PaymentSecret}; | ||
use crate::chain::transaction; | ||
use crate::offers::invoice::Bolt12Invoice; | ||
use crate::routing::gossip::NetworkUpdate; | ||
use crate::util::errors::APIError; | ||
use crate::util::ser::{BigSize, FixedLengthReader, Writeable, Writer, MaybeReadable, Readable, RequiredWrapper, UpgradableRequired, WithoutLength}; | ||
|
@@ -582,6 +583,43 @@ pub enum Event { | |
/// The `payment_id` to have been associated with payment for the requested invoice. | ||
payment_id: PaymentId, | ||
}, | ||
/// Indicates that a [`Bolt12Invoice`] was generated in response to an [`InvoiceRequest`] and is | ||
/// being prepared to be sent via an [`OnionMessage`]. The event is provided only for invoices | ||
/// corresponding to an [`Offer`], not for a [`Refund`]. For the latter, the invoice is returned | ||
/// by [`ChannelManager::request_refund_payment`]. | ||
/// | ||
/// Note that this doesn't necessarily mean that the invoice was sent and -- once sent -- it may | ||
/// never reach its destination because of the unreliable nature of onion messages. Any of the | ||
/// following scenarios may occur. | ||
/// - Dropped by a node along the path to the destination | ||
/// - Dropped upon node restart prior to being sent | ||
/// - Buffered waiting to be sent by [`PeerManager`] | ||
/// - Buffered waiting for an [`Event::ConnectionNeeded`] to be handled and peer connected | ||
/// - Dropped waiting too long for such a peer connection | ||
/// - Dropped because the onion message buffer was full | ||
/// - Dropped because the [`MessageRouter`] failed to find an [`OnionMessagePath`] to the | ||
/// destination | ||
/// | ||
/// Thus, this event is largely for informational purposes as the corresponding [`Offer`] and | ||
/// [`InvoiceRequest`] fields are accessible from the invoice. In particular: | ||
/// - [`Bolt12Invoice::metadata`] can help identify the corresponding [`Offer`] | ||
/// - A common [`Bolt12Invoice::payer_id`] indicates the payer sent multiple requests for | ||
/// redundancy, though in that case the [`Bolt12Invoice::payment_hash`] used may be different. | ||
/// | ||
/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest | ||
/// [`OnionMessage`]: crate::ln::msgs::OnionMessage | ||
/// [`Offer`]: crate::offers::offer::Offer | ||
/// [`Refund`]: crate::offers::refund::Refund | ||
/// [`ChannelManager::request_refund_payment`]: crate::ln::channelmanager::ChannelManager::request_refund_payment | ||
/// [`PeerManager`]: crate::ln::peer_handler::PeerManager | ||
/// [`MessageRouter`]: crate::onion_message::messenger::MessageRouter | ||
/// [`OnionMessagePath`]: crate::onion_message::messenger::OnionMessagePath | ||
InvoiceGenerated { | ||
/// An invoice that was generated in response to an [`InvoiceRequest`]. | ||
/// | ||
/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest | ||
invoice: Bolt12Invoice, | ||
}, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if we should provide the preimage/payment secret also while we're here? |
||
/// Indicates an outbound payment we made succeeded (i.e. it made it all the way to its target | ||
/// and we got back the payment preimage for it). | ||
/// | ||
|
@@ -1262,6 +1300,12 @@ impl Writeable for Event { | |
35u8.write(writer)?; | ||
// Never write ConnectionNeeded events as buffered onion messages aren't serialized. | ||
}, | ||
&Event::InvoiceGenerated { ref invoice } => { | ||
37u8.write(writer)?; | ||
write_tlv_fields!(writer, { | ||
(0, invoice, required), | ||
}) | ||
}, | ||
// Note that, going forward, all new events must only write data inside of | ||
// `write_tlv_fields`. Versions 0.0.101+ will ignore odd-numbered events that write | ||
// data via `write_tlv_fields`. | ||
|
@@ -1668,6 +1712,18 @@ impl MaybeReadable for Event { | |
}, | ||
// Note that we do not write a length-prefixed TLV for ConnectionNeeded events. | ||
35u8 => Ok(None), | ||
37u8 => { | ||
let f = || { | ||
let mut invoice_bytes = WithoutLength(Vec::new()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Any reason we can't just implement There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. serde would be great too |
||
read_tlv_fields!(reader, { | ||
(0, invoice_bytes, required), | ||
}); | ||
let invoice = Bolt12Invoice::try_from(invoice_bytes.0) | ||
.map_err(|_| msgs::DecodeError::InvalidValue)?; | ||
Ok(Some(Event::InvoiceGenerated { invoice })) | ||
}; | ||
f() | ||
}, | ||
// Versions prior to 0.0.100 did not ignore odd types, instead returning InvalidValue. | ||
// Version 0.0.100 failed to properly ignore odd types, possibly resulting in corrupt | ||
// reads. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make it a bit more explicit that this is the only way users can associate incoming payments with a previously-generated offer? I.e., the only way to know what was actually paid for is to handle this event and keep track of all sent-out payment hashes to be able to associate them with the offer based on
metadata
.While this is probably fine for now, I really wonder if we eventually should take care of the tracking in LDK (or offer a utility for it at least), as every node receiving payments will want to know what a payment is for.