More divisibility required - move the decimal point

[goblin]

Hi,

With the latest price jumps, one bitcent is now worth more than the american currency's lowest divisible unit - cent. It's also been the case for other currencies for a while already.

I believe this is the correct time to increase bitcoin's divisibility - i.e. move the decimal point right by one, or something similar.

The transaction fee could also be decreased in the process - e.g. to 0.001 bitcoin for oversized transactions, but that's maybe not a very good idea due to possible spam. Perhaps charge 0.001 for transactions less than 0.001, and charge around 0.005 for oversized transactions?

That should allow more possibilities for representation of real-world currencies.

[1714207765]

1714207765

[1714207765]

1714207765

[1714207765]

1714207765

[1714207765]

1714207765

[1714207765]

1714207765

[ShadowOfHarbringer]

+ 1
Definately agreed.

[fabianhjr]

I agree + the fees aren't really necesary.

[Gavin Andresen]

I wonder how much a bitcoin transaction actually costs, in terms of bandwidth and disk space on everybody's machines.

If nobody beats me to it, I'll try to do a back-of-the-envelope calculation later today.

[goblin]

I agree + the fees aren't really necesary.

The fees are definitely necessary to prevent spam.

Gavin: yeah, would be cool to know, but that value will keep changing as the price increases ;-) Also, might be a bit hard... because the more users, the more diskspace and bandwidth is used... so a transaction cost to the whole network would have to include number of nodes involved. I wouldn't even know how to approach such a calculation :-S

Ideally of course we want the user to be able to set the details like transaction fees and decimal point position in some 'settings' dialog...

[Mike Hearn]

It's easy to say "let's just move the decimal point". But this part of BitCoin is unusual in that it has not been well thought out by Satoshi in advance. Given he is absent, I guess it's up to us to come up with a good plan.

What does this mean? Effectively, it means we need global consensus on where the decimal point should be. If some people move it and others don't, it becomes difficult to trade because prices and payments become hopelessly confusing.

BitCoin is already very good at establishing global consensus on things. So how about this plan:

1) bitcoind gets a new RPC called "getNanosPerCoin" or something like that which returns the number of nanocoins that make up the arbitrary unit we call a "bitcoin".

2) Everyone who mines can configure their copy of BitCoin to say where they think the decimal point should be. This data could be embedded into the coinbase transaction. I'd have to check the code carefully but I think it's possible to stuff arbitrary extra data onto the end of the coinbase tx and not have the client complain or reject the block. Adding a regular new field means bumping the version number and I think that might be difficult, so what I'd suggest is if we do start appending stuff to the coinbase.in[0].scriptSig that it be a protocol buffer or some other binary data structure that supports versioning built in. Otherwise we might want to do it again later and find it hard.

3) At the end of each two week adjustment period, the client scans backwards to calculate the new nanosPerCoin based on the collective votes of the network. If >80% of the network agree on a new value for nanosPerCoin then the BitCoin client accepts this and begins reporting it in the RPC.

4) Existing software that renders "X.Y BTC" type strings would have to be changed to fetch the current nanosPerCoin value from a server somewhere. To make this simpler perhaps the JSON RPC port could accept an unauthenticated HTTP request like

http://server:1234/renderAmount?nanocoins=15000000,300000&style=unicode

and return a nicely formatted string like "Ⓑ15.00\nⒷ0.03" as a text/plain UTF-8 response. This HTTP call can just be wrapped into library functions in most languages so rendering BitCoin amounts wouldn't be too difficult, and it could be exposed via bitcoin.org so websites could simply say

Code:

<script src="http://www.bitcoin.org/render-amounts.js"></script>

This will cost you <script>bitcoin.render(15000000)</script>

and it would print out the amount as agreed on by the consensus. If stating "true prices" in terms of nanocoins is too inconvenient, prices could be specified as a natural amount and a date:

Code:

This will cost you <script>bitcoin.render(1.50, "2011-02-10 17:00:00 UTC")</script>

So when the decimal point moves this would then be rendered as Ⓑ15.00 automatically.

[goblin]

Thanks mike for an insightful reply.

Of course it's very easy to just say "let's just move the decimal point" - that's why I said it ;-) I do realize it's quite an amount of change in the current implementation.

What you propose is interesting - basically we make the block generators put their votes.

