Print Page - Why 1BTC should equal 10^8 satoshi ?

If you come from a financial background then obvious choices are:

Code:

    0.0001       : a percentage in point (pip) is a unit of change specifically in foreign exchange markets
   1,000,000.00 : accountants favorite view

BUT if you come from a hacker/programmer or cryptanalyst background the

Code:

   0.00000000  is definitely what you would prefer  because resembles the 8 hex digits of a 4 byte (32bit) integer  0x1234ABCD

also note that values satoshi incide tx's are encoded Little Endian like this:

Code:

   40 4B 4C 00 00 00 00 00  - 0.05 BTC (5000000)

contrary to common practice that everything emitted to the network should encoded Big Endian

Any thoughts or better explanation?

PS: I find a representation like 1000.0001 the most clean for the average.

Quote from: odolvlobo on October 11, 2014, 04:28:11 PM

The choice is pretty arbitrary. I can think of two possible reasons.
The first is possibly convenience. It allows you to describe a value as a millionth of a bitcoin with two decimal places.
A second possibility is that the total number of satoshis is about 10 times the total wealth of the world in dollars.

The protocol uses a 64-bit number to represent a number of satoshis and the largest possible number is 9,223,372,036,854,775,807, which is about 4000 times the maximum number of satoshis. So I would either increase the maximum number of bitcoins to 84 billion or make 1 BTC = 10¹¹ satoshis, rather than letting those 12 bits go to waste.

I don't think this would be necessary. It is unlikely that bitcoin will ever have enough value that it will be necessary to have this level of precision.

For the first several years of bitcoin being in existence, QT did not even support displaying the balance in amounts other then by two decimal places

I think the OP is asking: "Why do we call 100,000,000 of the protocol's actual base units (ie, satoshis), '1 bitcoin'? Why not one million base units, or a thousand?"

That is, there are approx 2,100,000,000,000,000 eventual base units ("satoshis"). Those are the units the protocol actually deals with on the network. Why do we happen to call 100million of them "1 bitcoin"?

"1 bitcoin" is just a term. I think Satoshi picked 100,000,000 base units because bitcoin needed a standard denomination size in the early users that felt fairly natural to people. If one cup of coffee cost 27500000 units, it'd be weird/confusing to people. In day to day life, people are used to transacting in single, double, triple, and quadruple digits. Go much beyond that, and people get confused. Worse, use a number with a lot of sub-decimal-point digits and people just can't handle it.

In bitcoin's early years, it seemed reasonable/natural that "50" units would be mined every 10 minutes. Early adopters could mine a few hundred in a day, and then play around by sending amounts like "10", "75", "200" around to each other. If, instead, "1 bitcoin" meant "1000 base units", those numbers all would've had a lot of zeros after them and been cumbersome to look at and deal with.

So I think it was just a balance issue, with a goal of keeping the reasonable day-to-day transaction amounts in-line with what people are used to. Note that at this point, today, with bitcoin's dramatically increased purchasing power, it would be more convenient if "1 bitcoin" meant "100,000 base units" or even "100 base units". We wouldn't be dealing with sub-decimal-point numbers for buying a cup of coffee. Hence the push people were making last year to consider "millis" the day-to-day standard, and now the push being made for "bits".

Obviously no matter how you chop up the nomenclature, you control the same percentage of the total supply, so it doesn't matter in an economic sense. But humans are difficult, so there are certainly ease-of-use and familiarity concerns to optimize.

There is a line in the code like this:
COIN=100000000;

It tells the wallet how many satoshis that shall be called a BTC. Nothing more. if the line is changed to, for example
COIN=100;
and you had 1 bitcoin, your wallet would now say that you had 1 million bitcoins. But it would not make you any richer, because the code works only with with satoshis 'under the hood', and does not really care how many satoshi we choose to make up one bitcoin.

