BTC → BLAKE2b Relay

Live relay throughput, queue, acceptance and lifecycle metrics.

Loading snapshot

About this relay

Why this relay exists and what it relays

Bitcoin transactions are public, signed messages. This service does not create, modify, or sign them. It watches transactions newly accepted into a Bitcoin mainnet node’s mempool, tests the original transaction bytes against a BLAKE2b node’s current UTXO set and mempool policy, and submits only those that remain valid and acceptable under BLAKE2b rules, without changing their bytes.

I operate this relay because non-propagation is not replay protection. If a transaction is valid on both chains, users and protocol designers should assume that any network participant can relay it. An open network should not depend on valid transactions remaining unseen.

Experimentation with this relay began on September 9, 2026. The first transaction was relayed that day, and the service moved from canary testing to live operation later that evening. Detailed BLAKE2b-side lifecycle and per-block tracking for this relay began on September 14, 2026. On September 20, 2026, the BLAKE2b node used by this relay had its minimum relay fee lowered from 1.0 to 0.1 ṩ/vB, matching the Bitcoin source node. This allows the relay to handle otherwise valid transactions below 1 ṩ/vB under normal mempool conditions.

The relay is deliberately selective: a transaction accepted into Bitcoin’s mempool may be invalid or non-standard on BLAKE2b because the two chains now have different UTXO sets and mempool policies. Since the verified public v2 measurement began at November 3, 2026, 13:45 UTC, this service has successfully relayed 296,532 of 4,944,834 newly observed Bitcoin mempool transactions (6.00%). During the last hour it recorded 821 successful relays and 13,591 newly observed transactions, a ratio of 6.04%. Since that measurement epoch, the two largest rejection classes were inputs unavailable on BLAKE2b (2,540,387) and already known (31,610).

Across fully evaluated active-chain BLAKE2b blocks, transactions previously relayed from Bitcoin to BLAKE2b by this service account for 87.22% across the latest 6 blocks (594 of 681), 87.82% over the last 24 hours (24,001 of 27,331), and 87.93% since tracking began on September 14, 2026 (1,890,305 of 2,149,715). Only non-coinbase transactions are counted.

Important

Replay risk

Bitcoin and BLAKE2b share chain history through Bitcoin block 961,639 and diverge at block 961,640. A Bitcoin transaction spending an output that remains unspent on both chains may also move the corresponding BLAKE2b coins to the same output scripts.

If the sender does not control those destination outputs on BLAKE2b, they may lose control of the corresponding BLAKE2b funds. Holders should split their coins or establish chain-specific spendability before broadcasting transactions. Robust protection requires protocol-level replay protection—not reliance on transactions remaining unrelayed.

This relay is intentionally designed to make Bitcoin transactions that remain valid on BLAKE2b available to the BLAKE2b network.

Stella, Nick and Luke are local names I use for the host and nodes running this relay.

Host

Stella

My server in Vienna, running both nodes and the relay service.

Bitcoin source

Nick

Bitcoin Core v31.1.0, following the Bitcoin chain and observing newly accepted mempool transactions.

Tip: 975,739Synced
Peers: 49 peers total (39 in / 10 out)

Mempool: 165.67 MB / 300.00 MB
Min fee: 0.100 ṩ/vB

BLAKE2b target

Luke

BLAKE2b-enabled Bitcoin Knots v29.4.2 · a BLAKE2b node using outbound-only Tor P2P connections and no public listener.

Tip: 981,884Synced
Peers: 10 peers total (0 in / 10 out) · routed through Tor

Mempool: 83.33 MB / 300.00 MB
Min fee: 0.100 ṩ/vB

Safety guide

How to split BTC and BLAKE2b safely

The safe direction is BLAKE2b first: spend each shared pre-fork output to yourself on BLAKE2b with every signature using SIGHASH_UNIFIED, wait for enough BLAKE2b confirmations for the value at risk, and only then spend the original output on Bitcoin.

Read the step-by-step guide

Back up and separate the wallets. Keep an offline backup of your seed or descriptors. Use independently verified Bitcoin and BLAKE2b nodes, and never paste a seed or private key into a website.
Verify the BLAKE2b signer. Use a current BLAKE2b-enabled Bitcoin Knots wallet or another signer that explicitly supports SIGHASH_UNIFIED. Do not use -walletoldsigs. An external or hardware signer must support the new hash type too.
Spend the BLAKE2b copy first. On BLAKE2b, use coin control to send the selected shared output to a fresh self-custody destination you control. Every signature for a shared input must opt in; where possible, verify that the decoded transaction reports a hash type such as ALL|UNIFIED.
Wait and verify independently. Broadcast through your BLAKE2b node and wait for sufficient BLAKE2b confirmations. Confirm on your Bitcoin node that the original outpoint is still unspent. For a material balance, test the workflow with one low-value UTXO first.
Spend the Bitcoin copy second. Only after the BLAKE2b split is confirmed, spend the original Bitcoin outpoint to a fresh Bitcoin destination. Do not combine it with any still-unsplit shared inputs.

What does not prove a safe split

A different address, an OP_RETURN, a low fee, a mempool rejection or any reason shown in Recent Operational Reasons is not protocol-level replay protection. Node policy can differ or change; the protection comes from the opted-in signature and the confirmed BLAKE2b-first spend.

This is a protocol-level workflow, not wallet-specific financial advice. Exact controls vary by wallet; stop if your signer cannot prove that it used SIGHASH_UNIFIED.

Primary sources Bitcoin Knots specification BLAKE2b replay-protection FAQ

The metrics below report local relay decisions and Luke’s observations. Acceptance by Luke is not proof that every BLAKE2b node received the transaction.

Loading chart

Loading table