More divisibility required - move the decimal point

[ribuck]

Complicating the payment UI would suck. Right now it's nice and simple. Destination + amount. Can't get easier to understand than that.

The payment UI should stay simple. Of course. Simplicity is essential if Bitcoin is to spread to less technical people.

A transaction fee field is already present in the UI (click "Settings | Options"). I don't know whether it has any effect in the current release.

[nelisky]

I'm not saying we should complicate anything. Actually, all this should be transparent to the user, with at most a simple fee/priority option, and *maybe* a notice that 'maybe you should include a fee' when last block was topped up, or something.

What I am saying is that with the current implementation there is a chance a tx stays in limbo forever, by being back logged by miners consistently. Hence the proposal for a default 'allow X free tx in each block' structure. Of course I run my own version of bitcoin and can hardcode whatever I feel like, but most casual miners make up most of the network, I guess.

[Hal]

Lots of good ideas here!

I like Gavin's idea to display full precision in the UI and allow it on payments.

I like ribuck's terminology: 100 bitcents in a bitcoin, 1000 millicents in a bitcent, 1000 microcents in a Millicent.

I like [mike]'s suggestion to allow miners to store information relating to costs and policies, and to adapt network behavior from that information. I'd suggest using it specifically to normalize the "anti-spam" limits: the 0.01 minimums for large-transaction fees and for free transactions. Clearly Bitcoin needs a way to adjust these values, and Mike's proposal seems like a good candidate.

I also wonder if the anti-spam rule shouldn't be changed, to trigger if the largest output is tiny, rather than for any output. In Gavin's example, outputs of 1.5 and 0.000001 change seem ok to me.

[theymos]

I like supporting full precision in the UI and fixing coin selection.

The fees for generators should reflect actual costs, but I don't like the idea of hard-coding this. It should be user-selectable, and relaying fee requirements should be removed (or reduced and also user-selectable).

0.001 BTC is a good default fee. Amazon S3 charges $0.140 per GB if storage and $0.100 per GB of bandwidth. Even 0.0001 BTC per KB would be significantly higher.

[ShadowOfHarbringer]

I like supporting full precision in the UI and fixing coin selection.

Coin selection would be an awesome thing.
It would allow more privacy for BTC users.

[Cusipzzz]

I like supporting full precision in the UI and fixing coin selection.

The fees for generators should reflect actual costs, but I don't like the idea of hard-coding this. It should be user-selectable, and relaying fee requirements should be removed (or reduced and also user-selectable).

0.001 BTC is a good default fee. Amazon S3 charges $0.140 per GB if storage and $0.100 per GB of bandwidth. Even 0.0001 BTC per KB would be significantly higher.

agree with all of this, especially coin selection.

[jon_smark]

I suggest the following:

One bitcoin equals 100 bitcents
One bitcent equals one thousand millicents
One bitcent equals one million microcents

By subdividing the bitcent rather than the bitcoin, we neatly end up with a name for the tiniest piece of bitdust, i.e. 1/100000000 of a bitcoin.

No doubt in time nicknames would arise for these small units. I like "austrian" and "satoshi" as possible nicknames

That's an interesting proposal, but I have one strong argument against it: the mixing of a three-order of magnitude scale (1 bitcent = 10^3 millicents = 10^6 microcents) with a two-order scale (1 bitcoin = 100 bitcent) is almost guaranteed to lead to confusion down the road.  Moreover, the fixation on cents is largely an artifact derived from the current versions of the Bitcoin GUI using by default two decimal places.  Should a future version switch to a three decimal default (a move I think is wise) then this anchoring on cents will go away.

We should pick a scale that uses a uniform jump in orders of magnitude all the way from the tiniest amount to the largest. And the number of orders of magnitude should be three, since it's the one most familiar to people. Granted, speaking of millicoins and microcoins could get tiresome, so choosing nicknames for the multiples and submultiples is a good idea.  I agree that "Satoshi" is a good candidate, but I'll have to disagree with you on the "Austrian"... :-)

My suggestions:

1 satoshi = 1000 BTC
1 BTC = 1000 koishi  ('koishi' being Japanese for 'pebble')
1 koishi = 1000 suna  ('suna' being japanese for 'sand')

[ShadowOfHarbringer]

That's an interesting proposal, but I have one strong argument against it: the mixing of a three-order of magnitude scale (1 bitcent = 10^3 millicents = 10^6 microcents) with a two-order scale (1 bitcoin = 100 bitcent) is almost guaranteed to lead to confusion down the road.

Well, i had other proposals.

Code:

1 BTCX0 = 1 BTC
1 BTCX1 = 0.1 BTC
1 BTCX2 = 0.01 BTC
1 BTCX3 = 0.001 BTC
1 BTCX4 = 0.0001 BTC

or

Code:

1 BTCA = 0.1 BTC
1 BTCB = 0.01 BTC
1 BTCC = 0.001 BTC
1 BTCD = 0.0001 BTC

or

Code:

1 BTC-0 = 1 BTC
1 BTC-1 = 0.1 BTC
1 BTC-2 = 0.01 BTC
1 BTC-3 = 0.001 BTC
1 BTC-4 = 0.0001 BTC

