Bitcoin supply discrepancy

[n0nce]

So, I'm working on my latest weekend project right now, which is something like a custom 'block clock' based on a 64x64 pixel LED matrix that I had lying around.
I'd like it to display a few Bitcoin metrics, such as

• Bitcoin price
• Bitcoin supply
• Lightning Network capacity

The idea sparked here:

and the number of Bitcoins continues to rise on the lightning network ... also the number of nodes and channels is very remarkable and pleasing

Do you have an API for this? I'd like to hang something fun on my wall; recently acquired one of these LED matrices.
I'd probably have it switch between BTC amount in circulation and dollar valuation as well as LN info such as what you've got in that dashboard type image.

Since I do have an ESP32-based driver board for that matrix, I can't access my local Bitcoin Core instance, so I was looking for a web API. To verify that they're accurate, I compared a few of them to my local bitcoin-cli gettxoutsetinfo output and noticed a discrepancy of a few hundred BTC.

Right now, the APIs tell me 18,998,531.25 while Bitcoin Core claims 18,998,310.93100097

This article nicely explains the discrepancy and basically Bitcoin Core gives the real number of issued BTC, while those APIs all show 21M-[BTC left to be mined]. A couple hundred are 'missing' due to miners not taking the fees and / or the block rewards a few times in the past.
Now, my question is whether those missing ones are going to be mined 'on top or not', because I'm not sure, but I'm pretty confident that they won't.

Is there a way to have Bitcoin Core tell you the number that those APIs give? Or do you just have to do this simple calculation yourself:

Code:

210,000 * 50 + 210,000 * 25 + 210,000 * 12.5 + (block_height-630,000) * 6.25

[1714100228]

1714100228

[1714100228]

1714100228

[1714100228]

1714100228

[1714100228]

1714100228

[pooya87]

Now, my question is whether those missing ones are going to be mined 'on top or not', because I'm not sure, but I'm pretty confident that they won't.

There was a block with X BTC reward that the miner didn't claim, in order to change that there needs to be a hard fork which is not going to happen for something this trivial. So the answer to your question is no, they won't be mined ever.

Is there a way to have Bitcoin Core tell you the number that those APIs give? Or do you just have to do this simple calculation yourself:

Just use the manual calculation, what core gives you is the accurate value though.

[garlonicon]

Yes, it is a miner-based burning of coins with no additional UTXO's, it is very clean way of burning coins: if you can take 50 BTC in the coinbase, but you only take 30 BTC, then 20 BTC is simply burned. To revert that, you need to re-mine an alternative chain, where the whole reward is claimed. That would require a huge reorg, so I guess nobody will do that.

Another thing is that coin supply can be changed in a soft-fork way, you can add as many zero satoshi outputs as you want, and then pretend they are worth something. If you convince enough nodes, then you can move zero coins, it will be compatible with the network, and can be used in case if all "real" amounts will be burned.

[o_e_l_e_o]

There was a block with X BTC reward that the miner didn't claim, in order to change that there needs to be a hard fork which is not going to happen for something this trivial.

There were many such blocks. A few larger examples:

Block 501726 claimed zero of the allowed 12.5 BTC.
Block 526591 claimed 6.25 of the allowed 12.5 BTC.
Block 164246 failed to claim any of the 1.76 BTC in fees.

Also note that block 91842 has a coinbase transaction which is identical to block 91812, and block 91880 has a coinbase transaction which is identical to block 91722. Since these transactions are identical, with identical hashes, they can only be spent once, meaning in each case 50 BTC was lost. (This bug was fixed in BIP 30.)

Also, the genesis coinbase transaction isn't part of the UTXO set, and so will not be counted by gettxoutsetinfo. The same applies to OP_RETURN outputs.

As noted, all these coins are provably and irretrievably lost. They can be permanently removed from the maximum supply.

[Pmalek]

block 501726 claimed zero of the allowed 12.5 BTC.
Block 526591 claimed 6.25 of the allowed 12.5 BTC.
Block 164246 failed to claim any of the 1.76 BTC in fees.

But why? Is this their good will? Is it a wrongly configured setup, or a bug that affected miners who mined those particular blocks? I don't see why they would turn down the block reward voluntarily.

[vjudeu]

For the same reason why people burn coins. Just because they can and it is valid. It is better way of burning coins than sending them to OP_RETURN, because it costs zero additional on-chain bytes. Most of the time it is just a bug or misconfiguration, but the same way of burning can be used in any Proof of Burn protocols: if you want to have an altcoin that is 1:1 covered with Bitcoin and it is one-way-ticket, then you can mine it just by getting less coins in the coinbase transaction, then for burning 1 BTC you can get 1 ALT. It would be better if Counterparty would do such things, rather than sending coins to 1CounterpartyXXXXXXXXXXXXXXXUWLpVr (because they are unlikely to be moved, but it may be possible by finding some matching key, so they are not entirely lost).

