When to "move the decimal points" ?

[asdf]

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.

[1714015831]

1714015831

[1714015831]

1714015831

[1714015831]

1714015831

[1714015831]

1714015831

[1714015831]

1714015831

[1714015831]

1714015831

[bitcoinex]

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"

[ribuck]

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]

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]

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]

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]

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.

[FreeMoney]

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?"

[ShadowOfHarbringer]

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]

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

[jgarzik]

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.

[doublec]

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]

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

[fergalish]

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]

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]

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]

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]

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]

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]

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.