When to "move the decimal points" ? - page 5.

ribuck

donator

Activity: 826

Merit: 1060

Quote from: ShadowOfHarbringer on February 02, 2011, 11:25:27 AM

Quote from: ribuck on February 02, 2011, 11:13:01 AM

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.

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: ribuck on February 02, 2011, 11:13:01 AM

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

Activity: 826

Merit: 1060

Quote from: ShadowOfHarbringer on February 02, 2011, 11:05:55 AM

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

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

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.

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: wobber on February 01, 2011, 09:19:21 AM

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.

fergalish

sr. member

Activity: 440

Merit: 250

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 :-)

wobber

legendary

Activity: 1064

Merit: 1001

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

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: jgarzik on January 31, 2011, 05:51:03 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.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: jgarzik on January 31, 2011, 05:23:24 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.

jgarzik

legendary

Activity: 1596

Merit: 1100

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

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: FreeMoney on November 21, 2010, 12:30:19 PM

Quote from: Gavin Andresen on November 21, 2010, 09:08:42 AM

Quote from: ShadowOfHarbringer on November 20, 2010, 10:42:52 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.

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

FreeMoney

legendary

Activity: 1246

Merit: 1016

Strength in numbers

Quote from: Gavin Andresen on November 21, 2010, 09:08:42 AM

Quote from: ShadowOfHarbringer on November 20, 2010, 10:42:52 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.

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

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

Quote from: ShadowOfHarbringer on November 20, 2010, 10:42:52 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.

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.

ribuck

donator

Activity: 826

Merit: 1060

Quote from: ShadowOfHarbringer on November 20, 2010, 10:42:52 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.

nanotube

hero member

Activity: 482

Merit: 501

Quote from: ShadowOfHarbringer on November 20, 2010, 10:42:52 AM

Quote from: MoonShadow on November 19, 2010, 03:19:59 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.

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: MoonShadow on November 19, 2010, 03:19:59 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.

ribuck

donator

Activity: 826

Merit: 1060

Quote from: asdf on November 19, 2010, 07:13:58 PM

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.

bitcoinex

sr. member

Activity: 350

Merit: 252

probiwon.com

Quote from: MoonShadow on November 19, 2010, 03:19:59 PM

Quote from: nanotube on November 19, 2010, 03:00:05 PM

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

(or TeX)

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

asdf

hero member

Activity: 527

Merit: 500

Quote from: MoonShadow on November 19, 2010, 03:19:59 PM

Quote from: nanotube on November 19, 2010, 03:00:05 PM

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.

jimbobway

legendary

Activity: 1304

Merit: 1015

Using bitcoind server it's possible to send decimals under .01 right? I think the default bitcoin client should by default show .01 but it should be adjustable in the menu.

Topic: When to "move the decimal points" ? - page 5. (Read 17815 times)