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.

[1715606542]

1715606542

[1715606542]

1715606542

[1715606542]

1715606542

[1715606542]

1715606542

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

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

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

[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?

[FatherMcGruder]

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?

You mean the use of base ten has nothing to do with the fact that most people have five digits on each of their two hands, that we will "naturally see the benefit of, and move toward" not counting our thumbs?

[Prze_koles]

1.0000 would be enough precision at the moment IMO

[MoonShadow]

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

In the course of my life I've had to use both systems quite extensively.  Base 10 and base 2 are great with regard to engineering and computers.  Yet they, at best, add nothing to the (general) halving of measurements that American Standard uses, and at worst make thinking in such metrics more difficult and therefore more prone to error.  This has nothing to do with Bitcoin, of course, since it's a computerized metric; but think  about it....

Even the metric system is based upon entirely arbitrary units, such as the meter, liter and gram.  AS is mostly taking an arbitrary unit and repeatedly halving it.  Some examples...

Dollar, half-dollar, quarter, bit (no longer used)  (The dime and nickel were introduced only due to decimalization, the same is generally true in British Pounds)

Peck (2 gallons), gallon, half-gallon, quart, pint, half-pint, cup, gill (4 fluid ounces)

If you grew up using meters as your primary unit of length, have you ever found yourself thinking in half-meters instead of 50 cm?  For example, measuring a wall of your house with a tape measure, if you need precision you write down meters and centimeters, but then you are really measuring in centimeters.  But if you are just shooting for a general measurement, say for example, judging the area of a flat you intend to rent to see if your funiture will fit, do you think in half meters?

For that matter, have you ever thought in half centimeters?

What about when you buy petrol?  Sure, the pump measures in liters and hundredths of a liter, but when the pump says 11.51 liters, do you think "eleven and a half liters"?

While driving, do you think of a driving distance as km's and meters?  Or do you think, "it's about 3 and a half kilometers to the next turn"? 

I'll concede that metric is much more uniform, and there is much to be said for that, but AS is easier to think within.

[LMGTFY]

In the course of my life I've had to use both systems quite extensively.  Base 10 and base 2 are great with regard to engineering and computers.  Yet they, at best, add nothing to the (general) halving of measurements that American Standard uses, and at worst make thinking in such metrics more difficult and therefore more prone to error.  This has nothing to do with Bitcoin, of course, since it's a computerized metric; but think  about it....

Even the metric system is based upon entirely arbitrary units, such as the meter, liter and gram.  AS is mostly taking an arbitrary unit and repeatedly halving it.  Some examples...

Dollar, half-dollar, quarter, bit (no longer used)  (The dime and nickel were introduced only due to decimalization, the same is generally true in British Pounds)

Peck (2 gallons), gallon, half-gallon, quart, pint, half-pint, cup, gill (4 fluid ounces)

If you grew up using meters as your primary unit of length, have you ever found yourself thinking in half-meters instead of 50 cm?  For example, measuring a wall of your house with a tape measure, if you need precision you write down meters and centimeters, but then you are really measuring in centimeters.  But if you are just shooting for a general measurement, say for example, judging the area of a flat you intend to rent to see if your funiture will fit, do you think in half meters?

For that matter, have you ever thought in half centimeters?

What about when you buy petrol?  Sure, the pump measures in liters and hundredths of a liter, but when the pump says 11.51 liters, do you think "eleven and a half liters"?

While driving, do you think of a driving distance as km's and meters?  Or do you think, "it's about 3 and a half kilometers to the next turn"? 

I'll concede that metric is much more uniform, and there is much to be said for that, but AS is easier to think within.

Couple of points (from someone who's pretty exclusively metric, but lives in a country that hasn't ever completely adopted the metric system - it still uses pints for beer, and miles for long distances).

Sterling isn't quite like the dollar, it uses 1, 2 and 5 rather than doubling. So... 1p, 2p, 5p, ... 10p, 20p, 50p, £1, £2, £5 for coins (£5 coins aren't that common), and for notes it follows the same pattern: £5, ... £10, £20, £50.

Centimetres are something of an aberration: normally SI units focus on 1000s. There are also decimetres, which don't seem to have gained any traction but which I remember from school rulers in the 1970s. This aberration only seems to exist with measuring distances, and only at the >1mm to <1m scale. There are no special words for 10 metres or 0.1mm, for example.

