Skip to content

Conversation

TheBlueMatt
Copy link

The BOLT 12 `quantity` field is incredibly unlikely to get any use
in practice (it assumes an online store which places some kind of
static offer for each item on its site, assuming that the merchant
doesn't want structured customer information nor the ability to
sell more than one item in a single order, both of which do not
exist in practice). Worse, supporting it requires an entire UI
flow built around the "quantity" concept, something which is a
nontrivial investment for downstream users of ldk-node.

Because the cost/utility tradeoff isn't nearly worth it, it was
dropped from the main offer-payment API in the upstream `lightning`
crate (requiring a separate
`ChannelManager::pay_for_offer_with_quantity` call).

For the same reason, we simply drop it from our API entirely here.
Absent someone who actually wants to use the `quantity` logic,
there is really no reason to support it.

Also upgrades to latest RL.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Sep 20, 2025

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@TheBlueMatt
Copy link
Author

Oops, I missed #639. Anyway, I think we should drop the quantity arguments.

The BOLT 12 `quantity` field is incredibly unlikely to get any use
in practice (it assumes an online store which places some kind of
static offer for each item on its site, assuming that the merchant
doesn't want structured customer information nor the ability to
sell more than one item in a single order, both of which do not
exist in practice). Worse, supporting it requires an entire UI
flow built around the "quantity" concept, something which is a
nontrivial investment for downstream users of ldk-node.

Because the cost/utility tradeoff isn't nearly worth it, it was
dropped from the main offer-payment API in the upstream `lightning`
crate (requiring a separate
`ChannelManager::pay_for_offer_with_quantity` call).

For the same reason, we simply drop it from our API entirely here.
Absent someone who actually wants to use the `quantity` logic,
there is really no reason to support it.
@TheBlueMatt TheBlueMatt force-pushed the 2025-09-upgrade-ldk branch 2 times, most recently from 7be11c3 to 938ac6d Compare September 21, 2025 00:07
Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I agree that quantity is very confusing, but given it's a BOLT12 feature that other implementations might use, I'm not fully sure if we can get rid of it? Are we certain this doesn't lead to even more interop issues / confusion down the line?

Also added a few comments, this will also need a rebase since we landed #639 first as per @joostjager's request to fix develop breakage ASAP to be able to make progress.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please drop these changes to the static Swift files. These will only be updated/regenerated during release (though here on develop it doesn't matter as much as on main, which are actually part of the SwiftPM dependency).

if let Some(qty) = quantity {
if qty == 0 {
log_error!(self.logger, "Failed to create offer: quantity can't be zero.");
return Err(Error::InvalidQuantity);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can now also drop the InvalidQuantity error variant.

match self.channel_manager.pay_for_offer(
&offer,
quantity,
if offer.expects_quantity() { Some(1) } else { None },
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this do the right thing internally w.r.t Quantity::One vs Quantity::Bounded(1)?

@tnull tnull changed the base branch from develop to main October 7, 2025 08:52
@tnull
Copy link
Collaborator

tnull commented Oct 7, 2025

We decided to make the develop behavior (tracking more-recent LDK main) the default behavior. With #655 we merged develop into main and now deleted the develop branch. Hence the base branch is changed to main here, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants