Quote from: DannyHamilton on August 30, 2012, 05:32:58 PM

Quote from: Kazimir on August 30, 2012, 02:01:50 PM

. . . Current bitcoin clients support up to 8 decimals, and this can be increased further whenever the need arises . . . By definition, there is an infinite amount of units available.

I was under this same mistaken impression (and made a similar comment in https://bitcointalk.org/index.php?topic=102756.msg1128037#msg1128037) until I took a closer look at the blockchain layout. The blockchain doesn't use decimals to represent bitcoins, it uses integers representing satoshis. The bitcoin representation is just something that the client program does to display the value (the client takes the number stored in the blockchain and places a decimal 8 places to the left before displaying it. This means that we can't just "add more decimals". We would have to change what the number in the blockchain represents. There would be a upgrade time period during which some people might still be running software that used the old representation while others use software with the new representation. This would be a problem (one program sending 100000000 thinking that it is sending 1 BTC, and another program thinking that the amount it is receiving is only .01 BTC), and would require a hard fork in the blockchain. There are ways to deal with the situation, but it isn't as simple as "just add moar decimals!"

No different than the half dozen protocol enhancements which have occurred in the past. Nobody said it is as easy as MOAR decimals however it wouldn't be that difficult to implement. It would have a whole lots less risks than implementing P2SH did and that went off rather smoothly. The easiest way to prevent what you fear is to have a new transaction type (high precision tx). Non compliant nodes would see those transactions and blocks as invalid and not even attempt to process them.

IIRC Gavin had expressed interest in implementing protocol versioning and then using that in existing clients to en and version checking in client nodes. If that is done it would be even easier to extend the protocol. Older clients would be warned to upgrade, the developers would ensure there is sufficient hashing power to support the new protocol version. At a preset block compliant nodes & miners would switch to new protocol version. Older clients seeing the newer protocol blocks would warn the user.