Yup.

The U.S. does not care about lost coins because it introduces new coins at a rate sufficient to compensate.

The actual quantity of paper bills and metal coins in circulation is market driven.

If all of us decide to cut up our credit cards, withdraw our savings from the banks in cash, and pay cash for everything, then they just print more bills and mint more coins.

If a month later, we reverse our decision and return a huge mountain of paper and coin to banks for deposit, they burn the bills and melt down the coins or put them aside out of circulation.

Bitcoin needs to decide whether it is an alternative medium of exchange, or an alternative long term store of wealth.

It is way too young and fragile to provide a reliable long term store of wealth; so it necessarily will raise and fall on its suitability as a medium of exchange.

A suitable medium of exchange needs to hold its value relatively stable over the short term.  If the market price of some good or service, specified in some currency unit, rises or falls noticeably, it should mostly be because of something to do with that good or service, not with a recent surplus or shortage of the currency unit, relative to the demand for that currency by the current economic activity.

As FOFOA notes in http://fofoa.blogspot.com/2010/12/windmills-paper-tigers-straw-men-and.html :

One of the essential and defining properties of bitcoin is that it not so react.  After an initial buildup, its supply is permanently capped and in the long run, declining at a gradual and slow rate, regardless of overall economic activity.  This is a property perhaps suitable to a long term store of wealth, not a medium of exchange.

I don't think this works.

Yes - where?

I found that an email list was nearly ideal for such work when in the Linux kernel (the famous lkml list.)

This allows threaded discussions, keeping a visible history, and a wide variety of client readers.

Web forums have the history and the threading, but are limited in what they can do compared to
some of the fancier email clients in the hands of an experienced user.

IRC is not threaded, and tends to be more off the cuff conversational.

On a separate topic, I would suggest that a mercurial (hg) interface to the tree, running alongside
the git interface, would be cool.   Aha -- I just noticed http://hg-git.github.com/.  My wish is granted.

You're changing your tune, from
  "It should not be worried about -- it's a non-issue because users would not  notice if their clients were displaying nano-bitcoins",
to
  "it should not be worried about now, because it will not matter for a long time."

Well, if it will matter in a long time, then (1) it might be easier to address now, while bitcoin is young, (2) if it is not addressed, it could harm acceptance, as some savier people will not adapt something in the short term that doesn't have a long term path to success, and (3) you're still wrong that users would not notice whether their client displayed bitcoins or nano-bitcoins.

People do not work in isolation, seeing BTC's only via their BTC client.

They also talk about them, read about them, see such values displayed on potential offers to buy and sell, ...

Human factors absolutely should be worried about.

But sed -r is not available on all sed commands.  I wanted something portable.  Granted, I have no example of a sed command that presently lacks it.  I just know that extended regular expression support was added (to sed and anything else) sometime after such commands first existed, so I studiously avoid using extended regular expressions in situations where portability to unknown runtime environments is desired.

If one uses sed -r, then I suppose a better (well, shorter anyway) expression would be:

We're in agreement.  I just understood your "not desire" position to mean "it would be wrong even if we could", whereas I take it now that you meant "it is not something I seek, because it almost certainly cannot be found."

Peace.

It may be a non-issue to the minority of us who can shift decimal points about with ease, but for the majority of humans, currency units need to be scaled to practical values.

Just because something doesn't seem realistic at present doesn't mean we should not prefer it, were it available.

Ok - thanks for the BSD sample output.

How about this code then:

Well, darn.

Could you provide a sample few lines of output from a BSD netstat -an?

It would take more than changing the /:8333/ pattern to fix this, if I understand your description
correctly.  There is also the awk split on the ":" which would have to be fixed as well.  This is all
doable with a little bit of regular expression hacking (something I do easily.)  But I should see the
exact BSD netstat -an output first, to be sure I understand it correctly.

Good - thanks.

Of course I think it is desirable.  Why would I think not?

I agree that it appears out of reach, at least given our current understanding.

But if the core mechanism provided perfect security and instant validation of millions of simultaneous payment requests of value from tiny fractions of a BTC to billions of BTCs, why would that not be desirable?

The closer we can push the core mechanisms to that ideal  imaginary  goal, the better, all else being equal.

First however we need to reverse engineer the protocols, validate that specification with the successful implementation of alternative, fully compatible, clients, and subject the network behavior to a rigorous algorithmic complexity analysis.  I presume there are others with similar goals, who have already made some progress in such directions.  As I read through old posts on this forum, I will likely find postings mentioning such efforts.

That pybitcoin effort does not seem to have been updated since August 2010 (it is now the end of December 2010.)

What efforts (that one, or others I have not noticed yet) to reverse engineer the protocol and write other clients (C or Python being the languages I am fluent in) are currently active?

Such work seems to me to be critical to the success of bitcoin.

So ... how does this work after bitcoin has been successful for several decades, and we have trillions of past transactions, but only hundreds of millions of active users providing meaningful compute power for mining?

In other words, does the cost of mining increase over time with a higher exponent than the number of computationally useful mining nodes?
 

I am quite willing to agree that bitcoin as currently conceived is not well suited for micro-payments, without some additional supporting infrastructure, outside of the core bitcoin mechanism.

However, it might be possible, once such a full fledged analysis of these factors had been done that this would illuminate the way to core algorithmic improvements in this or other useful regards.

Someone else asked the question, so I can just guess from what they said.

My guess is that the interest is not so much in coding the guts of the client in shell script (not exactly a high performance engine for computationally intensive tasks), but rather in exposing the data flows and stores to shell script manipulation.

In other words, as I have often done myself in other tasks, write several tools that each have specific capabilities, and which have interfaces that work well when combined in shell scripts with each other and other *nix utilities.  One shot commands are handled in that environment by forking/execing a command that is passed command line arguments, environment variables and files or file descriptors to read or write.  Higher performance for repetitive tasks is obtained by using commands in a series of filters, operating on a stream of line oriented text.  The new, individual tools would each be written in C or Python or some other such language that provided adequate performance and library support for their particular purpose.

That transaction processing is subject to the market does not eliminate the requirement (in my view) to understand its algorithmic performance characteristics.

Duh!  Excellent.  Thanks.

In the current design, yes, a bitcoin bank handles micropayments better.  I was more concerned with the "does not scale" phrase I quoted.

Where can I find a careful performance analysis of bitcoin?  How does it scale with millions or billions of users, in terms of such things as transaction speed, computational and memory requirements per node, network bandwidth requirements, ...?  

An ideal system would allow a billion human users all to issue 0.0001 BTC transactions at the same time, and have all such transactions (for those users whose local network and computer resources function adequately) to complete in under a second.  I presume that neither bitcoin nor any other system we are aware of can reach this ideal.  But I doubt bitcoin can succeed unless it has a performance analysis, preferably of peer-reviewed research paper quality, and a clear strategy for dealing with whatever manner and way it falls short of the impossible ideal I described.

But I'm new here; so likely such a performance analysis exists and I just have not noticed it yet.

One could work around that inefficiency in at least a couple of ways:
 1) Background a task that has a file descriptor open back to the active shell, that can manipulate and communicate with sockets, or
 2) Use a shell that provides this builtin, such as the net/socket module in zsh as described at  http://www.cims.nyu.edu/cgi-systems/info2html?%28zsh%29The%2520zsh%2Fnet%2Fsocket%2520Module

Care to elaborate?