Topic: Why 1BTC should equal 10^8 satoshi ? (Read 6723 times)
What is this about... nobody cares, go home
Who is proposing this?
That doesn't matter.
Who thinks this is a good idea?
This does matter.
I think this patch is probably a good idea. I have no idea how to get community support for it though.
That remains to be seen
I think this patch is probably a good idea. I have no idea how to get community support for it though.
This is the current GetBlockValue, providing a total money supply of 2099'9999'9769'0000 satoshis, halving the subsidy every 21'0000 blocks:
This is a proposed GetBlockValue, providing a total money supply of 2099'9999'9769'0000 satoshis, halving the subsidy every 21'0000 blocks, smoothly:
This is the corresponding hard fork proposal, with switchover scheduled for block 42'0000:
Code:
CAmount GetBlockValue(int nHeight, const CAmount &nFees) {
int64_t nSubsidy = 50 * COIN;
int halvings = nHeight / Params().SubsidyHalvingInterval();
// Force block reward to zero when right shift is undefined.
if (halvings >= 64)
return nFees;
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
nSubsidy >>= halvings;
return nSubsidy + nFees;
}This is a proposed GetBlockValue, providing a total money supply of 2099'9999'9769'0000 satoshis, halving the subsidy every 21'0000 blocks, smoothly:
Code:
CAmount GetBlockValue(int nHeight, const CAmount &nFees) {
int nHalvingInterval = Params().SubsidyHalvingInterval();
int nHalvings = nHeight / nHalvingInterval;
// Force block reward to zero when right shift is undefined.
if (nHalvings >= 64)
return nFees;
// Subsidy is cut in half every 210000 blocks which will occur approximately every 4 years.
int64_t nSubsidy = COIN * 50 >> nHalvings;
int nMaxIntervalHeight = nHalvingInterval - 1;
int nSubinterval = nHeight * 2 / nHalvingInterval % 2;
// Subsidy decreases linearily, beginning with 4/3, ending with 2/3 of the nominal value.
nSubsidy *= (nMaxIntervalHeight * 2 - nHeight % nHalvingInterval) * 2;
nSubsidy -= nSubinterval;
nSubsidy /= nMaxIntervalHeight * 3;
nSubsidy += nSubinterval;
return nSubsidy + nFees;
}This is the corresponding hard fork proposal, with switchover scheduled for block 42'0000:
Code:
CAmount GetBlockValue(int nHeight, const CAmount &nFees) {
int nHalvingInterval = Params().SubsidyHalvingInterval();
int nHalvings = nHeight / nHalvingInterval;
// Force block reward to zero when right shift is undefined.
if (nHalvings >= 64)
return nFees;
// Subsidy is cut in half every 210000 blocks which will occur approximately every 4 years.
int64_t nSubsidy = COIN * 50 >> nHalvings;
// Smoothened subsidy commences after the second halving, i.e. at block 420000.
if (nHalvings >= 2) {
int nMaxIntervalHeight = nHalvingInterval - 1;
int nSubinterval = nHeight * 2 / nHalvingInterval % 2;
// Subsidy decreases linearily, beginning with 4/3, ending with 2/3 of the nominal value.
nSubsidy *= (nMaxIntervalHeight * 2 - nHeight % nHalvingInterval) * 2;
nSubsidy -= nSubinterval;
nSubsidy /= nMaxIntervalHeight * 3;
nSubsidy += nSubinterval;
}
return nSubsidy + nFees;
}This explanation is quite thorough. Maybe I should download the source myself and check it out. Thanks
Who is proposing this? Who thinks this is a good idea?
This is the current GetBlockValue, providing a total money supply of 2099'9999'9769'0000 satoshis, halving the subsidy every 21'0000 blocks:
This is a proposed GetBlockValue, providing a total money supply of 2099'9999'9769'0000 satoshis, halving the subsidy every 21'0000 blocks, smoothly:
This is the corresponding hard fork proposal, with switchover scheduled for block 42'0000:
Edit: This is the final version.
Code:
CAmount GetBlockValue(int nHeight, const CAmount &nFees) {
int64_t nSubsidy = 50 * COIN;
int halvings = nHeight / Params().SubsidyHalvingInterval();
// Force block reward to zero when right shift is undefined.
if (halvings >= 64)
return nFees;
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
nSubsidy >>= halvings;
return nSubsidy + nFees;
}This is a proposed GetBlockValue, providing a total money supply of 2099'9999'9769'0000 satoshis, halving the subsidy every 21'0000 blocks, smoothly:
Code:
CAmount GetBlockValue(int nHeight, const CAmount &nFees) {
int nHalvingInterval = Params().SubsidyHalvingInterval();
int nHalvings = nHeight / nHalvingInterval;
// Force subsidy to zero when right shift is undefined.
if (nHalvings >= 64)
return nFees;
// Subsidy is cut in half every 210000 blocks which will occur approximately every 4 years.
int64_t nSubsidy = COIN * 50 >> nHalvings;
// Subsidy decreases linearily, beginning with 4/3, ending with 2/3 of the nominal value.
nSubsidy *= nHalvingInterval * 4 - nHeight % nHalvingInterval * 2 - 1;
nSubsidy += nHeight * 2 / nHalvingInterval % 2 * (nHalvingInterval * 3 - 1);
nSubsidy /= nHalvingInterval * 3;
return nSubsidy + nFees;
}This is the corresponding hard fork proposal, with switchover scheduled for block 42'0000:
Code:
CAmount GetBlockValue(int nHeight, const CAmount &nFees) {
int nHalvingInterval = Params().SubsidyHalvingInterval();
int nHalvings = nHeight / nHalvingInterval;
// Force subsidy to zero when right shift is undefined.
if (nHalvings >= 64)
return nFees;
// Subsidy is cut in half every 210000 blocks which will occur approximately every 4 years.
int64_t nSubsidy = COIN * 50 >> nHalvings;
// Smoothened subsidy commences after the second halving, i.e. at block 420000.
if (nHalvings >= 2) {
// Subsidy decreases linearily, beginning with 4/3, ending with 2/3 of the nominal value.
nSubsidy *= nHalvingInterval * 4 - nHeight % nHalvingInterval * 2 - 1;
nSubsidy += nHeight * 2 / nHalvingInterval % 2 * (nHalvingInterval * 3 - 1);
nSubsidy /= nHalvingInterval * 3;
}
return nSubsidy + nFees;
}Edit: This is the final version.
Honestly, I don't think he did come from a financial background. Had he come from a financial background, block rewards would not be adjusted downwards in 50% increments. In fact the kool-aid in the financial industry is universally that mild continuous inflation is a good thing, so if Satoshi were educated in that industry, then block rewards would probably eventually start going *up* by a few percent a year to keep the capital dedicated to hashing (ie, block chain security) in a constant proportion relative to the bitcoin money supply (ie, the value that must be secured), and we wouldn't be looking at a 21M coin maximum.
I am concerned that down the line the sudden drops in hashing reward are likely to create dislocations of capital and hashing infrastructure. Meaning, that at some point the financial return on miners' invested capital suddenly justifies only about half of it, and then what do they do with the rest?
The thing about ASIC hashing infrastructure is that the thing that's required to secure the blockchain -- that is to say, hashing power -- is the very same thing that's required to attack it. And the weirdo economics here have caused a huge amount of it to be built -- much more than will be financially justified three or four more halvings down the line. The miners have sunk costs in dedicated equipment, so that equipment is not going to just go away because there's not a financial justification for the amortized expense of acquiring it. And it's ASICs, so they're not going to be able to switch it as general computing power to any other purpose.
I'm concerned that when the profits from hashing go down suddenly, a bunch of people looking for the most profitable use of their dedicated sunk-cost in hashing infrastructure will start to consider attacks. Way back when we were working on this, I took it for a lark. I never *imagined* the current value of Bitcoin or the idea that eventually dedicated farms of ASICs that literally cannot be used for anything else except supporting OR ATTACKING the blockchain would exist.
So I would be much less nervous with a very gradual adjustment to keep the miners in something closer to a steady state. Gradual adjustments make gradual dislocations, with plenty of time for equipment to wear out, turn into doorstops, blow power supplies, etc. and keep the amount of active usable infrastructure close to the amount that's financially justified by the declining block rewards.
I am concerned that down the line the sudden drops in hashing reward are likely to create dislocations of capital and hashing infrastructure. Meaning, that at some point the financial return on miners' invested capital suddenly justifies only about half of it, and then what do they do with the rest?
The thing about ASIC hashing infrastructure is that the thing that's required to secure the blockchain -- that is to say, hashing power -- is the very same thing that's required to attack it. And the weirdo economics here have caused a huge amount of it to be built -- much more than will be financially justified three or four more halvings down the line. The miners have sunk costs in dedicated equipment, so that equipment is not going to just go away because there's not a financial justification for the amortized expense of acquiring it. And it's ASICs, so they're not going to be able to switch it as general computing power to any other purpose.
I'm concerned that when the profits from hashing go down suddenly, a bunch of people looking for the most profitable use of their dedicated sunk-cost in hashing infrastructure will start to consider attacks. Way back when we were working on this, I took it for a lark. I never *imagined* the current value of Bitcoin or the idea that eventually dedicated farms of ASICs that literally cannot be used for anything else except supporting OR ATTACKING the blockchain would exist.
So I would be much less nervous with a very gradual adjustment to keep the miners in something closer to a steady state. Gradual adjustments make gradual dislocations, with plenty of time for equipment to wear out, turn into doorstops, blow power supplies, etc. and keep the amount of active usable infrastructure close to the amount that's financially justified by the declining block rewards.
That, or the value of bitcoin will increase (in relative terms to native currency) as there will be fewer 'new' BTC being sold off on the market, pushing the price up. Surely that was always the original intention? This is also combined with increased transaction fees (either through purely increased transaction volume or through fee/tx increasing). Miners not making enough on block subsidy + free/low tx fee tx's can simply stop mining free tx's or tx's with "too-low" a fee.
The free market at it's finest should be able to naturally find the optimum point for all involved (rather than the current system we have of some old guys sitting around and arbitrarily deciding a position [which is sure to benefit them, and *might* benefit the wider economy])...
Yes, the dislocation risk is largest when the value of the system as a whole is smallest. Which is clearly how you'd want it. I think the logic goes:
1) If bitcoin as a whole were high-value, it probably entails high transaction volume.
2) High transaction volume probably entails non-trivial transaction fee revenue relative to subsidy, even if fairly early in bitcoin's emission curve.
3) That transaction fee rev has the effect of drastically smoothing the otherwise severe dislocation that a 50% reward drop would otherwise represent.
Correct me if I'm wrong, Ray, but it seems like Satoshi highly valued simplicity; specifically in terms of protocol rules. He probably realized these likely fee/subsidy dynamics and took the trade off of simple code and simple rules, instead of a smoother function that probably would've been more complex to implement and/or presented a larger attack surface somehow. So while a finance guy may have pushed for more intellectual purity, a seasoned engineer would push for simple-to-implement with the hope/confidence that the market would provide the smoothing naturally. Maybe Satoshi was both and the engineer side won out.
Here's the answer to "why 21 million" and "why 8 decimal places":
http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/
fixed.http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/
Quote
The 21 Million BTC limit
One somewhat controversial property of Bitcoin is its fixed currency supply. There are currently 25 BTC being generated every 10 minutes, and this amount cuts in half every four years. All in all, there will never be more than 21 million BTC in existence. On the other hand, each bitcoin can be split into 100 million pieces (called “satoshis”), so it will not become difficult to use Bitcoin if its value goes up the same way it would become problematic to trade with dollars if each penny was enough to buy a car. Thus, all in all, the total number of currency units that will ever exist stands at 2,100,000,000,000,000: 2.1 quadrillion, or about 250.899. In choosing this figure, Satoshi was much luckier, or wiser, than most people realize. First of all, the number is considerably less than 264 – 1, the largest integer that can be stored in a standard integer on a computer – go above that, and the integers wrap around to zero like an odometer.
...
Notice how scientific notation allows you to express all of these values with reasonable accuracy despite their wildly varying scales. Floating point notation is essentially scientific notation in binary; when you store the number 9.625, your computer stores “1.001101 * 1011” (or rather, it stores 01000000 00100011 01000000 00000000 00000000 00000000 00000000 00000000, which is the same thing in high-precision serialized form). In this high-precision form, the “significand” (the part that’s not the exponent) has 52 bits. What this means is that high-precision (more precisely, “double precision”) floating point numbers are good enough to exactly store integers up to 253, but not higher – if you go higher, you start lopping off digits at the end. Bitcoin’s 250.9 satoshis are, in exponential terms, just below this maximum.
One somewhat controversial property of Bitcoin is its fixed currency supply. There are currently 25 BTC being generated every 10 minutes, and this amount cuts in half every four years. All in all, there will never be more than 21 million BTC in existence. On the other hand, each bitcoin can be split into 100 million pieces (called “satoshis”), so it will not become difficult to use Bitcoin if its value goes up the same way it would become problematic to trade with dollars if each penny was enough to buy a car. Thus, all in all, the total number of currency units that will ever exist stands at 2,100,000,000,000,000: 2.1 quadrillion, or about 250.899. In choosing this figure, Satoshi was much luckier, or wiser, than most people realize. First of all, the number is considerably less than 264 – 1, the largest integer that can be stored in a standard integer on a computer – go above that, and the integers wrap around to zero like an odometer.
...
Notice how scientific notation allows you to express all of these values with reasonable accuracy despite their wildly varying scales. Floating point notation is essentially scientific notation in binary; when you store the number 9.625, your computer stores “1.001101 * 1011” (or rather, it stores 01000000 00100011 01000000 00000000 00000000 00000000 00000000 00000000, which is the same thing in high-precision serialized form). In this high-precision form, the “significand” (the part that’s not the exponent) has 52 bits. What this means is that high-precision (more precisely, “double precision”) floating point numbers are good enough to exactly store integers up to 253, but not higher – if you go higher, you start lopping off digits at the end. Bitcoin’s 250.9 satoshis are, in exponential terms, just below this maximum.
Here's the answer to "why 21 million" and "why 8 decimal places":
http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/
fixed. http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/
Quote
The 21 Million BTC limit
One somewhat controversial property of Bitcoin is its fixed currency supply. There are currently 25 BTC being generated every 10 minutes, and this amount cuts in half every four years. All in all, there will never be more than 21 million BTC in existence. On the other hand, each bitcoin can be split into 100 million pieces (called “satoshis”), so it will not become difficult to use Bitcoin if its value goes up the same way it would become problematic to trade with dollars if each penny was enough to buy a car. Thus, all in all, the total number of currency units that will ever exist stands at 2,100,000,000,000,000: 2.1 quadrillion, or about 250.899. In choosing this figure, Satoshi was much luckier, or wiser, than most people realize. First of all, the number is considerably less than 264 – 1, the largest integer that can be stored in a standard integer on a computer – go above that, and the integers wrap around to zero like an odometer.
...
Notice how scientific notation allows you to express all of these values with reasonable accuracy despite their wildly varying scales. Floating point notation is essentially scientific notation in binary; when you store the number 9.625, your computer stores “1.001101 * 1011” (or rather, it stores 01000000 00100011 01000000 00000000 00000000 00000000 00000000 00000000, which is the same thing in high-precision serialized form). In this high-precision form, the “significand” (the part that’s not the exponent) has 52 bits. What this means is that high-precision (more precisely, “double precision”) floating point numbers are good enough to exactly store integers up to 253, but not higher – if you go higher, you start lopping off digits at the end. Bitcoin’s 250.9 satoshis are, in exponential terms, just below this maximum.
One somewhat controversial property of Bitcoin is its fixed currency supply. There are currently 25 BTC being generated every 10 minutes, and this amount cuts in half every four years. All in all, there will never be more than 21 million BTC in existence. On the other hand, each bitcoin can be split into 100 million pieces (called “satoshis”), so it will not become difficult to use Bitcoin if its value goes up the same way it would become problematic to trade with dollars if each penny was enough to buy a car. Thus, all in all, the total number of currency units that will ever exist stands at 2,100,000,000,000,000: 2.1 quadrillion, or about 250.899. In choosing this figure, Satoshi was much luckier, or wiser, than most people realize. First of all, the number is considerably less than 264 – 1, the largest integer that can be stored in a standard integer on a computer – go above that, and the integers wrap around to zero like an odometer.
...
Notice how scientific notation allows you to express all of these values with reasonable accuracy despite their wildly varying scales. Floating point notation is essentially scientific notation in binary; when you store the number 9.625, your computer stores “1.001101 * 1011” (or rather, it stores 01000000 00100011 01000000 00000000 00000000 00000000 00000000 00000000, which is the same thing in high-precision serialized form). In this high-precision form, the “significand” (the part that’s not the exponent) has 52 bits. What this means is that high-precision (more precisely, “double precision”) floating point numbers are good enough to exactly store integers up to 253, but not higher – if you go higher, you start lopping off digits at the end. Bitcoin’s 250.9 satoshis are, in exponential terms, just below this maximum.
Now that I think of it, we did talk about the floating point format in that discussion. 8-decimal divisibility was the maximum Satoshi would consider, for that reason (although he was a fanatic about doing everything with unsigned integers). Hal's point about the smallest division being less than a penny, and that being possible even if the whole world's money supply were denominated in Bitcoin, meant no extraordinary measures were necessary.
One thing I learned, was that in C, numeric overflow is undefined behavior on signed integers, and some compilers (notably gcc, which Satoshi was using) will even eliminate overflow checks, and then drop any error handlers or commands to output debug messages as dead code. Which is a reason why Satoshi was such a fanatic about using unsigned integers everywhere.
IOW, if you check for overflow by writing code like
int a,b, c;
.....a and b acquire values ....
if (a > 0 && b > 0 && a+b <= 0) {
errprintf("integer overflow at checkpoint 232\n");
halt(-1);
}
c = a+b;
gcc will eliminate the whole clause because, in its tiny little brain, integer overflow is undefined behavior so it can do whatever it likes with programming statements that depend on integer overflow having semantics. And since it's trying to make the code shorter, faster, and less complicated, it just drops 'em.
But if you check for overflow by writing
unsigned int a,b,c;
.... a and b acquire values ....
if (a+b < b || a+b < a) {
errprintf("unsigned integer overflow at checkpoint 233\n");
halt(-1);
}
c = a+b;
gcc will actually output the code to do that, because unsigned integers are specified as having modular addition and subtraction so it can't replace the if condition with if(0) and then drop the whole thing.
Not that I ever saw such baroque error checking in the Bitcoin code.
One thing I learned, was that in C, numeric overflow is undefined behavior on signed integers, and some compilers (notably gcc, which Satoshi was using) will even eliminate overflow checks, and then drop any error handlers or commands to output debug messages as dead code. Which is a reason why Satoshi was such a fanatic about using unsigned integers everywhere.
IOW, if you check for overflow by writing code like
int a,b, c;
.....a and b acquire values ....
if (a > 0 && b > 0 && a+b <= 0) {
errprintf("integer overflow at checkpoint 232\n");
halt(-1);
}
c = a+b;
gcc will eliminate the whole clause because, in its tiny little brain, integer overflow is undefined behavior so it can do whatever it likes with programming statements that depend on integer overflow having semantics. And since it's trying to make the code shorter, faster, and less complicated, it just drops 'em.
But if you check for overflow by writing
unsigned int a,b,c;
.... a and b acquire values ....
if (a+b < b || a+b < a) {
errprintf("unsigned integer overflow at checkpoint 233\n");
halt(-1);
}
c = a+b;
gcc will actually output the code to do that, because unsigned integers are specified as having modular addition and subtraction so it can't replace the if condition with if(0) and then drop the whole thing.
Not that I ever saw such baroque error checking in the Bitcoin code.
Here's the answer to "why 21 million" and "why 8 decimal places":
http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/
http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/
Quote
The 21 Million BTC limit
One somewhat controversial property of Bitcoin is its fixed currency supply. There are currently 25 BTC being generated every 10 minutes, and this amount cuts in half every four years. All in all, there will never be more than 21 million BTC in existence. On the other hand, each bitcoin can be split into 100 million pieces (called “satoshis”), so it will not become difficult to use Bitcoin if its value goes up the same way it would become problematic to trade with dollars if each penny was enough to buy a car. Thus, all in all, the total number of currency units that will ever exist stands at 2,100,000,000,000,000: 2.1 quadrillion, or about 250.899. In choosing this figure, Satoshi was much luckier, or wiser, than most people realize. First of all, the number is considerably less than 264 – 1, the largest integer that can be stored in a standard integer on a computer – go above that, and the integers wrap around to zero like an odometer.
Second, however, there is another, lower threshold that the total satoshi count manages to fall just below: the largest possible integer that can be exactly represented in floating point format. Integers are not the only kind of number that computers can store; to handle decimal numbers, computers use a format known as floating point representation. Floating point representation is essentially a binary version of scientific notation. For example, here are some values that you may be familiar with if you studied any physics:
Mass of the Earth: 5.972 * 1024 kg
Mass of the Sun: 1.989 * 1030 kg
Speed of light: 2.998 * 108 m/s
One lightyear: 9.460 * 1015 m
Mass of a proton: 1.672 * 10-27 kg
Planck length: 1.616 * 10-35 m
Notice how scientific notation allows you to express all of these values with reasonable accuracy despite their wildly varying scales. Floating point notation is essentially scientific notation in binary; when you store the number 9.625, your computer stores “1.001101 * 1011” (or rather, it stores 01000000 00100011 01000000 00000000 00000000 00000000 00000000 00000000, which is the same thing in high-precision serialized form). In this high-precision form, the “significand” (the part that’s not the exponent) has 52 bits. What this means is that high-precision (more precisely, “double precision”) floating point numbers are good enough to exactly store integers up to 253, but not higher – if you go higher, you start lopping off digits at the end. Bitcoin’s 250.9 satoshis are, in exponential terms, just below this maximum.
Why do we care about floating point values if we have integers? Because many higher-level programming languages (eg. Javascript) do not expose the low-level “floating point” and “integer representations”, instead providing the programmer with only the concept of “number” – represented in floating point form, of course. If Satoshi had chosen 210 million instead of 21 million, Bitcoin programming in many languages would be considerably harder than it is today.
Note that Stefan Thomas in his BitcoinJS library did not take advantage of this, so that library uses a specialized “big number” object instead of a plain number to store transaction output values. When asked about this, Thomas replied that he realized that using regular numbers was possible, but BitcoinJS needed to include the “big number” library regardless, since elliptic curve arithmetic requires numbers up to 2512, so the choice was arbitrary. My own BitcoinJS fork (which also adds other improvements) does use plain numbers to store the number of satoshis, a decision motivated largely by the desire to be compatible with external sources of transaction output data such as sx and pybitcointools.
One somewhat controversial property of Bitcoin is its fixed currency supply. There are currently 25 BTC being generated every 10 minutes, and this amount cuts in half every four years. All in all, there will never be more than 21 million BTC in existence. On the other hand, each bitcoin can be split into 100 million pieces (called “satoshis”), so it will not become difficult to use Bitcoin if its value goes up the same way it would become problematic to trade with dollars if each penny was enough to buy a car. Thus, all in all, the total number of currency units that will ever exist stands at 2,100,000,000,000,000: 2.1 quadrillion, or about 250.899. In choosing this figure, Satoshi was much luckier, or wiser, than most people realize. First of all, the number is considerably less than 264 – 1, the largest integer that can be stored in a standard integer on a computer – go above that, and the integers wrap around to zero like an odometer.
Second, however, there is another, lower threshold that the total satoshi count manages to fall just below: the largest possible integer that can be exactly represented in floating point format. Integers are not the only kind of number that computers can store; to handle decimal numbers, computers use a format known as floating point representation. Floating point representation is essentially a binary version of scientific notation. For example, here are some values that you may be familiar with if you studied any physics:
Mass of the Earth: 5.972 * 1024 kg
Mass of the Sun: 1.989 * 1030 kg
Speed of light: 2.998 * 108 m/s
One lightyear: 9.460 * 1015 m
Mass of a proton: 1.672 * 10-27 kg
Planck length: 1.616 * 10-35 m
Notice how scientific notation allows you to express all of these values with reasonable accuracy despite their wildly varying scales. Floating point notation is essentially scientific notation in binary; when you store the number 9.625, your computer stores “1.001101 * 1011” (or rather, it stores 01000000 00100011 01000000 00000000 00000000 00000000 00000000 00000000, which is the same thing in high-precision serialized form). In this high-precision form, the “significand” (the part that’s not the exponent) has 52 bits. What this means is that high-precision (more precisely, “double precision”) floating point numbers are good enough to exactly store integers up to 253, but not higher – if you go higher, you start lopping off digits at the end. Bitcoin’s 250.9 satoshis are, in exponential terms, just below this maximum.
Why do we care about floating point values if we have integers? Because many higher-level programming languages (eg. Javascript) do not expose the low-level “floating point” and “integer representations”, instead providing the programmer with only the concept of “number” – represented in floating point form, of course. If Satoshi had chosen 210 million instead of 21 million, Bitcoin programming in many languages would be considerably harder than it is today.
Note that Stefan Thomas in his BitcoinJS library did not take advantage of this, so that library uses a specialized “big number” object instead of a plain number to store transaction output values. When asked about this, Thomas replied that he realized that using regular numbers was possible, but BitcoinJS needed to include the “big number” library regardless, since elliptic curve arithmetic requires numbers up to 2512, so the choice was arbitrary. My own BitcoinJS fork (which also adds other improvements) does use plain numbers to store the number of satoshis, a decision motivated largely by the desire to be compatible with external sources of transaction output data such as sx and pybitcointools.
Woah, I actually learned something today. Mommy will be so proud!
Soooooo........ A lot of people don't know very much about Asian culture. Let me explain.
Counting in Asia developed along a different line. Basically Asians don't count by sets of 3, they count by 4s.
So really 100,000,000 is counted in the head of an Asian as 1,0000,0000 and the total number of Satoshi is 2100,0000,0000,0000.
Lots of people don't think Satoshi was Asian, but it seems to me that he sure counts like an Asian. Or maybe figured that most people in the world use this system of counting.
Counting in Asia developed along a different line. Basically Asians don't count by sets of 3, they count by 4s.
So really 100,000,000 is counted in the head of an Asian as 1,0000,0000 and the total number of Satoshi is 2100,0000,0000,0000.
Lots of people don't think Satoshi was Asian, but it seems to me that he sure counts like an Asian. Or maybe figured that most people in the world use this system of counting.
Honestly, I don't think he did come from a financial background. Had he come from a financial background, block rewards would not be adjusted downwards in 50% increments. In fact the kool-aid in the financial industry is universally that mild continuous inflation is a good thing, so if Satoshi were educated in that industry, then block rewards would probably eventually start going *up* by a few percent a year to keep the capital dedicated to hashing (ie, block chain security) in a constant proportion relative to the bitcoin money supply (ie, the value that must be secured), and we wouldn't be looking at a 21M coin maximum.
I am concerned that down the line the sudden drops in hashing reward are likely to create dislocations of capital and hashing infrastructure. Meaning, that at some point the financial return on miners' invested capital suddenly justifies only about half of it, and then what do they do with the rest?
The thing about ASIC hashing infrastructure is that the thing that's required to secure the blockchain -- that is to say, hashing power -- is the very same thing that's required to attack it. And the weirdo economics here have caused a huge amount of it to be built -- much more than will be financially justified three or four more halvings down the line. The miners have sunk costs in dedicated equipment, so that equipment is not going to just go away because there's not a financial justification for the amortized expense of acquiring it. And it's ASICs, so they're not going to be able to switch it as general computing power to any other purpose.
I'm concerned that when the profits from hashing go down suddenly, a bunch of people looking for the most profitable use of their dedicated sunk-cost in hashing infrastructure will start to consider attacks. Way back when we were working on this, I took it for a lark. I never *imagined* the current value of Bitcoin or the idea that eventually dedicated farms of ASICs that literally cannot be used for anything else except supporting OR ATTACKING the blockchain would exist.
So I would be much less nervous with a very gradual adjustment to keep the miners in something closer to a steady state. Gradual adjustments make gradual dislocations, with plenty of time for equipment to wear out, turn into doorstops, blow power supplies, etc. and keep the amount of active usable infrastructure close to the amount that's financially justified by the declining block rewards.
I am concerned that down the line the sudden drops in hashing reward are likely to create dislocations of capital and hashing infrastructure. Meaning, that at some point the financial return on miners' invested capital suddenly justifies only about half of it, and then what do they do with the rest?
The thing about ASIC hashing infrastructure is that the thing that's required to secure the blockchain -- that is to say, hashing power -- is the very same thing that's required to attack it. And the weirdo economics here have caused a huge amount of it to be built -- much more than will be financially justified three or four more halvings down the line. The miners have sunk costs in dedicated equipment, so that equipment is not going to just go away because there's not a financial justification for the amortized expense of acquiring it. And it's ASICs, so they're not going to be able to switch it as general computing power to any other purpose.
I'm concerned that when the profits from hashing go down suddenly, a bunch of people looking for the most profitable use of their dedicated sunk-cost in hashing infrastructure will start to consider attacks. Way back when we were working on this, I took it for a lark. I never *imagined* the current value of Bitcoin or the idea that eventually dedicated farms of ASICs that literally cannot be used for anything else except supporting OR ATTACKING the blockchain would exist.
So I would be much less nervous with a very gradual adjustment to keep the miners in something closer to a steady state. Gradual adjustments make gradual dislocations, with plenty of time for equipment to wear out, turn into doorstops, blow power supplies, etc. and keep the amount of active usable infrastructure close to the amount that's financially justified by the declining block rewards.
That, or the value of bitcoin will increase (in relative terms to native currency) as there will be fewer 'new' BTC being sold off on the market, pushing the price up. Surely that was always the original intention? This is also combined with increased transaction fees (either through purely increased transaction volume or through fee/tx increasing). Miners not making enough on block subsidy + free/low tx fee tx's can simply stop mining free tx's or tx's with "too-low" a fee.
The free market at it's finest should be able to naturally find the optimum point for all involved (rather than the current system we have of some old guys sitting around and arbitrarily deciding a position [which is sure to benefit them, and *might* benefit the wider economy])...
Interesting points and perspective.
2 counterpoints:
#1) Don't you think that commercial miners are well aware of the
subsidy schedule and have worked that into their business plans?
Yes, I believe that they have. I hope that they have done so correctly and without making business plans involving malign intent.
#2) Even if jarring displacements occur as you speak of, I
don't understand what conditions there could be that would
make attacking more profitable than mining. Can you give
an example?
Sure. Terrorist wants to spread chaos and make a profit to arm and equip his jihadis. He acquires massive hashing infrastructure which miners are getting rid of on a secondary market like ebay for cheap, shorts Bitcoin with sixty-day contracts, and starts doing double spends of large amounts, forcing orphaning of chains hours or even days deep. This will attract media attention and shatter confidence in Bitcoin security, as well as inspiring people to wait longer and longer and let the blockchain get days deep before they consider a payment secure, so he gets profits from his double spends, a huge payback on his short, and as a bonus, strikes a blow against the capitalist swine by destroying the value of their Bitcoin.
Is totally obvious Satoshi come from financial background.
Facts indicate quite the opposite I am afraid!
If you design a currency for the web obviously you have to consider Javascript.
Most Javascript implementations internaly represent integers as Double-precision floating-point format.
The IEEE 754 standard specifies a binary64 as having:
Sign bit: 1 bit
Exponent width: 11 bits
Significand precision: 53 bits (52 explicitly stored) This gives from 15–17 significant decimal digits precision.
Code:
21 000 000 000 000 00 (a 16 decimal digit num) of integral currency units (satoshi)
is the maximum you can get and safe work with in modern Javascript.I think this says a lot!
https://en.wikipedia.org/wiki/Double-precision_floating-point_format
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
Honestly, I don't think he did come from a financial background. Had he come from a financial background, block rewards would not be adjusted downwards in 50% increments. In fact the kool-aid in the financial industry is universally that mild continuous inflation is a good thing, so if Satoshi were educated in that industry, then block rewards would probably eventually start going *up* by a few percent a year to keep the capital dedicated to hashing (ie, block chain security) in a constant proportion relative to the bitcoin money supply (ie, the value that must be secured), and we wouldn't be looking at a 21M coin maximum.
I am concerned that down the line the sudden drops in hashing reward are likely to create dislocations of capital and hashing infrastructure. Meaning, that at some point the financial return on miners' invested capital suddenly justifies only about half of it, and then what do they do with the rest?
The thing about ASIC hashing infrastructure is that the thing that's required to secure the blockchain -- that is to say, hashing power -- is the very same thing that's required to attack it. And the weirdo economics here have caused a huge amount of it to be built -- much more than will be financially justified three or four more halvings down the line. The miners have sunk costs in dedicated equipment, so that equipment is not going to just go away because there's not a financial justification for the amortized expense of acquiring it.
I'm concerned that when the profits from hashing go down suddenly, a bunch of people looking for the most profitable use of their dedicated sunk-cost in hashing infrastructure will start to consider attacks. Way back when we were working on this, I took it for a lark. I never *imagined* the current value of Bitcoin or the idea that eventually dedicated farms of ASICs that literally cannot be used for anything else except supporting OR ATTACKING the blockchain would exist.
So I would be much less nervous with a very gradual adjustment to keep the miners in something closer to a steady state. Gradual adjustments make gradual dislocations, with plenty of time for equipment to wear out, turn into doorstops, blow power supplies, etc. and keep the amount of active usable infrastructure close to the amount that's financially justified by the declining block rewards.
I am concerned that down the line the sudden drops in hashing reward are likely to create dislocations of capital and hashing infrastructure. Meaning, that at some point the financial return on miners' invested capital suddenly justifies only about half of it, and then what do they do with the rest?
The thing about ASIC hashing infrastructure is that the thing that's required to secure the blockchain -- that is to say, hashing power -- is the very same thing that's required to attack it. And the weirdo economics here have caused a huge amount of it to be built -- much more than will be financially justified three or four more halvings down the line. The miners have sunk costs in dedicated equipment, so that equipment is not going to just go away because there's not a financial justification for the amortized expense of acquiring it.
I'm concerned that when the profits from hashing go down suddenly, a bunch of people looking for the most profitable use of their dedicated sunk-cost in hashing infrastructure will start to consider attacks. Way back when we were working on this, I took it for a lark. I never *imagined* the current value of Bitcoin or the idea that eventually dedicated farms of ASICs that literally cannot be used for anything else except supporting OR ATTACKING the blockchain would exist.
So I would be much less nervous with a very gradual adjustment to keep the miners in something closer to a steady state. Gradual adjustments make gradual dislocations, with plenty of time for equipment to wear out, turn into doorstops, blow power supplies, etc. and keep the amount of active usable infrastructure close to the amount that's financially justified by the declining block rewards.
Interesting points and perspective.
2 counterpoints:
#1) Don't you think that commercial miners are well aware of the
subsidy schedule and have worked that into their business plans?
#2) Even if jarring displacements occur as you speak of, I
don't understand what conditions there could be that would
make attacking more profitable than mining. Can you give
an example?
Honestly, I don't think he did come from a financial background. Had he come from a financial background, block rewards would not be adjusted downwards in 50% increments. In fact the kool-aid in the financial industry is universally that mild continuous inflation is a good thing, so if Satoshi were educated in that industry, then block rewards would probably eventually start going *up* by a few percent a year to keep the capital dedicated to hashing (ie, block chain security) in a constant proportion relative to the bitcoin money supply (ie, the value that must be secured), and we wouldn't be looking at a 21M coin maximum.
I am concerned that down the line the sudden drops in hashing reward are likely to create dislocations of capital and hashing infrastructure. Meaning, that at some point the financial return on miners' invested capital suddenly justifies only about half of it, and then what do they do with the rest?
The thing about ASIC hashing infrastructure is that the thing that's required to secure the blockchain -- that is to say, hashing power -- is the very same thing that's required to attack it. And the weirdo economics here have caused a huge amount of it to be built -- much more than will be financially justified three or four more halvings down the line. The miners have sunk costs in dedicated equipment, so that equipment is not going to just go away because there's not a financial justification for the amortized expense of acquiring it. And it's ASICs, so they're not going to be able to switch it as general computing power to any other purpose.
I'm concerned that when the profits from hashing go down suddenly, a bunch of people looking for the most profitable use of their dedicated sunk-cost in hashing infrastructure will start to consider attacks. Way back when we were working on this, I took it for a lark. I never *imagined* the current value of Bitcoin or the idea that eventually dedicated farms of ASICs that literally cannot be used for anything else except supporting OR ATTACKING the blockchain would exist.
So I would be much less nervous with a very gradual adjustment to keep the miners in something closer to a steady state. Gradual adjustments make gradual dislocations, with plenty of time for equipment to wear out, turn into doorstops, blow power supplies, etc. and keep the amount of active usable infrastructure close to the amount that's financially justified by the declining block rewards.
I am concerned that down the line the sudden drops in hashing reward are likely to create dislocations of capital and hashing infrastructure. Meaning, that at some point the financial return on miners' invested capital suddenly justifies only about half of it, and then what do they do with the rest?
The thing about ASIC hashing infrastructure is that the thing that's required to secure the blockchain -- that is to say, hashing power -- is the very same thing that's required to attack it. And the weirdo economics here have caused a huge amount of it to be built -- much more than will be financially justified three or four more halvings down the line. The miners have sunk costs in dedicated equipment, so that equipment is not going to just go away because there's not a financial justification for the amortized expense of acquiring it. And it's ASICs, so they're not going to be able to switch it as general computing power to any other purpose.
I'm concerned that when the profits from hashing go down suddenly, a bunch of people looking for the most profitable use of their dedicated sunk-cost in hashing infrastructure will start to consider attacks. Way back when we were working on this, I took it for a lark. I never *imagined* the current value of Bitcoin or the idea that eventually dedicated farms of ASICs that literally cannot be used for anything else except supporting OR ATTACKING the blockchain would exist.
So I would be much less nervous with a very gradual adjustment to keep the miners in something closer to a steady state. Gradual adjustments make gradual dislocations, with plenty of time for equipment to wear out, turn into doorstops, blow power supplies, etc. and keep the amount of active usable infrastructure close to the amount that's financially justified by the declining block rewards.
Is totally obvious Satoshi come from financial background.
Jump to: