Yes, I think the simplest think that could possibly make this work is the best way to go.  There has been a lot of talk about factoring the code to enable things like this, but doing the simplest thing instead of a grand refactoring makes a lot of sense (and I think it would go a long way toward encouraging alternate implementations of a wallet UI as it removes the need for the wallet implementation to speak the bitcoin protocol directly or manage a local block chain).

One thing that would make the bitcoin client far more useful for me is if the wallet and the client were split.  I don't keep bitcoin running continuously and hence when I restart it, I have to wait a while the client catches up with the latest blocks.  I also have multiple wallets and keeping a separate block chain for each of them is wasteful.  I want to keep a bitcoin p2p client running somewhere continuously and have my wallets connect through it to the bitcoin network.  I imagine two executables:

- bitcoinWallet
- bitcoinClient

The bitcoinWallet would be the familiar GUI front end to a wallet.  It would work just as it works today (although, I'd like a "File" menu that lets you choose which wallet.dat to open and use).

The bitcoinClient would be a headless process that could easily be turned into a service or daemon.  It connects to the p2p network, validates blocks and transactions, and keeps its own local copy of the block chain.

By default, the bitcoinWallet would attempt to connect to a locally running bitcoinClient on a well known port.  A command line option would let you specify an alternate host:port where the client can be found.  A setting in the GUI could also let you specific a client to connect to (and the setting could be remembered in some config file).

I realize that there are ways some of these issues can be addressed with the current distribution, but I think a more user friendly solution is needed.  Mainly what it comes down to is the ability to fire up the wallet that may have not been running for a day or two and have it be instantly usable (without having to wait for it to catch up).  Having it startup instantly (rather than take several minutes for the GUI to appear) would be good too.  Also, if there is still a need for the wallet to sync with the block chain (getting the very most recent transactions that are relevant to the wallet) and it takes more than a couple seconds, some visual indication that the client is syncing and not ready for use would be good.

Very nice!  What accounts for the difference in the number of unique clients and the total of the clients by version?

Is there really that much to be made?  Even if you waive all the fees and commissions for people providing this liquidity, I'm not sure the volume is there to make very much "free money."  Perhaps if the exchanges (particularly the smaller ones) got together and funded the development of a simple to use arbitrage utility then people would start doing it.  Ideally, it would be almost as simple as: go deposit X amount in the exchanges you want to arbitrage, configure the utility with the OAuth keys for each of your arbitrage accounts, and run the utility.  The exchanges should make it easy to move fiat funds between exchanges (exchanges could settle such transfers directly and enable the arbitrage client to use the API to initiate fiat transfers).  The arbitrage client would place orders and rebalance fiat funds between accounts at multiple exchanges.  From an end user perspective, you would just be putting up funds to earn a little extra from these arbitrage opportunities.

There's probably little incentive for mtgox to implement this, but if all the other exchanges got together and did it, they would in effect be pooling all of their volume and could become a formidable competitor to mtgox.  Alternatively, the exchanges could simply integrate their quoting and matching engines such that no matter which exchange you prefer to use, you're always looking at the combined order book of all exchanges and orders could be matched and later settled across the exchanges.  You would eliminate the arbitrage opportunities, but the users would see the savings in the form of tighter spreads and higher liquidity.

I use it as a currency almost every day.  Therefore, it's a currency.

This is not quite correct.  The inflation rate has in fact been steadily declining.  From block 0 to block 1, the annualized inflation rate was infinitely large.  From block 1 to block 2, the annualized inflation rate was 5,256,000%.  Currently the annualized inflation rate is ~35.7%.

Do you honestly think that if you had $250 million that you could buy 7 million bitcoins today?  I doubt it.

Market cap is a meaningless figure when it comes to bitcoin or any other currency.  Bitcoin is not a stock (where market cap would indicate the total value of a company).  To illustrate why this is a meaningless figure, consider that when bitcoin was trading at $35, if everyone cashed out all their bitcoins, people would have received nowhere near $210,000,000 for them.  Conversely, if I offered to by all bitcoins in existence for $210,000,000, I would have obtained no where near the 6+ million bitcoins that had been mined as of that date.  

It's tempting to think in terms of market cap, but it is in reality an utterly meaningless statistic in relation to bitcoin.  The market cap is just a figure derived from the total number of bitcoins mined and the last trade price.  And the last trade price is a trailing indicator that, depending on circumstances, may not even have any relation to the next trade price.  Open bid and ask orders are better indicators of what the next trade is likely to be, but the open orders on the exchanges have a very wide price range for a relatively small number of bitcoins (compared with the total amount mined).  Again, there is no way that 6+ million bitcoins could have ever been sold for $210,000,000...and I'd say that's still true today.  There's also no way that 6+ million bitcoins could have ever been bought for $210,000,000...and that's also still true today.  I doubt $1 billion could buy you 6+ million bitcoins.

The statistic that is far more relevant is the volume of bitcoin traded for other currencies, goods, or services.  I'd be interested if anyone had some educated guesses on that statistic over time (you can't simply add up exchange volume and block chain volume, but one could come up with some models that incorporated those figures).

