Run Bark captaind: version floor, version-3 submit, TRUC, 0-value anchor #1164

What this is

Bark's Ark server, captaind, speaks only Bitcoin Core JSON-RPC. This issue is the set of changes that let a current captaind boot and broadcast on this node, without turning libre relay into Core standardness.

Measured against:

• bark master 2ed8223a8 (require-mailbox-auth-post-recovery, 2026-10-23), https://gitlab.com/ark-bitcoin/bark
• rbitcoin master fb991651 (Merge pull request #1149)

Captaind's boot gate is in server/src/bitcoind.rs: network match, getnetworkinfo.version >= 310000, and getindexinfo reporting txindex. The 310000 floor exists because Core 31 added getmempoolentry's chunkweight and fees.chunk. This node already returns those fields. The round-funding transaction is version 2 (server/src/wallet/mod.rs). The vtxo tree, forfeits, connectors, and the exit CPFP are version 3, and the exit is submitpackage of [progress_tx, cpfp_tx] where the parent is 0-fee and carries fee_anchor() (Amount::ZERO).

Already in place

These are not open work. A regtest probe of fb991651 against captaind's client (bitcoincore-rpc 0.19, the same crate bark pins) got through every boot and round call except the two gates in the first two drafts below:

• cookie auth on 127.0.0.1
• getblockcount, getblockhash, getblockheader, getrawtransaction (verbose and hex), gettxout (null result included), gettxspendingprevout
• getindexinfo → { "txindex": { "synced": true, "best_block_height": N } }
• getmempoolentry including chunkweight and fees.chunk (vsize is chunkweight)
• submitpackage in the Core shape (package_msg, tx-results keyed by wtxid, replaced-transactions)
• estimatesmartfee with conf_target and estimate_mode. An empty mempool omits feerate and returns errors: ["Insufficient data or no feerate found"], which is Core's current shape. Captaind logs that and uses its fallback rates.
• sendrawtransaction of an already-confirmed spend returns -25 RPC_VERIFY_ALREADY_IN_UTXO_SET, which captaind swallows on rebroadcast
• duplicate sendrawtransaction returns the txid. Captaind treats Ok as success
• getmempoolentry of a missing tx is -5, so captaind's chunk-fee lookup becomes Ok(None)
• the round's BDK Emitter synced a fresh rounds wallet across getblock verbosity 0 and 2

The four changes

Each one is a draft. Libre relay stays: 0.1 sat/vB, no numeric dust floor, full RBF, P2P still admits any nVersion.

1. Reported version. Default getnetworkinfo.version stays 190000 so existing clients keep the Core 0.19 getblockchaininfo shape. --rpc-client-version=310000 (conf rpc_client_version=) raises only that integer. Captaind will not boot below 310000. rpc: let operators raise getnetworkinfo.version #1159
2. Version 3 on RPC submit. sendrawtransaction, testmempoolaccept, and submitpackage reject every nVersion other than 1 or 2 before accept. Captaind's tree, forfeit, connector, and CPFP transactions are version 3. P2P already allows them. Other versions stay rejected. rpc: admit nVersion 3 on submit #1160
3. BIP 431 TRUC. A version-3 transaction may have one unconfirmed ancestor and one unconfirmed descendant, at most 10,000 vB, and at most 1,000 vB when that ancestor is unconfirmed. Parent and child must both be version 3. Replacing the existing child is allowed because that child conflicts. A second child that spends a different output is truc-descendant-count (no sibling eviction). Full RBF and the package feerate waiver already cover the other two BIP 431 rules. mempool: enforce BIP 431 TRUC topology #1161
4. The 0-value anchor. One 0-value spendable output may enter when the fee is 0 and a later package member spends it. A child that spends the parent and leaves that output is missing-ephemeral-spends. A fee-paying transaction, a second 0-value output, and a lone sendrawtransaction stay dust. This is not a pay-to-anchor special case. mempool: admit one 0-value output inside a package #1163

#1159 and #1160 are independent. #1161 and #1163 both edit crates/rbitcoin-mempool/src/accept.rs in different places (the fee-floor tail, and the shape check plus accept_package). Whichever lands second needs a rebase.

Not captaind, and not in these drafts

• ZMQ. Captaind polls. The bark client and the test harness use ZMQ; the server does not require it to run.
• Esplora scripthash byte order and POST /txs/package. That is the bark wallet, not captaind.
• --sh-index. Captaind does not read scripthashes.
• RPC user/password. Cookie auth is what captaind is pointed at here.
• Raising the default getnetworkinfo.version. A higher default would make old bitcoincore-rpc clients look for wallet RPC this node does not have.

Operator shape, once the drafts are in

rbitcoin-node --network signet --milestone 0 \
  --rpc-listen 127.0.0.1:38332 \
  --rpc-cookie-file <cookie> \
  --rpc-client-version=310000

Captaind's bitcoind_url is that RPC port and the cookie's user:password. No second wallet.