Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adds lightning-transaction-sync in favor of Confirm #251

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Adds lightning-transaction-sync in favor of Confirm #251

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8c7f506
Adds lightning-transaction-sync in favor of Confirm
Feb 14, 2024
a0f1002
Update docs/building-a-node-with-ldk/setting-up-a-channel-manager.md
ConorOkus Feb 15, 2024
4f8109a
Removes steps that only work in Kotlin
Feb 16, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
94 changes: 66 additions & 28 deletions docs/building-a-node-with-ldk/setting-up-a-channel-manager.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -931,16 +931,18 @@ _after_ the `ChannelMonitor`s and `ChannelManager` are synced to the chain tip (

### Sync `ChannelMonitor`s and `ChannelManager` to chain tip

**What it's used for:** this step is only necessary if you're restarting and have open channels. This step ensures that LDK channel state is up-to-date with the bitcoin blockchain
**What it's used for:** this step is only necessary if you're restarting and have open channels. This step ensures that LDK channel state is up-to-date with the bitcoin blockchain.

There are 2 main options for synchronizing to chain on startup:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Spell out numbers zero to ten.


#### Full Blocks or BIP 157/158 (Compact Block Filters)

**Example:**

<CodeSwitcher :languages="{rust:'Rust', kotlin:'Kotlin', swift:'Swift'}">
<CodeSwitcher :languages="{rust:'Rust'}">
<template v-slot:rust>

```rust
// Full Blocks or BIP 157/158

use lightning_block_sync::init;
use lightning_block_sync::poll;
use lightning_block_sync::UnboundedCache;
Expand Down Expand Up @@ -1006,17 +1008,74 @@ chain_tip = Some(
.await
.unwrap(),
);
```

</template>

</CodeSwitcher>

**Implementation notes:**

If you are connecting full blocks or using BIP 157/158, then it is recommended to use
LDK's [`lightning_block_sync`](https://docs.rs/lightning-block-sync/*/lightning_block_sync/) crate as in the example above: the high-level steps that must be done for both `ChannelManager` and each `ChannelMonitor` are as follows:

1. Get the last blockhash that each object saw.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all of the examples given in these steps are bindings-specific and would look differently in Rust.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah agree, generally speaking, the kotlin & swift examples approach things from a mobile-first perspective but I've not seen any simple examples of CBF in a mobile context yet. Hopefully, with BDK 1.0 it's possible. Current mobile users are opting for Esplora/Electrum and we have some coverage there.

- Receive the latest block hash when through [deserializtion](https://docs.rs/lightning/*/lightning/ln/channelmanager/struct.ChannelManagerReadArgs.html) of the `ChannelManager` via `read()`
- Each `ChannelMonitor`'s is in `channel_manager.channel_monitors`, as the 2nd element in each tuple
2. For each object, if its latest known blockhash has been reorged out of the chain, then disconnect blocks using `channel_manager.as_Listen().block_disconnected(..)` or `channel_monitor.block_disconnected(..)` until you reach the last common ancestor with the main chain.
3. For each object, reconnect blocks starting from the common ancestor until it gets to your best known chain tip using `channel_manager.as_Listen().block_connected(..)` and/or `channel_monitor.block_connected(..)`.
4. Call `channel_manager.chain_sync_completed(..)` to complete the initial sync process.


#### Electrum or Esplora

Alternatively, you can use LDK's [`lightning-transaction-sync`](https://docs.rs/lightning-transaction-sync/*/lightning_transaction_sync/) crate. This provides utilities for syncing LDK via the transaction-based [`Confirm`](https://docs.rs/lightning/*/lightning/chain/trait.Confirm.html)interface.
ConorOkus marked this conversation as resolved.
Show resolved Hide resolved

**Example:**

<CodeSwitcher :languages="{rust:'Rust', kotlin:'Kotlin', swift:'Swift'}">
<template v-slot:rust>

````
```rust
let tx_sync = Arc::new(EsploraSyncClient::new(
esplora_server_url,
Arc::clone(&some_logger),
));

let chain_monitor = Arc::new(ChainMonitor::new(
Some(Arc::clone(&tx_sync)),
Arc::clone(&some_broadcaster),
Arc::clone(&some_logger),
Arc::clone(&some_fee_estimator),
Arc::clone(&some_persister),
));

let channel_manager = Arc::new(ChannelManager::new(
Arc::clone(&some_fee_estimator),
Arc::clone(&chain_monitor),
Arc::clone(&some_broadcaster),
Arc::clone(&some_router),
Arc::clone(&some_logger),
Arc::clone(&some_entropy_source),
Arc::clone(&some_node_signer),
Arc::clone(&some_signer_provider),
user_config,
chain_params,
));

let confirmables = vec![
&*channel_manager as &(dyn Confirm + Sync + Send),
&*chain_monitor as &(dyn Confirm + Sync + Send),
];

tx_sync.sync(confirmables).unwrap();
```

</template>

<template v-slot:kotlin>

```java
// Electrum/Esplora

// Retrieve transaction IDs to check the chain for un-confirmation.
val relevantTxIdsFromChannelManager: Array<ByteArray> = channelManager .as_Confirm().get_relevant_txids()
val relevantTxIdsFromChannelManager: Array<ByteArray> = chainMonitor.as_Confirm().get_relevant_txids()
Expand Down Expand Up @@ -1062,8 +1121,6 @@ channelManagerConstructor.chain_sync_completed(customEventHandler);
<template v-slot:swift>

```Swift
// Electrum/Esplora

// Retrieve transaction IDs to check the chain for un-confirmation.
let relevantTxIds1 = channelManager?.asConfirm().getRelevantTxids() ?? []
let relevantTxIds2 = chainMonitor?.asConfirm().getRelevantTxids() ?? []
Expand Down Expand Up @@ -1118,25 +1175,6 @@ channelManagerConstructor.chainSyncCompleted(persister: channelManagerPersister)

</CodeSwitcher>

**Implementation notes:**

There are 2 main options for synchronizing to chain on startup:

**Full Blocks or BIP 157/158**

If you are connecting full blocks or using BIP 157/158, then it is recommended to use
LDK's `lightning_block_sync` crate as in the example above: the high-level steps that must be done for both `ChannelManager` and each `ChannelMonitor` are as follows:

1. Get the last blockhash that each object saw.
- Receive the latest block hash when through [deserializtion](https://docs.rs/lightning/*/lightning/ln/channelmanager/struct.ChannelManagerReadArgs.html) of the `ChannelManager` via `read()`
- Each `ChannelMonitor`'s is in `channel_manager.channel_monitors`, as the 2nd element in each tuple
2. For each object, if its latest known blockhash has been reorged out of the chain, then disconnect blocks using `channel_manager.as_Listen().block_disconnected(..)` or `channel_monitor.block_disconnected(..)` until you reach the last common ancestor with the main chain.
3. For each object, reconnect blocks starting from the common ancestor until it gets to your best known chain tip using `channel_manager.as_Listen().block_connected(..)` and/or `channel_monitor.block_connected(..)`.
4. Call `channel_manager.chain_sync_completed(..)` to complete the initial sync process.

**Electrum/Esplora**

Alternatively, you can use LDK's `lightning-transaction-sync` crate. This provides utilities for syncing LDK via the transaction-based `Confirm` interface.

### Optional: Initialize `P2PGossipSync or RapidGossipSync`

Expand Down
Loading