BankNode
Ethereum guide Back to downloads
Threshold Bitcoin system

Bitcoin Threshold Schnorr V1

A Telegram-controlled deterministic 2-of-3 Taproot wallet with personal and group addresses, approval-driven signing, Bitcoin sends, and three cooperating signer nodes. The complete private key is never created or stored by one participant.

2-of-3 Schnorr Taproot BIP340 BIP341 Telegram HTTPS peer mesh
Key model

Distributed deterministic derivation and share generation without reconstructing the private key.

Signing model

Any two of three signer nodes cooperate to produce a Taproot key-path Schnorr signature.

Operating modes

Personal wallets and deterministic group wallets with Telegram approval flows.

Overview

The system consists of three independent signer services. Each service acts as an HTTPS peer server and a Telegram bot. Any addressed bot can coordinate a protocol round.

During /create, key material is produced through distributed deterministic derivation and distributed share generation. During signing, the nodes produce a threshold Schnorr signature without reconstructing the full private key.

Personal mode

One Telegram user receives one deterministic Taproot address and can sign or send with approval.

  • /create@bot
  • /sign@bot
  • /signhash@bot
  • /send@bot

Group mode

One initiator and two additional Telegram IDs receive one deterministic group address. Member order does not matter.

  • /create@bot <user_id2> <user_id3>
  • /multisign@bot
  • /multisignhash@bot
  • /multisend@bot
Prototype status: This implementation is intended for a controlled test environment and should not be treated as production custody software without independent validation and operational hardening.

Project structure

The active V1 implementation uses the following components:

  • three-headed-bot.js - entry point, peer server, and protocol orchestration.
  • crypto_backend.js - cryptography, storage, peer transport, and Bitcoin transaction construction.
  • tg_backend.js - Telegram polling, command parsing, and approval handling.
  • node-1.config.json, node-2.config.json, node-3.config.json - signer configurations.
  • v1/data - local persistent share and wallet data for each node.
Active rounds and pending approvals are held in memory. Derived addresses, local shares, and other persistent records live in the node data directory.

Configuration

Each signer uses one JSON configuration. Critical fields include:

  • protocol_fix
  • node.index_fix
  • crypto.masterSeed_fix
  • telegram.botToken
  • telegram.allowedGroupId
  • http.listenHost, http.port, and TLS certificate fields
  • peers
  • bitcoin.providers

Secret

  • crypto.masterSeed_fix
  • http.tls.keyPem
  • contents of v1/data

Not secret

  • Telegram bot usernames
  • Bitcoin addresses
  • group keys
  • peer IP addresses and ports

Start

Install dependencies:

npm install

Run all three nodes in separate terminals:

node v1/three-headed-bot.js v1/node-1.config.json
node v1/three-headed-bot.js v1/node-2.config.json
node v1/three-headed-bot.js v1/node-3.config.json

Or use the npm script:

npm run v1:start -- v1/node-1.config.json
At startup, each node loads its identity, starts the HTTPS peer server, begins Telegram polling and peer health checks, and publishes a short help message to the allowed Telegram group.

Telegram commands

Every command must be addressed to a specific bot and sent inside the configured Telegram group.

/create@bot
/create@bot <user_id2> <user_id3>
/address@bot
/balance@bot [<address>]
/utxo@bot
/status@bot
/sign@bot <message>
/signhash@bot <32-byte-hex-hash>
/send@bot <to_address> <amount_sats> <fee_rate>
/multisign@bot <user_id2> <user_id3> <message>
/multisignhash@bot <user_id2> <user_id3> <32-byte-hex-hash>
/multisend@bot <user_id2> <user_id3> <to_address> <amount_sats> <fee_rate>
/approve@bot
/reject@bot

An amount_sats value of zero enables send-all mode, with the calculated fee subtracted from the available total.

Approval flow

Signing and sending commands require approval before the second signer releases its partial signature.

Personal

  1. The user sends a command to one bot.
  2. That bot becomes coordinator and selects a second signer.
  3. The second signer posts an approval request.
  4. The same user sends /approve or /reject.

Group

  1. The initiator sends a multi-user command.
  2. The second signer posts an approval request.
  3. Either listed additional member may approve.
  4. The request aborts if no approval arrives before timeout.

Bitcoin logic

Provider model

The provider layer uses Esplora-compatible HTTP APIs. Balance and UTXO queries compare configured providers, while transaction broadcast succeeds when at least one selected provider accepts the final raw transaction.

Send pipeline

  1. Validate destination, amount, and fee rate.
  2. Fetch UTXOs from configured providers and check consistency.
  3. Build the Taproot spend candidate and select inputs.
  4. Compute one BIP341 sighash for every selected input.
  5. Threshold-sign each input without reconstructing the private key.
  6. Finalize the witness and broadcast the raw transaction.
Supported: Taproot key-path spending, multiple input selection, and send-all mode. Not currently supported: PSBT import/export, Taproot script-path spending, advanced coin-selection policy, or multiple recipients in one command.

Testing

Personal flow

/create@bank_node_1_bot
/address@bank_node_1_bot
/balance@bank_node_1_bot
/sign@bank_node_1_bot hello world
/signhash@bank_node_1_bot 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Group flow

/create@bank_node_1_bot 111111111 222222222
/address@bank_node_1_bot
/balance@bank_node_1_bot
/multisign@bank_node_1_bot 111111111 222222222 hello
/multisignhash@bank_node_1_bot 111111111 222222222 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Send examples

/send@bank_node_1_bot bc1p... 15000 3
/send@bank_node_1_bot bc1p... 0 3
/multisend@bank_node_1_bot 111111111 222222222 bc1p... 15000 3

Troubleshooting

sign already in progress

Finish the active approval flow, wait for timeout, or inspect the coordinator logs.

no address ... run create first

Run personal /create or group /create <id2> <id3>.

bitcoin providers inconsistent

Configured providers returned different UTXO views. Retry later or replace the inconsistent provider.

all bitcoin providers unavailable

Check network access and provider URLs in all node configurations.

Pending approvals and active protocol rounds are memory-only and are not restored after process restart.

Security review

AI-assisted security review

The Bitcoin threshold Schnorr implementation and its operational controls were reviewed with Claude Mythos and GPT-5.6 as AI-assisted analysis tools. This review does not replace an independent professional security audit.