Since my last status update the core development team has continued to make steady progress. We have no spectacular new world-changing features to announce, but that should be expected– in my experience, the best way to be successful is to try to make steady progress towards your goals every day. But expect that reaching your goals almost always takes longer than you expect, because you always run into unexpected setbacks and detours.

It was a pretty good month for making steady progress on the reference code; the only setback was a little time taken to roll out a 0.7.2 minor bug-fix release (release notes and binary downloads at SourceForge).

The core team received a grant of 470 BTC from the Foundation for infrastructure needs over the next year, which we promptly started to spend. The first purchase is a year’s rental of a fairly powerful (six-core, 12GB memory) dedicated server that we’ll run several virtual machines on. Matt Corallo has already moved the “jenkins pull tester” to the new machine, and we’re enjoying a much faster turnaround time from when pull requests are submitted or updated until sanity-tested build results (for both Windows and Linux) are available. We’ll be spending the rest of that grant on other infrastructure needs over the coming year; code-signing certificates for Windows and Mac are next on the spending priority list.

Testing and development of the next major release (0.8) continues, with testing being the bottleneck. As I’ve said before, writing code is a lot more fun than testing or reviewing it, but, especially for a project like Bitcoin where serious value is at stake, thorough testing and review is incredibly important. See the thread in the bitcointalk forums for how you can help.

A lot of my time in the last month has been working on getting feedback on, and consensus for, a new payment protocol. After lots of great discussion on the bitcoin-development mailing list resulting in over a dozen (so far) revisions to the proposal, I feel like it is solid enough to start creating a prototype implementation (code on github; patches that help tackle items on the TODO list very welcome!). Mike Hearn deserves a lot of credit– he did the initial prototyping and has been incredibly helpful contributing great ideas from the very beginning when this was only a half-baked idea, and continuing on through all the public discussions.

Coincidentally, Ilja Gerhardt and Timo Hanke just published a paper that is directly relevant: “Homomorphic Payment Addresses and the Pay-to-Contract Protocol.” I expect a future version of the protocol to be extended to support their ideas– the first version is designed to make that easy.

So… why is a new payment protocol important? A few reasons:

First, for security. Today the bitcoin payment protocol looks like this:
1. You get a bitcoin address from someone, via a website, email, QR code, etc.
2. You send bitcoins to that address.

That works, but is vulnerable to “man in the middle” attacks if the “get a bitcoin address” step is done over some insecure communication channel (like an insecure web page). If somebody can intercept the bitcoin address and replace it with one of their own, they might be able to trick you into sending them coins instead of the person you intend to pay.

I’ve never heard of that actually happening, but as bitcoin payments get more common it is only a matter of time before attackers decide it is worth the effort to try to replace bitcoin addresses that might be going through insecure web or email servers.

The new payment protocol makes life much harder for potential attackers, by working like this:
1. You get a “signed payment request” from someone, via a website, email, QR code, etc.
2. Your bitcoin software checks the signature to make sure it hasn’t been tampered with by an attacker.
3. You send bitcoins to the address specified in the payment request.

The second reason for a new payment protocol is also security. Creating much more secure wallets that remain secure even if your computer or mobile phone (or web server, if you are a merchant) is completely compromised by malware is still near the top of my development priority list. The payment protocol is a key part of that– signed payment requests will be used to make sure bitcoins are only sent to where they are supposed to go, after being properly authorized on more than one device.

The last reason for a new payment protocol is to make paying with bitcoin less geeky. Bitcoin addresses are not user-friendly, and neither is the experience of sending a transaction and getting no immediate feedback that you sent the right amount to the right address. The new payment protocol adds a human-readable, cryptographically-verified identity (so you are asked to approve an 11 BTC payment to “bitcoinfoundation.org” instead of “1BTCorgHwCg6u2YSAWKgS17qUad6kHmtQW“). It also optionally lets the recipient give the sender a message confirming that their payment was received.

There are a couple of other spiffy new features, like refund addresses, so merchants can easily refund overpayments or send bitcoins back to customers if their factory is invaded by zombies and they are unable to satisfy orders; see the proposal for all the details. It will take at least several months of steady progress before bitcoin wallets and merchants support the new payment protocol.