Implement `process_kyoto_events` by randomlogin · Pull Request #28 · febyeji/ldk-node

randomlogin · 2026-06-09T02:26:56Z

Partly depends on 2140-dev/kyoto#585, for now we would just stall if the header was reorganized during processing.

Implements `process_kyoto_events` and `ChainOp`
Added 4 variants of `ChainOp`:
- ConnectFull,
- ConnectFiltered,
- Disconnect,
- Synced
Now `process_kyoto_events` reacts to an event from kyoto and sends a
`ChainOp` to listener (`BlockApplicator`).
Note that on a filter with no match we still need to apply header and we
need double check that header in the canonical chain is the relevant
one and has not been reorged. Right now it is left as a todo, because of
an upstream PR.

Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Previously tests assumed that the chain source of the lightning node and is node which mines. This is not the case with CBF chain source which needs to wait until after mining a new block a new tips propagates to it. `wait_for_block` is made to return a new height and a new function `wait_for_node_tip` is added which waits until the given height is processed (returned via `status.best_block` ) on a given node.

Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

When `process_kyoto_events` processes events it decides whether we need to take any action (e.g. apply block). These actions are sent to a new abstraction — `BlockApplicator` which holds `ChainListener` (which in turn has wallets and can apply blocks / filtered blocks). This `BlockApplicator` has to have a receiver of a channel (and `process_kyoto_events` has to have a sender to this channel. Thus we cannot create them in `new`, because we would own them at `CbfChainSource`, so they are created in `start`. Also this commit ran `cargo fmt --all` which was missed previously.

Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Added 4 variants of `ChainOp`: - ConnectFull, - ConnectFiltered, - Disconnect, - Synced Now `process_kyoto_events` reacts to an event from kyoto and sends a `ChainOp` to listener (`BlockApplicator`). Note that on a filter with no match we still need to apply header and we need double check that header in the canonical chain is the relevant one and has not been reorged. Right now it is left as a todo, because of an upstream PR. Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji · 2026-06-09T03:04:50Z

Looks fine as an intermediate step. I will merge this.

* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomlogin · 2026-06-09T02:26:56Z

Partly depends on 2140-dev/kyoto#585, for now we would just stall if the header was reorganized during processing.

Implements `process_kyoto_events` and `ChainOp`
Added 4 variants of `ChainOp`:
- ConnectFull,
- ConnectFiltered,
- Disconnect,
- Synced
Now `process_kyoto_events` reacts to an event from kyoto and sends a
`ChainOp` to listener (`BlockApplicator`).
Note that on a filter with no match we still need to apply header and we
need double check that header in the canonical chain is the relevant
one and has not been reorged. Right now it is left as a todo, because of
an upstream PR.

Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Previously tests assumed that the chain source of the lightning node and is node which mines. This is not the case with CBF chain source which needs to wait until after mining a new block a new tips propagates to it. `wait_for_block` is made to return a new height and a new function `wait_for_node_tip` is added which waits until the given height is processed (returned via `status.best_block` ) on a given node.

Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

When `process_kyoto_events` processes events it decides whether we need to take any action (e.g. apply block). These actions are sent to a new abstraction — `BlockApplicator` which holds `ChainListener` (which in turn has wallets and can apply blocks / filtered blocks). This `BlockApplicator` has to have a receiver of a channel (and `process_kyoto_events` has to have a sender to this channel. Thus we cannot create them in `new`, because we would own them at `CbfChainSource`, so they are created in `start`. Also this commit ran `cargo fmt --all` which was missed previously.

Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Added 4 variants of `ChainOp`: - ConnectFull, - ConnectFiltered, - Disconnect, - Synced Now `process_kyoto_events` reacts to an event from kyoto and sends a `ChainOp` to listener (`BlockApplicator`). Note that on a filter with no match we still need to apply header and we need double check that header in the canonical chain is the relevant one and has not been reorged. Right now it is left as a todo, because of an upstream PR. Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji · 2026-06-09T03:04:50Z

Looks fine as an intermediate step. I will merge this.

* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomlogin · 2026-06-09T02:26:56Z

Partly depends on 2140-dev/kyoto#585, for now we would just stall if the header was reorganized during processing.

Implements `process_kyoto_events` and `ChainOp`
Added 4 variants of `ChainOp`:
- ConnectFull,
- ConnectFiltered,
- Disconnect,
- Synced
Now `process_kyoto_events` reacts to an event from kyoto and sends a
`ChainOp` to listener (`BlockApplicator`).
Note that on a filter with no match we still need to apply header and we
need double check that header in the canonical chain is the relevant
one and has not been reorged. Right now it is left as a todo, because of
an upstream PR.

Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Previously tests assumed that the chain source of the lightning node and is node which mines. This is not the case with CBF chain source which needs to wait until after mining a new block a new tips propagates to it. `wait_for_block` is made to return a new height and a new function `wait_for_node_tip` is added which waits until the given height is processed (returned via `status.best_block` ) on a given node.

Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

When `process_kyoto_events` processes events it decides whether we need to take any action (e.g. apply block). These actions are sent to a new abstraction — `BlockApplicator` which holds `ChainListener` (which in turn has wallets and can apply blocks / filtered blocks). This `BlockApplicator` has to have a receiver of a channel (and `process_kyoto_events` has to have a sender to this channel. Thus we cannot create them in `new`, because we would own them at `CbfChainSource`, so they are created in `start`. Also this commit ran `cargo fmt --all` which was missed previously.

Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Added 4 variants of `ChainOp`: - ConnectFull, - ConnectFiltered, - Disconnect, - Synced Now `process_kyoto_events` reacts to an event from kyoto and sends a `ChainOp` to listener (`BlockApplicator`). Note that on a filter with no match we still need to apply header and we need double check that header in the canonical chain is the relevant one and has not been reorged. Right now it is left as a todo, because of an upstream PR. Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji · 2026-06-09T03:04:50Z

Looks fine as an intermediate step. I will merge this.

* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomlogin · 2026-06-09T02:26:56Z

Partly depends on 2140-dev/kyoto#585, for now we would just stall if the header was reorganized during processing.

Implements `process_kyoto_events` and `ChainOp`
Added 4 variants of `ChainOp`:
- ConnectFull,
- ConnectFiltered,
- Disconnect,
- Synced
Now `process_kyoto_events` reacts to an event from kyoto and sends a
`ChainOp` to listener (`BlockApplicator`).
Note that on a filter with no match we still need to apply header and we
need double check that header in the canonical chain is the relevant
one and has not been reorged. Right now it is left as a todo, because of
an upstream PR.

Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Previously tests assumed that the chain source of the lightning node and is node which mines. This is not the case with CBF chain source which needs to wait until after mining a new block a new tips propagates to it. `wait_for_block` is made to return a new height and a new function `wait_for_node_tip` is added which waits until the given height is processed (returned via `status.best_block` ) on a given node.

Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

When `process_kyoto_events` processes events it decides whether we need to take any action (e.g. apply block). These actions are sent to a new abstraction — `BlockApplicator` which holds `ChainListener` (which in turn has wallets and can apply blocks / filtered blocks). This `BlockApplicator` has to have a receiver of a channel (and `process_kyoto_events` has to have a sender to this channel. Thus we cannot create them in `new`, because we would own them at `CbfChainSource`, so they are created in `start`. Also this commit ran `cargo fmt --all` which was missed previously.

Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Added 4 variants of `ChainOp`: - ConnectFull, - ConnectFiltered, - Disconnect, - Synced Now `process_kyoto_events` reacts to an event from kyoto and sends a `ChainOp` to listener (`BlockApplicator`). Note that on a filter with no match we still need to apply header and we need double check that header in the canonical chain is the relevant one and has not been reorged. Right now it is left as a todo, because of an upstream PR. Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji · 2026-06-09T03:04:50Z

Looks fine as an intermediate step. I will merge this.

* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomlogin · 2026-06-09T02:26:56Z

Partly depends on 2140-dev/kyoto#585, for now we would just stall if the header was reorganized during processing.

Implements `process_kyoto_events` and `ChainOp`
Added 4 variants of `ChainOp`:
- ConnectFull,
- ConnectFiltered,
- Disconnect,
- Synced
Now `process_kyoto_events` reacts to an event from kyoto and sends a
`ChainOp` to listener (`BlockApplicator`).
Note that on a filter with no match we still need to apply header and we
need double check that header in the canonical chain is the relevant
one and has not been reorged. Right now it is left as a todo, because of
an upstream PR.

Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Previously tests assumed that the chain source of the lightning node and is node which mines. This is not the case with CBF chain source which needs to wait until after mining a new block a new tips propagates to it. `wait_for_block` is made to return a new height and a new function `wait_for_node_tip` is added which waits until the given height is processed (returned via `status.best_block` ) on a given node.

Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

When `process_kyoto_events` processes events it decides whether we need to take any action (e.g. apply block). These actions are sent to a new abstraction — `BlockApplicator` which holds `ChainListener` (which in turn has wallets and can apply blocks / filtered blocks). This `BlockApplicator` has to have a receiver of a channel (and `process_kyoto_events` has to have a sender to this channel. Thus we cannot create them in `new`, because we would own them at `CbfChainSource`, so they are created in `start`. Also this commit ran `cargo fmt --all` which was missed previously.

Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Added 4 variants of `ChainOp`: - ConnectFull, - ConnectFiltered, - Disconnect, - Synced Now `process_kyoto_events` reacts to an event from kyoto and sends a `ChainOp` to listener (`BlockApplicator`). Note that on a filter with no match we still need to apply header and we need double check that header in the canonical chain is the relevant one and has not been reorged. Right now it is left as a todo, because of an upstream PR. Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji · 2026-06-09T03:04:50Z

Looks fine as an intermediate step. I will merge this.

* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomlogin · 2026-06-09T02:26:56Z

Partly depends on 2140-dev/kyoto#585, for now we would just stall if the header was reorganized during processing.

Implements `process_kyoto_events` and `ChainOp`
Added 4 variants of `ChainOp`:
- ConnectFull,
- ConnectFiltered,
- Disconnect,
- Synced
Now `process_kyoto_events` reacts to an event from kyoto and sends a
`ChainOp` to listener (`BlockApplicator`).
Note that on a filter with no match we still need to apply header and we
need double check that header in the canonical chain is the relevant
one and has not been reorged. Right now it is left as a todo, because of
an upstream PR.

Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Previously tests assumed that the chain source of the lightning node and is node which mines. This is not the case with CBF chain source which needs to wait until after mining a new block a new tips propagates to it. `wait_for_block` is made to return a new height and a new function `wait_for_node_tip` is added which waits until the given height is processed (returned via `status.best_block` ) on a given node.

Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

When `process_kyoto_events` processes events it decides whether we need to take any action (e.g. apply block). These actions are sent to a new abstraction — `BlockApplicator` which holds `ChainListener` (which in turn has wallets and can apply blocks / filtered blocks). This `BlockApplicator` has to have a receiver of a channel (and `process_kyoto_events` has to have a sender to this channel. Thus we cannot create them in `new`, because we would own them at `CbfChainSource`, so they are created in `start`. Also this commit ran `cargo fmt --all` which was missed previously.

Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Added 4 variants of `ChainOp`: - ConnectFull, - ConnectFiltered, - Disconnect, - Synced Now `process_kyoto_events` reacts to an event from kyoto and sends a `ChainOp` to listener (`BlockApplicator`). Note that on a filter with no match we still need to apply header and we need double check that header in the canonical chain is the relevant one and has not been reorged. Right now it is left as a todo, because of an upstream PR. Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji · 2026-06-09T03:04:50Z

Looks fine as an intermediate step. I will merge this.

* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomlogin · 2026-06-09T02:26:56Z

Partly depends on 2140-dev/kyoto#585, for now we would just stall if the header was reorganized during processing.

Implements `process_kyoto_events` and `ChainOp`
Added 4 variants of `ChainOp`:
- ConnectFull,
- ConnectFiltered,
- Disconnect,
- Synced
Now `process_kyoto_events` reacts to an event from kyoto and sends a
`ChainOp` to listener (`BlockApplicator`).
Note that on a filter with no match we still need to apply header and we
need double check that header in the canonical chain is the relevant
one and has not been reorged. Right now it is left as a todo, because of
an upstream PR.

Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Previously tests assumed that the chain source of the lightning node and is node which mines. This is not the case with CBF chain source which needs to wait until after mining a new block a new tips propagates to it. `wait_for_block` is made to return a new height and a new function `wait_for_node_tip` is added which waits until the given height is processed (returned via `status.best_block` ) on a given node.

Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

When `process_kyoto_events` processes events it decides whether we need to take any action (e.g. apply block). These actions are sent to a new abstraction — `BlockApplicator` which holds `ChainListener` (which in turn has wallets and can apply blocks / filtered blocks). This `BlockApplicator` has to have a receiver of a channel (and `process_kyoto_events` has to have a sender to this channel. Thus we cannot create them in `new`, because we would own them at `CbfChainSource`, so they are created in `start`. Also this commit ran `cargo fmt --all` which was missed previously.

Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Added 4 variants of `ChainOp`: - ConnectFull, - ConnectFiltered, - Disconnect, - Synced Now `process_kyoto_events` reacts to an event from kyoto and sends a `ChainOp` to listener (`BlockApplicator`). Note that on a filter with no match we still need to apply header and we need double check that header in the canonical chain is the relevant one and has not been reorged. Right now it is left as a todo, because of an upstream PR. Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji · 2026-06-09T03:04:50Z

Looks fine as an intermediate step. I will merge this.

* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomlogin · 2026-06-09T02:26:56Z

Partly depends on 2140-dev/kyoto#585, for now we would just stall if the header was reorganized during processing.

Implements `process_kyoto_events` and `ChainOp`
Added 4 variants of `ChainOp`:
- ConnectFull,
- ConnectFiltered,
- Disconnect,
- Synced
Now `process_kyoto_events` reacts to an event from kyoto and sends a
`ChainOp` to listener (`BlockApplicator`).
Note that on a filter with no match we still need to apply header and we
need double check that header in the canonical chain is the relevant
one and has not been reorged. Right now it is left as a todo, because of
an upstream PR.

Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Previously tests assumed that the chain source of the lightning node and is node which mines. This is not the case with CBF chain source which needs to wait until after mining a new block a new tips propagates to it. `wait_for_block` is made to return a new height and a new function `wait_for_node_tip` is added which waits until the given height is processed (returned via `status.best_block` ) on a given node.

Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

When `process_kyoto_events` processes events it decides whether we need to take any action (e.g. apply block). These actions are sent to a new abstraction — `BlockApplicator` which holds `ChainListener` (which in turn has wallets and can apply blocks / filtered blocks). This `BlockApplicator` has to have a receiver of a channel (and `process_kyoto_events` has to have a sender to this channel. Thus we cannot create them in `new`, because we would own them at `CbfChainSource`, so they are created in `start`. Also this commit ran `cargo fmt --all` which was missed previously.

Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Added 4 variants of `ChainOp`: - ConnectFull, - ConnectFiltered, - Disconnect, - Synced Now `process_kyoto_events` reacts to an event from kyoto and sends a `ChainOp` to listener (`BlockApplicator`). Note that on a filter with no match we still need to apply header and we need double check that header in the canonical chain is the relevant one and has not been reorged. Right now it is left as a todo, because of an upstream PR. Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji · 2026-06-09T03:04:50Z

Looks fine as an intermediate step. I will merge this.

* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomloginand others added 6 commits June 3, 2026 01:06

Add CBF chain source stubs for starting
0cd84fb
Add stub methods/functions, add basic build and start of the CBF chain source as well as basic struct containing the fields which undoubtedtly are needed.

Populate revealed spks for CBF
ca6293e
Ask wallet for revealed spks, register them. Implement `Listen` trait ans add register_script method as well as implementation of registered scripts/outputs.

Merge branch 'cbf-chain-source-cleanup' into cbf-chain-source
fd9a0f2
Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

Merge branch 'cbf-chain-source-cleanup' into cbf-chain-source
c4e05f8

randomlogin requested a review from febyeji June 9, 2026 02:26

randomlogin force-pushed the cbf-chain-source branch from 3f6672c to ce52bb9Compare June 9, 2026 02:30

febyeji merged commit a38ac8d into febyeji:cbf-chain-source-cleanupJun 9, 2026
12 of 23 checks passed

febyeji added a commit that referenced this pull request Jun 22, 2026
Implementprocess_kyoto_events(#28)
8f2a2e9
* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

randomlogin deleted the cbf-chain-source branch June 28, 2026 18:58

febyeji added a commit that referenced this pull request Jul 8, 2026
Implementprocess_kyoto_events(#28)
1e1d3a1
* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>

febyeji added a commit that referenced this pull request Jul 16, 2026
Implementprocess_kyoto_events(#28)
bcc663b
* Add CBF chain source stubs for starting * Implement `process_kyoto_events` and `ChainOp` Co-authored-by: febyeji <yeji.han@sf.snu.ac.kr>