Historical question:

[Luno]

how was the block reward system decided?

Was 50BTC and 4 years just arbitrary or was there some financial formula behind it.

Did Satoshi himself decide it or was it debated?

In hindsight would it have been better if the generation of Bitcoin had been slower or faster?

I know that the most important property of the block reward system is that it is set in stone, so this is not a "why don't we change it" question.

[Mike Hearn]

Like all aspects of Bitcoins initial design, it was decided by Satoshi.

I wanted something that would be not too low if it was very popular and not too high if it wasn't.

It works out to an even 10 minutes per block:
21000000 / (50 BTC * 24hrs * 365days * 4years * 2) = 5.99 blocks/hour

I fudged it to 364.58333 days/year.  The halving of 50 BTC to 25 BTC is after 210000 blocks or around 3.9954 years, which is approximate anyway based on the retargeting mechanism's best effort.

I thought about 100 BTC and 42 million, but 42 million seemed high.

I wanted typical amounts to be in a familiar range.  If you're tossing around 100000 units, it doesn't feel scarce.  The brain is better able to work with numbers from 0.01 to 1000.

If it gets really big, the decimal can move two places and cents become the new coins.

Of course this will lead you to ask, why 10 minutes per block?

Another is the 10 minute block target. I understand this was chosen to allow transactions to propagate through the network. However existing large P2P networks like BGP can propagate new data worldwide in <1 minute.

If propagation is 1 minute, then 10 minutes was a good guess.  Then nodes are only losing 10% of their work (1 minute/10 minutes).  If the CPU time wasted by latency was a more significant share, there may be weaknesses I haven't thought of.  An attacker would not be affected by latency, since he's chaining his own blocks, so he would have an advantage.  The chain would temporarily fork more often due to latency.

[Luno]

Thank you for this detailed answer. So it was a guess! So if he felt that the halving formula chosen was just right, he would have had some idea on how the price should evolve and how big the final market cap would be. Was any of this ever discussed?

[CIYAM]

From the analysis that Meni Rosenfield recently published it seems that the 10 minute per block time frame could well have been reduced but as stated this was an arbitrary decision that was made to be "extra sure" that no (at the time) unforeseen attack would be successful if it were much lower.

I think that this single decision may likely lead to another crypto-currency (i.e. a bitcoin clone) also becoming popular (such as perhaps LTC) but also this possibly "unnecessary" extra level of security will most likely keep Bitcoin's status as being the "gold standard" in the crypto-currency families.

Personally I found the starting point a 50 BTC block reward (as opposed to say 64) to be more "strange" - am guessing the only reason for this particular number was to try and "appeal" to non-nerds (not that there probably are any that would be mining BTC).

[Stephen Gornick]

Personally I found the starting point a 50 BTC block reward (as opposed to say 64) to be more "strange" - am guessing the only reason for this particular number was to try and "appeal" to non-nerds (not that there probably are any that would be mining BTC).

Well, they outnumber us by about an order of magnitude so preferring 50 and 25 versus 64 and 32 is obvious.

Like all aspects of Bitcoins initial design, it was decided by Satoshi.

I wanted something that would be not too low if it was very popular and not too high if it wasn't.

There are some people who think that Facebook ($FB) is a better stock than Alcoa ($AA) because a share of Facebook trades at $25 versus $9 for Alcoa.  These same people don't generally trade themselves so a basic understanding of stock prices isn't necessary for them. 

I personally didn't appreciate this until Bitcoin hit parity and suddenly instead of Bitcoin being these fake bits it was now "worth more than a dollar, so it must be somehow legit".   

The benefit of this decision helped bitcoin (in the court of public opinion) when it was critically needed.    What many sites are doing is displaying the amount of bitcoins in one field and right next to it is that amount's value in dollars.    This will ease the concern when we start seeing things priced in mBTCs -- where at one site you are paying 130 millibits for an item and at the next one the price is listed as 0.137 BTC.

[grau]

If it gets really big, the decimal can move two places and cents become the new coins.

This sounds right and even timely for me.

