Skip to content

Implement process_kyoto_events#28

Merged
febyeji merged 7 commits into
febyeji:cbf-chain-source-cleanupfrom
randomlogin:cbf-chain-source
Jun 9, 2026
Merged

Implement process_kyoto_events#28
febyeji merged 7 commits into
febyeji:cbf-chain-source-cleanupfrom
randomlogin:cbf-chain-source

Conversation

@randomlogin

Copy link
Copy Markdown
Collaborator

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.

randomlogin and others added 6 commits June 3, 2026 01:06
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>
@randomlogin randomlogin requested a review from febyeji June 9, 2026 02:26
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

febyeji commented Jun 9, 2026

Copy link
Copy Markdown
Owner

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

@febyeji febyeji merged commit a38ac8d into febyeji:cbf-chain-source-cleanup Jun 9, 2026
12 of 23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants