Pre-work for BOLT 12 invoices #1927

jkczyz · 2022-12-20T19:03:42Z

Some fixes and pre-work for BOLT 12 invoices taken from #1926.

Corrects some documentation pertaining to Refund::payer_id
Removes an unnecessary Option from InvoiceRequest's interface
Adds Features for Invoice

codecov-commenter · 2022-12-20T19:26:26Z

Codecov Report

Attention: Patch coverage is 94.28571% with 2 lines in your changes missing coverage. Please review.

Project coverage is 92.29%. Comparing base (8e36737) to head (b50fc4e).
Report is 3917 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/offers/invoice_request.rs	88.23%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1927      +/-   ##
==========================================
+ Coverage   92.20%   92.29%   +0.09%     
==========================================
  Files          95       97       +2     
  Lines       62066    63153    +1087     
  Branches    62066    63153    +1087     
==========================================
+ Hits        57228    58289    +1061     
- Misses       4838     4864      +26

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

valentinewallace

Basically looks good, still need to give 005566a another glance

valentinewallace · 2022-12-20T20:26:02Z

lightning/src/offers/refund.rs

@@ -285,7 +285,9 @@ impl Refund {
 		&self.contents.features
 	}

-	/// A possibly transient pubkey used to sign the refund.
+	/// A possibly transient pubkey used for the node to send to if there are no [`paths`].


I guess it can't be transient if there are no paths?

Hmm... given this is required it can be transient though you're right that wouldn't be in the case mentioned. Was trying to remember why this actually required and dug up rustyrussell/lightning-rfc#11 (comment).

Yeah, just want to make sure it's clear, but if we think it's clear as-is I'm fine with the phrasing

I'm not a huge fan of this phrasing, no. If its not transient, the docs dont tell you what you should use (node_id), at a minimum.

Are you recommending dropping "possibly transient"? Or do you think it needs more rewording in addition to that? (i.e., Should the docs say what to set for both cases of paths being included and not?)

Yea, maybe lets spell it out - if paths is set...transient key, if paths is not set, node_id, etc?

lightning/src/offers/invoice_request.rs

valentinewallace · 2022-12-21T17:03:07Z

lightning/src/ln/features.rs

-impl_feature_tlv_write!(OfferFeatures);
-impl_feature_tlv_write!(InvoiceRequestFeatures);


Tests are passing for me on #1926 with keeping use of the macro for these sets of features:

diff --git a/lightning/src/ln/features.rs b/lightning/src/ln/features.rs index a3c1b7f6..335dad03 100644 --- a/lightning/src/ln/features.rs +++ b/lightning/src/ln/features.rs @@ -751,6 +751,8 @@ macro_rules! impl_feature_tlv_write { } impl_feature_tlv_write!(ChannelTypeFeatures); +impl_feature_tlv_write!(OfferFeatures); +impl_feature_tlv_write!(InvoiceRequestFeatures); // Some features may appear both in a TLV record and as part of a TLV subtype sequence. The latter // requires a length but the former does not. @@ -872,11 +874,11 @@ mod tests { assert_eq!(features.flags.len(), 8); let mut serialized_features = Vec::new(); - WithoutLength(&features).write(&mut serialized_features).unwrap(); + features.write(&mut serialized_features).unwrap(); assert_eq!(serialized_features.len(), 8); let deserialized_features = - WithoutLength::<OfferFeatures>::read(&mut &serialized_features[..]).unwrap().0; + OfferFeatures::read(&mut &serialized_features[..]).unwrap(); assert_eq!(features, deserialized_features); } diff --git a/lightning/src/offers/invoice_request.rs b/lightning/src/offers/invoice_request.rs index fc2b90f8..46f7b626 100644 --- a/lightning/src/offers/invoice_request.rs +++ b/lightning/src/offers/invoice_request.rs @@ -408,7 +408,7 @@ impl Writeable for InvoiceRequestContents { tlv_stream!(InvoiceRequestTlvStream, InvoiceRequestTlvStreamRef, 80..160, { (80, chain: ChainHash), (82, amount: (u64, HighZeroBytesDroppedBigSize)), - (84, features: (InvoiceRequestFeatures, WithoutLength)), + (84, features: InvoiceRequestFeatures), (86, quantity: (u64, HighZeroBytesDroppedBigSize)), (88, payer_id: PublicKey), (89, payer_note: (String, WithoutLength)), diff --git a/lightning/src/offers/offer.rs b/lightning/src/offers/offer.rs index d92d0d8b..04acc4da 100644 --- a/lightning/src/offers/offer.rs +++ b/lightning/src/offers/offer.rs @@ -578,7 +578,7 @@ tlv_stream!(OfferTlvStream, OfferTlvStreamRef, 1..80, { (6, currency: CurrencyCode), (8, amount: (u64, HighZeroBytesDroppedBigSize)), (10, description: (String, WithoutLength)), - (12, features: (OfferFeatures, WithoutLength)), + (12, features: OfferFeatures), (14, absolute_expiry: (u64, HighZeroBytesDroppedBigSize)), (16, paths: (Vec<BlindedPath>, WithoutLength)), (18, issuer: (String, WithoutLength)),

