[ANN] 🔥burned.money🔥 - Track lost, destroyed, and never-mined BTC

[raghavsood]

Announcing burned.money - a tracker designed to monitor the Bitcoin supply.

Overview

I track cases of lost, burned, or never-mined BTC to give a lower bound on the amount of BTC that's been lost (and inversely, an upper bound on the Circulating Supply)

The site is intended as a resource for anyone interested or participating in the Bitcoin ecosystem, as well as researchers or other parties who look into specific instances or time periods.

Methodology

There are a few different things tracked by burned.money:

1. Miner losses - this covers BTC that was never mined to begin with, such as the 50 BTC from the genesis block, the duplicate coinbase transactions from blocks 91722 and 91812, as well as instances where miners claim a lower block reward than permitted by subsidy + fees, such as block 124724
2. OP_RETURN - OP_RETURNs provably mark BTC as unspendable, so any BTC sent to an OP_RETURN is effectively destroyed. Check out this transaction that sends 1.888 BTC to its demise.
3. Unspendable Scripts - There have been cases where BTC was sent to scripts which can never be redeemed, such as the Mt. Gox burn of 2609+ BTC, and the P2Pool coinbase tx output construction error
4. Cryptographic constraints - On occasion, addresses have been constructed which would be invalid on Bitcoin's secp256k1 implementation: https://burned.money/scriptgroup/ecdsa_incompatibility
5. Burn addresses - A variety of Burn Addresses are tracked, such as 1BitcoinEaterAddressDontSendf59kuE and 1CounterpartyXXXXXXXXXXXXXXXUWLpVr.
6. Lost keys - Perhaps the most controversial category, since it is rather difficult to prove a key has been lost. I try to restrict this to cases with some degree of confidence. To end up on this list, the public addresses must be known, and I should be reasonably convinced that the key is truly lost. However, the indexer does monitor the chain to ensure that if any coins from any output marked as burned are moved at some point in the future, they are added back to the supply figures.

Why?

As far as I'm aware, there is no high-quality index of such data - bitcoin-supply.com is the closest, but restricts itself to OP_RETURN and miner errors.

Upcoming/Planned Features

1. Exporting of data - The database is large, but not unbearably so (~500GB uncompressed). I intend to make this available as an SQLite/CSV dump for anyone wanting to do more indepth research
2. Adding more cases - there are several cases on my radar, such as the scripts made unspendable by the P2SH changes, as well as invalid taproot ecdsa constructs, and a laundry list of other burn addresses
3. Exploring the dataset - Even with a cursory look over the past few days, there are quite a few interesting patterns to share and write up on
4. More informative parsing of OP_RETURNs - right now, everything is nulldata - eventually, I'd like to mark Omni, Runes, etc. more clearly
5. Statistics - Presently, charing is limited to the supply curve - with all the data available, many interesting statistics can be shared.
6. RSS Feeds - Subscribe to new losses in transactions and blocks Implemented at burned.money/feeds

HELP CONTRIBUTE

The tracker is only as good as its data and implementation. The code is available at github.com/RaghavSood/btcsupply.

