Transaction e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468

Block #91722

2010-11-14 08:37:28 +0000 UTC (~13 years, 9 months ago)

BTC Burned: 🔥50 BTC🔥


Inputs

Coinbase: 0456720e1b00

Coinbase converted to ASCII Vr�

Outputs
4104124b212f5416598a92ccec88819105179dcb2550d571842601492718273fe0f2179a9695096bff94cd99dcccdea7cd9bd943bfca8fea649cac963411979a33e9ac
50 BTC
now $3,066,700.00
50 BTC
04124b212f5416598a92ccec88819105179dcb2550d571842601492718273fe0f2179a9695096bff94cd99dcccdea7cd9bd943bfca8fea649cac963411979a33e9 OP_CHECKSIG pubkey

How did this transaction burn BTC?

Identical Coinbase Transaction Bug

In the early days of Bitcoin, it was assumed that two different transactions would never have the same hash, or transaction ID. This was a fair assumption on the surface, as each transaction consumes unique inputs, and the hash of a transaction was based on the contents of the transaction. However, this overlooked the fact that Coinbase transactions had no prior inputs, and the coinbase field was entirely determined by the miner.

In 2010, this was demonstrated accidentally twice in quick succession. Blocks 91722 and 91880 both sent the 50 BTC block subsidy to the same public key. Both blocks charged no fees, and used an identical coinbase field of 0456720e1b00. Simultaneously, blocks 91812 and 91842 used a different public key, but had the same coinbase field of 0456720e1b00.

This resulted in two instances of identical coinbase transactions, which resulted in them having identical transaction IDs:

  1. e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468 - Blocks 91722 and 91880
  2. d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599 - Blocks 91812 and 91842

With the Bitcoin Core implementation at the time, this caused the second blocks containing each duplicate transaction to effectively “overwrite” the previous one, resulting in a loss of 50 BTC each time. This effectively reduced the value of the UTXO set by 100 BTC, thereby permanently reducing the supply.

This was subsequently address in BIP301 and BIP342, which restricted overwriting of transactions, and ensured that each coinbase transaction contained the block height in the coinbase field, making them unique.

Unfortunately, it came too late for the miner(s) who lost 100 BTC.

View revision history

Coinbase Reward Loss

For a variety of reasons, some blocks do not claim their full block reward.

The Bitcoin Protocol and reference Bitcoin Core implementation only require that the sum of all outputs in the coinbase transaction are less than or equal to block subsidy + transaction fees for that block. They don’t require that all of this entitlement is claimed by the miner.

Over the years, numerous misconfigurations and bugs in the systems used by miners to generate block templates have resulted in under-claiming of the block reward. Not only is this a loss to the miner, but it also reduces the total supply of Bitcoin that will ever be mined. There is no mechanism to claim unclaimed rewards after the block in which they were supposed to be claimed.

On rarer occasions, bugs in the reference implementation itself have led to losses - notably, the Genesis Block, Block 91722, and Block 91812 block rewards were claimed but destroyed due to bugs in the Bitcoin Core implementation at that time.

View revision history
Raw Transaction
{
  "txid": "e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468",
  "hash": "e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468",
  "version": 1,
  "size": 133,
  "vsize": 133,
  "weight": 532,
  "locktime": 0,
  "vin": [
    {
      "txid": "",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "prevout": {
        "generated": false,
        "height": 0,
        "value": "",
        "scriptPubKey": {
          "asm": "",
          "desc": "",
          "hex": "",
          "type": ""
        }
      },
      "coinbase": "0456720e1b00",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": "50.00000000",
      "n": 0,
      "scriptPubKey": {
        "asm": "04124b212f5416598a92ccec88819105179dcb2550d571842601492718273fe0f2179a9695096bff94cd99dcccdea7cd9bd943bfca8fea649cac963411979a33e9 OP_CHECKSIG",
        "desc": "pk(04124b212f5416598a92ccec88819105179dcb2550d571842601492718273fe0f2179a9695096bff94cd99dcccdea7cd9bd943bfca8fea649cac963411979a33e9)#ss7pe7ny",
        "hex": "4104124b212f5416598a92ccec88819105179dcb2550d571842601492718273fe0f2179a9695096bff94cd99dcccdea7cd9bd943bfca8fea649cac963411979a33e9ac",
        "type": "pubkey"
      }
    }
  ],
  "fee": "",
  "hex": "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff060456720e1b00ffffffff0100f2052a01000000434104124b212f5416598a92ccec88819105179dcb2550d571842601492718273fe0f2179a9695096bff94cd99dcccdea7cd9bd943bfca8fea649cac963411979a33e9ac00000000"
}