That is expected because impl_feature_tlv_write should be equivalent. I suppose ideally we get rid of the macro and make it explicit for ChannelTypeFeatures.

I'm confused why get rid of the macro, it seems cleaner to have it and avoid WithoutLength in the offers code 🤔

Seems confusing if Features encoding were determined by the type of features rather than the context in which they are encoded. While features for the BOLT 12 message are currently only encoded inside a TLV record, that may not always be the case. Better to have the context be explicit about the encoding than to decide now on how the features must be encoded in all contexts, even unknown future contexts.

Aren't all features encoded the same everywhere except this weird blinded payinfo one? Seems weird to make several callsites uglier because of one exception, or at least better to do them all on one go rather than have a few flexible exceptions for offers-related feature sets only. Don't think it's weird enough to hold up the PR but just trying to clarify.

There are two cases where the length needs to be included with the features:

Non-TLV message fields (e.g., features in init, node_announcement, and channel_announcement messages)

TLV records whose value is a collection of a subtype, each containing features (e.g., features in the blinded_payinfo subtype)

The second case is more generally necessary when the subtype contains any variable-length field (e.g., the witness program in fallback addresses). Otherwise, there is no way to tell the length of each element in the collection. See last paragraph in https://github.com/lightning/bolts/blob/master/01-messaging.md#rationale-1.

For BOLT 12, yes, only features in blinded_payinfo need the length as they fall under the second case above. But that's not to say that any of the other feature types won't be used in a similar scenario in the future.

Oh, I just meant that for any given feature set X with the exception of blinded_payinfo_features, X will always be encoded the same way.

But that's not to say that any of the other feature types won't be used in a similar scenario in the future.

I just don't see what that scenario would be 🤔 this seems like a one-off weird one.

At very least, if there is a such a scenario, the compiler would complain. Whereas it won't complain when defining the serialization with impl_feature_tlv_write.

TheBlueMatt · 2022-12-21T17:15:22Z

lightning/src/offers/refund.rs

@@ -285,7 +285,9 @@ impl Refund {
 		&self.contents.features
 	}

-	/// A possibly transient pubkey used to sign the refund.
+	/// A possibly transient pubkey used for the node to send to if there are no [`paths`].


I'm not a huge fan of this phrasing, no. If its not transient, the docs dont tell you what you should use (node_id), at a minimum.

TheBlueMatt · 2022-12-21T17:19:53Z

lightning/src/offers/offer.rs