If you are aware of any more burns, losses, or lost keys, I encourage you to reply to this thread, open an issue on GitHub, or email tips@burned.money - any information on the ownership of funds that is not known to be public will be kept confidential (but you probably want to email me if that's the case).

Changelog

June 24, 2024

New page to list the last 500 losses incurred by miners (claiming less fees/block subsidy than allowed, duplicate coinbase tx, genesis coinbase) at https://burned.money/transactions/coinbase

June 18, 2024

ATOM feeds added at https://burned.money/feeds

[raghavsood]

reserved

[raghavsood]

Atom feeds are now live!

burned.money/feeds shows the overview for the feeds.

Feeds are available for block and transactions - feeds take an optional

Code:

?min_loss=100000000

parameter in Satoshis to filter for losses greater than or equal to that amount - the default is 100000 Satoshis, or 0.001 BTC.

For blocks, this filters against the sum of all burn outputs. For transactions, the sum of all burns within that transaction.

This should be followed by a telegram channel in the next day or so for people who want to subscribe easily. For those with their own RSS/ATOM feed readers, they can subscribe right away!

[dkbit98]

How can we see how much coins are burned during the time of extreme high transaction fees?

Lost keys - Perhaps the most controversial category, since it is rather difficult to prove a key has been lost. I try to restrict this to cases with some degree of confidence. To end up on this list, the public addresses must be known, and I should be reasonably convinced that the key is truly lost. However, the indexer does monitor the chain to ensure that if any coins from any output marked as burned are moved at some point in the future, they are added back to the supply figures.

Maybe you should add additional category for coins that didn't move for a long time or they never moved.
It would be more correct to say that coins are Unmovable, instead of Lost, but we don't know if one day Satoshi coins will be moved.

PS
What we know that those coins surely won't be moved my Faketoshi CSW

[BlackHatCoiner]

Lost != Burned.

I think you should clarify this on your main page, or even better remove "Lost keys" category once and for all. A "lost" bitcoin is still a spendable bitcoin. Satoshi's bitcoins are very spendable, and even though it's unlikely to ever be spent by him, it's likely that they'll be stolen sometime in the future, given the resources.

Same goes for "Burn addresses".

[DaveF]

I don't know how much work it would be but getting a dust total might be interesting too.
Saying there is a lot of BTC out there that will cost more to send then it's worth is one thing, knowing the actual number is another.

-Dave

[raghavsood]

How can we see how much coins are burned during the time of extreme high transaction fees?

Fees aren't considered burned, since a well-formed block will pay them back out in the coinbase transaction and put the coins back into circulation.

That said, I do store the block stats, so it is possible to have charts for things such as fees, difficulty, number of transactions, avg/medians fees, etc. Will look into how well it works.

Maybe you should add additional category for coins that didn't move for a long time or they never moved.
It would be more correct to say that coins are Unmovable, instead of Lost, but we don't know if one day Satoshi coins will be moved.

PS
What we know that those coins surely won't be moved my Faketoshi CSW

At this moment, I'm first focusing on building a provably or very likely lost index. A dormant coins confidence level may be added once I have some more work done to allow people to differentiate it on the UI.

[raghavsood]

Lost != Burned.

I think you should clarify this on your main page, or even better remove "Lost keys" category once and for all. A "lost" bitcoin is still a spendable bitcoin. Satoshi's bitcoins are very spendable, and even though it's unlikely to ever be spent by him, it's likely that they'll be stolen sometime in the future, given the resources.

Same goes for "Burn addresses".

For Lost Keys, yes, in theory they could be spent again - at this stage, only keys which I personally believe are truly lost are included (hence the small number). I do not include cases like James Howells' missing drive, as they may yet be found, and the addresses involved are unknown.

For burn addresses, spending would require breaking the security assumptions of deriving a private key from a public key [and/or] pre-image attacks on both SHA256 [and/or] RIPEMD160. This seems unlikely, and in my view merits considering the coins as burned.

[raghavsood]

I don't know how much work it would be but getting a dust total might be interesting too.
Saying there is a lot of BTC out there that will cost more to send then it's worth is one thing, knowing the actual number is another.

-Dave

That's actually a great idea, but at this stage I don't index all outputs, only those going to scripts believed to be inaccessible - as such, a dust counter would be inaccurate (as spendable scripts may contain dust).

I will likely roll this into a future, more general purpose explorer, thanks!

[raghavsood]

A new page has been added at https://burned.money/transactions/coinbase to show the 500 most recent losses incurred by miners who failed to mine the allowed amount of BTC (subsidy + fees).

Some notable examples:

https://burned.money/block/0 - We don't know if it was a mistake or intentional, but the 50 BTC from the genesis block were not added to the UTXO set and do not contribute to the circulating supply.
https://burned.money/block/91722 and https://burned.money/block/91812 - Duplicate Coinbase transactions resulted in the loss of 50x2 BTC.
https://burned.money/block/124724 - An intentional under-claiming of the block subsidy by midnightmagic (post by the user at the time)
https://burned.money/block/501726 - A miner failed to claim the entire 12.5 BTC block reward, paying out 0 BTC in the Coinbase transaction.
https://burned.money/block/526591 - A miner failed to claim half of the block reward, paying out only 6.25/12.5 BTC in the Coinbase transaction. The remaining 6.25 BTC is permanently lost.

There are numerous other smaller losses due to under-claiming of transaction fees or block subsidies.

Note that this does NOT include cases where the block is well formed (sum(coinbase outputs) == block subsidy + fees), but some of the BTC is sent to a burn address or other inaccessible output such as the P2Pool script output error (0.60280235 BTC).

[DaveF]

I don't know how much work it would be but getting a dust total might be interesting too.
Saying there is a lot of BTC out there that will cost more to send then it's worth is one thing, knowing the actual number is another.

-Dave

That's actually a great idea, but at this stage I don't index all outputs, only those going to scripts believed to be inaccessible - as such, a dust counter would be inaccurate (as spendable scripts may contain dust).

I will likely roll this into a future, more general purpose explorer, thanks!

Because when you see things like this transaction:

https://mempool.space/tx/ecf51c30b0597f6461daaad42066d1fb90c1a85b3c023ef8da5b87f11485556e

You know that a lot of those are never going to move.

But the question is what is the total number of those.

-Dave