But why the choice of such a high number like 10^8 ? My guess: If bitcoin were to become widespread, most people would have to do with only small fraction of a single bitcoin. Not vey practical. But as I explained above, the code can very easy be changed to denominate the unit. I think Satoshi or whoever wrote the code thought that such denominations should take place as the coin spread out. Why? Maybe because such denominations it would also make it less evident how much the bitcoin money supply favorizes early adapters?

Thanks for your really awesome answers.

After carefully reading them here are some extra facts
https://en.wikipedia.org/wiki/Integer_(computer_science)

A 32bit signed integer can represent numbers from −2,147,483,648 to 2,147,483,647

if you wanted to do accounting for modern currencies with pure integers due to denomination factor of 100 (1$ = 100 cents)
then the obvious choice is to work in cents

Code:

        1 -> 1 cent
     100 -> 1 $

in such a system the most you can represent is slight above 21 million $

Code:

    from  −21,474,836.48 $      to       21,474,836.47 $

Note that left of side of the dot there are 8 digit/decimal places (21 xxx xxx).
Lets assume 1BTC worth(represents) 1 $.
To make it symmetric the dynamic logarithmic range has to be [ 10E-8 , 10E8 ]
This range permits exponential growth or decay for 2*8 orders of magnitude!

Code:

21 xxx xxx . yyy yyy 01

::)

Quote from: qdoop on October 11, 2014, 08:23:33 PM

Code:

        1 -> 1 cent
     100 -> 1 $

in such a system the most you can represent is slight above 21 million $

Code:

    from  −21,474,836.48 $      to       21,474,836.47 $

Code:

21 xxx xxx . yyy yyy 01

::)

That is interesting.

I would say that in a vast majority of computing applications,
optimizing how one types variables is of little importance.

Obviously there are exceptions, such as databases, or
the situation when you've mistakenly truncated data.

But usually, software development projects
have a hard enough time being completed on schedule,
within budget, while fulfilling requirements and
providing adequate robustness.

I remember this discussion, actually.

Finney, Satoshi, and I discussed how divisible a Bitcoin ought to be. Satoshi had already more or less decided on a 50-coin per block payout with halving every so often to add up to a 21M coin supply. Finney made the point that people should never need any currency division smaller than a US penny, and then somebody (I forget who) consulted some oracle somewhere like maybe Wikipedia and figured out what the entire world's M1 money supply at that time was.

We debated for a while about which measure of money Bitcoin most closely approximated; but M2, M3, and so on are all for debt-based currencies, so I agreed with Finney that M1 was probably the best measure.

21Million, times 10^8 subdivisions, meant that even if the whole word's money supply were replaced by the 21 million bitcoins the smallest unit (we weren't calling them Satoshis yet) would still be worth a bit less than a penny, so no matter what happened -- even if the entire economy of planet earth were measured in Bitcoin -- it would never inconvenience people by being too large a unit for convenience.

Quote from: Cryddit on October 12, 2014, 03:28:14 AM

Assuming you're Ray Dillinger - is that conversation public anywhere? I don't recall reading it on http://www.mail-archive.com/cryptography%40metzdowd.com/msg10005.html

Quote from: Cryddit on October 12, 2014, 03:28:14 AM

Very interesting background. Thanks for sharing!

Unfortunately, the most important factor was missed: inertia to change, and observing the existing convention of 2dp in fiat currencies, and the vast majority of financial computer systems also supporting 2dp.

So, the ideal would have been 21 million million bitcoins, with 100 sub-units each. It would have made for large numbers from early on, like dogecoin has today, but as the network and ecosystem grew, bitcoin amounts would rapidly look sensible in day-to-day transactions. The Italians did fine when it was 1500 lira to the dollar for many years.

Quote from: Cryddit on October 12, 2014, 04:27:14 AM

Quote from: Melbustus on October 12, 2014, 03:55:19 AM

Assuming you're Ray Dillinger - is that conversation public anywhere? I don't recall reading it on http://www.mail-archive.com/cryptography%40metzdowd.com/msg10005.html

