matthewh3
Legendary
Offline
Activity: 1372
Merit: 1003
|
|
October 21, 2012, 01:11:16 AM |
|
I hear it would take at least 150 years for all the bitcoins to be acquired as the internal software has a limit.
I hear people make up random statistics as their tolerance for actual facts has a limit. You can make up statistics to prove anything. 83% of people will tell you that! It's true it will take a very long time to completely stop and if the decimal place kept getting shifted due to rising bitcoin value then mining may happen indefinitely.
|
|
|
|
lilphilog
Newbie
Offline
Activity: 22
Merit: 0
|
|
October 21, 2012, 12:45:26 PM |
|
I hope they never stop, i just love the whole concept of "bitcoins"
|
|
|
|
Ploo
|
|
October 21, 2012, 04:28:13 PM |
|
I hope they never stop, i just love the whole concept of "bitcoins"
By design, they will stop being produced. That's what the protocol says. Or rather they'll be produced indefinitely but because the block reward is halved roughly once every four years, it won't be until far into the future till the reward halves from 1 satoshi (0.00000001) to no reward at all because bitcoin is only divisable to 8 places. So while technically they'll be produced for a long time to go, in practice the reward will be so small miners will be paid through transaction fees instead.
|
|
|
|
helloworld
|
|
October 23, 2012, 06:08:59 AM |
|
Does the calculation lose accuracy each time the reward drops, or is it always based on 50*something?
What will the next list of rewards be after 0.09765625 per block?
I realised this is a dumb question because at some point an actual figure (i.e 50) must have been hardcoded into the software, and that software isn't going to get updated every single time the reward drops.
So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.
|
|
|
|
Foxpup
Legendary
Offline
Activity: 4494
Merit: 3178
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
October 23, 2012, 07:51:47 AM |
|
Does the calculation lose accuracy each time the reward drops, or is it always based on 50*something?
What will the next list of rewards be after 0.09765625 per block?
I realised this is a dumb question because at some point an actual figure (i.e 50) must have been hardcoded into the software, and that software isn't going to get updated every single time the reward drops.
So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.
Actually, since bitcoins are only divisible down to 8 decimal places, the reward drop will indeed "lose accuracy" on the 10th halving (sometime around the year 2048), when the reward will drop from BTC0.09765625 to BTC0.04882812 (it is always rounded down to the 8th decimal place, so there will be no confusion about it when the time comes).
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
|
|
|
josephliton
|
|
October 23, 2012, 10:13:46 AM |
|
I think in the end 1 bitcoin will be = to 500 dollar.
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4798
|
|
October 23, 2012, 02:29:54 PM |
|
So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.
Actually, since bitcoins are only divisible down to 8 decimal places, the reward drop will indeed "lose accuracy" on the 10th halving (sometime around the year 2048), when the reward will drop from BTC0.09765625 to BTC0.04882812 (it is always rounded down to the 8th decimal place, so there will be no confusion about it when the time comes).
I believe it is technically handled by performing a bitwise right shift on the reward as an integer. So right now the block reward is 5,000,000,000 which can be represented in binary as: 100101010000001011111001000000000 When we see the reward cut in half in a few weeks, the programming will simply chop a digit off the right-hand side of that binary number giving us 10010101000000101111100100000000 Which is 2,500,000,000 in base 10. In 2048 the reward will go from 9,765,625 to 4,882,812 100101010000001011111001 (9,765,625) 10010101000000101111100 (4,882,812) You can see that we will "lose precision" any time we chop off a one, and we will have a nice even halving whenever we chop off a zero. What will the next list of rewards be . . . ?
For the list of rewards, try this: http://lmgtfy.com/?q=0b100101010000001011111001000000000+in+decimalThen you can just remove digits from the right hand side of the binary number to represent the number of "halvings" you are interested in, and you should see the new reward represented in "Satoshi". If you want to see it represented in BTC, just move the decimal 8 places to the left after the conversion.
|
|
|
|
odolvlobo
Legendary
Offline
Activity: 4438
Merit: 3388
|
|
October 24, 2012, 01:28:15 AM |
|
So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.
For the list of rewards, try this: http://lmgtfy.com/?q=0b100101010000001011111001000000000+in+decimalThen you can just remove digits from the right hand side of the binary number to represent the number of "halvings" you are interested in, and you should see the new reward represented in "Satoshi". If you want to see it represented in BTC, just move the decimal 8 places to the left after the conversion. ... or go to https://en.bitcoin.it/wiki/Controlled_Currency_Supply, where all of this is explained and there is a table showing all the block rewards.
|
Join an anti-signature campaign: Click ignore on the members of signature campaigns. PGP Fingerprint: 6B6BC26599EC24EF7E29A405EAF050539D0B2925 Signing address: 13GAVJo8YaAuenj6keiEykwxWUZ7jMoSLt
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4798
|
|
October 24, 2012, 02:05:53 AM |
|
For the list of rewards, try this: http://lmgtfy.com/?q=0b100101010000001011111001000000000+in+decimalThen you can just remove digits from the right hand side of the binary number to represent the number of "halvings" you are interested in, and you should see the new reward represented in "Satoshi". If you want to see it represented in BTC, just move the decimal 8 places to the left after the conversion. But which does nothing to explain technically how the reward is modified. Are the reward amounts coded directly into the software? Is a divide-by-two floating point calculation performed with rounding to 8 decimal places?
|
|
|
|
ldrgn
Member
Offline
Activity: 118
Merit: 10
|
|
October 24, 2012, 02:12:03 AM |
|
But which does nothing to explain technically how the reward is modified. Are the reward amounts coded directly into the software? Is a divide-by-two floating point calculation performed with rounding to 8 decimal places?
I'm sorry I can't find you a source, but it's a bit shift of one digit. Bitcoins are always stored as an integer number of Satoshis.
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4798
|
|
October 24, 2012, 02:19:43 AM |
|
But which does nothing to explain technically how the reward is modified . . .
I'm sorry I can't find you a source, but it's a bit shift of one digit. Bitcoins are always stored as an integer number of Satoshis. I believe you are correct, which is why I already explained it that way here: I believe it is technically handled by performing a bitwise right shift on the reward as an integer.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
October 24, 2012, 03:39:12 AM |
|
But which does nothing to explain technically how the reward is modified. Are the reward amounts coded directly into the software? Is a divide-by-two floating point calculation performed with rounding to 8 decimal places?
I'm sorry I can't find you a source, but it's a bit shift of one digit. Bitcoins are always stored as an integer number of Satoshis. Correct. All values at the protocol level are 64bit integers (representing satoshis). The block reward function uses a right bit shift. int64 static GetBlockValue(int nHeight, int64 nFees) { int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees; } https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp
|
|
|
|
zebedee
Donator
Hero Member
Offline
Activity: 668
Merit: 500
|
|
October 24, 2012, 05:10:42 AM |
|
Correct. All values at the protocol level are 64bit integers (representing satoshis). The block reward function uses a right bit shift. int64 static GetBlockValue(int nHeight, int64 nFees) { int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees; } https://github.com/bitcoin/bitcoin/blob/master/src/main.cppThat code needs fixing by the devs. It has undefined behaviour for large nHeight in the right shift operation, and as such is a security hole in the future. I'd have hoped devs with their experience would know their programming language...
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4798
|
|
October 24, 2012, 06:14:02 AM |
|
Correct. All values at the protocol level are 64bit integers (representing satoshis). The block reward function uses a right bit shift. int64 static GetBlockValue(int nHeight, int64 nFees) { int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees; } https://github.com/bitcoin/bitcoin/blob/master/src/main.cppThat code needs fixing by the devs. It has undefined behaviour for large nHeight in the right shift operation, and as such is a security hole in the future. I'd have hoped devs with their experience would know their programming language... I don't think we'll have to worry about undefined behavior for at least another 130 years. I can't think of any computer program that was running 130 years ago that is still running today. I can't even think of any programming languages that were in use 130 years ago that are still in use today. I agree that for the sake of well written code it should probably be handled a bit more carefully, but this isn't a bug that will concern me in my lifetime.
|
|
|
|
Foxpup
Legendary
Offline
Activity: 4494
Merit: 3178
Vile Vixen and Miss Bitcointalk 2021-2023
|
|
October 24, 2012, 06:55:53 AM |
|
Correct. All values at the protocol level are 64bit integers (representing satoshis). The block reward function uses a right bit shift. int64 static GetBlockValue(int nHeight, int64 nFees) { int64 nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years nSubsidy >>= (nHeight / 210000);
return nSubsidy + nFees; } https://github.com/bitcoin/bitcoin/blob/master/src/main.cppThat code needs fixing by the devs. It has undefined behaviour for large nHeight in the right shift operation, and as such is a security hole in the future. I'd have hoped devs with their experience would know their programming language... Ouch. Oh well, at least it's an easy fix and we've got over 250 years to implement it...
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
|
|
|
helloworld
|
|
October 28, 2012, 01:53:54 PM |
|
So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.
Actually, since bitcoins are only divisible down to 8 decimal places, the reward drop will indeed "lose accuracy" on the 10th halving (sometime around the year 2048), when the reward will drop from BTC0.09765625 to BTC0.04882812 (it is always rounded down to the 8th decimal place, so there will be no confusion about it when the time comes).
I believe it is technically handled by performing a bitwise right shift on the reward as an integer. So right now the block reward is 5,000,000,000 which can be represented in binary as: 100101010000001011111001000000000 When we see the reward cut in half in a few weeks, the programming will simply chop a digit off the right-hand side of that binary number giving us 10010101000000101111100100000000 Which is 2,500,000,000 in base 10. In 2048 the reward will go from 9,765,625 to 4,882,812 100101010000001011111001 (9,765,625) 10010101000000101111100 (4,882,812) You can see that we will "lose precision" any time we chop off a one, and we will have a nice even halving whenever we chop off a zero. What will the next list of rewards be . . . ?
For the list of rewards, try this: http://lmgtfy.com/?q=0b100101010000001011111001000000000+in+decimalThen you can just remove digits from the right hand side of the binary number to represent the number of "halvings" you are interested in, and you should see the new reward represented in "Satoshi". If you want to see it represented in BTC, just move the decimal 8 places to the left after the conversion. However, these truncated values are not hardcoded into the software, but rather the software still only contains the hardcoded 50 (100101010000001011111001000000000) with a run-time algorithm to determine how many times it's shifted. So this means that it does not lose accuracy each time. i.e. The accuracy loss when a 1 is chopped off does not *compound*. Example: Let's say we only had 1 decimal place and the reward started at 10, then at some point in the future we decide to use 2 decimal places. If accuracy loss was compounded we'd have the following series. 10.0 5.0 2.5 1.2 "Hey everyone, let's use more decimal places!" 0.60 0.30 0.15 0.07 Whereas if accuracy-loss is not compounded (i.e. only the initial 10.0 is hardcoded into the software) then we end up with a different series 10.0 5.0 2.5 1.2 "Hey everyone, let's use more decimal places!" 0.62 0.31 0.15 0.07
|
|
|
|
paraipan
In memoriam
Legendary
Offline
Activity: 924
Merit: 1004
Firstbits: 1pirata
|
|
October 28, 2012, 02:00:13 PM |
|
^interesting to know, thank you @helloworld for the easy to understand explanation
|
BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4798
|
|
October 28, 2012, 07:14:51 PM |
|
However, these truncated values are not hardcoded into the software, but rather the software still only contains the hardcoded 50 (100101010000001011111001000000000) with a run-time algorithm to determine how many times it's shifted.
So this means that it does not lose accuracy each time. i.e. The accuracy loss when a 1 is chopped off does not *compound*.
Example: Let's say we only had 1 decimal place and the reward started at 10, then at some point in the future we decide to use 2 decimal places. If accuracy loss was compounded we'd have the following series.
10.0 5.0 2.5 1.2 "Hey everyone, let's use more decimal places!" 0.60 0.30 0.15 0.07
Whereas if accuracy-loss is not compounded (i.e. only the initial 10.0 is hardcoded into the software) then we end up with a different series
10.0 5.0 2.5 1.2 "Hey everyone, let's use more decimal places!" 0.62 0.31 0.15 0.07
Except that right now the code doesn't use decimal places at all. It works with integers, and then moves the decimal after the calculation is done... So in your first example (ten plus 1 decimal places) you'd actually be working with 100, then right shift, then move your decimal, to get the extra decimals, you'd have to change your hardcoded starting number fro 100 to 1000 to get the extra precision and still have the starting number be 10 after moving the decimal. So, you get the extra accuracy, not because the loss wasn't "compounded", but rather because you changed the number that you are starting with to an entirely different number.
|
|
|
|
helloworld
|
|
October 28, 2012, 11:37:57 PM |
|
and then moves the decimal after the calculation is done...
This is my entire point (emphasis mine). The reward will always be based on a calculation where '50' (in whatever shape or form) is the only hard-coded amount.
|
|
|
|
|