Bitcoin Forum
July 14, 2026, 11:52:27 AM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [ANN] ThankBitcoin (TBC) — a Bitcoin Core fork; beneficiary decided by a Bitcoin  (Read 53 times)
thankbitcoin (OP)
Newbie
*
Offline

Activity: 1
Merit: 0


View Profile
July 13, 2026, 03:21:48 PM
Last edit: July 13, 2026, 04:08:32 PM by thankbitcoin
 #1

ThankBitcoin (TBC) - a Bitcoin Core fork that outsources one consensus decision to the Bitcoin chain

Experimental / educational protocol research. Not a product, not a company, not a financial instrument. See the disclaimer at the end.

Quote
TL;DR: A Bitcoin Core fork where who receives part of each block reward is decided by an open auction on the Bitcoin chain - and that ruling is enforced by Bitcoin's own hashrate. One added consensus rule; everything else is Bitcoin unchanged.



What it is

ThankBitcoin is a fork of Bitcoin Core with exactly one added consensus rule. Everything else - proof of work, the longest-chain rule, the UTXO model, scripts, signatures, addresses - is inherited from Bitcoin unchanged.

The one change: each block's coinbase pays two shares instead of one.
  • a miner share (won by PoW, plus all transaction fees), and
  • a beneficiary share - paid to an address that is not chosen by ThankBitcoin's own chain, but decided by a public, on-chain competition on the Bitcoin chain.

Why do this

A brand-new PoW chain has almost no hashrate, so its longest-chain rule is weak and its history is cheap to rewrite. ThankBitcoin does not claim to fix that for every transaction (it can't - ordinary blocks still rely on ThankBitcoin's own PoW; we say so plainly). Instead it takes the single most consensus-critical decision on the chain - who receives the beneficiary share - and hands the ruling to Bitcoin's hashrate. The competition result is written into a Bitcoin transaction; once that transaction has enough confirmations, changing the result would mean reorganizing Bitcoin itself.



How the competition works

Time is divided into terms of 1000 blocks each. Within one term the beneficiary is fixed. To become the beneficiary of the next term, you broadcast a specially-structured transaction on the Bitcoin chain:

Code:
   A qualifying bid = one Bitcoin transaction, 4 outputs:

   inputs: your BTC --+
                      |
                      +-> vout[0]  bid amount   --> fixed recipient (bitcoin.org donation addr)
                      |                              the higher the bid, the better your rank
                      |
                      +-> vout[1]  >= dust       --> previous term's beneficiary
                      |                              (links the term history, anyone can trace)
                      |
                      +-> vout[2]  change        --> back to you
                      |
                      +-> vout[3]  OP_RETURN 52B --> [ 32B: prev ThankBitcoin block hash | 20B: ThankBitcoin payout addr ]
                                                     binds the bid to THIS round (no replay)

  • output 0 - your bid, a real Bitcoin transfer to a fixed recipient address (the public bitcoin.org donation address). Making the bid a real transfer is what makes bidding costly and sybil-resistant.
  • output 1 - a small linking output to the previous term's beneficiary; chains term history together, verifiable by anyone scanning Bitcoin.
  • output 3 - the only data output: the previous term's last ThankBitcoin block hash (binds the bid to this round, prevents replay) followed by the 20-byte hash of the address you want to receive the ThankBitcoin beneficiary share.

The rule for picking the winner is a deterministic pure function of the Bitcoin chain, so any two nodes with the same Bitcoin view compute the same result:
  • Scan the Bitcoin chain from the term's start height upward.
  • The decisive block B* is the first block that (a) contains at least one qualifying bid and (b) has at least 8 confirmations.
  • Inside B*, the highest bid wins (ties broken deterministically by txid).

No bidders? A fallback, not a stall. Each term opens a grace window that starts at the term-boundary anchor and lasts until a Bitcoin block ~8 confirmations deep has appeared (so bidders get real on-chain time). If no qualifying bid shows up in that window, the term falls back: the beneficiary share is paid to a provably-unspendable burn address (all-zero HASH160 - no private key can exist for it, anyone can verify), not carried over to the previous beneficiary. This removes any incentive to manufacture a "no-bid" term to keep collecting - nobody can collect. The chain keeps producing blocks normally.