+		match self.amount {
+			None => 0,
+			Some(Amount::Bitcoin { amount_msats }) => amount_msats,
+			Some(Amount::Currency { .. }) => unreachable!(),


unreachable!() branches indicates our data model is incorrect - if we aren't going to support Currency amounts, then we shouldn't store them (Offer should just store a u64). We can change that storage model later.

We still need to be able to parse a semantically valid offer. It's really that we can't create an InvoiceRequest (which shares OfferContent) from an Offer with a currency. I could make this return an Option or Result, but that just kicks the problem to the caller. Figured it would better to have this code near the code that checks for currency support.

I think we should just refuse to parse an offer if the amount is a currency. Parsing an offer and not being able to create an InvoiceRequest for it is basically useless, no? Let's just fix our data storage to be consistent with our assumptions so we don't have panics and unreachables lying around.

Alternatiely, we could check for the value and store it in the InvoiceRequest, which is probably what we'll want when we do add currency support anyway - store the msat conversion in InvoiceRequest. That will also avoid an unwrap/unreachable.

I think we should just refuse to parse an offer if the amount is a currency. Parsing an offer and not being able to create an InvoiceRequest for it is basically useless, no? Let's just fix our data storage to be consistent with our assumptions so we don't have panics and unreachables lying around.

I don't think we want to limit LDK in that manner. Someone may want to use it, for instance, to create a BOLT 12 offer equivalent of https://lightningdecoder.com/.

Alternatiely, we could check for the value and store it in the InvoiceRequest, which is probably what we'll want when we do add currency support anyway - store the msat conversion in InvoiceRequest. That will also avoid an unwrap/unreachable.

We need to support an InvoiceRequest without an amount set. Storing it would cause the value returned by InvoiceRequestContents::as_tlv_stream to be inaccurate, and thus break the signature calculation.

I can move the code back to InvoiceRequest::amount_msats if you prefer. Then at very least we can't accidentally call it from inside Offer.

Since OfferContents has an optional Amount, InvoiceRequestBuilder::new would need to take an (optional?) amount for when that is None. Otherwise, it's unclear what the builder should initialize InvoiceRequestContents::amount_msats to. But when the offer does have an amount, it would be strange to require that the user supply an amount when constructing the builder or even pass None if the parameter is an Option rather than them just explicitly calling InvoiceRequestBuilder::amount_msats only if they want to give a larger amount than necessary.

Won't it need to do that when we get to currency conversion anyway? We could have two methods, one which does not do currency conversion (and fails if no amount is passed and there isn't an amount in the offer) and one which takes an explicit amount and checks it?

But why add this complexity -- and what would be required in the builder and parsing code mentioned above -- when we don't need to?

Because we need to to make the data model match the reality of what's going on to avoid unnecessary panics? Having a check to figure out what to write in the serialization logic is way cleaner than adding additional preconditions we have to enforce at construction plus deserialization :).

And the unreachable is only temporary.

I'm confused, how is the unreachable temporary? We need it until we add an amount in the InvoiceRequest{,Contents} to support currencies.

Also note, for the currency case, during building we'd end up having the user pass in an amount in new but then we'd need to do some sort of check in sign to determine if as_tlv_stream should use Some or None for the amount. And that check would need to take into account the exchange rate, which may be different from when the builder is first constructed, unless we want to assume a constant exchange rate across the life of the builder.

I assume a builder only exists for a few seconds at max, not sure why we can't assume an exchange rate doesn't change during that time.

I'd much prefer the simpler approach over this. I'm not opposed to considering a concrete patchset that you think would be acceptable. I'm just not seeing why all this the added complexity is desirable.

I'm not seeing what the "simpler approach" is here?

Won't it need to do that when we get to currency conversion anyway? We could have two methods, one which does not do currency conversion (and fails if no amount is passed and there isn't an amount in the offer) and one which takes an explicit amount and checks it?

