Include onchain transactions in events #448
Conversation
Here, we move updating fields via `PaymentDetailsUpdate` to `PaymentDetails::update`. This allows us to only update the fields that changed, keeping track *whether* something changed, and only updating the timestamp and persisting the entry *if* something changed. This is a nice improvement in general (as we want to reduce persist calls anyways), but we'll also use this for batch updates in the next commits.
We implement a batch updating method that will only persist entries that have been changed.
Previously, `PaymentKind::Onchain` was simply a placeholder entry we never actually used. Here, we extend it to include fields that are actually useful.
We update the payment store whenever syncing the wallet state finished.
…events .. two new events that we're emitting when we sent or received an onchain payment, i.e., the transactions reached ANTI_REORG_DELAY confirmations.
|
While the latest BDK 2.2 now shipped event (which would make emitting events easier on our end), we still need lightningdevkit/rust-lightning#3566 to properly classify the transactions in our store. So this remains blocked until the latter ships (likely with LDK 0.3). |
Is there a way we could get this into ldk-node sooner?
The team seems to lean towards favoring option 3, which is not ideal IMHO, but the main argument is that we don't really have the time to go any other route. The issue that I see from my PoV is that option 2 might even seem faster. Could 2 be an option? |
2 participants
Closes #446.
Based on #432.
In #432 we exposed transactions in store. Here we take a stab at exposing them via events. However, to avoid emitting duplicate events for channel-related transactions, this is in draft until we have lightningdevkit/rust-lightning#3566