Note - two different addresses, don't confuse them: the bid recipient (output 0 above) is a real, spendable address on the Bitcoin chain (the bitcoin.org donation address); the fallback burn address is an all-zero address on the ThankBitcoin chain that provably has no private key. Bids are real Bitcoin transfers; fallback shares are ThankBitcoin coins that can never be spent (effectively destroyed).

Anchoring. Because each term-boundary block hash is embedded in the Bitcoin transaction that carries the bid, ThankBitcoin's key history is anchored into Bitcoin. This anchoring is enforced as a consensus rule: a term's first block is only valid if it correctly commits to the Bitcoin block that decided the term, checked against a fixed, closed interval - so both auctioned and fallback terms can be re-verified by anyone, at any time, and cannot be poisoned after the fact by a late bid.



It is not a "slow chain"

Out of 1000 blocks in a term, 999 are ordinary blocks produced at the normal 60-second target. Only the one term-first block waits - it must wait for the decisive Bitcoin block to reach 8 confirmations (~80 minutes, roughly once every ~16.7 hours). That pause is a design feature: it aligns the two chains and gives bidders real time to get on-chain.



Parameters

  • Base: Bitcoin Core v31.1 fork
  • Block target: 60 seconds
  • Term length: 1000 blocks
  • Beneficiary share = miner share x 1.7 (integer math); fees go only to the miner. (The beneficiary share is deliberately the larger of the two - an intentional choice to draw attention to on-chain bidding in the early phase; miners keep 100% of fees as an offset. This tradeoff is discussed openly in the whitepaper, section R9.)
  • Bitcoin confirmations required to settle the competition: 8
  • PoW: SHA256d (same as Bitcoin). "Difficulty = Litecoin x 2/5" refers only to the powLimit numeric value, not the hashing algorithm - it is NOT scrypt.
  • Addresses/keys: byte-for-byte identical to Bitcoin mainnet (bech32 "bc1q...", same WIF/xpub, BIP44 coin type 0). Chains are separated by network magic + ports.



Running a node / verifying the competition

Verifying term rollover requires reading the Bitcoin chain. Two options:
  • (Recommended, highest assurance) Run your own Bitcoin full node and point the ThankBitcoin node at its local RPC - zero third-party trust, fully self-verified.
  • (Zero-setup) Point it at any Bitcoin data service you trust (e.g. getblock.io, mempool.space, or any public node) - no full node required; the tradeoff is trusting that source's view of the Bitcoin chain.
The data source is pluggable; the consensus logic is identical either way.



Status

Mining goes live: 2026-07-15 01:00 UTC. At that moment the genesis block becomes valid and anyone can start mining. The genesis timestamp is fixed to this time; the anchor Bitcoin height and seed node(s) are published in the source repo and announced in this thread at launch.

What is public right now: the full source code, the complete mechanism, and a running demo chain (visible in the block explorer) for review and experimentation.




How to participate

Two ways to take part:
  • Mine - run a node and produce blocks (SHA256d, same as Bitcoin). The only setup choice is how your node reads the Bitcoin chain: your own full node (zero trust), or a public data service (mempool.space built-in, or getblock.io via a tiny local proxy). The miner share + all fees go to you.
  • Bid - publish a structured transaction on the Bitcoin chain to compete for a term's beneficiary slot. You build and sign it with your own wallet - keys and coins never leave you; no ThankBitcoin server is involved. Note a bid spends real Bitcoin and is not refundable (see the guide).
Step-by-step commands for both (mining examples + exact bid transaction format): https://thankbitcoin.com/how-to



Links




Known limits (stated honestly)

  • Ordinary blocks are protected only by ThankBitcoin's own PoW; against double-spends of ordinary transactions ThankBitcoin is no safer than any small PoW chain.
  • Fallback (no-bid) terms carry no Bitcoin-backed finality - they are self-verifiable but not anchored by hashrate. This is most common early on.
  • Bitcoin gives finality of the competition result, not censorship-resistance of the competition process - the miner who packs the decisive Bitcoin block still has influence over which bids it contains.



Disclaimer

ThankBitcoin is an experimental, educational protocol research project. It is not an investment, not a security, not a financial product, and makes no claims of value, price, return, or future worth of any kind. Do not treat TBC as money or as an asset. The code is provided as-is for study and experimentation. Run it only if you understand what it does.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!