I disagree with one thing, however - after moving the decimal point, we SHOULD NOT re-render 1 000 000 nanocoins from 0.01 to 0.10. That would cause an insane amount of confusion - people who had 0.01 bitcoins on their accounts suddenly would now have 0.10? Why? No, I think they should still have 0.01, just be able to trade with 0.001 precision from now on.

The voting system you propose is nice - I think it could be used for other types of voting too...

But thinking about it, what is it that we're really adjusting here? It's not anything network-related, really. It's just presentation at the end user, i.e. the client showing 3 decimal places instead of 2. That's why I said ideally, it should be just a per-client setting that could be altered by the end-user. Same with transaction fees - they should be set by the miners. Perhaps a vote or a forum or a "default" value provided by the mainstream client could be used as a suggestion, but in the end, the prices should be set by users, not by coders.

[jon_smark]

Perhaps I'm missing something, but is this really a proposal for moving the decimal point (ie, 1 old BTC = 10 new BTC) or do you mean a proposal for increasing the precision exposed to the user (ie, 1.00 BTC => 1.000 BTC)?  Let's get our terminology correct, people!

Personally, I think the former option (revaluing the currency) can be much more confusing and traumatic than the latter.  Besides, if the value of the unitary BTC continues to climb in such a manner that smaller and smaller amounts become more practical, then the only thing that should be changed is the way values are exposed in the user interface: instead of showing amounts in BTC, the GUI could switch to mBTC (milliBTC).  Perhaps there may even come a time when talking in μBTC (microBTC) will become useful, not mention nBTC (nanoBTC).  In fact, it is a shame that "only" 8 decimal places were chosen.  Picking 9 would have made the smallest Bitcoin unit exactly 1 nBTC.

[jon_smark]

(Just noted that goblin posted an argument similar to mine closely before mine. It seems we are in agreement).

[ribuck]

It's out of the question to literally move the decimal point, and goblin didn't mean it literally.

Two things we can do are to (a) expose more of the existing precision in the user interface, and (b) see if we can agree on terminology and notation.

We have previously discussed notation without an apparent conclusion. I would like to suggest an alternative notation that has not yet been proposed.

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

[goblin]

It's out of the question to literally move the decimal point, and goblin didn't mean it literally.

sorry yeah I accidentally caused confusion. I didn't mean to move the decimal point, I meant to increase the decimal precision. And decrease the transaction fee for transactions less than 0.01 so that it's possible to actually make use of that change.

[Mike Hearn]

Yes, lowering the fee is useful but it can be done today. It doesn't solve the problem of ending up with prices like "0.0001 BTC for a pair of socks".

Switching the rendering of a price by shifting the decimal point is no different than simply using a different suffix. You just have to pick your poison. Would you rather that from time to time the decimal point moves, or that somebody exchanges $100 and gets 0.90 BTC in return and is then faced with a price of 1uBTC?

You don't think that'll confuse people? The whole "verizon math" episode proved that many, many people (in the USA at least) don't seem to understand the concept of a fractional cent. When faced with an amount clearly written as $0.002 they pronounced it "zero point zero zero two cents" even though it was actually 0.2 cents.

[Gavin Andresen]

WAY too many issues being mixed up here...   I'm sorry I ever framed this as "moving the decimal point"

I think the next release of Bitcoin should:

+ Show full-precision bitcoins in the GUI.  If you have 1.5 BTC, it will display as it does now ("1.50").
  If you have 1.50001 BTC, it will display the extra precision.

+ Allow you to send full-precision from the GUI and from JSON.  If you have 1.500001 BTC, you will see
  you have that many and can send that many.

+ Incorporate luke-jr's patch to avoid losing "dust change", when possible.  (e.g. if you have received transactions of 1.5000001 and 20 BTC, and then send 1.5, Bitcoin shouldn't choose just the 1.5000001 input transaction).

Those issues are being driven by pooled mining-- a lot of people are getting sub-cent bitcoins from their pooled mining shares.


Then there's the issue of "what is a micro-transaction for which you should be forced to pay a fee."  Currently, it is any transaction with an output less than 0.01 BTC.

And the issue of "what is the minimum fee" (also currently 0.01 BTC).

Ideally, transaction fees should reflect real-world costs... although just making them hidden costs that are spread between everybody running bitcoin might work perfectly well.  Still, I'd like to get a rough idea of the real-world cost of a transaction.


It is too early to be worried about "paying 0.001 bitcoins for a pair of socks".

[davout]

Then there's the issue of "what is a micro-transaction for which you should be forced to pay a fee."  Currently, it is any transaction with an output less than 0.01 BTC.

