Skip to content

Commit 70810ba

Browse files
authored
Merge pull request #157 from tnull/2022-08-improve-confirmable-doc
Improve 'Confirmed Transactions' section
2 parents 1551e16 + d1780e5 commit 70810ba

File tree

1 file changed

+21
-12
lines changed

1 file changed

+21
-12
lines changed

docs/blockchain_data/confirmed_transactions.md

Lines changed: 21 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -4,20 +4,29 @@ Up until this point, we've explored how to notify LDK of chain activity using
44
blocks. But what if you're sourcing chain activity from a place that doesn't
55
provide a block-centric interface, like Electrum?
66

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

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+
:::
1827

1928
::: tip Note
2029
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.
2332
:::

0 commit comments

Comments
 (0)