Bitcoin Forum
May 24, 2019, 12:34:09 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Where is the block reward function?  (Read 3336 times)
misterbigg
Legendary
*
Offline Offline

Activity: 1064
Merit: 1001



View Profile
December 13, 2012, 02:47:31 PM
 #1

Can someone please point me to the block reward function in the source code? There is some debate whether the reward ceases to exist on 2040, or 2140 (the Wikipedia entry lists 2140).

Thanks
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DannyHamilton
Legendary
*
Offline Offline

Activity: 2198
Merit: 1404



View Profile
December 13, 2012, 03:04:15 PM
Last edit: December 13, 2012, 03:31:25 PM by DannyHamilton
 #2

I'm not sure exactly where in the code it is handled, but the protocol and math are pretty clear and simple:

Start with a subsidy of 50 BTC (represented in the output as an integer of 5000000000)
Every 210,000 blocks cut the subsidy in half (handled by performing a bitwise right shift on the integer value of the initial block reward)

This bitwise right shift puts the block subsidy at 0 in block 6,930,000

There are an average of approximately 6 blocks per hour.

6 blocks per hour multiplied by 24 hours per day multiplied by 365.25 days per year gives us approximately 52,596 blocks per year.

block number 6930000 divided by 52596 blocks per year tells us the block subsidy will cease to exist approximately 131 years after block 0 was created.

Block 0 was created in 2009

2009 + 131 = 2140

Looks like Wikipedia is right.

Why did you think it would be 2040?

DannyHamilton
Legendary
*
Offline Offline

Activity: 2198
Merit: 1404



View Profile
December 13, 2012, 03:22:37 PM
 #3

Looks like you can see the code here:

https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/main.cpp

Quote
int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}

zebedee
Donator
Hero Member
*
Offline Offline

Activity: 668
Merit: 500



View Profile
December 14, 2012, 12:56:33 PM
 #4

Looks like you can see the code here:

https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/main.cpp

Quote
int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}
As I've pointed out before, this is shoddy code.  Once nHeight is about 13.23 million (admittedly some way off) this code has undefined right-shift behaviour.  It needs a conditional such as

  if (nHeight / 210k >= 63)
    nSubsidy = 0;
  else
    nSubsidy >>= (nHeight / 210k);

Why code is written with nFees, nHeight and nSubsidy as signed integers, given they can only ever be non-negative, is also weak and a source of bugs IMO.
dree12
Legendary
*
Offline Offline

Activity: 1246
Merit: 1032



View Profile
December 14, 2012, 01:01:24 PM
 #5

Looks like you can see the code here:

https://github.com/bitcoin/bitcoin/blob/v0.7.1/src/main.cpp

Quote
int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}
As I've pointed out before, this is shoddy code.  Once nHeight is about 13.23 million (admittedly some way off) this code has undefined right-shift behaviour.  It needs a conditional such as

  if (nHeight / 210k >= 63)
    nSubsidy = 0;
  else
    nSubsidy >>= (nHeight / 210k);

Why code is written with nFees, nHeight and nSubsidy as signed integers, given they can only ever be non-negative, is also weak and a source of bugs IMO.
I'm sure you've seen this problem with using unsigned integers.
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
December 14, 2012, 01:45:08 PM
 #6

lets fix this within the next 127 years, otherwise we will have 50 BTC blocks again.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2744
Merit: 2266



View Profile
December 14, 2012, 02:26:23 PM
 #7

lets fix this within the next 127 years, otherwise we will have 50 BTC blocks again.
You mean 246 years, right?
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
December 14, 2012, 05:55:30 PM
 #8

lets fix this within the next 127 years, otherwise we will have 50 BTC blocks again.
You mean 246 years, right?
Block reward will be 0 in years:
Code:
N[Ceiling[Log2[25*100000000]]*210000*10/60/24/365]
127.854
It will be 50 BTC again as nHeight overflows in about 40853 years.
Code:
N[(2^31 - 1 - 212190)*10/60/24/365]
40853.7
Shift with negative numbers will thereafter exponentially increase block reward and destroy the economy in a hyperinflation.

Let us do something against it in this century!
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
December 14, 2012, 06:28:58 PM
 #9

BTW the expected date of the first 0 reward block is 5th September 2140

Code:
DatePlus[{2012, 12,
  14}, (2*210000 - 212196 +
    Ceiling[Log2[12.5 * 100000000]]*210000)*10/60/24]
{2140, 9, 5, 10}
DannyHamilton
Legendary
*
Offline Offline

Activity: 2198
Merit: 1404



View Profile
December 14, 2012, 07:13:01 PM
 #10

. . . Once nHeight is about 13.23 million . . . this code has undefined right-shift behaviour . . .

Before we start worrying about improvements to code that won't be a problem for over 130 years, can we first deal with the more pressing problem of storing the block time stamp as UNIX epoch time in a 4 byte unsigned integer?  Unless I'm mistaken this time stamp will roll over in only 93 years on 2106-02-07!


gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2744
Merit: 2266



View Profile
December 15, 2012, 01:01:18 AM
 #11

lets fix this within the next 127 years, otherwise we will have 50 BTC blocks again.
You mean 246 years, right?

It's still 246 years before the shift becomes undefined (I'm mostly asking to confirm that you are not expecting to use int32 or uint32 to hold bitcoin values…).
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
December 15, 2012, 07:03:33 AM
 #12

lets fix this within the next 127 years, otherwise we will have 50 BTC blocks again.
You mean 246 years, right?

It's still 246 years before the shift becomes undefined (I'm mostly asking to confirm that you are not expecting to use int32 or uint32 to hold bitcoin values…).
Would you explain the 246 ?

Since there never will be more than 2099999997690000 satoshis, therefore 51 bits would be sufficient to hold them, even if they would choose to gather at the same place.

I offer a couple more at their places, so they can fit loosely and feel that I threat them with respect.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2744
Merit: 2266



View Profile
December 15, 2012, 05:54:42 PM
 #13

Would you explain the 246 ?
Because that is roughly when (well, a couple years before) the shift would go from 63 to 64 and become undefined. (See the standard, "The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand."). Until then its just outputting zero which is the reasonable and expected behavior, after then the compiler is permitted to end the universe (but more likely it will return 0 on some systems and 50 BTC on others).
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
December 15, 2012, 07:40:19 PM
 #14

Would you explain the 246 ?
Because that is roughly when (well, a couple years before) the shift would go from 63 to 64 and become undefined. (See the standard, "The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand."). Until then its just outputting zero which is the reasonable and expected behavior, after then the compiler is permitted to end the universe (but more likely it will return 0 on some systems and 50 BTC on others).

Sounds exciting, let us leave it as it is, I want to see it happening then.
dree12
Legendary
*
Offline Offline

Activity: 1246
Merit: 1032



View Profile
December 15, 2012, 09:40:14 PM
 #15

Would you explain the 246 ?
Because that is roughly when (well, a couple years before) the shift would go from 63 to 64 and become undefined. (See the standard, "The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand."). Until then its just outputting zero which is the reasonable and expected behavior, after then the compiler is permitted to end the universe (but more likely it will return 0 on some systems and 50 BTC on others).

Sounds exciting, let us leave it as it is, I want to see it happening then.
I doubt Bitcoin will be around then. I doubt computers will be around then. Heck, I doubt humans as we know them will be around them. With power comes responsibility, and with the nigh-infinite power mankind is achieving I doubt we're responsible enough.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!