IPC interface for LND support

[GeorgeTsagk]

Description

The current Cap'n Proto IPC surface only exposes Init, Echo, and Mining. This is enough for a mining controller but not for downstream consumers that need to query chain state, mempool, or broadcast transactions.

This issue scopes the minimum IPC methods to add so that LND (via a downstream IPC translator) can use this node as a backend. The Node and Chain C++ interfaces already provide most of the underlying functionality in-process, they just aren't projected onto the wire.

Required IPC methods (to add)

Chain / blocks

• getBlockchainInfo: sync status before LND starts. taproot_check.go
• getBestBlockHash: current tip after reconnect. blockchain.go
• getBlockHash: height to hash for rescan/reorg handling. blockchain.go
• getBlockHeader: cheap header walk for confirmation depth. blockchain.go
• getBlock: scan blocks for channel funding, HTLC spends, justice triggers. blockchain.go

Transactions

• getRawTransaction: look up historical txs by txid (also blocked by txindex removal). bitcoind.go
• broadcastTransaction: broadcast commitment / HTLC / sweep / justice txs (exists in Node, not on the wire). btcwallet.go
• getTxOut: confirm a funding output is unspent. bitcoind.go

Mempool

• testMempoolAccept: pre-flight bumped txs before broadcasting. btcwallet.go

Fees & info

• estimateSmartFee: fee rates for closes, anchors, sweeps (exists in Chain, not on the wire). estimator.go
• getNetworkInfo: version gating for health-check selection. chainregistry.go

Already adequate

ZMQ rawblock / rawtx (and hashblock / hashtx): push notifications LND relies on, including spotting counterparty commitment broadcasts in the mempool without polling.
chainregistry.go

Additional blockers

txindex is gone: projecting getRawTransaction won't work without restoring the index (or an equivalent).

Acceptance / Notes

LND can start, open a channel, broadcast a force-close, and recover after restart against this node via a downstream IPC translator.

The IPC translator needs further definition, but won't be outlined in this issue. This issue focuses on the bitcoin backend methods required by LND (probably any other LN node impl too) to work.

[josibake]

Thanks for writing this up! At a quick glance, it looks like the only thing you need txindex for is getrawtransaction. Can you give an example of where getrawtransaction is in a critical path (as opposed to used as a convenience)?

[GeorgeTsagk]

Thanks for writing this up! At a quick glance, it looks like the only thing you need txindex for is getrawtransaction. Can you give an example of where getrawtransaction is in a critical path (as opposed to used as a convenience)?

getRawTransaction is used by the sweeper to fetch a mempool-spending tx by txid (mempool lookup only, not historical) in order to detect conflicts and reconstruct RBF info for fee-bumping decisions: sweeper.go:1314

For historical (confirmed-tx) lookups, getRawTransaction is used as a fast path to locate a tx's containing block, but it's a performance optimization with a manual block-rescan fallback when the index isn't available: bitcoind.go:551

So to answer your question, the only critical path is a mempool lookup, the rest of the call sites are mostly for performance and convenience. I guess we can downgrade the txindex from being a requirement to a "nice-to-have".

[josibake]

Nice, thanks for the explanation. Considering its not critical and assuming the IPC interface is expanded to allow a client to efficiently build their own index, you might have better luck building a usecase specific performance index. You could build something that is a) prunable and b) only contains blocks/txs you care about.

As it is today, Bitcoin Core's txindex is not prunable and does not work with a pruned node, so you end up with close to a TB of storage (+ whatever the gb/per day block growth).