+ 1
Definately agreed.

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.

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


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:


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

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.

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

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.

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.

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.

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.

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