Add docs to run ldk-server against pruned bitcoind - #261
Conversation
|
👋 Thanks for assigning @benthecarman as a reviewer! |
| startup, for example during mnemonic recovery. Replace the value below with a mainnet height at or | ||
| before the earliest relevant wallet transaction: |
There was a problem hiding this comment.
According to claude we start scanning at above the given height so need to update. Maybe this is worth fixing in ldk-node though?
| startup, for example during mnemonic recovery. Replace the value below with a mainnet height at or | |
| before the earliest relevant wallet transaction: | |
| startup, for example during mnemonic recovery. Replace the value below with a mainnet height | |
| before the earliest relevant wallet transaction: |
There was a problem hiding this comment.
Opened this PR let me know if you think it feels like an improvement, seems so to me
| If the requested range is pruned, LDK Server may expose gRPC while chain synchronization logs | ||
| repeated transient errors. Stop it and recover against an archival backend (or re-download Core's | ||
| chain with pruning disabled). Retry from clean recovery state derived from verified backups; a | ||
| failed first scan may already have persisted its starting checkpoint. |
There was a problem hiding this comment.
docs/pruned-bitcoind.md:120 — Recovery advice after a failed first scan is wrong. The BDK wallet is persisted before the rescan checkpoint resolves (builder.rs:1652-1660 vs tip check at 1670). If the first build fails (height above tip, pruned block, process dies), the next start loads the existing wallet, silently ignores --rescan-from-height, and syncs from genesis against the pruned node forever. The doc must say: delete the fresh data directory before retrying.
| If LDK Server is offline while Core prunes past its persisted tip, catch-up will fail with | ||
| `Block not available (pruned data)`. A larger prune target reduces this risk but does not express a |
There was a problem hiding this comment.
| If LDK Server is offline while Core prunes past its persisted tip, catch-up will fail with | |
| `Block not available (pruned data)`. A larger prune target reduces this risk but does not express a | |
| If LDK Server is offline while Core prunes past its persisted tip, catch-up will stall with | |
| `Block not available (pruned data)`. A larger prune target reduces this risk but does not express a |
this doesn't crash it
| Everything else has sensible defaults. See [Configuration](configuration.md) for the full | ||
| reference. | ||
| reference. For a mainnet Bitcoin Core deployment that uses pruning, also review | ||
| [Running with Pruned Bitcoin Core](pruned-bitcoind.md) before choosing its retention target. |
There was a problem hiding this comment.
retention target
Can we say prune height or something. I don't think I've ever heard someone call it that
3 participants
No description provided.