@@ -4,20 +4,29 @@ Up until this point, we've explored how to notify LDK of chain activity using
4
4
blocks. But what if you're sourcing chain activity from a place that doesn't
5
5
provide a block-centric interface, like Electrum?
6
6
7
- LDK has a ` chain::Confirm ` interface to support this use case, analogous to the
8
- block-oriented ` chain::Listen ` interface which we've been using up until now.
9
- With this alternative approach, you still need to give LDK block headers, but
10
- only for blocks containing transactions of interest. These are identified by
11
- ` chain::Filter ` as before. You also need to notify LDK of any transactions with
12
- insufficient confirmation that have been reorganized out of the chain. Use the
13
- ` transactions_confirmed ` and ` transaction_unconfirmed ` methods, respectively.
7
+ LDK's ` ChannelManager ` and ` ChainMonitor ` implement a ` chain::Confirm ` interface to support this
8
+ use case, analogous to the block-oriented ` chain::Listen ` interface which we've been using up until
9
+ now. With this alternative approach, you still need to give LDK information about chain activity,
10
+ but only for transactions of interest. To this end, you must call ` Confirm::transactions_confirmed `
11
+ when any transactions identified by ` chain::Filter ` 's ` register_tx ` /` register_output ` methods are
12
+ confirmed.
14
13
15
- Additionally, you must notify LDK whenever a new chain tip is available using
16
- the ` best_block_updated ` method. See the documentation for a full picture of how
17
- this interface is intended to be used.
14
+ You also need to notify LDK of any transactions with insufficient confirmations
15
+ that have been reorganized out of the chain. Transactions that need to be monitored for such
16
+ reorganization are returned by ` Confirm::get_relevant_txids ` . If any of these transactions become
17
+ unconfirmed, you must call ` Confirm::transaction_unconfirmed ` .
18
+
19
+ Lastly, you must notify LDK whenever a new chain tip is available using
20
+ the ` Confirm::best_block_updated ` method. See the documentation for a full
21
+ picture of how this interface is intended to be used.
22
+
23
+ ::: tip Note
24
+ Note that the described methods of ` Confirm ` must be called both on the
25
+ ` ChannelManager ` * and* the ` ChainMonitor ` .
26
+ :::
18
27
19
28
::: tip Note
20
29
Be advised that ` chain::Confirm ` is a less mature interface than
21
- ` chain::Listen ` . As such, there is not yet a utility like ` lightning-block-sync `
22
- to use for interacting with clients like Electrum.
30
+ ` chain::Listen ` . As such, there is not yet a utility like
31
+ ` lightning-block-sync ` to use for interacting with clients like Electrum.
23
32
:::
0 commit comments