I tend to focus on one, appropriate, scale and stick to it. So I would never think of "1 metre and 50 centimetres" - it would always be 1.5 metres (or, I'll concede, 1 and a half metres - though to be honest I do tend to think in decimals rather than fractions: "half" is just short-hand for "0.5" to me). I wouldn't think of centimetres when dealing primarily with metres. (Incidentally, is that true for AS folk? Do people tend to work in feet, or use mixtures? I see things like 1' 2" which suggests units get mixed, but I don't know if that's just when written or if people think in mixtures as well).

My problem with AS is that the "number" keeps changing: 12 inches in a foot, 3 feet in a yard, and I can never remember how many yards (or feet) in a mile. I can see potential advantages in using 12 instead of 10 - if there was a system that had 12 inches to a foot, 12 feet to a "bigyard", and 12 bigyards to a "twelvemile" then I could see some value in that. But 10, or - better - 1000, seems perfectly usable to me.

[MoonShadow]

In the course of my life I've had to use both systems quite extensively.  Base 10 and base 2 are great with regard to engineering and computers.  Yet they, at best, add nothing to the (general) halving of measurements that American Standard uses, and at worst make thinking in such metrics more difficult and therefore more prone to error.  This has nothing to do with Bitcoin, of course, since it's a computerized metric; but think  about it....

Even the metric system is based upon entirely arbitrary units, such as the meter, liter and gram.  AS is mostly taking an arbitrary unit and repeatedly halving it.  Some examples...

Dollar, half-dollar, quarter, bit (no longer used)  (The dime and nickel were introduced only due to decimalization, the same is generally true in British Pounds)

Peck (2 gallons), gallon, half-gallon, quart, pint, half-pint, cup, gill (4 fluid ounces)

If you grew up using meters as your primary unit of length, have you ever found yourself thinking in half-meters instead of 50 cm?  For example, measuring a wall of your house with a tape measure, if you need precision you write down meters and centimeters, but then you are really measuring in centimeters.  But if you are just shooting for a general measurement, say for example, judging the area of a flat you intend to rent to see if your funiture will fit, do you think in half meters?

For that matter, have you ever thought in half centimeters?

What about when you buy petrol?  Sure, the pump measures in liters and hundredths of a liter, but when the pump says 11.51 liters, do you think "eleven and a half liters"?

While driving, do you think of a driving distance as km's and meters?  Or do you think, "it's about 3 and a half kilometers to the next turn"? 

I'll concede that metric is much more uniform, and there is much to be said for that, but AS is easier to think within.

Couple of points (from someone who's pretty exclusively metric, but lives in a country that hasn't ever completely adopted the metric system - it still uses pints for beer, and miles for long distances).

Sterling isn't quite like the dollar, it uses 1, 2 and 5 rather than doubling. So... 1p, 2p, 5p, ... 10p, 20p, 50p, £1, £2, £5 for coins (£5 coins aren't that common), and for notes it follows the same pattern: £5, ... £10, £20, £50.

Centimetres are something of an aberration: normally SI units focus on 1000s. There are also decimetres, which don't seem to have gained any traction but which I remember from school rulers in the 1970s. This aberration only seems to exist with measuring distances, and only at the >1mm to <1m scale. There are no special words for 10 metres or 0.1mm, for example.

I tend to focus on one, appropriate, scale and stick to it. So I would never think of "1 metre and 50 centimetres" - it would always be 1.5 metres (or, I'll concede, 1 and a half metres - though to be honest I do tend to think in decimals rather than fractions: "half" is just short-hand for "0.5" to me). I wouldn't think of centimetres when dealing primarily with metres. (Incidentally, is that true for AS folk? Do people tend to work in feet, or use mixtures? I see things like 1' 2" which suggests units get mixed, but I don't know if that's just when written or if people think in mixtures as well).

My problem with AS is that the "number" keeps changing: 12 inches in a foot, 3 feet in a yard, and I can never remember how many yards (or feet) in a mile. I can see potential advantages in using 12 instead of 10 - if there was a system that had 12 inches to a foot, 12 feet to a "bigyard", and 12 bigyards to a "twelvemile" then I could see some value in that. But 10, or - better - 1000, seems perfectly usable to me.

Length is an exception to the 'generally halving' rule, which is why I didn't include it.  It could stand to be fixed, and yes, most such measurements are mixed.  However, fine measurements are always measured in fractions of an inch (tool sizes for example) and tend to be significantly more precise and easier to think about than metric units, which can be rated in cm or mm and often do not mark which upon the tool.

[LMGTFY]

Length is an exception to the 'generally halving' rule, which is why I didn't include it.  It could stand to be fixed, and yes, most such measurements are mixed.  However, fine measurements are always measured in fractions of an inch (tool sizes for example) and tend to be significantly more precise and easier to think about than metric units, which can be rated in cm or mm and often do not mark which upon the tool.

Ah, interesting about mixing.

For fine measurements in metric, (I assume you mean for something like carpentry or metalworking?) mm would be used almost exclusively - I had a crusty old carpentry teacher who shouted at the class if anyone used centimetres! I presume there are (commonly used) fractions of inches that are smaller than millimetres, and that's where the precision comes from? I always found mm precise enough, but I was never much of a carpenter...

[Luke-Jr]

There are no special words for 10 metres or 0.1mm, for example.

10 metres = decametre

Do people tend to work in feet, or use mixtures? I see things like 1' 2" which suggests units get mixed, but I don't know if that's just when written or if people think in mixtures as well).

Honestly, I don't measure enough to work in any unit really. When I measure stuff, I find something I can easily work with (eg, pillow-lengths to measure bedrooms) on the spot. I do plan to order some nice Tonal rules, though...

My problem with AS is that the "number" keeps changing: 12 inches in a foot, 3 feet in a yard, and I can never remember how many yards (or feet) in a mile. I can see potential advantages in using 12 instead of 10 - if there was a system that had 12 inches to a foot, 12 feet to a "bigyard", and 12 bigyards to a "twelvemile" then I could see some value in that. But 10, or - better - 1000, seems perfectly usable to me.

There is such a system. It's called TGM.

[LMGTFY]

There are no special words for 10 metres or 0.1mm, for example.

10 metres = decametre

Doh! I knew that. It's not a unit I've ever encountered outside primary school, however. I suspect when Britain "went metric" (ahem!) back in the early 70s they assumed we'd need and use centimetres, decimetres and decametres, but only centimetres stuck (probably due to the - rough - correlation with inches).

Do people tend to work in feet, or use mixtures? I see things like 1' 2" which suggests units get mixed, but I don't know if that's just when written or if people think in mixtures as well).

Honestly, I don't measure enough to work in any unit really. When I measure stuff, I find something I can easily work with (eg, pillow-lengths to measure bedrooms) on the spot. I do plan to order some nice Tonal rules, though...

My problem with AS is that the "number" keeps changing: 12 inches in a foot, 3 feet in a yard, and I can never remember how many yards (or feet) in a mile. I can see potential advantages in using 12 instead of 10 - if there was a system that had 12 inches to a foot, 12 feet to a "bigyard", and 12 bigyards to a "twelvemile" then I could see some value in that. But 10, or - better - 1000, seems perfectly usable to me.

There is such a system. It's called TGM.

Why does that not surprise me? ;-) If it had the traction that AS has, I'd consider it - to my mind it's preferable to AS but metric's widespread usage still wins out for me. Except when it comes to beer: 500ml of beer is just wrong.

[FatherMcGruder]

For fine measurements in metric, (I assume you mean for something like carpentry or metalworking?) mm would be used almost exclusively - I had a crusty old carpentry teacher who shouted at the class if anyone used centimetres! I presume there are (commonly used) fractions of inches that are smaller than millimetres, and that's where the precision comes from? I always found mm precise enough, but I was never much of a carpenter...

Anyone ever use decimal fractions of an inch? I have.

[MoonShadow]

For fine measurements in metric, (I assume you mean for something like carpentry or metalworking?) mm would be used almost exclusively - I had a crusty old carpentry teacher who shouted at the class if anyone used centimetres! I presume there are (commonly used) fractions of inches that are smaller than millimetres, and that's where the precision comes from? I always found mm precise enough, but I was never much of a carpenter...

Anyone ever use decimal fractions of an inch? I have.

Yes, but only in an engineering context, using a micrometer.  Even then, the workmen tend to object to decimal fractions, and insist on plans using halving fractions.  Even tool/die makers hate using decimal fractions, and they almost have to because if modern machinery isn't made in Germany, it's designed there and made in Japan.

[MoonShadow]

Length is an exception to the 'generally halving' rule, which is why I didn't include it.  It could stand to be fixed, and yes, most such measurements are mixed.  However, fine measurements are always measured in fractions of an inch (tool sizes for example) and tend to be significantly more precise and easier to think about than metric units, which can be rated in cm or mm and often do not mark which upon the tool.

Ah, interesting about mixing.

For fine measurements in metric, (I assume you mean for something like carpentry or metalworking?)

Among other things, yes. 

mm would be used almost exclusively

Almost being the operative word.  I know for a fact that not all metric tool manufacturers stick with mm, and not all of them are up front about it.  Chinese tool manufacturers are particularly bad about this, in addition to sloppy fit in general, but they also happen to be the cheapest toolmakers in the world.  In my experience, Chinese tools following the American Standard aren't as bad about fit, but that might just be me.

 - I had a crusty old carpentry teacher who shouted at the class if anyone used centimetres!

I can imagine why.  This can only be because he has experienced the order of magnitude error that can occur because of this.

I presume there are (commonly used) fractions of inches that are smaller than millimetres, and that's where the precision comes from?

Well, there is no such thing as 'common' sizes smaller than a mm in any context, but yes.  The procession of dimminishing sizes is very orderly, and can be understood intuitively to anyone that has experience with the larger tools that use fractions of an ich.

I always found mm precise enough, but I was never much of a carpenter...

That pretty much says it all, right there.

[LMGTFY]

mm would be used almost exclusively

Almost being the operative word.  I know for a fact that not all metric tool manufacturers stick with mm, and not all of them are up front about it.  Chinese tool manufacturers are particularly bad about this, in addition to sloppy fit in general, but they also happen to be the cheapest toolmakers in the world.  In my experience, Chinese tools following the American Standard aren't as bad about fit, but that might just be me.

Sure, here in the UK you can easily buy rulers that show centimetres - particularly the (plastic) kind used in schools, but the more serious kind too. But wouldn't that fall under the "a poor workman..." case? When I measure something I make sure I'm using the unit I should be using. Anyway, my point was that - while a ruler might show centimetres and inches, the serious worker would stick to mm.

- I had a crusty old carpentry teacher who shouted at the class if anyone used centimetres!

I can imagine why.  This can only be because he has experienced the order of magnitude error that can occur because of this.

Indeed. That, for me, is the main reason to avoid the non-standard SI units - centimetres, decimetres, etc.

I presume there are (commonly used) fractions of inches that are smaller than millimetres, and that's where the precision comes from?

Well, there is no such thing as 'common' sizes smaller than a mm in any context, but yes.  The procession of dimminishing sizes is very orderly, and can be understood intuitively to anyone that has experience with the larger tools that use fractions of an ich.

What fractions in particular? Father McGruder mentioned decimalised inches, which would be 2.54mm for 1/10th of an inch, and seems fairly useless to me. I'm assuming something in the order of 1/32" or 1/64"? I remember rulers with inches divided into 12s and 16s, but powers of 2 seem logical (possibly due to too much binary) - is that how it works?

I always found mm precise enough, but I was never much of a carpenter...

That pretty much says it all, right there.

[grue]

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.

[citation needed]

[MoonShadow]

mm would be used almost exclusively

Almost being the operative word.  I know for a fact that not all metric tool manufacturers stick with mm, and not all of them are up front about it.  Chinese tool manufacturers are particularly bad about this, in addition to sloppy fit in general, but they also happen to be the cheapest toolmakers in the world.  In my experience, Chinese tools following the American Standard aren't as bad about fit, but that might just be me.

Sure, here in the UK you can easily buy rulers that show centimetres - particularly the (plastic) kind used in schools, but the more serious kind too. But wouldn't that fall under the "a poor workman..." case?

I guess I'm not being clear.  Every tape measure that I've seen in the US has both inches and cm.  When I say 'tooling' I'm not refering to measuring devices, but to actual machine tools designed and built with the intent to be used with a particular part, in turn designed to fit withing a particular system of measurement.  A common example is a socket wrench set.

I presume there are (commonly used) fractions of inches that are smaller than millimetres, and that's where the precision comes from?

Well, there is no such thing as 'common' sizes smaller than a mm in any context, but yes.  The procession of dimminishing sizes is very orderly, and can be understood intuitively to anyone that has experience with the larger tools that use fractions of an ich.

What fractions in particular? Father McGruder mentioned decimalised inches, which would be 2.54mm for 1/10th of an inch, and seems fairly useless to me.

He's not talking about conversion from AS to Metric, but about the division of an inch into hundredths.  At least that is what I thought that he was talking about.

I'm assuming something in the order of 1/32" or 1/64"? I remember rulers with inches divided into 12s and 16s, but powers of 2 seem logical (possibly due to too much binary) - is that how it works?

Inches are normally shown divided into eighths on a common ruler, which is simply three halvings.  Furthur precision is gained by continuing this process; one-sixteenth, one thirty-secondth, one sixty-fourth, and so on.  The precision is base 2 and infinite.  I've not seen a tweevlth used on any such measuring device within my career.  I'm not saying that they don't exist, but they are not really an American Standard issue, perhaps a throwback to British Imperial?

[FatherMcGruder]

What fractions in particular? Father McGruder mentioned decimalised inches, which would be 2.54mm for 1/10th of an inch, and seems fairly useless to me.

He's not talking about conversion from AS to Metric, but about the division of an inch into hundredths.  At least that is what I thought that he was talking about.

I have a pair of calipers at work that goes to thousandths of an inch. I think you need a micrometer to get any more precise. I recall having to machine something down to a ten thousandths of an inch tolerance in a class once.

[LMGTFY]

Sure, here in the UK you can easily buy rulers that show centimetres - particularly the (plastic) kind used in schools, but the more serious kind too. But wouldn't that fall under the "a poor workman..." case?

I guess I'm not being clear.  Every tape measure that I've seen in the US has both inches and cm.  When I say 'tooling' I'm not refering to measuring devices, but to actual machine tools designed and built with the intent to be used with a particular part, in turn designed to fit withing a particular system of measurement.  A common example is a socket wrench set.

Ah, got it - dodgy tool manufactures using metric but labelling in AS. In my defence it's been a long day...

What fractions in particular? Father McGruder mentioned decimalised inches, which would be 2.54mm for 1/10th of an inch, and seems fairly useless to me.

He's not talking about conversion from AS to Metric, but about the division of an inch into hundredths.  At least that is what I thought that he was talking about.

That's what I thought, too, I just imagined it as 10th of an inch. 100ths make more sense, particularly in light of the callipers/micrometer comment later.

I'm assuming something in the order of 1/32" or 1/64"? I remember rulers with inches divided into 12s and 16s, but powers of 2 seem logical (possibly due to too much binary) - is that how it works?

Inches are normally shown divided into eighths on a common ruler, which is simply three halvings.  Furthur precision is gained by continuing this process; one-sixteenth, one thirty-secondth, one sixty-fourth, and so on.  The precision is base 2 and infinite.  I've not seen a tweevlth used on any such measuring device within my career.  I'm not saying that they don't exist, but they are not really an American Standard issue, perhaps a throwback to British Imperial?

Ah, not sure I've ever seen 8ths of an inch on a British ruler. Base 2 makes sense, though. I wouldn't swear to seeing 12ths, though I'm reasonably certain - it was 16ths (which makes sense to me) and something "odd" - probably 12ths, possibly something else that wasn't a power of 2.

Anyway... apologies for dragging this hugely off-topic, and thanks for providing your insight.

[MoonShadow]

[Ah, got it - dodgy tool manufactures using metric but labelling in AS.

Actually, more likely the other way around.  Said dodgy tool manufactures originaly sold vastly more AS toolsets than Metric sets, although that's likely no longer so.

Anyway... apologies for dragging this hugely off-topic, and thanks for providing your insight.

You're quite welcome.

[marcus_of_augustus]

So after all that .... any update on opinions of how bitcoin should be commonly measured?

[Alex Beckenham]

So after all that .... any update on opinions of how bitcoin should be commonly measured?

In Libraries of Congress of course.

[LMGTFY]

So after all that .... any update on opinions of how bitcoin should be commonly measured?

One useful aspect of the discussion on measuring wood and metal in AS is that it got me thinking about how the US regulates this compared to metric countries. As I understand it, the US doesn't regulate it: folk are free to use AS or metric as they choose (possibly subject to "not misleading people by using dubious measurements"?)

This seems to me to be the best approach. We can't anticipate what needs different groups of users with different customs will have. All we can do is expect that those needs will differ. A group selling a boat to another group in Somalia, pointing RPGs and AK47s at each other while they wait for the transaction to confirm, is going to use different units to an individual making a micropayment to buy a postage stamp online in Germany.

If we start creating our own units - satoshis, bitcents, whatever - we create something additional to understand before bitcoin can be used. If we stick with The One True Unit (BTC) we can leave creation of units to the end user, and they can use what they feel comfortable with.

[Luke-Jr]

So after all that .... any update on opinions of how bitcoin should be commonly measured?

TBC!

No, seriously, that's why we have the different units. If you're making micro-payments, cBTC or mBTC might make sense for now. If you're doing a huge payment, consider kBTC. If you use Tonal, you'll probably want to use ᵇTBC for most payments. In a few years, the value changes will probably adjust everything to mBTC/TBC (for normal sizes) and μBTC/TBCᵐ for micro-payments.

[Anonymous]

We just moved the decimal at witcoin.com on most posts because we can 

.01 starts to look expensive compared to .001 or .0001

[gigabytecoin]

+ 1
Definately agreed.

+1 I agree.

[TiagoTiago]

You aren't moving anything, only adding precision