[o_e_l_e_o]

But why? Is this their good will? Is it a wrongly configured setup, or a bug that affected miners who mined those particular blocks? I don't see why they would turn down the block reward voluntarily.

Rarely because they intended to. Sometimes because of a bug. Sometimes because of poorly implemented code. Sometimes because they were trying to do something else and messed up. Sometimes we don't know. The only limit in the protocol is that the sum of all the outputs in a block must be equal or less than the sum of all the inputs plus the block subsidy. This places an upper limit that the miner can claim in the coinbase transaction (subsidy + fees), but places no lower limit, so it is perfectly valid for miners to claim less or nothing at all.

if you want to have an altcoin that is 1:1 covered with Bitcoin and it is one-way-ticket, then you can mine it just by getting less coins in the coinbase transaction, then for burning 1 BTC you can get 1 ALT. It would be better if Counterparty would do such things, rather than sending coins to 1CounterpartyXXXXXXXXXXXXXXXUWLpVr (because they are unlikely to be moved, but it may be possible by finding some matching key, so they are not entirely lost).

But such a set up would require everyone who wants to be able to own the altcoin to be able to mine a bitcoin block, which would never work: People who care about pointless shitcoins don't have enough ASICs to mine a solo block, and big mining pools aren't going to trade some of their reward for some pointless shitcoin that the majority of their miners don't want.

[BlackHatCoiner]

if you want to have an altcoin that is 1:1 covered with Bitcoin and it is one-way-ticket, then you can mine it just by getting less coins in the coinbase transaction, then for burning 1 BTC you can get 1 ALT. It would be better if Counterparty would do such things, rather than sending coins to 1CounterpartyXXXXXXXXXXXXXXXUWLpVr

There's no need to do either of those. Just use OP_RETURN and within those few bytes insert the destination (usually it's a hash) of the altcoin's address, plus some extra info such as the alt's prefix. That's the most convenient way to say "Hey, I'm burning these for the 29th dog coin".

But why? Is this their good will? Is it a wrongly configured setup, or a bug that affected miners who mined those particular blocks? I don't see why they would turn down the block reward voluntarily.

I'm sure most of those happened due to a wrongly configured setup. Whoever wants to test things does it in testnet. For those who want to "do good" there are hundreds of better ways I can think of, other than burning coins for the "common good".

[n0nce]

Sneak peek of my latest weekend project.
I'll clean up the code and start a topic for this with all the info like where to find the parts and what to install etc., in the next days but I wanted to have it up and running before block #19M. What do you guys think?
It looks a lot better in real life; it's very hard to photograph very bright individual LEDs, as it turns out.



I had seen this video, but due to component availability stuff and prices, ended up buying an older, ESP32-based adapter board from Tindie. But the details will follow.
I also need to find a way to keep it upright, because it does stand on its own or leaned against something, but every time it does fall, it crashes onto the circuitry on the back. Best would be a way to put it on the wall.

For now, I can count the last 1000 blocks until 19M.
The next million will take around 4 more years, if my calculations are correct, right?

[pooya87]

I'm sure most of those happened due to a wrongly configured setup. Whoever wants to test things does it in testnet. For those who want to "do good" there are hundreds of better ways I can think of, other than burning coins for the "common good".

Considering most of these things happened in early days it could be simply because bitcoin didn't really have that much value and people were playing around with it. It's kind of absurd to think about it now but losing 50BTC meant wasted computation time (maybe 30 min) on your CPU to mine one block.

P.S. Did testnet exist from the start? The wiki only has a timestamp for version 3.

[BlackHatCoiner]

P.S. Did testnet exist from the start? The wiki only has a timestamp for version 3.

Testnet was introduced in v0.3.14, which was released in October 2010.

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
- Key pool feature for safer wallet backup
Gavin Andresen:
- TEST network mode with switch -testnet
- Option to use SSL for JSON-RPC connections on unix/osx
- validateaddress RPC command
eurekafag:
- Russian translation

And in Bitcoin time, that must have happened around in block 86700. They could have used the testnet.

What do you guys think?

Nice! One thing I'd also add is sats per dollar.

The next million will take around 4 more years, if my calculations are correct, right?

It's 110,148 blocks 'til next halving. That's 688,425 BTC. Then, it's 311,575 BTC left which will take 311,575 / 3.125 = 99,704 blocks. So, we're 110,148 + 99,704 = 209,852 blocks far. That's ~1457 days = 3.94 years. Yep.

