More divisibility required - move the decimal point

[RHorning]

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.

On this point, I strongly disagree.  When the "anti-spam" limit of 0.01 BTC was first put in to stop petty transactions, the value of 0.01 BTC was about a 20th of a cent.  That still allowed experimentation with microtransaction concepts with Bitcoins.... which now is mostly impossible.

The problem is that the protocol doesn't have any mechanism to adjust if the value of Bitcoins appreciates relative to other currencies, and I don't know of a reasonable way to make that happen either.

Right now, the "official client" that almost everybody has puts in a minimum transaction fee of 0.01 BTC if you attempt to send less than 0.01 BTC.  In effect, this is the absolute hard minimum transaction that can be sent using the reference implementation of the software.  Instead of being a trivial amount, that is now worth at least $0.01 dollars and is likely to go up.  Assuming the current rate of deflation of Bitcoins continues, that may soon be worth $0.10 dollars, and I can see that within a year or two as high as a dollar in value for 0.01 BTC.

This is a problem, and it could be a big one.  Yes, a patch can be done to solve this "problem" and alternate implementations of the software can be used to "solve" the issue too so it isn't as big of a deal as it would seem, but you can't use the current software to send those smaller amounts.  Miners may or may not accept these smaller transactions, but it is a client-side user interface issue and a presumption that shouldn't have been put into the client-side software in the first place.

The client user interface needs to have full control over transaction fees.... both for what that node will pay to initiate a transaction as well as what fees it will accept if it "wins" a block.  Burying this all in the source code on some high minded presumption of what you think the value of Bitcoins ought to be is pure bunk and something that ought not be there.  If somebody like lzsaver wants to refuse to deal with petty amounts less than 0.01 BTC when he is mining, that is his privilege... but it shouldn't be forced upon the community in an artificial manner as it is right now where this is the absolute minimum transaction which can take place.

Acceptance or rejection of a transaction belongs with the miners and I'm fine with that.  My issue is the presumptions put into the clients that are commonly spread throughout the community.  If it doesn't get changed, it will spawn a bunch of "alternative clients" that will put in the necessary changes.

Then again, that may be a good thing if the current reference implementation is simply abandoned.  If so, may it rest in peace, but that is a completely different topic here.  Giving developers a strong reason to fork Bitcoin could be useful.

[1714039093]

1714039093

[1714039093]

1714039093

[1714039093]

1714039093

[1714039093]

1714039093

[Mike Hearn]

Yes, the 0.01 minimum is a hack. The easiest fix is to just adjust it downwards in the next release. Better solutions are being discussed in other threads.

[Hal]

The problem is this code in main.h:GetMinFee(), called from main.cpp:AcceptToMemoryPool()

601           // To limit dust spam, require a 0.01 fee if any output is less than 0.01
602           if (nMinFee < CENT)
603               foreach(const CTxOut& txout, vout)
604                   if (txout.nValue < CENT)
605                       nMinFee = CENT;


This will prevent clients from forwarding transactions with outputs < 0.01 btc. We can change this rule but not everyone upgrades so lower value transactions will propagate unreliably for months.

I suggest we figure out how to fix this once and for all, put in the new rule but set it to trigger only as of some block number in the future, and meanwhile do something cool in the client so people will want to upgrade before the rule change.

[theymos]

I think we could just remove the special "dust spam" fee and rely on the priority mechanism. Then "dust" would only be allowed in the first 27k of a block, and non-dust would usually be given priority in that area.

The -limitfreerelay switch can be enabled by default to protect relay nodes from dust spam.

[LZ]

I think that we can do anything, but it should be compatible with the first Bitcoin release. Test on testnet first.

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

But I do not think that it is good idea. I do not want to say something like "1 BTCX1" or "1 BTCX2". It is terrible.

[jgarzik]

I think we could just remove the special "dust spam" fee and rely on the priority mechanism. Then "dust" would only be allowed in the first 27k of a block, and non-dust would usually be given priority in that area.

I think this should be done -- because we will reach this end state eventually, anyway.

[schnak]

I think that we can do anything, but it should be compatible with the first Bitcoin release. Test on testnet first.

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

But I do not think that it is good idea. I do not want to say something like "1 BTCX1" or "1 BTCX2". It is terrible.

might want to give this a read...
http://bitcointalk.org/index.php?topic=3574.0

[lfm]

I think we could just remove the special "dust spam" fee and rely on the priority mechanism. Then "dust" would only be allowed in the first 27k of a block, and non-dust would usually be given priority in that area.

The -limitfreerelay switch can be enabled by default to protect relay nodes from dust spam.