A user only needs to set an amount if they want to pay more than the expected amount (or if the offer didn't contain an amount). AFAICT, the reader of the invoice request (i.e., payee) is the one that determines if this amount is sufficient when taking into account currency conversions.

So when the offer has an amount (currency or not), the normal case is to not set an amount in the invoice request. It's only when receiving an invoice does the payer check if they are happy with the exchange rate given by the payee.

Because we need to to make the data model match the reality of what's going on to avoid unnecessary panics?

IIUC, the data model is "set an amount invoice request if you want to tip / obscure the amount" not "set an amount in invoice request that you are willing to pay". i.e., currency conversion only matters insomuch that you want to tip / obscure the amount of an offer with a currency denomination.

The panic is only there because we don't currently support currencies. It disappears once we do. In fact, the code in question is only needed when creating an invoice and thus could be moved entirely there without any changes to InvoiceRequest or OfferContents. Much of the discussion around the data model is resulting from the reuse of the "contents" types across higher-level structures.

Having a check to figure out what to write in the serialization logic is way cleaner than adding additional preconditions we have to enforce at construction plus deserialization :).

I'm not sure I follow this point. Which additional preconditions?

I'm confused, how is the unreachable temporary? We need it until we add an amount in the InvoiceRequest{,Contents} to support currencies.

Yeah, that's what I meant by temporary.

I assume a builder only exists for a few seconds at max, not sure why we can't assume an exchange rate doesn't change during that time.

Fair point. But note my point above about there shouldn't really need to care about any of this at InvoiceRequest creation time. It's only important after reading and deciding whether to respond with an Invoice.

I'm not seeing what the "simpler approach" is here?

Leaving the code as is. 🙂

Or moving the checks into InvoiceBuilder rather than trying to "reuse" InvoiceRequest and OfferContents.

Followed up offline, there was a good bit of confusion as to what the amount field in the invoice_request is even for (tldr: basically nothing) and also where the currency conversion has to happen.

Discussed offline. Since we only support non-currency offers, we can check the Offer::amount in InvoiceBuilder::for_offer and return an error if the InvoiceRequest is for an Offer with a currency. So I can drop the related commit and fixup from this PR.

The reasoning around this is that the payer does not need to care about conversion in the typical InvoiceRequest case. It's the payee who will need to convert to msats when building an Invoice. The payer should only need to deal with msats.

However, the payer's app may display the currency-to-msats conversion for the offer (and the opposite for the invoice) to the user before paying. We'll need to carefully document the payment flow so users are aware of how this is intended to work.

Updated both PRs accordingly.

TheBlueMatt · 2022-12-21T17:22:14Z

lightning/src/ln/features.rs

 			}
 		}
 		impl Readable for $features {
 			fn read<R: io::Read>(r: &mut R) -> Result<Self, DecodeError> {
-				let v = io_extras::read_to_end(r)?;
-				Ok(Self::from_be_bytes(v))
+				Ok(WithoutLength::<Self>::read(r)?.0)
 			}
 		}
 	}
 }

 impl_feature_tlv_write!(ChannelTypeFeatures);


Should we not change this too? I guess it can wait to avoid conflicting with #1860, but we should probably avoid having two paths for this, no?

Yeah, noted in response to Val as well, we probably want to drop impl_feature_tlv_write and make the encoding explicit. Would require allowing encodings in impl_writeable_msg, which I think would mostly just work.

TheBlueMatt · 2023-01-04T23:12:49Z

lightning/src/offers/refund.rs