[darkv0rt3x]

Nice work @n0nce. Do you have a dedicated thread to this project or you just have what you posted here? I found it interesting as I also like to do small things at home in my (little) spare time.

[achow101]

Considering most of these things happened in early days

A couple of these losses have occurred relatively recently. This stackexchange post enumerates many of the instances where miners failed to claim their full reward, with the most recent occurring in 2018.

[n0nce]

Nice work @n0nce. Do you have a dedicated thread to this project or you just have what you posted here? I found it interesting as I also like to do small things at home in my (little) spare time.

I'm going to make a new topic for the project, haven't had the time to do it yet.

Also: my first post of this year's April first and I see this..
Good job, theymos.

[larry_vw_1955]

Considering most of these things happened in early days

A couple of these losses have occurred relatively recently. This stackexchange post enumerates many of the instances where miners failed to claim their full reward, with the most recent occurring in 2018.

has any miners actually comment on this happening to them? and did they say why? seems like a very strange thing.

[pooya87]

has any miners actually comment on this happening to them? and did they say why? seems like a very strange thing.

One of the 2 most recent blocks (501,726) seems to be a failed attempt in merge mining RootStock, the miner successfully includes the RSK block hashes but forgets to also include another output claiming the block's reward. Possibly in their code, instead of adding the output to the output array they replaced the array with a new one.

[dkbit98]

Sneak peek of my latest weekend project.
I'll clean up the code and start a topic for this with all the info like where to find the parts and what to install etc., in the next days but I wanted to have it up and running before block #19M. What do you guys think?

This looks amazing but I would personally change the color of led lights to make it more visible, if that is even possible.
One more thing I would add is transaction fee estimates from mempool, either in sat/vB units or in inflationary unstable USD currency.
Now all you have to do is proper naming for this little project

[n0nce]

Sneak peek of my latest weekend project.
I'll clean up the code and start a topic for this with all the info like where to find the parts and what to install etc., in the next days but I wanted to have it up and running before block #19M. What do you guys think?

This looks amazing but I would personally change the color of led lights to make it more visible, if that is even possible.
One more thing I would add is transaction fee estimates from mempool, either in sat/vB units or in inflationary unstable USD currency.
Now all you have to do is proper naming for this little project

Thanks for the feedback.
In real life, it is actually a pretty vibrant shade of magenta, but it's just very hard to photograph well. I will try again with better light for the dedicated thread.
These things are just insanely bright, even on a low setting, since they're usually screwed together into those Times Square - type LED billboards. They have all the connectors in the back so it can easily be done as long as you have enough power. I'm pretty sure the microcontroller and library do even support 'chained' panels. For my needs this size is fine for now, but I thought about getting a second one and screwing them onto a wooden panel for a vertical layout.

So for now, what I'd like to add (thanks to your suggestions here):

• Lightning Network capacity
• Satoshi / $ (very useful, I have that as a phone widget)
• Fees in sat/vB

It will probably be kind of 2 screens that cycle, since otherwise it'd get too crammed. Though I do have 4 empty 'lines' at the moment so 3 more sets of information would theoretically fit.
If you've got name suggestions, I'd be glad to hear them! 'Block Clock' is already taken.

Edit: New layout currently looks like follows. It's not too crammed honestly.

Code:

 729983 blk
 18,999,893
   20sat/vB

  45438.11$
  2200sat/$

       3:59

[BlackHatCoiner]

If you want more suggestions,

• Chain size.
• Blocks until next difficulty.
• Blocks until next halving.
• Hash rate.

Proud to be a Bitcoin geek.

[n0nce]

If you want more suggestions,

• Chain size.
• Blocks until next difficulty.
• Blocks until next halving.
• Hash rate.

Proud to be a Bitcoin geek.

Thanks, those are great suggestions!

I believe I'll split it up into multiple screens then:
Blockchain Data

• Block height
• Bitcoin mined
• Blockchain size

Mining

• Blocks until next diff
• Blocks until next halving
• Hashrate

Mempool

• Size
• Fee fastest
• Fee medium
• Fee slow

Price

• USD per coin
• [insert other currency] per coin
• sat per USD
• sat per [insert other currency]

Lightning

• Capacity
• Number of channels
• ...

It would become tricky to set a useful speed though; if it's too fast, you can't read it in time and it is distracting. If it's too slow, you can miss milestones like the 19M BTC (it was fun to watch it live!)..

Maybe I'll just try to get my hands on 2 more panels..


I think I'll stop these ideas here though and continue once I have the new thread set up, so we can stay on-topic in the off-chance that someone has some more to say about the Bitcoin supply discrepancy.