Of course, this may be little consolation to those that purchased bitcoin when they were trading at $35.  

I think as far as exposing private keys, that cat is already out of the bag regardless of whether such an RPC command exists or not (we have casascius coins and bitbills that are already handling private keys).

I had discussions last week along these lines with TTBit at our Orlando meetup.  He brought some bills he printed that included the private key.  I actually think there are some compelling use cases for this in addition to the one casascius mentioned (side note, TTBit was kind enough to sell me a handful of casascius coins...very nice!).

Imagine this scenario...you want to go out for dinner and drinks and you want to pay with bitcoins, but you don't want to fumble with the smartphone (or you don't have one, or data access is cost prohibitive, or you want to make sure you don't go crazy and spend all your bitcoins).  You could print up 10 bills of say 1 BTC each.  Each bill would have a scannable public/private key.  To pay for things, you give these to the restaurant and they either:

- sweep all funds and send change to another "change" address you also printed on the bill
- sweep all funds and print you a new bill for the amount of the change (with a new unique public/private key pair)
- leave the change on the bill for you to use again

If you lose one of these bills, you only lose the amount stored on the bill (and maybe not even that if you kept the keys and can later spend the funds before anyone else does).  You could even take it a step further and encrypt the keys with a pin code that you would have to give the recipient (or type into a key pad) in order to decrypt the keys.

The key difference here is that at the point of the transaction, only the recipient needs software and an internet connection to complete the transaction.  You do have to trust the merchant, but that's not so different from the situation today when you give them a $20 bill and expect them to return with change or you trust that they won't steal your CC number, etc.  I still like the idea of a trusted, personal hardware device, but in the short term, this low tech solution could prove quite useful.

What I find interesting about this is that they clearly view all forms of digital money in the same light.  They cannot (yet) discern what is unique about bitcoin relative to other forms of digital money (past and present).  In time they will.

@Nagle I can appreciate that you don't believe bitcoin will be successful.  I also understand that there have been several spectacular failures when it comes to bitcoin related businesses and people are understandably cautious.  I think you have good intentions by trying to check into the operations of bitcoin related businesses, but I encourage you to contact us directly, talk to us by phone, and even meet with us in person if you have concerns about our operations.  We are just a couple of people trying to find a niche in an exciting new frontier.

It's also great from a marketing perspective...if every bill has a QR code and a caption below that says "Pay with Bitcoin", then every patron will see that on the their bill, regardless of whether they actually pay with bitcoin or not.

It's actually more of an issue for the customer to have internet than the restaurant.  There are lots of possible ways to make it work.  This is just a small step in the right direction and something easy for us to do.  Ultimately, it would be nice to do away with the use of paper altogether...either restaurant checks or FRNs .  We'll be piloting this with a few restaurants to see how well it works in practice and go from there.

Are you aware of the script capabilities in bitcoin?  They will enable transactions of the sort that require say 3 out of 5 signature to spend funds.  This is exactly what is needed in a corporate accounting context.  This same capability can also be used for multi-factor authentication to protect high value wallets.  I believe Gavin and other core developers are doing work to enable these capabilities as we speak.

You'll find these same clauses in the terms of virtually every payment service on the internet because they all face similar risks.

To the extent the policies leave any questions that our merchants might have, we answer them.  Some of the details of how we process payments are not visible unless you've opened an account.

That's not true, we operate out of two houses, one in Florida and another in Georgia.  Tony has experience as a merchant for over 10 years and I have experience in building and managing the development of financial software.  We both have prior experience in owning and operating small businesses.

I suspect he means that it's a hopeless cause to try and build a secure system on top of operating systems that are fundamentally insecure.  You likely need to start over from the ground up and have security in mind at every step of the way (perhaps even getting into trust issues relating to the proprietary hardware and microcode that virtually all computers are based on).

