asdf
|
|
November 20, 2010, 12:13:58 AM |
|
The 'max 8 decimal places' can stay for a while... Just my 0.0298723 BTC The 'max 8 decimal places' will have to stay for a long while, since that is a byproduct of how the bitcoin value is stored. It's a very long (binary?) integer (64 bit, I think) and has no decimal point. The clients simply display the values with a decimal point in the middle of the base 10 translation of the integer, as there are 8 decimal places to each side of the display. Changing that might prove to be a breaking change, and may not be an easy one. I don't know how difficult it would be to switch to an 128 bit integer, but since I don't think that there is any OS that yet process 128 bit natively I imagine that might have to come first. Wouldn't it by much easier to, for example, put a 1 as the first bit of the 64bit int to indicate a 16bit shift in the interpretation of the remaining bits? so if I have 0000 ... 000110101 coins this could also be represented by 1000 ... 0001101010000000000000000, but now I have 16 more bits of low range precision. It's not like the first bit will be used for anything else. no one will ever have 2^64 nanobitcoins. Alternatively you could change the precision after a agreed upon block number. This seems to me much easier that changing the integer size. Clients just need to have a consensus about the protocol change.
|
|
|
|
bitcoinex
|
|
November 20, 2010, 03:42:52 AM |
|
The 'max 8 decimal places' can stay for a while... Just my 0.0298723 BTC The 'max 8 decimal places' will have to stay for a long while, since that is a byproduct of how the bitcoin value is stored. It's a very long (binary?) integer (64 bit, I think) and has no decimal point. The clients simply display the values with a decimal point in the middle of the base 10 translation of the integer, as there are 8 decimal places to each side of the display. Changing that might prove to be a breaking change, and may not be an easy one. I don't know how difficult it would be to switch to an 128 bit integer, but since I don't think that there is any OS that yet process 128 bit natively I imagine that might have to come first. Better go to the text (or TeX) Also we get a numbers with an absolute accuracy: "1/3 BTC"
|
New bitcoin lottery: probiwon.com- Moжeт, ты eщё и в Heвидимyю Pyкy Pынкa вepyeшь? - Зaчeм жe вepoвaть в тo, чтo мoжнo нaблюдaть нeпocpeдcтвeннo?
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1056
|
|
November 20, 2010, 11:15:24 AM |
|
Wouldn't it by much easier to, for example, put a 1 as the first bit of the 64bit int Yes, a "signal bit" is a much better way of doing it than moving to 128-bit integers, because 63 bits of precision is plenty for any transaction. But the 64th bit should not mean "shift everything by 16 bits", because we want to keep the subdivision of a bitcoin in decimal units, not binary units. The 64th bit could mean "the remaining bits are an integer count of the number of 10 -16-bitcoins rather than the number of 10 -8-bitcoins". 55 bits is enough to store all of the bitcoins at the current level of precision (21,000,000.000 000 00), so there will be quite a few spare bits available when the time comes.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1005
Bringing Legendary Har® to you since 1952
|
|
November 20, 2010, 03:42:52 PM |
|
The clients simply display the values with a decimal point in the middle of the base 10 translation of the integer, as there are 8 decimal places to each side of the display. Changing that might prove to be a breaking change, and may not be an easy one.
Actually I think i remember Satoshi or Gavin saying that it actually is a quite easy change as bitcoin was designed so that decimal places can be added indefinately.
|
|
|
|
nanotube
|
|
November 20, 2010, 11:29:13 PM |
|
The clients simply display the values with a decimal point in the middle of the base 10 translation of the integer, as there are 8 decimal places to each side of the display. Changing that might prove to be a breaking change, and may not be an easy one.
Actually I think i remember Satoshi or Gavin saying that it actually is a quite easy change as bitcoin was designed so that decimal places can be added indefinately. Yes that has been my understanding as well... though I certainly haven't actually looked at any code to confirm.
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1056
|
|
November 21, 2010, 10:05:59 AM |
|
Actually I think i remember Satoshi or Gavin saying that it actually is a quite easy change as bitcoin was designed so that decimal places can be added indefinately.
An authoritative link would be really good, because this issue keeps coming up and it would be nice to have it answered once-and-for-all in the FAQ.
|
|
|
|
Gavin Andresen (OP)
Legendary
Offline
Activity: 1652
Merit: 2226
Chief Scientist
|
|
November 21, 2010, 02:08:42 PM |
|
Actually I think i remember Satoshi or Gavin saying that it actually is a quite easy change as bitcoin was designed so that decimal places can be added indefinately.
Wasn't me. I don't remember Satoshi ever writing something like that, but I'm really good at forgetting things. I agree with ribuck, if we ever need more than 21quadrillion bit-atoms, encoding more using the unused high bits in the 64-bit number will work nicely. That would be a very nice problem to have.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1015
Strength in numbers
|
|
November 21, 2010, 05:30:19 PM |
|
Actually I think i remember Satoshi or Gavin saying that it actually is a quite easy change as bitcoin was designed so that decimal places can be added indefinately.
Wasn't me. I don't remember Satoshi ever writing something like that, but I'm really good at forgetting things. I agree with ribuck, if we ever need more than 21quadrillion bit-atoms, encoding more using the unused high bits in the 64-bit number will work nicely. That would be a very nice problem to have. No doubt. Right there with "Oh, no, will all of my yachts fit in my private bay?"
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1005
Bringing Legendary Har® to you since 1952
|
|
November 21, 2010, 08:16:58 PM |
|
Actually I think i remember Satoshi or Gavin saying that it actually is a quite easy change as bitcoin was designed so that decimal places can be added indefinately.
Wasn't me. I don't remember Satoshi ever writing something like that, but I'm really good at forgetting things. I agree with ribuck, if we ever need more than 21quadrillion bit-atoms, encoding more using the unused high bits in the 64-bit number will work nicely. That would be a very nice problem to have. No doubt. Right there with "Oh, no, will all of my yachts fit in my private bay?" More like "i wonder what colour should i paint my space shuttle ?".
|
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1099
|
|
January 31, 2011, 10:23:24 PM |
|
If there is to be any change, please change to use int64 integers with no decimal points at all.
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
jgarzik
Legendary
Offline
Activity: 1596
Merit: 1099
|
|
January 31, 2011, 10:51:03 PM |
|
If there is to be any change, please change to use int64 integers with no decimal points at all.
UPDATE: After discussion on IRC, I think the change should be to represent "10.0" as a JSON string. That will successfully (a) avoid JSON implementations' int limitations, while achieving the goal of (b) never use floating point to represent bitcoin amounts.
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
doublec
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
January 31, 2011, 11:18:52 PM |
|
That will successfully (a) avoid JSON implementations' int limitations, while achieving the goal of (b) never use floating point to represent bitcoin amounts.
Won't this just move the problem to clients of the JSON interface? They'll either write their own buggy string to float/float to string implementations or use the one in the programming languages standard library which probably does a lossy conversion. How about providing additional JSON parameters for numerator/denominator so the amount can be expressed accurately as a rational number for those that what the safety.
|
|
|
|
wobber
Legendary
Offline
Activity: 1064
Merit: 1001
|
|
February 01, 2011, 02:19:21 PM |
|
I propose this notation, with something like a dropdown menu "UNIT OF BTC TO SEND". It would be easier than counting zeros if someday 1 BTC = 1000 USD and I want to send 1 cent , 0.00001 BTC
1 BTC = 10 dBTC (deci bitcoin) = 100 cBTC (centiBTC) = 1000 mBTC (miliBTC) = 10E-6 µBTC
|
If you hate me, you can spam me here: 19wdQNKjnATkgXvpzmSrkSYhJtuJWb8mKs
|
|
|
fergalish
|
|
February 02, 2011, 11:15:49 AM |
|
How about we call them "millibits", "microbits" etc. Or, if you imagine how "BTC" might be pronounced, we could call them millibitch etc. So if you buy a car, it'll cost you 100 bitches :-)
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1005
Bringing Legendary Har® to you since 1952
|
|
February 02, 2011, 04:03:35 PM |
|
I propose this notation, with something like a dropdown menu "UNIT OF BTC TO SEND". It would be easier than counting zeros if someday 1 BTC = 1000 USD and I want to send 1 cent , 0.00001 BTC
1 BTC = 10 dBTC (deci bitcoin) = 100 cBTC (centiBTC) = 1000 mBTC (miliBTC) = 10E-6 µBTC
I already proposed something like this before, but easier to read, as "normal" people don't know the mathematics/physics prefixes. 1 BTC0 = 1 BTC 1 BTC1 = 0.1 BTC 1 BTC2 = 0.01 BTC 1 BTC3 = 0.001 BTC 1 BTC4 = 0.0001 BTC Or with some adjustments: 1 BTX0 = 1 BTC 1 BTX1 = 0.1 BTC 1 BTX2 = 0.01 BTC Or: 1 BTC-0 = 1 BTC 1 BTC-1 = 0.1 BTC 1 BTC-2 = 0.01 BTC Or: 1 BT0 = 1 BTC 1 BT1 = 0.1 BTC 1 BT2 = 0.01 BTC Or something like that.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1005
Bringing Legendary Har® to you since 1952
|
|
February 02, 2011, 04:05:55 PM |
|
Going back to the topic - it seems that we will be reaching parity soon, so perhaps default maximum decimal places should be changed to 0.001 BTC.
Also, I propose that the number of decimal places could be set somewhere in the GUI application for convenience.
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1056
|
|
February 02, 2011, 04:13:01 PM |
|
Also, I propose that the number of decimal places could be set somewhere in the GUI application for convenience.
I don't think this is needed (contrary to what I suggested previously). If a transaction uses more than 2 decimal places, show them all. For everything else, show 2 decimal places. The "Send Coins" dialog already doesn't use any specific number of places. For ease of use, I would suggest that decimals after the first two are shown smaller. This keeps it intuitive for new users, because the main digits are more like "bitdollars and bitcents". Of course, the fee structure would need to be adjusted in the client. There's no point allowing people to send 0.001 BTC if it's going to cost them 0.01 BTC with the fees. Why not just have a maximum fee of 0.001 BTC for every transaction? Why should "dust" be charged any differently to "bullion"?
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1005
Bringing Legendary Har® to you since 1952
|
|
February 02, 2011, 04:25:27 PM |
|
Why not just have a maximum fee of 0.001 BTC for every transaction? Why should "dust" be charged any differently to "bullion"?
Not a bad idea, but this value cannot be static. It should be adjusted automatically somehow, because otherwise fees will be too high as soon as bitcoin gains more value. So i guess that if you can propose a very good algorithm for determining what the minimum fee should be, then this idea could have sense.
|
|
|
|
ribuck
Donator
Hero Member
Offline
Activity: 826
Merit: 1056
|
|
February 02, 2011, 04:52:45 PM |
|
Why not just have a maximum fee of 0.001 BTC for every transaction? Why should "dust" be charged any differently to "bullion"?
Not a bad idea, but this value cannot be static. Of course I agree with you, but 0.001 would be a workable default for now. As I understand it, fees work like this: - The client offers a maximum fee.
- The generator can choose to process the transaction or not. If it processes the transaction, it can charge any fee between zero and the limit specified by the client.
- The block must be accepted by the majority of the network for the fee payment to "stick".
Feel free to set me straight if there's more to it than that.
|
|
|
|
Hal
VIP
Sr. Member
Offline
Activity: 314
Merit: 3954
|
|
February 03, 2011, 01:35:43 AM |
|
This is how I understand transaction fees to work:
- the client offers a fee by creating a tx with a "surplus", ie. the input amount is greater than the output amount
- when a miner creates a block he can create a transaction paying himself up to 50 btc plus the sum of all the tx fees in the block
The miner doesn't have to pay himself that much but the tx fees are lost anyway.
|
Hal Finney
|
|
|
|