Skip to content

Re-export lightning-invoice as bolt11-invoice from lightning #3671

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

Merged
merged 1 commit into from
Mar 18, 2025

Conversation

TheBlueMatt
Copy link
Collaborator

Now that lightning depends on lightning-invoice, we should re-export it like we do bitcoin and types.

Now that `lightning` depends on `lightning-invoice`, we should
re-export it like we do `bitcoin` and `types`.
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Mar 17, 2025

I've assigned @valentinewallace 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.

Copy link
Contributor

@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.

LGTM, landing this as trivial.

@tnull tnull merged commit 592d9c7 into lightningdevkit:main Mar 18, 2025
26 of 27 checks passed
@TheBlueMatt
Copy link
Collaborator Author

Backported in #3697

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this pull request Apr 3, 2025
v0.1.2 - Apr 02, 2025 - "Foolishly Edgy Cases"

API Updates
===========

 * `lightning-invoice` is now re-exported as `lightning::bolt11_invoice`
   (lightningdevkit#3671).

Performance Improvements
========================

 * `rapid-gossip-sync` graph parsing is substantially faster, resolving a
   regression in 0.1 (lightningdevkit#3581).
 * `NetworkGraph` loading is now substantially faster and does fewer
   allocations, resulting in a 20% further improvement in `rapid-gossip-sync`
   loading when initializing from scratch (lightningdevkit#3581).
 * `ChannelMonitor`s for closed channels are no longer always re-persisted
   immediately after startup, reducing on-startup I/O burden (lightningdevkit#3619).

Bug Fixes
=========

 * BOLT 11 invoices longer than 1023 bytes long (and up to 7089 bytes) now
   properly parse (lightningdevkit#3665).
 * In some cases, when using synchronous persistence with higher latency than
   the latency to communicate with peers, when receiving an MPP payment with
   multiple parts received over the same channel, a channel could hang and not
   make progress, eventually leading to a force-closure due to timed-out HTLCs.
   This has now been fixed (lightningdevkit#3680).
 * Some rare cases with multi-hop BOLT 11 route hints or multiple redundant
   blinded paths could have led to the router creating invalid `Route`s were
   fixed (lightningdevkit#3586).
 * Corrected the decay logic in `ProbabilisticScorer`'s historical buckets
   model. Note that by default historical buckets are only decayed if no new
   datapoints have been added for a channel for two weeks (lightningdevkit#3562).
 * `{Channel,Onion}MessageHandler::peer_disconnected` will now be called if a
   different message handler refused connection by returning an `Err` from its
   `peer_connected` method (lightningdevkit#3580).
 * If the counterparty broadcasts a revoked state with pending HTLCs, those
   will now be claimed with other outputs which we consider to not be
   vulnerable to pinning attacks if they are not yet claimable by our
   counterparty, potentially reducing our exposure to pinning attacks (lightningdevkit#3564).
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