And the issue of "what is the minimum fee" (also currently 0.01 BTC).

As you know, there is no such thing as transaction for which you are forced to pay a fee.
There are, however, transactions that won't get relayed by the standard client due to the fact that they're probable spam.

We should just put a setting for the user to decide what the minimum amount a transaction should have in order not to be considered as spam, and included in mined blocks.

[Gavin Andresen]

We should just put a setting for the user to decide what the minimum amount a transaction should have in order not to be considered as spam, and included in mined blocks.

Okey doke.  And the default value should be.... ?

[Mike Hearn]

The point of the fee is to avoid somebody monopolizing the networks resources with tons of tiny transactions. The primary expense of receiving a transaction is the ECDSA verification and the disk IO associated with storing it. So maybe nodes should adapt the fee they charge according to their spare capacity.

When a node receives a transaction, it could insert it into a list of pending transactions sorted by the fees they provide. The client could check how much physical free RAM it has and if it looks like it might be about to run out, it could just drop some low value transactions from the end of the list (you don't want to start swapping).

In this way the network would adapt to its available CPU/IOP capacity automatically. If the network started to be DoSd then legitimate users could start providing a fee larger than the DoS transaction fees, regardless of how small that was.

It's also possible I guess to exhaust raw network capacity, but the client protocol could be upgraded to have a "pushback" command that'd say "don't relay transactions to me unless they include a fee >x".

BTW I worry about the decimal point/rendering issue, because by the time it does become a problem it'll be too late to have a global solution in place and we'll be stuck with hacks like pricing things in uBTC and having to constantly do the conversions in your head, which will suck.

[ribuck]

The point of the fee is to avoid somebody monopolizing the networks resources with tons of tiny transactions.

And what about somebody monopolizing the network's resources with tons of larger transactions (being sent back-and-forth between two nodes)?

Why not keep it simple? Allow the user to specify a fee to be sent with every transaction. In the user interface, set the default fee to zero, but let the user override it "to insure promptness".

[nelisky]

Say all miners enforce fees (which is unlikely right now, but still). I send a transaction without fees, does it get accepted but kept in backlog? If so can it be cancelled, does it timeout?

Reasoning is in a high volume situation I may send a "free" transaction but it may be ignored by miners for a long time, as most other transactions have non zero fees. This is all good, I can resubmit my transaction with a fee so it gets processed, but what with the original "free" request?

As a miner myself, I'd say I would never attach more than a certain (low) number of free transactions on my newly found blocks. This rule would allow the free transactions, but prevents spam from taking down the network without cost.

In fact, why not a default increasing fee structure for block transactions in miners? Each block would take 10 free tx, 10 @ 0.001, 10 @ 0.01, etc (10 is just a number, substitute with whatever makes sense). Then the market forces would keep this structure fair, I guess.

[Mike Hearn]

Well that is simple for the implementors but complicated for everyone else. What should a user put in that box, if they are just a plain old user who doesn't have knowledge of transient network load?

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

Once we start requiring users to provide magic numbers when paying, it'll have to percolate through to all kinds of other places like the ClearCoin UI, merchant stores etc. And what that number should be will remain mysterious. People would just get used to the fact that it's always zero and when a DoS attack starts, most people wouldn't understand they suddenly need to increase it, nor would they know what to increase it to. They'd just notice that merchants were refusing to sell them things even though they sent the coins.

If there is an adaptive fee then nodes can make a "best guess" based on their own load. It'd mean displaying it to the user and the number would be "magic" in that it'd move up and down due to forces beyond their understanding, but in some senses you can argue that VAT is similar :-) More importantly they wouldn't have to know anything or think beyond "is this fee acceptable to me".

Now if/when fees become the primary economic incentive to mine.... that's a bit harder. I guess you'd need some way that miners could communicate their minimum acceptable fee to nodes so they don't get stuck sending transactions with insufficient fees and users don't understand why they never confirm.

[Mike Hearn]

And what about somebody monopolizing the network's resources with tons of larger transactions (being sent back-and-forth between two nodes)?

I think coins have what somebody called a "cool down period" so to spam the network with lots of large transactions you'd need to have a lot of value to play with (as in spend lots of $$$ to obtain all the needed coins or whatever). Otherwise it'd be much harder to get up to a rate where you were breaking the network, which is the point of a DoS attack.

It'd be interesting to try and DoS the testnet (or a 3rd separate network).