Bump rust-lightning to include trampoline changes#825
Bump rust-lightning to include trampoline changes#825carlaKC wants to merge 2 commits intolightningdevkit:mainfrom
Conversation
In the event of a quiescence tie-breaker, the losing side may contribute as the splice acceptor. A min and max feerate allows us to determine whether to contribute. We use 150% of the min feerate for the max feerate to allow for RBFs in upcoming changes.
|
👋 Hi! I see this is a draft PR. |
src/event.rs
Outdated
| /// A set of multiple htlcs all associated with same forward. | ||
| #[derive(Debug, Clone, PartialEq, Eq)] | ||
| #[cfg_attr(feature = "uniffi", derive(uniffi::Record))] | ||
| pub struct HTLCSet(Vec<HTLCLocator>); |
There was a problem hiding this comment.
Interested in some feedback here 🙏
To use default_value to fill in legacy fields when the new field isn't present, we need to implement Readable/Writeable for Vec<HTLCLocator>. We can't do this because we don't own the trait or the type (orphan rule).
The solution I've gone with here is to use a wrapper struct and pull in the code we have in impl_for_vec in LDK.
Alternatives would be:
- Don't use
default_value, and write manualReadable/Writeableimpls forEventso that we can manually fill the legacy values (I can't find a way to do it within macros). - Just use
required_vecand don't fill legacy values (seems bad).
| // For backwards compatibility, write the first prev/next_htlc to our legacy fields. This | ||
| // allows use to downgrade with some information loss about the remaining htlcs. |
There was a problem hiding this comment.
Not sure what the project's philosophy is for backwards compatibility, so just gone with what I would have done in LDK - happy to do something else if it's preferred!
9a813f7 to
76e3d44
Compare
76e3d44 to
dd42f5f
Compare
Depends on #824.
Also needs the following patch on top of 2026-02-ldk-node-base in
bitcoin-payment-instructions.