My hope is that bitcoin will force the issue that we need a new operating system that is designed with security in mind.  The OSes we're using today are all based on 40+ year old technology.  Here's an interesting project that I think may eventually provide the underpinnings for such an OS:
http://www.pcmag.com/article2/0,2817,2392791,00.asp

That's exactly what I was saying (though perhaps not so clearly).

If a transaction appears in a block, you know that the network has agreed that it is the authoritative transaction to the extent that the network is able to agree to such a thing (reorgs, >50% attacks, etc).  If it doesn't appear in a block, well, you need to ask your peers if they think it's valid (if they've seen a conflicting transaction, they won't) or you wait for it to appear in a block (and both still carry degrees of risk when it comes to double spends).  A headers only client doesn't mean that you never pull the body of the block from the network...if you need to check that a transaction appeared in a block, you can ask a peer that question...the peer can respond with the portion of the merkle tree that proves the transaction is in the block.

My point is that with a lobotomized client, you still have to place trust in network peers...so you may as well go as thin as possible and not bother with the block chain at all.  Just a very thin client connecting to one (or several if you want a little bit of distributed trust) full network nodes.

Getting back to the topic of the OP...if you believe that bitcoin will flourish and be used for generations to come, then eventually this does become a problem.  I'm also interested in ways to allow the network to forget old transactions just out of principle (although, you should never assume old transactions are ever forgotten).  I think you can do this in a couple steps.  The first step is to establish a block depth, beyond which, the network will never accept a re-org.  This formalizes the current practice of hard coding recent blocks into the client.  It should be set deep enough that it doesn't present any real risk of block chain splits.  The second step is to add the hash of the unspent transactions to the block.  Nodes would have to validate this hash before considering the block to be valid.

New nodes joining the network could request the current block along with its transactions.  The node can then work backward, fetching each block and the transactions until it reaches a block that is old enough that it would never be subject to reorg (plus a few extra for good measure in case some of the rest of the network hasn't seen some of the more recent blocks).  It fetches all the unspent transactions that go with that block.  It can then validate going forward all of the transactions and blocks.  This new node will be trusting that other nodes have validated history up to the point in the past where it is starting from.  Care could be taken to ensure that trust is distributed among a large and diverse set of nodes by confirming everything with a large number of nodes (perhaps seeded by a group of nodes widely acknowledged to be trustworthy).  Another approach to this node bootstrapping would be to view it as a kind of cloning of existing nodes.  If Alice trust Bob, John, and Bill, then Alice would be confident in bootstrapping a new node from Bob, John and Bill and not have to place trust in the broader network.

If I'm not missing anything, nodes would only need to keep block headers and unspent transactions that are older than the block at which reorgs are prohibited.  Spent transactions that are older than the reorg boundary (plus some buffer) could be safely discarded.  The older blocks themselves could possibly be discarded as well (remember, all the unspent transactions can be verified to be in the chain by virtue of this new hash in the header).  I think for good measure you would want to keep a healthy amount of history beyond the reorg boundary, though I'm not sure it would be strictly necessary.  I even wonder whether this would work and be safe even on very short time scales if you retained a relatively long tail of block headers (i.e. a few hours for the reorg boundary).

You don't have to trust any peers...transactions are identified by their hash...when you ask a peer for the transaction associated with a txid (i.e. you need to retrieve a transaction input), you validate what it returns by hashing it and verifying that it matches the txid.  If that transaction is part of an earlier block, then to the extent you trust the block headers that you downloaded, you can trust that the input transaction was valid (you could make a rule that you only trust the headers that pre-date one of the hard coded blocks in the client...probably hundreds of other possibilities as well).


The digest for any block could be produced on demand by any node that has the full transaction history.  If you did something like this, keep it simple...define a standard format for the digest and have miners always include the hash of the digest in every block.  When a new block is found, other nodes would update their running digest with that block's transaction, then compute the hash of the digest and verify that it matches what is in the block.

Still, I'm struggling to think of a real benefit of such digests (it is redundant information after all)...using digests would require placing some trust in the information provided by peers (full validation of the transaction history and block chain is required to avoid trusting peers).  It's possible this could provide some benefit to lighter weight peers (that don't have the storage, CPU or bandwidth needed for full validation), but then I think that problem is better solved by a lightweight client that just communicates with a full node that it trusts.  In fact, as I write this, I'm wondering whether a "headers only" client fills an real need either.  

Either you're trusting other nodes or your not...if you're not, then you need the full transaction history...I don't think you can escape that.  If you are trusting other nodes, then just pull only the information you need from one or more trusted nodes when you need it and don't even try to connect directly to the p2p network.