Skip to content

Improve 'Confirmed Transactions' section #157

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Aug 11, 2022
Merged

Improve 'Confirmed Transactions' section #157

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 21 additions & 12 deletions docs/blockchain_data/confirmed_transactions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,20 +4,29 @@ Up until this point, we've explored how to notify LDK of chain activity using
blocks. But what if you're sourcing chain activity from a place that doesn't
provide a block-centric interface, like Electrum?

LDK has a `chain::Confirm` interface to support this use case, analogous to the
block-oriented `chain::Listen` interface which we've been using up until now.
With this alternative approach, you still need to give LDK block headers, but
only for blocks containing transactions of interest. These are identified by
`chain::Filter` as before. You also need to notify LDK of any transactions with
insufficient confirmation that have been reorganized out of the chain. Use the
`transactions_confirmed` and `transaction_unconfirmed` methods, respectively.
LDK's `ChannelManager` and `ChainMonitor` implement a `chain::Confirm` interface to support this
use case, analogous to the block-oriented `chain::Listen` interface which we've been using up until
now. With this alternative approach, you still need to give LDK information about chain activity,
but only for transactions of interest. To this end, you must call `Confirm::transactions_confirmed`
when any transactions identified by `chain::Filter`'s `register_tx`/`register_output` methods are
confirmed.

Additionally, you must notify LDK whenever a new chain tip is available using
the `best_block_updated` method. See the documentation for a full picture of how
this interface is intended to be used.
You also need to notify LDK of any transactions with insufficient confirmations
that have been reorganized out of the chain. Transactions that need to be monitored for such
reorganization are returned by `Confirm::get_relevant_txids`. If any of these transactions become
unconfirmed, you must call `Confirm::transaction_unconfirmed`.

Lastly, you must notify LDK whenever a new chain tip is available using
the `Confirm::best_block_updated` method. See the documentation for a full
picture of how this interface is intended to be used.

::: tip Note
Note that the described methods of `Confirm` must be called both on the
`ChannelManager` *and* the `ChainMonitor`.
:::

::: tip Note
Be advised that `chain::Confirm` is a less mature interface than
`chain::Listen`. As such, there is not yet a utility like `lightning-block-sync`
to use for interacting with clients like Electrum.
`chain::Listen`. As such, there is not yet a utility like
`lightning-block-sync` to use for interacting with clients like Electrum.
:::