New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
altsheets opened this Issue Dec 21, 2015 · 12 comments

Comments

Projects
None yet
4 participants
@altsheets

altsheets commented Dec 21, 2015

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:

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 obscuren added the question label Jan 4, 2016

@obscuren

This comment has been minimized.

Show comment
Hide comment
@obscuren

obscuren Jan 4, 2016

Member

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.

Member

obscuren commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets Jan 4, 2016

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?

altsheets commented Jan 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tgerring

tgerring Jan 8, 2016

Member

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

Member

tgerring commented Jan 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets Jan 8, 2016

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 commented Jan 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets Jan 8, 2016

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?

altsheets commented Jan 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Jan 8, 2016

Contributor

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.

Contributor

fjl commented Jan 8, 2016

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.

@fjl fjl closed this Jan 8, 2016

@altsheets

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets Jan 9, 2016

@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 commented Jan 9, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets Jan 9, 2016

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 commented Jan 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets Feb 17, 2016

Still wondering if I got it right, or not.

is my rewards calculation correct, or not?

altsheets commented Feb 17, 2016

Still wondering if I got it right, or not.

is my rewards calculation correct, or not?

@altsheets

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets Mar 27, 2016

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 commented Mar 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets commented Apr 1, 2016

anyone?

@altsheets

This comment has been minimized.

Show comment
Hide comment
@altsheets

altsheets Apr 12, 2016

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.

altsheets commented Apr 12, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment