From 38631498603774d9e3bb2a304d54773c0ab8ef52 Mon Sep 17 00:00:00 2001 From: Elias Rohrer Date: Thu, 28 Jul 2022 11:04:21 +0200 Subject: [PATCH 1/4] Update chain_activity.md --- docs/blockchain_data/chain_activity.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/blockchain_data/chain_activity.md b/docs/blockchain_data/chain_activity.md index 454d46d5d..e72e2ff02 100644 --- a/docs/blockchain_data/chain_activity.md +++ b/docs/blockchain_data/chain_activity.md @@ -6,7 +6,7 @@ a `ChannelMonitor` and passes it to the `ChainMonitor` to watch. At this point, you need to feed LDK any chain data of interest so that it can respond accordingly. It supports receiving either full blocks or pre-filtered -blocks using the `chain::Listen` interface. While block data can sourced from +blocks using the `chain::Listen` interface. While block data can be sourced from anywhere, it is your responsibility to call the `block_connected` and `block_disconnected` methods on `ChannelManager` and `ChainMonitor`. This allows them to update channel state and respond to on-chain events, respectively. @@ -24,4 +24,4 @@ the `BlockSource` interface or use one of the samples that it provides. ::: tip Note Currently, `lightning-block-sync` is only available in Rust. -::: \ No newline at end of file +::: From bc9ec244df60467bb5f2b33d52b6238273e49365 Mon Sep 17 00:00:00 2001 From: Elias Rohrer Date: Thu, 28 Jul 2022 11:08:36 +0200 Subject: [PATCH 2/4] f nit --- docs/blockchain_data/full_blocks.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/blockchain_data/full_blocks.md b/docs/blockchain_data/full_blocks.md index 93e1ce812..529bdc194 100644 --- a/docs/blockchain_data/full_blocks.md +++ b/docs/blockchain_data/full_blocks.md @@ -5,10 +5,10 @@ straight forward: call the appropriate methods on `ChannelManager` and `ChainMonitor` as blocks are connected and disconnected. LDK will handle the rest! -So what happens? The `ChannelManager` examines the blocks transactions and +So what happens? The `ChannelManager` examines the block's transactions and updates the internal channel state as needed. The `ChainMonitor` will detect any spends of the channel funding transaction or any pertinent transaction outputs, tracking them as necessary. If necessary, LDK will broadcast a transaction on your behalf. More on that -later. For now, let's look at the more interesting case of pre-filtered blocks. \ No newline at end of file +later. For now, let's look at the more interesting case of pre-filtered blocks. From 08be1837407616265cd30aa40df5d80d43571ccc Mon Sep 17 00:00:00 2001 From: Elias Rohrer Date: Thu, 28 Jul 2022 11:11:24 +0200 Subject: [PATCH 3/4] f nit --- docs/blockchain_data/pre_filtered_blocks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/blockchain_data/pre_filtered_blocks.md b/docs/blockchain_data/pre_filtered_blocks.md index 784fcdfa2..6adc67230 100644 --- a/docs/blockchain_data/pre_filtered_blocks.md +++ b/docs/blockchain_data/pre_filtered_blocks.md @@ -6,7 +6,7 @@ which transactions and outputs it is interested in. This information can then be used to filter blocks prior to sending them to your node. For example, if your block source is an Electrum client, you can pass along this -information to it. Or if you are making use of a BIP 157 client, you can check +information to it. Or, if you are making use of a BIP 157 client, you can check if a block contains relevant transactions before fetching it. So how does this work in practice? `ChainMonitor` is parameterized by an From 7306ac2e1965510123707bd78e8e61821d6bf40c Mon Sep 17 00:00:00 2001 From: Elias Rohrer Date: Thu, 28 Jul 2022 11:13:30 +0200 Subject: [PATCH 4/4] Update confirmed_transactions.md --- docs/blockchain_data/confirmed_transactions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/blockchain_data/confirmed_transactions.md b/docs/blockchain_data/confirmed_transactions.md index b65ab90a0..bdc54b3a7 100644 --- a/docs/blockchain_data/confirmed_transactions.md +++ b/docs/blockchain_data/confirmed_transactions.md @@ -6,7 +6,7 @@ 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 +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 @@ -20,4 +20,4 @@ this interface is intended to be used. 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. -::: \ No newline at end of file +:::