I'm looking forward to meeting everybody-- I be at the big red spider thing at 12:30.

I've got a temporary mobile phone, number is: 06 19887172

Ooh!  Ooh!  50 more bitcoins for the "Bitcoins Lost Forever" thread!

If processing old transactions becomes expensive, then miners will start charging transaction fees to include them in their blocks.

Speculating about exactly HOW the miners will charge (will they subscribe to an 'old transaction service' or somehow contact the old-transaction-spender for the merkle branch of the old transaction?) is a waste of time, in my humble opinion.

The only reason I can think of is it relies on the boost::xpressive regular expression parsing .hpp, and that slows down the build.

I did refactor most of this into a rpcmonitor.cpp file; rpc.cpp was getting huge, and was taking a ton of memory and time to compile.

RE: moving to another hashing algorithm for bitcoin addresses:

Did you read what Satoshi wrote?

If you want to make money, you are far, far, far, far, far, far better off using your hardware to generate blocks than trying to find a bitcoin address collision and steal bitcoins.  Potential address collisions are not a weakness, and switching to another algorithm would be just busy-work for us developers who should be spending time on REAL weaknesses (like figuring out how to make bitcoin more secure against trojans and viruses).

I vote for removing dead code; less code means less bugs, and less chance of security issues.  The source control system is the right place for code that we "might need again someday..."

If I understood the paper correctly (I skimmed it very quickly), this is a timing attack that requires the attacker send a bunch of things to be signed with the same ECDSA private key.

The good news is it they also give a patch to OpenSSL to fix it.  The other good news is bitcoin only signs things with private keys when you send coins, and if you have the ability to ask bitcoin to send coins then we don't really care if you can get the private key.

