-
Couldn't load subscription status.
- Fork 421
Add 0.2 changelog (and quick missing spliec doc) #4163
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
base: main
Are you sure you want to change the base?
Conversation
|
I've assigned @joostjager as a reviewer! |
Codecov Report✅ All modified and coverable lines are covered by tests. 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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
4741bb1 to
596e650
Compare
There was a problem hiding this 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`]. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
8c3b4bd to
a5acf3c
Compare
`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.
db8b91b to
6bb3314
Compare
|
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 |
6bb3314 to
b2d9dac
Compare
Note that this is against main so will need to be backported.