-
Notifications
You must be signed in to change notification settings - Fork 407
Include invoice requests in async payment onions #3207
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
cdc0c3b
3945bf8
88d689a
2ff6524
639446a
a80af56
9b3e307
6a42453
fead88f
520ae0b
925a0cb
d574de9
34e710e
240dd0a
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 |
---|---|---|
|
@@ -1747,6 +1747,7 @@ pub struct FinalOnionHopData { | |
mod fuzzy_internal_msgs { | ||
use bitcoin::secp256k1::PublicKey; | ||
use crate::blinded_path::payment::{BlindedPaymentPath, PaymentConstraints, PaymentContext, PaymentRelay}; | ||
use crate::offers::invoice_request::InvoiceRequest; | ||
use crate::types::payment::{PaymentPreimage, PaymentSecret}; | ||
use crate::types::features::{BlindedHopFeatures, Bolt12InvoiceFeatures}; | ||
use super::{FinalOnionHopData, TrampolineOnionPacket}; | ||
|
@@ -1827,6 +1828,7 @@ mod fuzzy_internal_msgs { | |
intro_node_blinding_point: Option<PublicKey>, // Set if the introduction node of the blinded path is the final node | ||
keysend_preimage: Option<PaymentPreimage>, | ||
custom_tlvs: &'a Vec<(u64, Vec<u8>)>, | ||
invoice_request: Option<&'a InvoiceRequest>, | ||
} | ||
} | ||
|
||
|
@@ -2760,13 +2762,17 @@ impl<'a> Writeable for OutboundOnionPayload<'a> { | |
}, | ||
Self::BlindedReceive { | ||
sender_intended_htlc_amt_msat, total_msat, cltv_expiry_height, encrypted_tlvs, | ||
intro_node_blinding_point, keysend_preimage, ref custom_tlvs, | ||
intro_node_blinding_point, keysend_preimage, ref invoice_request, ref custom_tlvs, | ||
} => { | ||
// We need to update [`ln::outbound_payment::RecipientOnionFields::with_custom_tlvs`] | ||
// to reject any reserved types in the experimental range if new ones are ever | ||
// standardized. | ||
let invoice_request_tlv = invoice_request.map(|invreq| (77_777, invreq.encode())); // TODO: update TLV type once the async payments spec is merged | ||
valentinewallace marked this conversation as resolved.
Show resolved
Hide resolved
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. Will this type eventually be less than 2^16? If so, should we just pick something there and move this to 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. My point of reference is mainly that eclair's approach has been to use experimental TLVs until the corresponding BOLT is close(r) to merge, e.g. for their experimental trampoline features. It does seem a little bit safer and might allow us to end up with a lower type since there wouldn't be risk of overlap with another feature? |
||
let keysend_tlv = keysend_preimage.map(|preimage| (5482373484, preimage.encode())); | ||
let mut custom_tlvs: Vec<&(u64, Vec<u8>)> = custom_tlvs.iter().chain(keysend_tlv.iter()).collect(); | ||
let mut custom_tlvs: Vec<&(u64, Vec<u8>)> = custom_tlvs.iter() | ||
.chain(invoice_request_tlv.iter()) | ||
.chain(keysend_tlv.iter()) | ||
.collect(); | ||
custom_tlvs.sort_unstable_by_key(|(typ, _)| *typ); | ||
_encode_varint_length_prefixed_tlv!(w, { | ||
(2, HighZeroBytesDroppedBigSize(*sender_intended_htlc_amt_msat), required), | ||
|
Uh oh!
There was an error while loading. Please reload this page.