getUncleCount(fromBlock,toBlock) - or: Doesn't total supply depend on uncle count?

[altsheets]

I want to calculate the total supply. But I cannot.

---

I am wondering if I understand the mining rewards correctly.
I think it is not simply

supply = premine + blocknumber*blockreward

because of "uncles", right?

An uncle miner gets 4.375 coins or 3.75 coins (for 0Uncles and 1Uncles). Correct? More such additional rewards?

Plus including an uncle into a block gives an extra 5/32 coins to the block miner. Correct?

---

So the total supply of ETH is (probably)

supply = premine 
+ blockReward * eth.blockNumber 
+ 0UncleReward * eth.numberOf0Uncles 
+ 1UncleReward * eth.numberOf1Uncles 
+ includeUnclesReward * NumberOfIncludedUncles

Correct, or am I completely missing the point?

EDIT: As far as I understand it, this should be true

NumberOfIncludedUncles = eth.numberOf0Uncles + eth.numberOf1Uncles 
blockReward = 5
0UncleReward = 4.375
1UncleReward = 3.75
includeUnclesReward = 5/32

so the only new thing a future version needs to provide are these two integers

eth.numberOf0Uncles
eth.numberOf1Uncles 

---

If the above is (near to) correct ... then it is impossible to calculate the REAL current supply at the moment. So:

I suggest new API functions:

eth.getUncleCount(fromBlock,toBlock)

or at least the aggregate sums until the current block:

eth.numberOf0Uncles
eth.numberOf1Uncles 

where the first one would return the tuple of number of 0Uncles and 1Uncles (and 2Uncles if there are any) in that range of blocks; or the second one would return simple integers with the total number of {0,1}-uncles from genesis until now (similar to the eth.blockNumber integer).

---

Or is there an easier way to do this?

Used sources:

• Wrong reward received for Uncles! #1591 (comment)
• http://gavwood.com/paper.pdf equation 143 & 144
• https://forum.ethereum.org/discussion/2437/confused-about-block-rewards

P.S.: Even the "big guys" are of a differing opinion on the "supply" topic - there is a (0.3 percent) difference between the "supply" reported at etherscan and CMC. Is that because of the above ?

[obscuren]

I don't see the point of having these new API calls. Could you please specify why these would be required for DApp development (or any other type of development)?

If you'd like to get all uncles for statistics just loop over all the blocks in your desired range.

Unsure what + includeUnclesReward * NumberOfIncludedUncles means however.

[altsheets]

Thanks a lot for your answer.

I don't see the point of having these new API calls.

Because otherwise I would have to iterate over all ~800,000 blocks, checking all of them for uncles.
And each time I want to update that information I either have to store my intermediate results, or completely redo them (and why should I store such a result, which is of such general interest? The ethereum software itself should know about those numbers - they are just small integers, and will not take up much space.).

The ethereum architects have created a complicated rewards scheme which is not simply blocknumber*blockreward. But the current API is not yet providing all the necessary information to work with that complicated rewards scheme.

why these would be required

I would like to calculate the REAL total supply.

supply = premine + mined

The 'mined' part is tricky because of the uncle rewards.

mined = rewards(blocks) + rewards(uncles) + rewards(include-uncle-into-block)

Unsure what ...

There is am extra reward given to miners who have included uncles into their mined blocks - right?

Plus including an uncle into a block gives an extra 5/32 coins to the block miner. Correct?

Or not? Then rewards(include-uncle-into-block) = 0 ? Yes? No?

[tgerring]

Because otherwise I would have to iterate over all ~800,000 blocks, checking all of them for uncles.
And each time I want to update that information I either have to store my intermediate results, or completely redo them (and why should I store such a result, which is of such general interest? The ethereum software itself should know about those numbers - they are just small integers, and will not take up much space.).

What you're describing are database indexes which is a non-trivial topic and why you're not likely to get an answer about aggregates via API any time soon. To effectively respond to queries like this will require more forethought than demanding a new API is created

[altsheets]

What you're describing are database indexes

Yes.

Probably because I have been coding on top of the fantastic, comfortable, genius NXT API for quite some time now, I am lacking the imagination how to live without it * lol * They do have a 7 times slower blocktime ... and I don't know how they did it ... but their blockchain size is only 1.7GB after 2.1 years. And still it provides exactly that:

Database indices, to directly access all data objects on the chain. Quite an amazing system, really. Get inspired ... :-)

[altsheets]

which is a non-trivial topic and why you're not likely to get an answer about aggregates via API any time soon.

Exactly.

To prevent that, I was thinking about a supersimple internal summation, whenever a new block is added. Just sum up the count of {0,1}uncles ...

---

These are thoughts about a future API, of course ...

Is my above "supply = premine + ..." formula correct at all? Perhaps I am wrong in my assumption how much ether has been mined. But if not ...:

Right now (without iterating over all 800k blocks) it is impossible to name the correct total supply of ether - right?

---

So what about (in the future) storing just two integer values:

• total NumberOf0Uncles that were included in all blocks until now
• total NumberOf1Uncles that were included in all blocks until now

That won't cost anything. And (only) with that information, the REAL supply of ether can be calculated.

---

Or ... if you think you can afford to store 800,000 * 4 bytes * 2 ... you could store 2 numbers for each block:

• total NumberOf0Uncles that were included in all blocks until that block
• total NumberOf1Uncles that were included in all blocks until that block

That would allow an easy getUncleCount(fromBlock,toBlock), and reveal all information.

---

The first suggestion is really really easy to include in a future version - don't you think so?

And to not be able to correctly name the total supply of a (platform that is also used as a) currency ... is a bit odd, no?

[fjl]

If you need detailed information on the uncle headers of all blocks, please consider creating your own index. It is not that hard to build one. You can even update it incrementally using existing features of the web3 API.

Just to be clear on this: We take suggestions for new APIs seriously and keep track of them. This is the first time anyone has requested an API for aggregate information on uncle headers. Consider
your suggestion noted.

[altsheets]

@fjl one last question: Have I actually understood the mined/supply function correctly - or not?

i.e. in #2088 (comment) is the central formula correct? -->

So the total supply of ETH is (probably)
supply = premine + blockReward ...

?

Still wondering if I got it right, or not.

Thanks a lot!

[altsheets]

We take suggestions for new APIs seriously and keep track of them.

Thanks a lot.

This is the first time anyone has requested ...

Then ... for the first time, anyone has ever wondered what the real supply of ether is - right? :-)

Consider your suggestion noted.

Nice. So one day, I might see that function. Thx.

A tiny thing to add to it: While you are on it anyways, and when that above data is then available, please also create a simple API function that tells me, us, everyone ... about the total real coin supply:

eth.supply()

[altsheets]

Still wondering if I got it right, or not.

is my rewards calculation correct, or not?

[altsheets]

When I came across this function suggestion totalSupply() for 'total token supply' I was reminded of my -still unanswered- question above.

I actually consider it suboptimal communication, to close github issues before they are actually answered.

-->

What is the totalSupply=fn(blocknumber) of ETH ?

[altsheets]

anyone?

[altsheets]

So here can can see what happens when issues are closed before they are answered.

They are not on your radar anymore.

This admin behaviour is just ... wrong.