{"slug": "show-hn-bitcoin-rs-an-ai-assisted-bitcoin-full-node-in-rust", "title": "Show HN: Bitcoin-rs – An AI-assisted Bitcoin full node in Rust", "summary": "A developer released bitcoin-rs, an AI-assisted Bitcoin full node written in Rust, positioning it as an alternative to Bitcoin Core that preserves consensus while enabling architectural experimentation. The project argues Bitcoin is well suited to AI-native development because implementations can be verified against Bitcoin Core, libbitcoinkernel, historical chain data, consensus test vectors, fuzzing, and differential tests, but says Bitcoin Core's review culture \"prioritizes minimizing change risk\" and makes radical architectural experimentation prohibitively expensive. bitcoin-rs makes the UTXO set the node's authoritative coin state with an integrated script index exposed through Esplora-compatible APIs, eliminating the need for a separate Electrum server, and supports Rust-native in-process integration instead of serialized RPC.", "body_md": "A Bitcoin full-node project for developers exploring typed Rust integration, node-owned indexing, and familiar Bitcoin interfaces.\n\n**Run locally. Inspect the contracts. Share one reproducible result.**\n\n[Getting started](https://github.com/gosuda/bitcoin-rs/blob/main/docs/getting-started.md) ·\n[Documentation](https://github.com/gosuda/bitcoin-rs/blob/main/docs/README.md) ·\n[Contributing](https://github.com/gosuda/bitcoin-rs/blob/main/CONTRIBUTING.md) ·\n[Benchmarks and limitations](https://github.com/gosuda/bitcoin-rs/blob/main/docs/benchmarks/end-to-end-sync.md)\n\n[Bitcoin Core](https://github.com/bitcoin/bitcoin) is the most successful\nimplementation of Bitcoin. Its conservatism, stability, and compatibility\ndiscipline are major reasons for\nthat success. Over time, however, those safeguards also shape which changes are\npractical: existing boundaries accumulate dependencies, and implementation\nchoices harden into assumptions that Bitcoin consensus does not require.\n\nbitcoin-rs asks a simple question:\n\n**If a Bitcoin full node were designed again today, what would we keep, and\nwhat would we change?**\n\nAI is changing how software is built. Work that once required large teams and\nlong development cycles can now be attempted by much smaller teams with far\nfaster iteration. Bitcoin is unusually well suited to this model because\nimplementations can be checked against Bitcoin Core, `libbitcoinkernel`,\nhistorical chain data, consensus test vectors, fuzzing, and differential tests.\n\n**Bitcoin is well suited to AI-native development; Bitcoin Core's development\nculture is not.** Its review process prioritizes minimizing change risk,\nrewarding incrementalism, entrenching existing boundaries, and making radical\narchitectural experimentation prohibitively expensive.\n\n**That is why we built `bitcoin-rs`: to preserve Bitcoin's consensus while\nmaking bold architectural experimentation practical—build alternatives,\nverify them against reproducible evidence, and keep iterating until better\ndesigns emerge.**\n\n- **Performance is a first-class requirement.**`bitcoin-rs` is not aiming for\nparity with Bitcoin Core simply by changing languages. Synchronization,\nstorage, memory ownership, concurrency, caching, I/O, and indexing can all be\nreconsidered. Improvements must be demonstrated with matched whole-node\nbenchmarks against Core.\n- **The UTXO set is the node's authoritative coin state.** Much of the Bitcoin\napplication ecosystem grew by rebuilding or duplicating wallet-, Electrum-,\nand explorer-specific views around the same chain data.`bitcoin-rs` simplifies that boundary: the node owns the canonical UTXO set used for\nvalidation and an integrated script index exposed through Esplora-compatible\nAPIs. This eliminates the need for a separate Electrum server with its own\nduplicate chain state and ingestion pipeline.\nWallet-specific keys, policies, and metadata remain outside the node.\nConsumers build on node state; they do not redefine where Bitcoin's coin\nstate lives.\n- **Modularity keeps the core isolated and components composable.** Clear\ndependency and failure boundaries keep extensions from destabilizing\nvalidation or chainstate while allowing components to be reused independently.\nExtensions own their state and lifecycle and may build on core capabilities,\nbut they do not become dependencies of the core.\n- **Rust-native integration is a primary path.** Applications and extensions in\nthe Rust Bitcoin ecosystem can attach to the node as typed, in-process\ncomponents instead of routing through serialized RPC or separate processes.\nThis improves runtime efficiency and simplifies integration and deployment,\nmaking the full node a native, composable part of the ecosystem.\n\nBitcoin is not defined by the continued preservation of one codebase. **The code\ncan change; consensus is what must remain.** `bitcoin-rs` aims to challenge\nBitcoin Core and build a better Bitcoin implementation. That challenge\nstrengthens the Bitcoin ecosystem: a separately designed codebase cross-checks\nconsensus interpretation, increases implementation diversity, and reduces the\nrisk of correlated implementation failures.\n\n- Consensus validation: the native Rust interpreter verifies Legacy, SegWit v0,\nand Taproot key-path and script-path spends. Core's committed `script_tests` ,`tx_valid` , and`tx_invalid` vectors pin zero native mismatches. Script checks\nrun in parallel across rayon workers with sighash midstate reuse per\ntransaction.`--features kernel` routes the same checks through`libbitcoinkernel` (Bitcoin Core's C++ engine) as an independent oracle.\n- Kernel feature: `--features kernel` enables`libbitcoinkernel` . The`crates/consensus` and`crates/node` library crates still default to`kernel` ;\nthe`bin/bitcoin-rs` binary defaults to`[\"fjall\", \"redb\", \"zmq\"]` (no kernel)\nand does not link`libbitcoinkernel` . Issue #213 keeps that split until\nnative wins the signed-spend and full-replay gates; see the[validation-default contract](https://github.com/gosuda/bitcoin-rs/blob/main/docs/contracts/validation-default.md) .\n- Pure-Rust storage defaults: LSM-tree storage backed by `fjall` by default,\nwith`redb` compiled in and`rocksdb` available through an optional Cargo\nfeature.\n- Sharded UTXO cache: a 256-shard in-memory UTXO set (`hashbrown::HashTable` of\ncompact records behind`parking_lot::RwLock` ) with checkpoint-based crash\nrecovery and effective`--dbcache-mb` budget allocation.\n- Asynchronous index consumer: `txindex` reconciles over a monotonic chain\nsnapshot and event hint channel without blocking block validation.\n- Integrated ScriptIndex and Esplora APIs: address and scripthash UTXO indexing and confirmed transaction history served directly over HTTP.\n- Mempool mutation gateway: centralized mutation tracking publishing ordered\naccept and remove events over ZMQ `pubsequence` .\n- Block template assembly: mining candidate generation via `getblocktemplate` .\n- Core-compatible RPC and typed embedding: synchronous HTTP JSON-RPC using Core\nmethod names and wire formats (walletless, no private keys), plus a typed\nasync `Node` embedding API for in-process Rust integrations.\n\nBuild and run the kernel-free default binary with the quick-start profile.\nConsult [Getting started](https://github.com/gosuda/bitcoin-rs/blob/main/docs/getting-started.md) for build lanes and\nprerequisites before choosing features:\n\n```\ncargo build --profile quickstart -p bitcoin-rs\n./target/quickstart/bitcoin-rs --data-dir .bitcoin-rs\n```\n\nUse the `quickstart` profile for initial exploration. For sustained IBD or\nbenchmarking, use `cargo build --release -p bitcoin-rs` and record the exact\nprofile and feature set with the result. No build-time ratio is claimed here.\n\nThis starts a mainnet node storing state in `.bitcoin-rs` and listening for\nJSON-RPC on `127.0.0.1:8332`.\n\nVerify the node is responding and syncing:\n\n```\ncurl -s --user bitcoin-rs:bitcoin-rs \\\n  -H 'content-type: application/json' \\\n  -d '{\"jsonrpc\":\"1.0\",\"id\":\"1\",\"method\":\"getblockchaininfo\",\"params\":[]}' \\\n  http://127.0.0.1:8332/\n```\n\nTo route script verification through `libbitcoinkernel` instead of the native\ninterpreter, install C++ dependencies (`cmake` and `libboost-dev` on\nDebian/Ubuntu), then pass `--features kernel`:\n\n```\ncargo build --release -p bitcoin-rs --features kernel\n./target/release/bitcoin-rs --data-dir .bitcoin-rs\n```\n\n[End-to-end synchronization evidence](https://github.com/gosuda/bitcoin-rs/blob/main/docs/benchmarks/end-to-end-sync.md) is the\nowner of methodology, measurements, artifact custody, and limitations. It\nretains historical bounded results from superseded engines, including both\nfaster local replays and slower daemon IBD results. Those figures are not\ncurrent end-state proof or a general speed comparison with Bitcoin Core.\n\nThe owner's end-state cells are marked `planned_not_executed`. Historical raw\nJSON was retired by #224; retained digests can identify an external copy, but\nare not a replacement for the raw evidence. This README makes no current\nperformance-superiority claim. Consult the owner document for the status of\neach workload before quoting a result.\n\n```\nSurfaces:      bin/bitcoin-rs, crates/rpc\nCapabilities:  crates/index, crates/mining, crates/mempool\nNode services: crates/node, crates/p2p, crates/storage\nCore & domain: crates/consensus, crates/script, crates/utxo, crates/chain, crates/primitives\n```\n\n- Validation: script execution runs in parallel across rayon workers, with\nsighash midstate reuse per transaction. The native interpreter covers every\nconsensus spend class. Under the `kernel` feature,`libbitcoinkernel` is the\nverifier instead.\n- Kernel boundary: `crates/consensus/src/kernel.rs` contains all`libbitcoinkernel` types behind`#[cfg(feature = \"kernel\")]` . Kernel types\nnever leak into node state or apply logic.\n- Storage: `crates/storage` provides backend abstraction. The active engine is\nconfigured at startup (`fjall` ,`redb` , or`rocksdb` ).\n- Indexing: `txindex` runs as an independent consumer, advancing its cursor and\nrollback metadata atomically.\n\n| Setting | Default | \n|---|---|\n| Storage backend | `fjall` | \n| Validation engine | Native Rust interpreter (default binary); `libbitcoinkernel` with`--features kernel` and as the consensus/node library default | \n| Kernel feature | Off in default binary build; on in `crates/consensus` and`crates/node` library defaults | \n| Database cache | 450 MiB ( `--dbcache-mb` , split 80/20 when txindex is enabled) | \n| Multi-peer download | On (8 outbound peers, 256-block window) | \n| Transaction index | Off | \n| Script index | Off | \n| Pruning | Off | \n\nMainnet defaults to skipping historical script verification up to the pinned\nassume-valid anchor. Pass `--assume-valid-height 0` to verify all scripts from\ngenesis.\n\n```\n# Build default binary (kernel-free)\ncargo build --release -p bitcoin-rs\n\n# Run workspace unit and integration tests\ncargo test --workspace\n\n# Lint all targets\ncargo clippy --workspace --all-targets -- -D warnings\n```\n\nContributions are welcome. See [CONTRIBUTING.md](https://github.com/gosuda/bitcoin-rs/blob/main/CONTRIBUTING.md) for local\nverification commands, CI workflows, and crate architecture conventions.\n\n- [docs/getting-started.md](https://github.com/gosuda/bitcoin-rs/blob/main/docs/getting-started.md) — Node setup and configuration\n- [docs/README.md](https://github.com/gosuda/bitcoin-rs/blob/main/docs/README.md) — Documentation index\n- [docs/contracts/](https://github.com/gosuda/bitcoin-rs/blob/main/docs/contracts) — Normative architecture and protocol contracts\n- [CONCEPTS.md](https://github.com/gosuda/bitcoin-rs/blob/main/CONCEPTS.md) — Domain terminology and concepts\n\nLicensed under [Apache-2.0](https://github.com/gosuda/bitcoin-rs/blob/main/LICENSE).", "url": "https://wpnews.pro/news/show-hn-bitcoin-rs-an-ai-assisted-bitcoin-full-node-in-rust", "canonical_source": "https://github.com/gosuda/bitcoin-rs", "published_at": "2026-09-21 09:03:05+00:00", "updated_at": "2026-09-21 09:23:54.872738+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents"], "entities": ["bitcoin-rs", "Bitcoin Core", "Rust", "libbitcoinkernel", "Esplora", "Electrum"], "alternates": {"html": "https://wpnews.pro/news/show-hn-bitcoin-rs-an-ai-assisted-bitcoin-full-node-in-rust", "markdown": "https://wpnews.pro/news/show-hn-bitcoin-rs-an-ai-assisted-bitcoin-full-node-in-rust.md", "text": "https://wpnews.pro/news/show-hn-bitcoin-rs-an-ai-assisted-bitcoin-full-node-in-rust.txt", "jsonld": "https://wpnews.pro/news/show-hn-bitcoin-rs-an-ai-assisted-bitcoin-full-node-in-rust.jsonld"}}