Uhh, I don't remember ever agreeing to keep it secret, but we didn't talk about it on the list either. At that time Hal was elbows-deep in the transaction scripting code, and I was checking Satoshi's work on the crypto on the blockchain architecture.

Finney had a lot to worry about with the transaction scripting and wound up blocking out about a dozen more opcodes than Satoshi had wanted to, but I found essentially nothing wrong with the block structure. I am still freakin' amazed how tight he got that blockchain design.

And, yeah, I'm Ray Dillinger.

Interesting - thanks for posting. I always assumed that all of those initial-state decisions had been made *before* Satoshi posted the whitepaper. I guess because of that comment he made in that list thread to the effect of "I'm almost ready to post the code."

It's a little amusing - if bitcoin continues to grow, economists will no doubt be horrified by the levity (relative to an econ committee mtg) with which these decisions were made. Not saying that's a bad thing, or that they weren't rationally through - it actually shows how strong the system is in that there were many possible "reasonable" initial conditions that could've been selected, since the system is largely self-equilibriating anyway.

Re Finney - if he was blocking bitcoin op-codes, I wonder what he would've thought of Ethereum's scripting lang. :)

(and I had to ask if you were Ray cuz your early posts on here were signed "Edward")

Quote from: Melbustus on October 12, 2014, 04:42:06 AM

He *was* just about ready to post the code. This was a debate about what value an already-defined constant ought to have. In fact I've already posted an archive of his code from just a few *days* later in another thread here for historical interest.

Hal and I were essentially giving it a last-minute looking over to see if we thought there was any way to attack it. I have the impression that Hal communicated with Satoshi a lot more than I did, but he was looking at a much tougher problem. The blockchain structure is essentially a mathematical proof -- very straightforward, you follow it and you can say with reasonable certainty that it's right or not. But a scripting language is generative. And generative structures present exponentially more attack surfaces.

Quote from: Melbustus on October 12, 2014, 04:42:06 AM

Re Finney - if he was blocking bitcoin op-codes, I wonder what he would've thought of Ethereum's scripting lang. :)

You're kidding right? Ethereum's scripting language is limited only by the amount of steps it will run a calculation. Hal would have pitched a fit about the Denial-of-Service possibilities.

Quote from: Melbustus on October 12, 2014, 04:42:06 AM

(and I had to ask if you were Ray cuz your early posts on here were signed "Edward")

Yeah, I made up a fake person because at first I didn't want people here to know who I was. I was kind of afraid they'd get freaky about it.

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.

Quote from: Cryddit on October 13, 2014, 05:30:58 AM

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.

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?

Quote from: CryptoCarmen on October 12, 2014, 07:44:04 PM

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! ;D

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

Quote from: jonald_fyookball on October 13, 2014, 05:36:28 AM

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.

Quote from: jonald_fyookball on October 13, 2014, 05:36:28 AM

#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.

Quote from: Cryddit on October 13, 2014, 05:30:58 AM

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])...

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/

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.

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.

Quote from: RenegadeMind on October 13, 2014, 10:37:05 AM

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/

Quote

fixed.

Quote from: phillipsjk on October 13, 2014, 05:41:17 PM

Quote from: RenegadeMind on October 13, 2014, 10:37:05 AM

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/

Quote

fixed.

fixed again. :)

Quote from: e4xit on October 13, 2014, 09:47:19 AM

Quote from: Cryddit on October 13, 2014, 05:30:58 AM

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.

This is the current GetBlockValue, providing a total money supply of 2099'9999'9769'0000 satoshis, halving the subsidy every 21'0000 blocks:

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.

Quote from: KingOfTrolls on October 14, 2014, 04:41:40 AM

This is the current GetBlockValue, providing a total money supply of 2099'9999'9769'0000 satoshis, halving the subsidy every 21'0000 blocks:

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

Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: qdoop on October 11, 2014, 08:11:40 AM