I do not like mBTC since it scales with 3 magnitudes.
People used to 2 magnitude moves from USD or EUR to cents and not to 1/10 cents.

Should we rather go for BTc for BT(c)ents, or cBTC?

[Luno]

If it gets really big, the decimal can move two places and cents become the new coins.

This sounds right and even timely for me.

I do not like mBTC since it scales with 3 magnitudes.
People used to 2 magnitude moves from USD or EUR to cents and not to 1/10 cents.

Should we rather go for BTc for BT(c)ents, or cBTC?

MB for Megabyte and Mb for megabit has been confused the last 25 years.

They will just be called "cents", everybody know that you are talking about Bitcoin.

BTW a half Byte, 4 bits, is a nipple.

[DeathAndTaxes]

Like other indicated it was a guestimate and the number of coins (and discrete units) is totally arbitrary.  Personally the only thing I wish was different is 1 use full 64bit (21M BTC * 1E8 =2.1E15, 64bit ulong = 1.84E19) for units and 2 make the subsidies base 2 so there would be a "clean" generation (i.e. 64 BTC, 32 BTC 16 BTC, 8 BTC ...  2 satoshi, 1 satoshis 0). 

[etotheipi]

Like other indicated it was a guestimate and the number of coins (and discrete units) is totally arbitrary.  Personally the only thing I wish was different is 1 use full 64bit (21M BTC * 1E8 =2.1E15, 64bit ulong = 1.84E19) for units and 2 make the subsidies base 2 so there would be a "clean" generation (i.e. 64 BTC, 32 BTC 16 BTC, 8 BTC ...  2 satoshi, 1 satoshis 0).  

I kind of wish Satoshi had just named these units himself.  "I decree that we will use these names for the different units."  Even if they weren't good names, they probably would've stuck, just like everything else in this system.  At least there would be a baseline to refer to if there was some decision to deviate.  Then we wouldn't need any more discussion about what to name them (since no one can agree since it's so awkward having 8 decimal places).

[notme]

If it gets really big, the decimal can move two places and cents become the new coins.

This sounds right and even timely for me.

I do not like mBTC since it scales with 3 magnitudes.
People used to 2 magnitude moves from USD or EUR to cents and not to 1/10 cents.

Should we rather go for BTc for BT(c)ents, or cBTC?

MB for Megabyte and Mb for megabit has been confused the last 25 years.

They will just be called "cents", everybody know that you are talking about Bitcoin.

BTW a half Byte, 4 bits, is a nipple.

Half a byte is a nibble, not a nipple.

[kjj]

Like other indicated it was a guestimate and the number of coins (and discrete units) is totally arbitrary.  Personally the only thing I wish was different is 1 use full 64bit (21M BTC * 1E8 =2.1E15, 64bit ulong = 1.84E19) for units and 2 make the subsidies base 2 so there would be a "clean" generation (i.e. 64 BTC, 32 BTC 16 BTC, 8 BTC ...  2 satoshi, 1 satoshis 0). 

Meh.  The extra ~13 bits leaves headroom for accounting systems using modern CPUs, just in case it really takes off fast.

[gmaxwell]

Like other indicated it was a guestimate and the number of coins (and discrete units) is totally arbitrary.  Personally the only thing I wish was different is 1 use full 64bit (21M BTC * 1E8 =2.1E15, 64bit ulong = 1.84E19)

I don't. the number used is the largest round number reward times the geometric decline amount that fits into a Decimal64.  There are other reasons to not use the full range of a signed 64 bit integer: if you do, there is no room to square a value without losing precision, which is very handy in doing prorated values without switching to infinite precision rational arithmetic.

[DeathAndTaxes]

Like other indicated it was a guestimate and the number of coins (and discrete units) is totally arbitrary.  Personally the only thing I wish was different is 1 use full 64bit (21M BTC * 1E8 =2.1E15, 64bit ulong = 1.84E19) for units and 2 make the subsidies base 2 so there would be a "clean" generation (i.e. 64 BTC, 32 BTC 16 BTC, 8 BTC ...  2 satoshi, 1 satoshis 0).  

Meh.  The extra ~13 bits leaves headroom for accounting systems using modern CPUs, just in case it really takes off fast.

Um the headroom would already exist if the bits were already used.

i.e.

use 64bits now = ~18,400 quadrillion units
vs
use 51 bits now = 2.1 quadrillion units expandable to ~18,400 quadrilion units if things take off.  

I don't. the number used is the largest round number reward times the geometric decline amount that fits into a Decimal64.  There are other reasons to not use the full range of a signed 64 bit integer: if you do, there is no room to square a value without losing precision, which is very handy in doing prorated values without switching to infinite precision rational arithmetic.

No it isn't.  The largest round unit would be 18,000 quadrillion.  Using 12 digits for precision that would make 1 satoshi = 1 nBTC (1E-12), total coinsupply = 18,000,000 BTC.

As far as losing precision?  On a 12 digit fixed precision format?   If the entire global money supply was represented by the 18M/12digit BTC (~$100T USD circa 2012) then 1 BTC = ~$5.6M.  Min precision would be ~1/2000th of 1 US cent.


Still it is nothing to lose sleep over just seem ineligent given how well thought out the rest of the protocol was.

[grau]

We named the smallest unit satoshi, and have BTC for 100,000,000 satoshis.

What about naming every second
magnitude inbetween honoring big chrypographers?

We would have three slots to fill.

[kjj]

Like other indicated it was a guestimate and the number of coins (and discrete units) is totally arbitrary.  Personally the only thing I wish was different is 1 use full 64bit (21M BTC * 1E8 =2.1E15, 64bit ulong = 1.84E19) for units and 2 make the subsidies base 2 so there would be a "clean" generation (i.e. 64 BTC, 32 BTC 16 BTC, 8 BTC ...  2 satoshi, 1 satoshis 0). 

Meh.  The extra ~13 bits leaves headroom for accounting systems using modern CPUs, just in case it really takes off fast.

Um the headroom would already exist if the bits were already used.

i.e.

use 64bits now = ~18,400 quadrillion units
vs
use 51 bits now = 2.1 quadrillion units expandable to ~18,400 quadrilion units if things take off. 

No, see headroom is the difference between the size of the register and the maximum number of fundamental units.  That's a definition.  If you have 2^64 units, and you use a 64 bit register to count them, then you either have no headroom, or you aren't exact.  (You can use a scaled format, but that just means that you have either headroom or exactness at any given step, but never both at the same time.)

I'm talking about accounting, and we generally don't limit our accounting systems to according to our money supply.  The notion of expanding the money supply is a different matter entirely.  We may expand to a 128-bit format in the future, and I'm strongly suspect that we will do so for aesthetic reasons (as in, "we have 128-bit registers, why are we still hauling these half-words around?") long before the fundamental unit becomes economically meaningful.  When we do that, if we do that, we will probably pick a scaling factor that provides even more than 12 or 13 bits of headroom at that time.

[DeathAndTaxes]

My point is that any such "headroom" would be unecessary and even using that headroom wouldn't be any more precise than simply making the protocol as precise as 64bit allows to begin with.

64bit allows 2^64 values.  So the minimium unit that can be represented is 1(2^64) of the "whole" (in this case 21M BTC).   You can't be more precise using 64bit integer.  So the idea that it would be better to make the protocol less precise in order to have headroom to allow greater precision up to (but not greater than the max 64bit allows is kinda silly .... if the protocol used the full range it would already be as precise as 64bit allows.   There would be no headroom but no headroom is possible regardless (without larger bit range).

64bit allows precision down to 11th digit (due to the 21M base units).   It doesn't matter how precise the protocol is you can't be more precise using 64bit integers off protocol.

