Make bitcoind optional and support transaction-sync as an additional chain backend

[bitwalt]

Motivation

rgb-lightning-node currently requires a full bitcoind JSON-RPC connection in addition to an indexer (electrum/esplora). For most operators this is redundant: the indexer is already a complete chain source, and running an extra bitcoind purely to feed LDK doubles the storage footprint, the boot time, and the surface area for "what do I configure".

Removing it lets the node run against any maintained electrum/esplora endpoint (self-hosted, public, or an LSP-managed one), and shrinks the regtest/CI matrix accordingly. It also aligns the node with the deployment posture of most other RGB tooling, which is already indexer-only.

Proposal

Drop the bitcoind requirement entirely and route block + transaction sync through the configured indexer:

• LDK chain source: replace lightning-block-sync (RPC mode) with lightning-transaction-sync, enabling both electrum and esplora-blocking features so a single binary supports both protocols.
• Fee estimation: poll the indexer (estimate_fee for electrum, get_fee_estimates for esplora), interpolating across confirmation buckets.
• Transaction broadcast: through the indexer's transaction_broadcast / esplora POST /tx.
• UTXO lookup for gossip verification: through the indexer (blockchain.transaction.id_from_pos / esplora block-index lookup), with async resolution so peer-manager isn't blocked.

API / config surface changes

• Removed from unlock and init payloads (and the OpenAPI spec): bitcoind_rpc_username, bitcoind_rpc_password, bitcoind_rpc_host, bitcoind_rpc_port.
• Unchanged: indexer_url (already accepts tcp://host:port for electrum or https://host for esplora; auto-detected).
• Dockerfile: drops the bitcoind service from the runtime image; compose.yaml still ships bitcoind for regtest because we still need a block source for the test stack, just not for the node itself.
• README: regtest and docker examples updated to remove the four bitcoind RPC fields.

Tradeoffs / behavioral notes

• Block-tip latency: previously near-synchronous via bitcoind RPC; now bounded by the chain-sync poll cadence (tokio::time::sleep(Duration::from_secs(1)) between tx_sync.sync(...) calls). For most workloads this is invisible, but tests that mine N blocks and then immediately assert on counterparty channel state need to wait for the indexer to expose the new tip — wait_for_usable_channels is the right primitive for this.
• Required indexer features: blockchain.transaction.id_from_pos (electrum) / block-index by height (esplora). These are standard in electrs and Mempool/BlockBook esplora; older indexers may not implement them.
• No more "bitcoind down" failure mode — replaced by "indexer down". The node already surfaces this clearly via InvalidIndexer errors at unlock and warnings during sync.
• Operators who run their own bitcoind can keep doing so; they just point the node at their existing electrs/esplora next to it. No bitcoind JSON-RPC creds needed in the node config.

[zoedberg]

Thanks for writing this up. I agree with the motivation that requiring bitcoind in addition to an indexer is heavy for many deployments, especially for regtest, CI, lightweight nodes and setups that already rely on electrum/esplora. That said, I don't think we should remove lightning-block-sync support entirely. I think the better direction is to make the chain source configurable and allow operators to choose the sync type (block vs transaction). These two approaches are not just interchangeable implementations of the same thing. They come with different tradeoffs:

• lightning-transaction-sync is easier to deploy and fits well with indexer-based setups. It avoids requiring Bitcoin Core RPC credentials, reduces storage requirements and aligns with many lightweight wallet deployments. For users who already trust or operate an electrum/esplora backend, this is a good option.
• lightning-block-sync has a different security model. A node that consumes full blocks from a trusted/local bitcoind does not rely on an indexer to tell it which transactions are relevant. That reduces omission risk and is generally preferable for users who want a more self-sovereign or trust-minimized setup.

Also please note that today RGB usage through indexers still involves some trust assumptions around data availability and completeness. But introduction of SPV proofs should reduce those assumptions over time, since clients will be able to verify more data instead of simply trusting the indexer response. So for some clients it could make sense to use LDK with a trusted/local bitcoind and RGB with a third-party indexer.
We also plan to support using RGB with only Bitcoin Core, without requiring an indexer. In that scenario, a desktop wallet or local-first node may reasonably prefer using a trusted local bitcoind + LDK block-sync + RGB without indexer. For those users, removing block-sync would force them back into an indexer-based architecture even when they explicitly want to avoid one.

So let's reframe the proposal from:
Remove direct bitcoind dependency, sync via electrum/esplora indexer
to:
Make bitcoind optional and support transaction-sync as an additional chain backend

This gives us the deployment simplification benefits without removing the stronger/local-first deployment option.

[bitwalt]

Hi, thanks for the response and the explanation. I'm fine with keeping both options and updating the PR.

On the implementation, we could go implicit (mode chosen by whether bitcoind_rpc_* is populated on unlock) or explicit via a chain_source enum. I'd lean implicit since it doesn't change existing setups.

For tests, I'd add a few covering the lightning-transaction-sync mode — what would you suggest here?

[zoedberg]

In this phase I won't worry about changing existing setups. Adding an enum would allow us to avoid manually checking that all or none bitcoind parameters have been set.

For the tests I think a single test is enough. Let's make it unlock 2 nodes, open a channel, restart a node and closing the channel.

I think we should also add a couple of features, by default I would enable both but I think it makes sense that a user that wants to use only a sync type should be able to import only the sync dependency he needs.