Topic: Theoretical vs Practical Extant Coin Supply Calculations (Read 1602 times)

Maybe. Entropy is probably the way to go.  I would put them in category 4 (post #8) as they are only probably lost.  Maybe one could make a entropy parser to flag potential keys to add to that list (semi-automated).  Humans are sometimes better at that kind of stuff.  If nothing else compiling such a list would be useful as test cases from an automated tool.

Is there an automatic way to flag pubkey hashes which appear "fake", as in we're very confident that nobody possesses a corresponding private key? (1BitcoinEaterAddressDontSendf59kuE)

Maybe some kind of entropy measurement?

Good idea.  In hindsight obviously the UXTO must always be equal to current "money supply" (if it isn't we have problems ).

The snapshot was as of block height 305,303.
https://blockchain.info/block-index/438269/00000000000000001e16587f86dba9eca1d64b24b33c29a8c663e0b7de63e661

In the quoted segment I actually rounded the output value.  It is 12,882,439.79102850 (unless I did something wrong, which is possible).  The bitcoin-core also has the "gettxoutsetinfo" RPC call to get stats on the uxto and it has the total value so that is an easier way.  

IIRC OP_RETURN outputs are already pruned from the UXTO and thus any coins burned that way are already removed from the stat.


The following outputs can't be redeemed and may still be in the UXTO (simply because the client doesn't look for provably bad outputs to prune:
986 outputs with 32 bytes and no OP codes.
336 outputs with 36 bytes and no OP codes.
182 outputs with the gibberish script OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH (the ASCII values for "script" was pushed rather than the actual script)
23 outputs with a single one byte zero as the PubKeyHash (oops) OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG

Both.

DeathAndTaxes was recently working on an UXTO parser to categorize unspent coins into "bins."  You could use a version of this tool to empirical calculate coin supply from the unspent outputs.  The empirical coin supply should be equal to or less than the "theoretical" coin supply set by bitcoin's inflation schedule (because it is possible for a miner to make coins vanish).  

Here's some of the initial data (I'm not sure what block number this was based on):



You could also modify the parser to remove "proveably unspendable" coins from your money-supply calculations.  I think all provably unspendable outputs would fall into the "RawScript" category, which means there's less than 2,627 BTC of provably destroyed coins (and probably a lot less than this because I expect most of the RawScript outputs to be native multisig).  

blockchain.info and the blockchain really are one and the same.

Blockchain.info has all of the blocks mined on it's website for anyone to view.

The difference is that blockchain may display a block that gets orphaned prior to it being orphaned.

Excellent.  I learn something new everyday here.

Actually you can't due to a small oversight in the protocol (or at least what I consider an oversight).

A block is valid if the coinbase reward is not more than the current subsidy plus transaction fees.  A block is valid if it is less than the max allowed reward and when that happens coins are lost and the supply is slightly less than the theoretical limit.  Miners have in the past (probably due to errors) have created coinbase transactions which payout less than the max allowed.  The two most common scenarios are a block which has a coinbase reward of zero and a block which has a coinbase reward equal to the subsidy when there are tx fees in the block (i.e. 25.0 BTC vs 25.00128 BTC).  Doing a computation based on block height will slightly overestimate the number of available coins.

To answer the OP the only way to get an exact count would involve parsing every block. Start at the genesis block and set a coin counter at zero.  For each block compute the amount of the transaction fees in the block.  Subtract the fees from the coinbase amount and the difference is the number of newly mined coins.  Add this to a coin counter and move to the next block.  Repeat until you reach the current block.  To be robust you may want to record the supply at all or some block heights.  In the event of a reorg you would need to return to that last known height prior to the reorg and recompute (differences due to reduced rewards are less likely now but not impossible).

You will also need to decide how to handle the genesis block.  There is a 50 BTC reward but the protocol currently doesn't allow them to be spent.  It is unlikely that will ever change. In my opinion that means it isn't part of the coin supply.  To improve your reported supply further you could subtract out all known provably lost coins and maybe ones which can be said to be unspenable with a high degree of confidence (i.e. coins sent to an address where the pubkeyhash is 1111111111111111111111111111111111111111111111111111 as the odds that by chance or design someone generated a pubkey which hashes to all zeroes is essentially zero.

So there are at least 4 potential supplies
1) theoretical supply (based on block height and subsidy calculations)
2) generated supply (based on blockchain and actual minting rewards)
3) provable maximal supply (based on #2 minus all provable lost coins after minting)
4) probable maximal supply (based on #3 minus all coins which have a high confidence of being lost)

Obviously each supply is slightly smaller than the one before it.  The difference is pretty small though (and very likely to diminish as % over time).   The last time I looked the difference between #1 and #4 was less than 0.5%.

The coinbase rewards aren't theoretical.  You CAN use a simple multiplication here.

Otherwise, I'm afraid I either don't know what you mean, or I don't have enough knowledge...sorry.

Sorry Jonald, perhaps I didn't explain it properly in the post but I'm not looking for block height to do a calculation that lives entirely outside of the blockchain; I'm looking to scan the blockchain to actually count the number of extant coins to get a number that is closer to reality rather than a theoretical figure.  Some of the implications extend to other cryptocurrencies with more complicated minting schedules and formulas.

Anyway, it looks like this calculation is being done via:


Starting at line 1507 here: https://github.com/rat4/blackcoin/blob/850c9f683f925d12225e634fbb9e4f757daf8a35/src/main.cpp#L1507

This is a great feature.  I'm guessing that eventually it will be implemented more widely, given its usefulness. Kudos to rat4.

Same thing though.  If you are a node, you HAVE a copy of the blockchain.  You just count the blocks essentially.

While that might be the shortest path to the figure in question, it doesn't address how the figure is calculated or the difference between theoretical and practical calculations.

When I use the term blockchain I mean the actual blockchain, not blockchain.info.  Please re-read the question.

Isn't this problem trivial? Just go to Blockchain.info and look at the latest block number.  
You can find  the number of blocks that mint 50 coins and the number that minted 25.

Am I missing something?

Additionally, how might OP_RETURNs be checked for unspendable amounts so that these could be subtracted from the extant coin supply?

While it is presumably infeasible to scan the entire bitcoin address space for burn addresses via an entropy threshold or via regex rules (many repeating characters), aren't there amounts that we can tell for certain are unspendable just by inspecting the blockchain?

Can extant (existing/available) coin supply only be calculated in theory according to the minting schedule or can it be determined programmatically by crawling the blockchain?

Blackcoin has a 'moneysupply' value that returns when `blackcoind getinfo` is called.  To the best of my knowledge, it is the only coin daemon that returns this figure.

The only references in code to money supply I can find appear on line 93 of src/rpcwallet.cpp at github.com/rat4/blackcoin


How is moneysupply being calculated from the blockchain? Is the same calculation possible with the bitcoin blockchain? If so, how do the calculations work? look like?

I have been told by bitcoin core devs that it is not possible to distinguish between miners fees and newly minted coins, making a practical calculation of extant coins (via blockchain crawl) impossible and forcing reliance on a theoretical calculation from block height, initial reward, and halving period.

I wrote the ruby solution below but it is theoretical and not derived directly from blockchain values.
If there is a way to crawl the blockchain for the 'real' amount, I would greatly appreciate help with learning how to do so. Thanks in advance.