Bitcoin Forum
September 25, 2016, 02:00:20 AM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 6 »  All
  Print  
Author Topic: When to "move the decimal points" ?  (Read 16071 times)
asdf
Hero Member
*****
Offline Offline

Activity: 527


View Profile
November 20, 2010, 12:13:58 AM
 #21


The 'max 8 decimal places' can stay for a while... Just my 0.0298723 BTC Cheesy

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.
1474768820
Hero Member
*
Offline Offline

Posts: 1474768820

View Profile Personal Message (Offline)

Ignore
1474768820
Reply with quote  #2

1474768820
Report to moderator
1474768820
Hero Member
*
Offline Offline

Posts: 1474768820

View Profile Personal Message (Offline)

Ignore
1474768820
Reply with quote  #2

1474768820
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350


probiwon.com


View Profile WWW
November 20, 2010, 03:42:52 AM
 #22


The 'max 8 decimal places' can stay for a while... Just my 0.0298723 BTC Cheesy

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 Smiley (or TeX)

Also we get a numbers with an absolute accuracy: "1/3 BTC"

New bitcoin lottery: probiwon.com
- Может, ты ещё и в Невидимую Руку Рынка веруешь? - Зачем же веровать в то, что можно наблюдать непосредственно?
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
November 20, 2010, 11:15:24 AM
 #23

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 Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
November 20, 2010, 03:42:52 PM
 #24

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
Hero Member
*****
Offline Offline

Activity: 485


View Profile WWW
November 20, 2010, 11:29:13 PM
 #25

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.

Join #bitcoin-market on freenode for real-time market updates.
Join #bitcoin-otc - an over-the-counter trading market. http://bitcoin-otc.com
OTC web of trust: http://bitcoin-otc.com/trust.php
My trust rating: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
November 21, 2010, 10:05:59 AM
 #26

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
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 21, 2010, 02:08:42 PM
 #27

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 Offline

Activity: 1246


Strength in numbers


View Profile WWW
November 21, 2010, 05:30:19 PM
 #28

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 Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
November 21, 2010, 08:16:58 PM
 #29

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 Offline

Activity: 1470


View Profile
January 31, 2011, 10:23:24 PM
 #30


If there is to be any change, please change to use int64 integers with no decimal points at all.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
January 31, 2011, 10:51:03 PM
 #31

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, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
January 31, 2011, 11:18:52 PM
 #32

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 Offline

Activity: 1050


View Profile
February 01, 2011, 02:19:21 PM
 #33

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
Sr. Member
****
Offline Offline

Activity: 440


View Profile
February 02, 2011, 11:15:49 AM
 #34

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 Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 02, 2011, 04:03:35 PM
 #35

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 Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 02, 2011, 04:05:55 PM
 #36

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
Legendary
*
Offline Offline

Activity: 826


View Profile
February 02, 2011, 04:13:01 PM
 #37

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 Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
February 02, 2011, 04:25:27 PM
 #38

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
Legendary
*
Offline Offline

Activity: 826


View Profile
February 02, 2011, 04:52:45 PM
 #39

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 Offline

Activity: 314



View Profile
February 03, 2011, 01:35:43 AM
 #40

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
Pages: « 1 [2] 3 4 5 6 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!