Skip to content

Conversation

tnull
Copy link
Collaborator

@tnull tnull commented Jan 27, 2025

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

tnull added 7 commits January 27, 2025 13:28
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.
@tnull
Copy link
Collaborator Author

tnull commented Oct 9, 2025

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).

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.

Expose on-chain transactions in events
1 participant