...and variations of above.

Yeah i agree - it's not very good looking, but I think it's the most intuitive and probably one of the most logical solutions.
Using it we can avoid a lot of mess.

[grondilu]

Will satoshi be back to sign the tarball if gavin increases the decimal precision?

I'd feel much more comfortable if it's satoshi who stays in charge for this.

[jgarzik]

Will satoshi be back to sign the tarball if gavin increases the decimal precision?

satoshi never signed any tarballs.  He posted SHA1 signatures, but anyone can do that.

Ideally, gavin or satoshi or whomever will post SHA1 signatures of 0.3.20 release inside a PGP-signed message.

[LZ]

I do not think that we really need values less then 0.01 BTC right now.
But on the other hand, of course, if you got 0.001 - UI should show it.

[FatherMcGruder]

I think it would be nice if the client would calculate the probability of a transaction going through in the next block for a given transaction fee, as specified by the user. The user would then have the necessary information to select a suitable fee.

[ribuck]

Here's how I think small amounts could be shown on the user interface, to minimise confusion:



The digits are grouped into milli-cents and micro-cents, and are shown smaller than the usual "bitcoins and bitcents".

The advantages of this scheme are that it preserves the familiar "dollar-and-cents" type notation with two digits after the decimal point, yet allows for all of the available precision to be displayed when needed. The groups of three digits help to make these amounts easier to read.

[marcus_of_augustus]

Around the mid-1800's in San Fran mining town you could get a clam chowder for 5 cents
http://www.foodtimeline.org/foodpioneer.html#provisionprices

In Zimbabwe recently they were trading trillions for pints of milk (before it collapsed completely) ...
... decimal divisions are arbitrary ... people will pay X number of something's if that is what is familiar.

[Local]

Here's how I think small amounts could be shown on the user interface, to minimise confusion:



The digits are grouped into milli-cents and micro-cents, and are shown smaller than the usual "bitcoins and bitcents".

I like it.

[ShadowOfHarbringer]

Here's how I think small amounts could be shown on the user interface, to minimise confusion:



The digits are grouped into milli-cents and micro-cents, and are shown smaller than the usual "bitcoins and bitcents".

I like it.

+1

[Luke-Jr]

Reminder that we already have a URI specification that defines a format for safely representing any BTC (or TBC) value in a human-readable way. 100 BTC is represented as 100X8 (for 8 places beyond the decimal point). It could just as well be used for 1X4 (for 0.0001 BTC) or even 1X0 (for a single base unit).

That being said, more human-friendly names/units are still appropriate. Base unit / 10000 could be named "DBC" (but then how would you pronounce it?), or possibly it might be better to just stick with the existing SI units and use mBTC (milli-bitcoin; 0.001 BTC) or μBTC (micro-bitcoin; 0.000001 BTC).

[ShadowOfHarbringer]

or possibly it might be better to just stick with the existing SI units and use mBTC (milli-bitcoin; 0.001 BTC) or μBTC (nano-bitcoin; 0.000001 BTC).

This creates another problem. You have mili-btc, which is easy enough, but what about 0.0001 BTC and 0.00001 BTC ?

Reminder that we already have a URI specification that defines a format for safely representing any BTC (or TBC) value in a human-readable way. 100 BTC is represented as 100X8 (for 8 places beyond the decimal point). It could just as well be used for 1X4 (for 0.0001 BTC) or even 1X0 (for a single base unit).

You mean something like this but kind of - reversed ?

1 BTCX0 = 1 BTC
1 BTCX1 = 0.1 BTC
1 BTCX2 = 0.01 BTC
1 BTCX3 = 0.001 BTC
1 BTCX4 = 0.0001 BTC

[Luke-Jr]

or possibly it might be better to just stick with the existing SI units and use mBTC (milli-bitcoin; 0.001 BTC) or μBTC (nano-bitcoin; 0.000001 BTC).

This creates another problem. You have mili-btc, which is easy enough, but what about 0.0001 BTC and 0.00001 BTC ?

Oh well, yet another reason decimal/SI sucks I guess. Switch to Tonal, or suffer with mdBTC (milli-deci-)?
(or just use 100 μBTC or 0.1 mBTC)

Reminder that we already have a URI specification that defines a format for safely representing any BTC (or TBC) value in a human-readable way. 100 BTC is represented as 100X8 (for 8 places beyond the decimal point). It could just as well be used for 1X4 (for 0.0001 BTC) or even 1X0 (for a single base unit).

You mean something like this but kind of - reversed ?

1 BTCX0 = 1 BTC
1 BTCX1 = 0.1 BTC
1 BTCX2 = 0.01 BTC
1 BTCX3 = 0.001 BTC
1 BTCX4 = 0.0001 BTC

Right. Introducing a new "BTCXn" would totally confuse things with the existing URI scheme probably.

[ShadowOfHarbringer]

Right. Introducing a new "BTCXn" would totally confuse things with the existing URI scheme probably.

That would be not for the URI scheme, but just for general use.