One problem is it isn't always obvious what is and is not "dust" or "spam". Consider the following:

1. a NEW wallet receives a txn for 1.0001 BTC. This would have been created by some modified or custom client. It is currently accepted and propagated without problems by all nodes. It may or may be displayed as 1.00 in the receiver's UI or it may be correctly displayed a 1.0001. It depends exactly how it is viewed.

2. the user wishes to spend 1.00 BTC and tries to send it off.

3. this creates a txn with one input which is a reference to the old 1.0001 value and TWO outputs, the 1.00 that the user specified and the remaining 0.0001 as change. The two output are indistinguishable by any outside party including miners and could just as easily be a "dust" transaction sending 0.0001BTC and keeping the 1.00 as change for more dust or whatever.

4.The client will TRY to treat this as a regular dust txn and try to charge the "standard" 0.01 fee but there is no way in this case to perform that operation so it falls through to discarding the 0.0001 by throwing it away as a txn fee which only passes on the problem to the miner who collects the fee. There are some non standard txn created by modified clients already which produce variations on these rules.

5 the TXN is then sent out on the net for the miners to decide if they want to accept it or not. Currently I think most miner will only accept it if it includes some fee, even a factional cent fee. There is at least one current miner which is modified to accept such txn even without the fee now so the txn is not consigned to an infinite limbo.  Once a miner creates/finds a block with the txn included the block is sent out on the net.

6  currently any node will accept all transactions included in a block so long as they are not totally illegal/fraudulent.

I may have got some of this wrong but I think it is pretty close. I suppose I don't have to tell you to feel free to post your "corrections"

each of the steps 3, 4, and 5 would need some changes for this proposal.

[ribuck]

One problem is it isn't always obvious what is and is not "dust" or "spam".

Quite apart from the technical difficulties of distinguishing spam, one person's spam is always another person's ham. Bitcoin should be free of value judgements. Any transaction fee should be independent of transaction value.

[imanikin]

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.

+1
For this generation of Bitcoin users, who are accustomed to  1/100 being the smallest unit, this does seem like the most practical approach. Future generations can always use something else, IF Bitcoin is still around then...

[imanikin]

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

+1

[TiagoTiago]

What would happen if the fee associated with a transaction was used for prioritizing that transaction like this: on a node with no other transaction in the queue a transa with no fee at all would get processed, but if before it is done another transa arives with a 0.00000001 fee, that one would get processed, if another with 0.00000001 arives it goes to the queue, then if one with a whole Bitcoin for fee arives that one gets processed; transactions with the same fee get processed on a first come first served based, transactions with higher fees are given priority over ones with lower fees.


(erm where i'm supposed to put the question mark there?)

[gigitrix]

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

+1

+1. This is genius and unobtrusive.

Also, clients should set fees automagically (based on perceived load, maybe even from fees of nodes around) BUT it MUST let 1337 h4xx0rs change this value from the interface, should they want to.

[Alex Beckenham]

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.

-1

I don't like the idea of 'preserving the familiar'. If we did that, America would still be using feet and inches... oh, wait.

[Luke-Jr]

I don't like the idea of 'preserving the familiar'. If we did that, America would still be using feet and inches... oh, wait.

Feet and inches are far better than the common alternative of metres. The latter is based on decimal, one of the worst possible radices, and has only ever been adopted by force. America deserves credit for not forcing people to use an inferior system.

[Alex Beckenham]

Haha no worries, have fun with your superior system.

Anyway, still prefer SI notation for currency divisions.

[grondilu]

Oh come on...

Money is not part of the International System, but for godness sake, decimal units are part of the way almost everyone in this world is counting numbers.

So a number such as 12.94388439 should not be confused with anything in any unit we are talking about.

Only people who are very, very unfamilar with numbers could have a problem with that.

[MoonShadow]

I don't like the idea of 'preserving the familiar'. If we did that, America would still be using feet and inches... oh, wait.

Feet and inches are far better than the common alternative of metres. The latter is based on decimal, one of the worst possible radices, and has only ever been adopted by force. America deserves credit for not forcing people to use an inferior system.

Amen to that, but America the government has actually tried.

[TiagoTiago]

Are you just being amusing, or do you really see any benefits in those crazy backwardds units?

[Luke-Jr]

Are you just being amusing, or do you really see any benefits in those crazy backwardds units?

Metric/SI is the backward units. Decimal really does suck. Seriously, just look at history: people naturally see the benefit of, and move toward, bases 6*2 and 8*2, DESPITE writing them in base 5*2. People only go back to base 5*2 units when forced. It's obvious which is superior. Now the question is, why do people still use base 5*2 for writing?