[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).

[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