We do have a patch in the "pull queue" that adds a RPC command to let bitcoin sign stuff ( https://github.com/bitcoin/bitcoin/pull/183 ), but, again assuming I read the paper correctly, even that doesn't worry me, since if you have the ability to run that RPC command you could either go through all the trouble of the timing attack to figure out the private key... or you could just issue a "send" command to steal all the bitcoins out of the wallet.

I'm just quiet because I've been busy being jet-lagged and sightseeing in Paris.

So with the recent avalanche of press interest in bitcoin, I thought I'd share my thoughts on how I'd like to see bitcoin positioned.  I'm not writing this as "This is the Official Bitcoin Organization Position" -- as always, I expect everybody to have, and express, their own views.

I'll restate what I see as the goal of The Bitcoin Project:  To give us control over our finances by establishing a stable, secure, global, "democratic" currency.

I think positioning bitcoin as "revolutionizing the financial system" is the goal-- not more radical statement I've heard (like "destabilizing governments").  Most people either like or are indifferent to their governments (I know, I know, sheeple and all that... lets not go there).  I don't think most people get the warm fuzzies when thinking about bankers and Big Corporations; bitcoin as "The People's Money" is the right way to think about it.

Also, whenever I talk to the press, I try to be realistic.  Bitcoin is still an experiment that has never been tried before; there is still a good chance it will fail, and there is still a lot of work to do to make it stable and secure.  I'm excited because bitcoin is a big idea that might change the world for the better, but I also realize that our little project is just a baby compared to the decades-old financial systems that we all use every day.

I think it is important to set expectations; I still wouldn't recommend that my mom use bitcoin for anything just yet, because it is not easy enough to use securely.  And the road ahead is likely to be bumpy; there will be technical issues that need fixing, there will be legal questions, there will be price bubbles, and there will be scams.  I predict that some company using bitcoins to do something illegal will be caught and prosecuted, and that will be mis-reported as "Bitcoin is illegal."

I said a year ago that creating solid technology was just the first step in a long road for bitcoin.  I'm very pleasantly surprised at how far the bitcoin project has come in a year; the innovation and experimentation and level of interest and excitement is fantastic.


Here's an email exchange I had with a reporter yesterday:


New technologies are always at least a little bit dangerous-- they can usually be used for both good and bad (think of gunpowder or ChatRoulette), and are certainly dangerous to the status-quo that they replace (think of cars and buggy-whip-manufacturers).

Bitcoin is a really ambitious project; we're trying to let people take back control of their money instead of trusting bureaucrats or bankers or politicians to keep it stable and safe. It is international, decentralized, and completely open to innovation, very much like the Internet.  Like the Internet, I expect its early years to be full of amazing successes and spectacular failures, and I don't think anybody will be able to predict in advance what will succeed and what will fail.

I think the real question is whether or not bitcoin will appeal to the majority of people who are happy with our current financial system. If it doesn't, bitcoin may fade away or end up as a niche currency used for a tiny percentage of global financial transactions.

I'd suggest removing/replacing the "it is anonymous" claim.
Anonymity and bitcoin is...complicated.  I'd suggest:

"It is like cash" -- no one can steal your identity

Sure, we'll call it GavinCoin and I get all the coins to start.

If you want some, you just send me some of that worthless fiat currency that you have laying around.

Sound good?

That is exactly what -connect does (if I recall correctly; you might need -connect and -nolisten together).

Just think of that guy who gave away 10,000 bitcoins through the Bitcoin Faucet...

No, no, no and yes.  I'm planning on making the answers to all of those questions "yes" within the next six months, although I need to look at how many bitcoins are contained at any given time in the ClearCoin wallet; it might make more sense to send double or triple that amount of bitcoin to a publicly verifiable address, prove I own the coins, and guarantee any losses due to ClearCoin getting hacked.

(note: I just looked, and right now there are 540 bitcoins in the ClearCoin wallet, so spending $50,000 to protect them really wouldn't make sense).


Yet another bitcoin chicken-and-egg problem that will get solved by investors taking a risk and giving bitcoin entrepreneurs the resources to do security right (or wealthy entrepreneurs stepping up and making the investment themselves).

My advice:  don't reinvent the wheel.  There are already standards and organizations dedicated to security practices surrounding currency, both physical and virtual, and financial transactions.  It doesn't really matter if the currency is bhat or bitcoin, the principles will be the same.

They haven't paid the ECDSA price.  The decision is "I know how big this transaction, how many OP_CHECKSIG opcodes I'll have to compute to verify it, and how much transaction fees it pays.  Should I do the work of verifying it or should I just ignore it?"


@ribuck:  yes, the UI would be much simpler, but internally the client needs a model of what the miners are accepting.  Maybe a really simple internal model will work if the UI is really simple...

Would it be good enough if I volunteered to write a little perl or python or php or bash script that reads the passphrase from a file descriptor and then posts the right JSON-HTTP request?

If the consensus is to teach bitcoind to read arguments from file descriptors, somebody please figure out if there's a standard for how other unix apps do that.  Here's what curl does:

In the long run, block size will NOT be the bottleneck, so it will NOT determine the marginal cost of a transaction.

The bottleneck is, and I believe will continue to be, the number of ECDSA signature verifications a miner can perform per second.  Each miner (or mining pool operator) will have a transaction processing capacity of N transactions per second.

If there are more than N transactions per second going across the network, then the smart miners will select the most profitable N for inclusion in their blocks and drop the least profitable.

And the smart miners will keep track of how much it would cost them to invest in more CPUs or specialized ECDSA-verification hardware so they can process N+M transactions per second.  And figure out how much they would make in fees or side-deals (or whatever) when they handle those extra M transactions per second.  If it is profitable, they will increase their transaction processing capacity.

---

I think what bitcoin is missing right now is code in the clients to figure out the "right" amount of fees.  We're currently relying on hard-coded rules that match in the client and in the miners (because it was All One Application to start).  We need to move to something more dynamic.  Some thoughts I jotted down last night:

Users want to know what fee to pay, given the constraints "I want this transaction confirmed in B or fewer blocks with probability greater than P".

If we think of that as an equation:
... then the question is can a client estimate f by looking at the block chain and/or observing transactions as they fly across the network and (eventually) get included in blocks?  Or can we come up with a protocol to communicate f between clients and miners?

My rule of thumb is "never inline methods more than 1 line long."

Unless you're doing something super performance-critical, in which case my rule of thumb is "don't change anything until after you've written a realistic benchmark."

But I'm an old-fashioned C++ coder, kids these days seem to want to put all the code in .hpp files.

To be completely sure you get all the donations you deserve, you should put the donation address on an https:// page.

Otherwise hackers can hijack http: pages if they can insert themselves into the network between you and your web visitors, and replace the donation address on the webpage with their bitcoin address.