Skip to content

Commit c91ff23

Browse files
author
Conor Okus
committed
Removes steps that only work in Kotlin
1 parent a0f1002 commit c91ff23

File tree

1 file changed

+10
-9
lines changed

1 file changed

+10
-9
lines changed

docs/building-a-node-with-ldk/setting-up-a-channel-manager.md

+10-9
Original file line numberDiff line numberDiff line change
@@ -1014,18 +1014,13 @@ chain_tip = Some(
10141014
10151015
</CodeSwitcher>
10161016
1017-
**Implementation notes:**
1017+
::: tip Full block syncing in mobile environments
10181018
1019-
If you are connecting full blocks or using BIP 157/158, then it is recommended to use
1020-
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:
1019+
Block syncing for mobile clients tends to present several challenges due to resource contraints and network limitiations typically associated with mobile devices. It requires a full node and usually fetches blocks over RPC.
10211020
1022-
1. Get the last blockhash that each object saw.
1023-
- Receive the latest block hash when through [deserializtion](https://docs.rs/lightning/*/lightning/ln/channelmanager/struct.ChannelManagerReadArgs.html) of the `ChannelManager` via `read()`
1024-
- Each `ChannelMonitor`'s is in `channel_manager.channel_monitors`, as the 2nd element in each tuple
1025-
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.
1026-
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(..)`.
1027-
4. Call `channel_manager.chain_sync_completed(..)` to complete the initial sync process.
1021+
Compact block filters (CBFs) are an alternative approach to syncing the blockchain that addresses some of the challenges associated with mobile clients. Please start a [discussion](https://github.com/orgs/lightningdevkit/discussions) if you would like us to expose `lightning-block-sync` in our bindings.
10281022
1023+
:::
10291024
10301025
#### Electrum or Esplora
10311026
@@ -1076,6 +1071,9 @@ tx_sync.sync(confirmables).unwrap();
10761071
<template v-slot:kotlin>
10771072

10781073
```java
1074+
// Note: This example calls the Confirm interface directly. The lightning-transaction-sync crate will
1075+
// be available in the next bindings release.
1076+
10791077
// Retrieve transaction IDs to check the chain for un-confirmation.
10801078
val relevantTxIdsFromChannelManager: Array<ByteArray> = channelManager .as_Confirm().get_relevant_txids()
10811079
val relevantTxIdsFromChannelManager: Array<ByteArray> = chainMonitor.as_Confirm().get_relevant_txids()
@@ -1121,6 +1119,9 @@ channelManagerConstructor.chain_sync_completed(customEventHandler);
11211119
<template v-slot:swift>
11221120

11231121
```Swift
1122+
// Note: This example calls the Confirm interface directly. The lightning-transaction-sync crate will
1123+
// be available in the next bindings release.
1124+
11241125
// Retrieve transaction IDs to check the chain for un-confirmation.
11251126
let relevantTxIds1 = channelManager?.asConfirm().getRelevantTxids() ?? []
11261127
let relevantTxIds2 = chainMonitor?.asConfirm().getRelevantTxids() ?? []

0 commit comments

Comments
 (0)