@@ -102,8 +102,8 @@ pub struct RefundBuilder {
 }

 impl RefundBuilder {
-	/// Creates a new builder for a refund using the [`Refund::payer_id`] for signing invoices. Use
-	/// a different pubkey per refund to avoid correlating refunds.
+	/// Creates a new builder for a refund using the [`Refund::payer_id`] for the node to send to


ISTM this should use the term node_id, to highlight that it should be that field if no paths are set.

Hmm... pushed a fixup but, IIRC, I chose payer_id because it seemed more general (and what is used in the spec) whereas node_id is specific to the "no paths" case.

Did you mean to change it only on RefundBuilder::new or throughout the file?

Oops, lol, sorry, no, I meant just in the docs here, not overall - I like the payer_id, but if we're gonna tell people that this is only an ephemeral key if no paths are provided, we should tell them what the key is otherwise (the node_id).

valentinewallace · 2023-01-05T16:30:04Z

Feel free to squash, I think it's good to go

TheBlueMatt · 2023-01-05T22:45:50Z

See comment at #1927 (comment)

The docs incorrectly stated that Refund::payer_id is for signing, where it is only used for identifying a node if Refund::paths is not present.

Refunds don't have signatures and now use their own abstraction. Therefore, signatures can be required in invoice requests as per the spec.

Most BOLT 12 features are used as the value of a TLV record and thus don't use an explicit length. One exception is the features inside the blinded payinfo subtype since the TLV record contains a list of them. However, these features are also used in the BOLT 4 encrypted_data_tlv TLV stream as a single record, where the length is implicit. Implement Readable and Writeable for Features wrapped in WithoutLength such that either serialization can be used where required.

BOLT 12 invoices may contain blinded_payinfo for each hop in a blinded path. Each blinded_payinfo contains features, whose length must be encoded since there may be multiple hops. Note these features are also needed in the BOLT 4 encrypted_data_tlv stream. But since they are a single TLV record, the length must *not* be encoded there.

0.0.114 - Mar 3, 2023 - "Faster Async BOLT12 Retries" API Updates =========== * `InvoicePayer` has been removed and its features moved directly into `ChannelManager`. As such it now requires a simplified `Router` and supports `send_payment_with_retry` (and friends). `ChannelManager::retry_payment` was removed in favor of the automated retries. Invoice payment utilities in `lightning-invoice` now call the new code (lightningdevkit#1812, lightningdevkit#1916, lightningdevkit#1929, lightningdevkit#2007, etc). * `Sign`/`BaseSign` has been renamed `ChannelSigner`, with `EcdsaChannelSigner` split out in anticipation of future schnorr/taproot support (lightningdevkit#1967). * The catch-all `KeysInterface` was split into `EntropySource`, `NodeSigner`, and `SignerProvider`. `KeysManager` implements all three (lightningdevkit#1910, lightningdevkit#1930). * `KeysInterface::get_node_secret` is now `KeysManager::get_node_secret_key` and is no longer required for external signers (lightningdevkit#1951, lightningdevkit#2070). * A `lightning-transaction-sync` crate has been added which implements keeping LDK in sync with the chain via an esplora server (lightningdevkit#1870). Note that it can only be used on nodes that *never* ran a previous version of LDK. * `Score` is updated in `BackgroundProcessor` instead of via `Router` (lightningdevkit#1996). * `ChainAccess::get_utxo` (now `UtxoAccess`) can now be resolved async (lightningdevkit#1980). * BOLT12 `Offer`, `InvoiceRequest`, `Invoice` and `Refund` structs as well as associated builders have been added. Such invoices cannot yet be paid due to missing support for blinded path payments (lightningdevkit#1927, lightningdevkit#1908, lightningdevkit#1926). * A `lightning-custom-message` crate has been added to make combining multiple custom messages into one enum/handler easier (lightningdevkit#1832). * `Event::PaymentPathFailure` is now generated for failure to send an HTLC over the first hop on our local channel (lightningdevkit#2014, lightningdevkit#2043). * `lightning-net-tokio` no longer requires an `Arc` on `PeerManager` (lightningdevkit#1968). * `ChannelManager::list_recent_payments` was added (lightningdevkit#1873). * `lightning-background-processor` `std` is now optional in async mode (lightningdevkit#1962). * `create_phantom_invoice` can now be used in `no-std` (lightningdevkit#1985). * The required final CLTV delta on inbound payments is now configurable (lightningdevkit#1878) * bitcoind RPC error code and message are now surfaced in `block-sync` (lightningdevkit#2057). * Get `historical_estimated_channel_liquidity_probabilities` was added (lightningdevkit#1961). * `ChannelManager::fail_htlc_backwards_with_reason` was added (lightningdevkit#1948). * Macros which implement serialization using TLVs or straight writing of struct fields are now public (lightningdevkit#1823, lightningdevkit#1976, lightningdevkit#1977). Backwards Compatibility ======================= * Any inbound payments with a custom final CLTV delta will be rejected by LDK if you downgrade prior to receipt (lightningdevkit#1878). * `Event::PaymentPathFailed::network_update` will always be `None` if an 0.0.114-generated event is read by a prior version of LDK (lightningdevkit#2043). * `Event::PaymentPathFailed::all_paths_removed` will always be false if an 0.0.114-generated event is read by a prior version of LDK. Users who rely on it to determine payment retries should migrate to `Event::PaymentFailed`, in a separate release prior to upgrading to LDK 0.0.114 if downgrading is supported (lightningdevkit#2043). Performance Improvements ======================== * Channel data is now stored per-peer and channel updates across multiple peers can be operated on simultaneously (lightningdevkit#1507). * Routefinding is roughly 1.5x faster (lightningdevkit#1799). * Deserializing a `NetworkGraph` is roughly 6x faster (lightningdevkit#2016). * Memory usage for a `NetworkGraph` has been reduced substantially (lightningdevkit#2040). * `KeysInterface::get_secure_random_bytes` is roughly 200x faster (lightningdevkit#1974). Bug Fixes ========= * Fixed a bug where a delay in processing a `PaymentSent` event longer than the time taken to persist a `ChannelMonitor` update, when occurring immediately prior to a crash, may result in the `PaymentSent` event being lost (lightningdevkit#2048). * Fixed spurious rejections of rapid gossip sync data when the graph has been updated by other means between gossip syncs (lightningdevkit#2046). * Fixed a panic in `KeysManager` when the high bit of `starting_time_nanos` is set (lightningdevkit#1935). * Resolved an issue where the `ChannelManager::get_persistable_update_future` future would fail to wake until a second notification occurs (lightningdevkit#2064). * Resolved a memory leak when using `ChannelManager::send_probe` (lightningdevkit#2037). * Fixed a deadlock on some platforms at least when using async `ChannelMonitor` updating (lightningdevkit#2006). * Removed debug-only assertions which were reachable in threaded code (lightningdevkit#1964). * In some cases when payment sending fails on our local channel retries no longer take the same path and thus never succeed (lightningdevkit#2014). * Retries for spontaneous payments have been fixed (lightningdevkit#2002). * Return an `Err` if `lightning-persister` fails to read the directory listing rather than panicing (lightningdevkit#1943). * `peer_disconnected` will now never be called without `peer_connected` (lightningdevkit#2035) Security ======== 0.0.114 fixes several denial-of-service vulnerabilities which are reachable from untrusted input from channel counterparties or in deployments accepting inbound connections or channels. It also fixes a denial-of-service vulnerability in rare cases in the route finding logic. * The number of pending un-funded channels as well as peers without funded channels is now limited to avoid denial of service (lightningdevkit#1988). * A second `channel_ready` message received immediately after the first could lead to a spurious panic (lightningdevkit#2071). This issue was introduced with 0conf support in LDK 0.0.107. * A division-by-zero issue was fixed in the `ProbabilisticScorer` if the amount being sent (including previous-hop fees) is equal to a channel's capacity while walking the graph (lightningdevkit#2072). The division-by-zero was introduced with historical data tracking in LDK 0.0.112. In total, this release features 130 files changed, 21457 insertions, 10113 deletions in 343 commits from 18 authors, in alphabetical order: * Alec Chen * Allan Douglas R. de Oliveira * Andrei * Arik Sosman * Daniel Granhão * Duncan Dean * Elias Rohrer * Jeffrey Czyz * John Cantrell * Kurtsley * Matt Corallo * Max Fang * Omer Yacine * Valentine Wallace * Viktor Tigerström * Wilmer Paulino * benthecarman * jurvis

jkczyz mentioned this pull request Dec 20, 2022

BOLT 12 invoice encoding and building #1926

Merged

jkczyz requested review from valentinewallace and TheBlueMatt December 20, 2022 19:05

valentinewallace reviewed Dec 20, 2022

View reviewed changes

jkczyz force-pushed the 2022-12-invoice-rework branch from 43b14cd to 5955bdd Compare December 21, 2022 16:52

valentinewallace reviewed Dec 21, 2022

View reviewed changes

TheBlueMatt reviewed Dec 21, 2022

View reviewed changes

jkczyz force-pushed the 2022-12-invoice-rework branch from 5955bdd to 30e3ccc Compare January 4, 2023 22:26

TheBlueMatt previously approved these changes Jan 4, 2023

View reviewed changes

TheBlueMatt assigned TheBlueMatt and valentinewallace Jan 4, 2023

jkczyz dismissed TheBlueMatt’s stale review via 498cf1a January 5, 2023 04:20

jkczyz force-pushed the 2022-12-invoice-rework branch from 30e3ccc to 498cf1a Compare January 5, 2023 04:20

jkczyz added 5 commits January 5, 2023 22:38

Correct documentation about Refund::payer_id

7964b9f

The docs incorrectly stated that Refund::payer_id is for signing, where it is only used for identifying a node if Refund::paths is not present.

Remove Option from InvoiceRequest::signature

1a437f4

Refunds don't have signatures and now use their own abstraction. Therefore, signatures can be required in invoice requests as per the spec.

Define BOLT 12 invoice features with MPP support

d985ced

jkczyz force-pushed the 2022-12-invoice-rework branch from 498cf1a to b50fc4e Compare January 6, 2023 04:39

TheBlueMatt approved these changes Jan 6, 2023

View reviewed changes

valentinewallace approved these changes Jan 6, 2023

View reviewed changes

valentinewallace merged commit d8a20ed into lightningdevkit:main Jan 6, 2023

jkczyz mentioned this pull request May 10, 2023

BOLT12 Offers Tracking Issue #1970

Open

60 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pre-work for BOLT 12 invoices #1927

Pre-work for BOLT 12 invoices #1927

jkczyz commented Dec 20, 2022 •

edited

Loading

codecov-commenter commented Dec 20, 2022 •

edited by codecov bot

Loading

valentinewallace left a comment

valentinewallace Dec 20, 2022

jkczyz Dec 20, 2022

valentinewallace Dec 21, 2022

TheBlueMatt Dec 21, 2022

jkczyz Dec 21, 2022

TheBlueMatt Dec 21, 2022

valentinewallace Dec 21, 2022

jkczyz Dec 21, 2022

valentinewallace Dec 21, 2022

jkczyz Dec 21, 2022

valentinewallace Dec 21, 2022

jkczyz Dec 21, 2022

valentinewallace Dec 21, 2022

jkczyz Dec 21, 2022

TheBlueMatt Dec 21, 2022

TheBlueMatt Dec 21, 2022

jkczyz Dec 21, 2022

TheBlueMatt Dec 21, 2022

TheBlueMatt Dec 21, 2022

jkczyz Dec 21, 2022

TheBlueMatt Jan 4, 2023

jkczyz Jan 4, 2023

TheBlueMatt Jan 4, 2023

jkczyz Jan 4, 2023

jkczyz Jan 4, 2023

TheBlueMatt Dec 21, 2022

jkczyz Dec 21, 2022

TheBlueMatt Jan 4, 2023

jkczyz Jan 5, 2023

TheBlueMatt Jan 5, 2023

valentinewallace commented Jan 5, 2023

TheBlueMatt commented Jan 5, 2023

		impl_feature_tlv_write!(OfferFeatures);
		impl_feature_tlv_write!(InvoiceRequestFeatures);

Pre-work for BOLT 12 invoices #1927

Pre-work for BOLT 12 invoices #1927

Conversation

jkczyz commented Dec 20, 2022 • edited Loading

codecov-commenter commented Dec 20, 2022 • edited by codecov bot Loading

Codecov Report

valentinewallace left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

valentinewallace commented Jan 5, 2023

TheBlueMatt commented Jan 5, 2023

jkczyz commented Dec 20, 2022 •

edited

Loading

codecov-commenter commented Dec 20, 2022 •

edited by codecov bot

Loading