Skip to content

Conversation

@TheBlueMatt
Copy link
Collaborator

Note that this is against main so will need to be backported.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Oct 16, 2025

I've assigned @joostjager 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 TheBlueMatt added this to the 0.2 milestone Oct 16, 2025
@codecov
Copy link

codecov bot commented Oct 16, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.86%. Comparing base (05f2848) to head (b2d9dac).
⚠️ Report is 71 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4163      +/-   ##
==========================================
+ Coverage   88.78%   88.86%   +0.07%     
==========================================
  Files         180      180              
  Lines      137004   137863     +859     
  Branches   137004   137863     +859     
==========================================
+ Hits       121642   122512     +870     
- Misses      12538    12543       +5     
+ Partials     2824     2808      -16     
Flag Coverage Δ
fuzzing 20.85% <100.00%> (-0.11%) ⬇️
tests 88.70% <100.00%> (+0.07%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@joostjager joostjager left a comment

Choose a reason for hiding this comment

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

I was assigned by the bot, but as @TheBlueMatt mentioned in the meet, everyone should really check their contributions here.

NIce concise changelogs

/// initialized with
/// Indicates that an onion message supporting peer has come online and any messages previously
/// stored for them (from [`Event::OnionMessageIntercepted`]s) should be forwarded to them by
/// calling [`OnionMessenger::forward_onion_message`].
Copy link
Contributor

Choose a reason for hiding this comment

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

Good addition, wasn't clear indeed that forward_onion_message needs to be called.


## API Updates

* Splicing is now supported. The current implementation is expected to be
Copy link
Contributor

Choose a reason for hiding this comment

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

Curious why it says "expected". Isn't interop confirmed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We have not had time to do interop testing, no. We will likely do some before the release but probably not a ton.

CHANGELOG.md Outdated
`UserConfig::reject_inbound_splices` can be set to block inbound ones (#4150)
* LDK now requires the `channel_type` feature in line with spec updates (#3896)

XXX release stats
Copy link
Contributor

Choose a reason for hiding this comment

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

Reminder to update. Maybe XXX is part of the process?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yea, will do it once we get the other PRs landed.

CHANGELOG.md Outdated
@@ -1,3 +1,154 @@
# 0.2 - XXX, 2025 - "Natively Asynchronous Splicing"
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be nice to add a bit of a sales pitch here? Example AI slop:

LDK 0.2 – “Natively Asynchronous Splicing” is here, delivering the future of Lightning development today. Splicing support has landed, letting you resize channels on the fly, with native async APIs across the stack for faster, cleaner, and more efficient operations. Async payments are now live too, enabling smoother BOLT 12 flows for often-offline users and LSPs. Zero-Fee-Commitment channels slash feerate headaches, while new LSPS and RGS features power next-gen liquidity and performance. With major speed boosts, deeper diagnostics, and smarter persistence, LDK 0.2 is your all-in-one upgrade for a faster, more flexible Lightning future.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We historically haven't, letting the API Updates section speak for itself (its roughly sorted in "importance" order so splicing and async and async payments are right at the top). We did for 0.1 just given we were starting to do backports and wanted to describe that. We do use this kinda pitch for the release announcement tho.

`ChannelManager::splice_channel` initiates a splice which
ultimately generates a series of events. The most important of
which, `FundingTransactionReadyForSigning` (which must always be
handled, unlike the others), was not documented.

Here we mention the event generation.
Users implementing the "onion message mailbox" feature and handling
`OnionMessageIntercepted` events need to also handle
`Event::OnionMessagePeerConnected` events.

Here we update the event docs for both to add additional references
and be more explicit about what implementors need to do.
@TheBlueMatt
Copy link
Collaborator Author

TheBlueMatt commented Oct 29, 2025

Okay, went ahead and squashed with the following changes, I think we can go ahead and land this as draft release notes, backport it, and we'll be about ready for an 0.2-rc.

$ git diff-tree -U1 a5acf3c27 b2d9dacf81
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8614fc6948..b4839d6423 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,2 +1,2 @@
-# 0.2 - XXX, 2025 - "Natively Asynchronous Splicing"
+# 0.2 - TODO: Add release date, 2025 - "Natively Asynchronous Splicing"

@@ -39,5 +39,8 @@
    force-closure risk for feerate disagreements by using a fixed, zero fee on
-   presigned transactions, relying on anchor bumps instead. This only works with
-   LDK peers, and feature signaling may change in a future version of LDK,
-   breaking compatibility. This is negotiated automatically for
+   presigned transactions, relying on anchor bumps instead. They also utilize
+   the new TRUC + ephemeral dust policy in Bitcoin Core 29 to substantially
+   improve the lightning security model. This requires having a path of Bitcoin
+   Core 29+ nodes between you and a miner for transactions to be mined. This
+   only works with LDK peers, and feature signaling may change in a future
+   version of LDK, breaking compatibility. This is negotiated automatically for
    manually-accepted inbound channels and negotiated for outbound channels based
@@ -94,2 +97,7 @@
  * `lightning-liquidity` now supports persisting relevant state (#4059, #4118).
+ * `ChannelManager::funding_transaction_generated_manual_broadcast` was added to
+   open a channel without automatically broadcasting the funding transaction
+   (#3838). In it and `unsafe_manual_funding_transaction_generated`
+   force-closure logic has been updated to no longer automatically broadcast the
+   commitment tx unless the funding transaction has been seen on-chain (#4109).
  * Various instances of channel closure which provided a
@@ -134,2 +142,5 @@
    `ListProtocols` message (#3785).
+ * A rare race which might lead `PeerManager` (and `lightning-net-tokio`) to
+   stop reading from a peer until a new message is sent to that peer has been
+   fixed (#4168).
  * The fields in `SocketAddress::OnionV3` are now corectly parsed, and the
@@ -168,3 +179,3 @@

-XXX release stats
+TODO release stats

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants