Skip to content

Conversation

@Camillarhi
Copy link
Contributor

@Camillarhi Camillarhi commented Oct 9, 2025

This PR updates update_payment_store to use BDK 2.2’s WalletEvent stream during sync instead of iterating over the full list of wallet transactions every time. The new event-based approach reduces redundant work and ensures the payment store stays in sync with only the changes that actually occurred.

It also sets up the foundation for RBF support in #628 with WalletEvent::TxReplaced. Since #628 depends on this event handling, this PR should be merged first.

This PR will also address #452

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Oct 9, 2025

👋 Thanks for assigning @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.

@Camillarhi Camillarhi force-pushed the payment-store-events-sync branch 9 times, most recently from 75ff700 to d3f7855 Compare October 15, 2025 20:32
@Camillarhi Camillarhi marked this pull request as ready for review October 15, 2025 20:35
@ldk-reviews-bot ldk-reviews-bot requested a review from tnull October 15, 2025 20:36
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 4th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 5th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 6th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

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.

Excuse the delay here!

Unfortunately I don't think we can make the move until we get corresponding functionality for all chain sources, i.e., also for bitcoind/apply_block. Will raise that with the BDK folks to make some progress.

I now opened bitcoindevkit/bdk_wallet#336 to add the missing APIs we need. In the meantime we can see to get this as close to being mergeable as possible.

})?;

self.update_payment_store(&mut *locked_wallet).map_err(|e| {
let events_vec: Vec<WalletEvent> = events.into_iter().collect();
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think this re-allocation is necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! I have removed the re-allocation

@@ -723,7 +943,7 @@ impl Listen for Wallet {

match locked_wallet.apply_block(block, height) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ugh, seems there is no corresponding apply_block_events method. I think we need that before actually moving forward here. Will raise it with the BDK folks.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I saw that the PR on BDK wallet has been merged and added to the next release milestone. This will be updated as soon as there is a new release on BDK wallet

}

self.payment_store
.list_filter(|p| {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, ugh, that's already slow right now, but will be prohibitively slow when we don't keep our entire payment store in-memory. I think we can't get around adding another persisted lookup table that tracks RBF-Txid to original-Txid.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this is true, if we have another table, the lookup will be faster and the original Txid can be updated when the RBF-Txid for example, has a confirmed event from BDK

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@tnull, I created a new persisted ReplacedTransactionStore that maintains lookups from any txid in an RBF chain to its associated payment. Store entries are automatically cleaned up when any transaction in the chain confirms. This keeps lookups fast even with large payment histories.

Copy link
Collaborator

@tnull tnull Nov 6, 2025

Choose a reason for hiding this comment

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

@tnull, I created a new persisted ReplacedTransactionStore that maintains lookups from any txid in an RBF chain to its associated payment. Store entries are automatically cleaned up when any transaction in the chain confirms. This keeps lookups fast even with large payment histories.

Huh, why do we need a whole other module/store for this? Let's just use a HashMap<Txid, Txid> and be done with it? Or do we need all that additionally tracked data somehow?

I guess we could use a DataStore implementation for this, but I don't quite see why we need to track ConfirmationStatus and latest_update_timestamp?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Huh, why do we need a whole other module/store for this? Let's just use a HashMap<Txid, Txid> and be done with it? Or do we need all that additionally tracked data somehow?

Yes, we need to track this data for faster lookup of replaced transaction IDs instead of a full iteration

I guess we could use a DataStore implementation for this, but I don't quite see why we need to track ConfirmationStatus and latest_update_timestamp?

You are right about the ConfirmationStatus and latest_update_timestamp, they were part of my original design, and as I proceeded with my implementation, I decided to clean the store instead upon confirmation of any of the transactions. I will go ahead and remove them. I also used a DataStore implementation for this.

@Camillarhi Camillarhi force-pushed the payment-store-events-sync branch from d3f7855 to a2c8a55 Compare October 29, 2025 16:08
@Camillarhi Camillarhi requested a review from tnull November 6, 2025 02:34
@Camillarhi Camillarhi force-pushed the payment-store-events-sync branch 2 times, most recently from ecaae51 to 8609d97 Compare November 6, 2025 10:58
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 4th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 5th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 6th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@tnull
Copy link
Collaborator

tnull commented Jan 13, 2026

Thanks for the suggestion. You're right. I initially thought list_filter was only checking for the filtered records, but it actually iterates through the entire payment store.
I'll create a PendingPaymentStore that tracks pending payments and replaced txids together. When we get an WalletEvent::TxUnconfirmed event, the payment will be created in the pending store first. Once it reaches ANTI_REORG_DELAY confirmations, it will be created in the main PaymentStore and removed from the pending store. This keeps both stores small and iteration fast.

Cool! Note that we might still want to keep the pending payments in the main store though, as list_payments should continue to return the PENDING entries. Otherwise you'd need to construct the entries on-the-fly from both stores, which I imagine could be more complicated than tracking the same entries twice. But let me know if you find that it works out otherwise.

Please ping me when you switched to the new approach and this is ready for another round of review.

@tnull tnull removed their request for review January 13, 2026 11:36
@Camillarhi Camillarhi force-pushed the payment-store-events-sync branch 5 times, most recently from 862c5a7 to a677335 Compare January 13, 2026 14:42
@Camillarhi Camillarhi requested a review from tnull January 13, 2026 14:50
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 3rd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 4th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 5th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@ldk-reviews-bot
Copy link

🔔 6th Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

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.

Excuse the delay here once more. I was about to just land this and address my comments myself in a follow-up, however, it seems this needs a rebase by now. Would also be great to at least avoid the churn of first adding the replaced_txids field to then remove it in a later commit.

@Camillarhi Camillarhi force-pushed the payment-store-events-sync branch 2 times, most recently from 00b7edc to 76000df Compare January 26, 2026 12:45
@Camillarhi Camillarhi force-pushed the payment-store-events-sync branch from 76000df to 70288e6 Compare January 26, 2026 13:19
Track pending payments with their replaced/conflicting transaction IDs
in a separate store. Pending payments are created here on WalletEvent::TxUnconfirmed,
then removed once they reach ANTI_REORG_DELAY confirmations. This avoids
scanning the entire payment store and enables efficient cleanup.
…sactions

Replace the full transaction list scan in `update_payment_store` with
handling of BDK's `WalletEvent` stream during sync. This leverages the
new events in BDK 2.2, reduces redundant work, and prepares the
foundation for reliable RBF/CPFP tracking via `WalletEvent::TxReplaced`
@Camillarhi Camillarhi force-pushed the payment-store-events-sync branch from 70288e6 to 9f02ec0 Compare January 26, 2026 13:59
@Camillarhi Camillarhi requested a review from tnull January 26, 2026 14:03
@tnull tnull mentioned this pull request Jan 27, 2026
6 tasks
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.

Thanks for the rebase, I'm going ahead landing this. I opened #770 to track some follow-ups I'd like to address before the next 0.8 release (for simplicity will likely just pick them up myself).

@tnull tnull merged commit ba16c92 into lightningdevkit:main Jan 27, 2026
17 of 18 checks passed
@tnull tnull mentioned this pull request Jan 27, 2026
10 tasks
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