So
1 satoshi = 1E-4  -> on protocol precision 4 digits -> off protocol precision 11 digits
1 satoshi = 1E-5  -> on protocol precision 5 digits -> off protocol precision 11 digits
1 satoshi = 1E-6  -> on protocol precision 6 digits -> off protocol precision 11 digits
1 satoshi = 1E-7  -> on protocol precision 7 digits -> off protocol precision 11 digits
1 satoshi = 1E-8  -> on protocol precision 8 digits -> off protocol precision 11 digits
1 satoshi = 1E-9  -> on protocol precision 9 digits -> off protocol precision 11 digits
1 satoshi = 1E-10  -> on protocol precision 10 digits -> off protocol precision 11 digits
1 satoshi = 1E-11  -> on protocol precision 11 digits -> off protocol precision 11 digits

Your saying yeah 1E-6 is great because we have 5 more digits of headroom off protocol.  I am saying 1E-11 is great because the protocol is as precise as possible (for 64bit).  We don't lose any precision because we don't have headroom.  We are still just as precise off protocol.

[grau]

We named the smallest unit satoshi, and have BTC for 100,000,000 satoshis.

What about naming every second
magnitude inbetween honoring big chrypographers?

We would have three slots to fill.

I would pick: Merkle for hashing and the tree, Zimmermann for PGP, Bernstein for his fight against restrictions on cryptography.

[gmaxwell]

I don't. the number used is the largest round number reward times the geometric decline amount that fits into a Decimal64.  There are other reasons to not use the full range of a signed 64 bit integer: if you do, there is no room to square a value without losing precision, which is very handy in doing prorated values without switching to infinite precision rational arithmetic.

No it isn't.  The largest round unit would be 18,000 quadrillion.  Using 12 digits for precision that would make 1 satoshi = 1 nBTC (1E-12), total coinsupply = 18,000,000 BTC.

As far as losing precision?  On a 12 digit fixed precision format?   If the entire global money supply was represented by the 18M/12digit BTC (~$100T USD circa 2012) then 1 BTC = ~$5.6M.  Min precision would be ~1/2000th of 1 US cent.

I'm talking about the largest exact integer in decimal64. Doing inexact math using decimal64 is nice because rational values stay rational.  I was also talking about having headroom for exact fixed point calculations, because while the discrepancy from rounding my be small, sum and difference not adding up _exactly_ (something which happens with any rounding mode you choose) or just getting different results depending on the rounding mode makes error checking hard and can permit subtle errors that slip trough. Not the end of the world, but there are qualities to the value we have.

[kjj]

My point is that any such "headroom" would be unecessary and even using that headroom wouldn't be any more precise than simply making the protocol as precise as 64bit allows to begin with.

64bit allows 2^64 values.  So the minimium unit that can be represented is 1(2^64) of the "whole" (in this case 21M BTC).   You can't be more precise using 64bit integer.  So the idea that it would be better to make the protocol less precise in order to have headroom to allow greater precision up to (but not greater than the max 64bit allows is kinda silly .... if the protocol used the full range it would already be as precise as 64bit allows.   There would be no headroom but no headroom is possible regardless (without larger bit range).

I'm not talking about the protocol, I'm talking about accounting systems that also use 64 bit computers, and thus typically use 64 bit values.  You don't design an accounting package based on the money supply, you give it headroom.

Right now, bitcoins are worth about $13.50 each, and there will never be more than 21 million of them.  If we were using a scaling factor such that the entire 64 bit range was needed to exactly represent the fundamental units, we would need a 128-bit accounting package to deal with projects bigger than, say, a medium-sized office buildings.

That example is just a snapshot, of course.  In the past, 64 bits wasn't enough to feed a family of four, but in the future, it may very well be able to handle all global economic activity for a year.  The point is that having some room between the maximum number of currency units, and the maximum range of the native register size of common CPUs isn't a bad thing.

[smtp]

My two cents:
Currently the US-government has liabilities of a bit more than 15*10^12 $, say roughly 10^13 $.
Taken all of the other liabilities world wide, I guess their sum is limited by $ 10^14.
Moreover I believe all sums of every money availible (converted to US-$ units) is < 10^15 $ at every past point of time.
So if you like to be precise on the level of 0.01 US-cent, you need an integer range up to 10^19.
Hmm ... 2^64 = 1.84...*10^9. Wow, critical close if everybody would use BTC for his business! ;-)
smtp