I wrote an article about some of the failures in wallet randomness we've seen in the past 12 months:

  https://medium.com/@octskyward/type-safety-and-rngs-40e3ec71ab3a

It's a 6 minute read, but the tl;dr summary is:

1) Find ways to make the type systems you are working with stronger, either through better tools or better languages

2) Try and get entropy as directly from the kernel as possible, bypassing userspace RNGs

I should practice what I preach - bitcoinj could be upgraded to use the Checker Framework for stricter type checking, and we currently only bypass the userspace RNG when Android is detected. I'll be looking at ways to make things stricter and more direct next year.

[HD wallets]

I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries. It is used by at least four Android wallets, three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets, for academic research projects and much more.

https://bitcoinj.github.io/

This release represents 8 months of work. The biggest new feature is HD wallets. Other notable enhancements include a bundled Tor client that can be activated with one line of code, support for multisig wallets, much faster and deterministic ECDSA, many API improvements and big upgrades to the included GUI wallet which can be seen in a new screencasted tutorial.

The commit hash of bitcoinj 0.12 is 83a9a71f3fff3f223d0737ad758b519a39dbbd62.

New in this release

Privacy enhancements:

• Wallets are now hierarchical and deterministic (HD) by default, using the BIP32 specification. Support for mnemonic codes (BIP 39) is also included. Change and receive addresses are no longer being reused. Old wallets are upgraded in place using the private key of the oldest non-rotating key as the seed bytes, so old backups remain valid.
  
• Thanks to devrandom, we have an integrated Tor mode using the Orchid library. The user does not have to install the Tor client as it’s all pure Java. WalletAppKit users can enable usage of Tor with a single line of code. This support should be considered experimental for now.

Thanks to Kosta Korenkov, we have an experimental multisig wallets implementation. Multisig (also “married”) wallets are HD wallets that are connected to a third party risk analysis service or device. When married, the wallet tracks multiple BIP32 key trees, keeps them in sync and starts vending P2SH addresses.

As part of this work, transaction signing is now pluggable. TransactionSigner implementations can be added to the wallet and will be serialized into and out of the users saved wallet file. Signers are given a transaction to sign in sequence. This is intended for risk analysis providers to provide a class that talks to their server to get a signature of the right form, so that all bitcoinj based wallets can be easily upgraded to support the new provider.

Reject messages are now deserialized and logged, though not yet exposed in the API.

Upgraded to Guava 16 and Bouncy Castle 1.51. Thanks to Peter Dettman and the rest of the Bouncy Castle team, bitcoinj now uses deterministic ECDSA for signing and we’re now using an accelerated secp256k1 implementation that exploits the special properties of this curve, for dramatically faster calculations.

Payment protocol code improvements: Some X.509 utility code was refactored out of PaymentSession for general usage. StartCom was added to the default trust store which was promoted to override the system trust store on non-Android platforms. A command line tool to dump requests to stdout was added.

Thanks to Andreas Schildbach:

• We are now BIP62 (canonical push encodings) compliant.
• A new Coin class replaces usage of BigInteger for marking values that are quantities of bitcoin. Formatting has moved into the new MonetaryFormat class.
• The wallet now saves the fee paid on transactions we calculated ourselves. This is useful for putting it into a wallet user interface.
• Transactions can have user memos and exchange rates attached, that will be saved by the wallet.
• Support for decrypting BIP 38 protected private keys has been added.
• Checkpoints can now be stored textually as well as in the old binary format.

There is also a new BtcFormat API that provides an alternative to MonetaryFormat that plugs in to the java.text framework.

Added new DNS seed from Addy Yeow.

Wallets can now have string->byte[] mappings attached to them, for lighter weight extensions.

Thanks to Richard Green, there is now a Python version of the ForwardingService program from the getting started tutorial. This shows how to use bitcoinj from Python using the Jython interpreter.

There is also a new Javascript tutorial.

bitcoinj now probes localhost for a Bitcoin node and automatically uses that instead of the P2P network, when present. This means any bitcoinj based app can be easily upgraded from SPV to full security just by running Core at the same time: no setup needed.

Thanks to Michael Bumann, there are now more example apps showing how to use parts of the API.

WalletTemplate/WalletAppKit improvements. WalletTemplate is a demo app that shows how to create a cross-platform GUI wallet with a modern style and 60fps animations. WalletAppKit is a very high level API for creating apps that have a Bitcoin wallet:

• Now supports mnemonic code and restore from seed words. A date picker is provided to cut down on the amount of chain that needs to be rescanned.
  
• Support for encrypting wallets. Password is requested when needed. The difficulty of the scrypt function is selected to always take a fixed number of seconds even if hardware gets more powerful.
• Some new animation and utility code backported from Lighthouse.
• Tor support

Thanks to Martin Zachrison, the micropayment channels implementation has received various improvements.

Thanks to Eric Tierney (Circle), the Postgres store can now take a custom schema.

The Bloom filtering API has been extended so FilteredBlock objects can now be produced from Block objects given a BloomFilter. Previously there was support for client-side Bloom usage but no implementation of the generation part.

Many other bugfixes, cleanups, minor tweaks and small new APIs.

Documentation and tutorials

A Javascript tutorial has been added, showing how to use bitcoinj from this language. More tutorials in other languages will come in future.

The “Working with the wallet” document has been significantly extended to cover encryption, watching wallets, HD wallets and multisig/married wallets.

A new document and accompanying screencast shows how to extend the WalletTemplate app to have a transactions list, and then make a native/bundled packages that don’t need the user to install Java. By following this tutorial you will learn how to make a basic cross platform desktop wallet of your own.

All other docs were refreshed to the latest APIs.

API changes

The package name has changed to org.bitcoinj and the core Maven artifact name is now “bitcoinj-core”. You can auto-port most of your code by running

Code:

find . -name '*.java' | xargs sed -i .bak 's/com.google.bitcoin./import org.bitcoinj./g'

Wallet.completeTx now throws more precise unchecked exceptions in edge cases, instead of IllegalArgumentException.

The use of BigInteger to represent quantities of Bitcoin has been replaced with the more efficient, type safe and useful class Coin. Coin is mostly source compatible with BigInteger so you can probably just do a search and replace to update your codebase. Utils.bitcoinValueToFriendlyString and friends moved to CoinFormat.

NetworkParameters.getProofOfWorkLimit was renamed to getMaxTarget for consistency with other Bitcoin codebases.

The library no longer uses the misleading term “nanocoins” to mean satoshis (the old term predated the use of the word satoshi to describe the smallest possible amount of bitcoin).

TransactionConfidence no longer tracks total work done.

Because outputs are now shuffled any code during that assumes the ordering is preserved will break. You can set the shuffleOutputs field of SendRequest to false to disable this behaviour if you need to.

The ECKey and HD API’s have changed quite a bit: several constructors were replaced with clearer static factory methods that make it more obvious how their parameters are interpreted. The new methods don’t change their behaviour depending on the pattern of nulls passed into them.

Some unit testing utilities have been moved to the new testing subpackage and cleaned up/rearranged. It should be easier to write unit tests for your app that need a simulated network now.

DeterministicKey now derives from ECKey.

We now use Utils.HEX.encode() and Utils.HEX.decode() to do translation to and from base 16.

Transaction.hashTransactionForSignature was renamed to just hashForSignature.

The subVer string sent by bitcoinj now has a lower cased first component.

I hired Saivann to make us a new website and as usual, he delivered some excellent work. Check it out!

http://www.bitcoinj.org

or SSL version at

https://bitcoinj.github.io

The new site is much less noisy and easier to navigate. Let us know what you think.

We've merged a bundled Tor client to git master, what will become bitcoinj 0.12. If you are a wallet author please help us test it out:

https://groups.google.com/forum/#!topic/bitcoinj/XlL5jJs9ur8


Enabling it is a singe line of code for most apps, but we need to find performance and correctness bugs and squash them before it can be rolled out to a large number of users.

I received a beta TREZOR from SatoshiLabs. I'll be ensuring that the HD wallets support in bitcoinj is compatible with it, as a first step to allowing any bitcoinj based wallet app to use the device.

The device works perfectly and was very easy to set up. It is extremely light and comes with a way to attach it to a keyring, though I think for now I'll keep it at home. As part of setting up the device, it generates a new random seed and you write down the 12 words into a booklet which comes with the device: that's your paper wallet. To make a payment you use the web app, and it asks you to confirm first the destination and then the amount+fee (so you press twice). The instructions are clear and simple at all times, and the performance is excellent - there are no long waits or other interruptions.

The web software still has a couple of minor bugs, but nothing that interferes with usage.

Version 1 of the system does  not yet support BIP 70, so when you see a confirmation, it's for the raw Bitcoin address. Future releases are planned to support BIP 70 so you will see a more useful and harder to tamper with confirmation message that includes the name of who you are paying.

I was one of the first supporters of the TREZOR project and I'm happy to report that together stick, slush, Alina and the others at SatoshiLabs have actually exceeded my expectations I'm very much looking forward to the device shipping.

[Notable changes and new features]

(mods: can we leave this in the general dev section for a few days before moving it to the the bcj specific section? thanks)

Hello,

I'm pleased to announce the release of bitcoinj 0.11, a library for writing Bitcoin applications that run on the JVM. BitcoinJ is widely used across the Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit, Hive, blockchain.info, the biteasy.com block explorer (written in Lisp!), Circle, Neo/Bee (Cypriot payment network), bitpos.me, Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic advanced contracts research and more.

The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The commit hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin key as with previous releases (check their release announcements to establish continuity). Additionally, this email is signed using DKIM and for the first time, a key that was ID verified by the Swiss government.

Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
Signature for last paragraph: H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg=

Notable changes and new features

• Thanks to Ken Sedgwick, an implementation of BIP39 ("Mnemonic code for generating deterministic keys") has been added. This is compatible with the latest Trezor implementation.
• Thanks to Mike Belshe, the wallet can now send to P2SH addresses.
• Thanks to Matt Corallo, the network layer was rewritten from scratch. It no longer depends on Netty, and it now supports both blocking and non-blocking sockets. In practice that means Java's built in support for transparent SSL and SOCKS becomes available again, which in turn means connecting via Tor is now possible. The new framework is lightweight, easy to understand and has been running a DNS seed crawler for some months now.
• Thanks to Kevin Greene, we've added some support for the BIP70 payment protocol. Wallet authors can now consume payment requests, check their signatures and submit payments with the new easy to use PaymentSession class. The wallet-tool command line UI has support and an article explains how to use it.
• Thanks to Miron Cuperman, the wallet can now watch arbitrary addresses and scripts. The wallet could previously watch an address as long as the public key was known. Now it's possible to watch for addresses even when the public key is not known.
• Also thanks to Miron, Bloom filtering was also improved. The system now tracks false positive rates and cleans the filter when FP rates get too high. Unfortunately, some privacy bugs in Bloom filtering remain, which could (amongst other things) allow a malicious remote peer to test whether you own a particular key.
• Thanks to Alex Taylor (bitpos.me), a new PostgreSQL based pruning block store was added. This block store is fast, and indexes the UTXO set, allowing for fast lookup of the balance of any given address.
• A Java 8 based wallet template app is now included. The template is designed for people writing contract based applications. It provides a simple app that can be copy/pasted, which connects to the P2P network, manages a wallet, and provides a GUI that shows progress, balance, address+qrcode for receiving money and has a button that is used to empty the wallet out. It's designed to have an attractive and modern look, with tasteful animations and artwork.
• Micropayment channels got many big improvements to the API and implementation. The release in 0.10 can be seen as a beta, in this release the micropayments code has been taken for a test drive for a couple of real apps and many rough edges polished as a result.
• The default USER_THREAD executor can now be replaced, allowing a 1-line switch of all callbacks onto a thread of your choice instead of needing to override each callback, each time. This should simplify and clean up the GUI code of wallet apps significantly.
• The WalletTool command line app has a more convenient user interface now.
• A new DNS seed has been added. The seed is run by Christian Decker, from ETH Zurich.
• bitcoinj 0.11 will shortly be available via Maven Central. Please use the dependency verifier plugin and/or check the PGP signatures on the uploads, if you use this!

Smaller improvements

• We finished adding nullity annotations to the API. You should now be able to assume that any method not annotated with @Nullable won't ever return null values.
• The WalletAppKit got a bunch of new features and convenience APIs.
• The wallet will now create inputs with dummy signatures if the private key for an output is missing, rather than throwing an exception. You can then edit the input later to substitute in a real signature. This is useful when the signing is being done elsewhere, outside of the library.
• In full verification mode, execution of scripts (i.e. checking signatures) can now be switched off. This is useful if you trust the source of the chain and just want to calculate the UTXO set.
• The wallet risk analysis code is now pluggable, better documented and checks for finality in a more sensible way.
• Various memory usage and flow control optimisations were made to allow much larger wallets to sync on Android.
• The transaction broadcast algorithm was changed to be more robust.
• Double spend handling in the wallet was improved.
• Generated signatures now use canonical S values. This will aid a future hard-forking rule change which bans malleable signatures.
• Some fixes were made for enable usage with the Orchid Tor library. Further support for Tor is planned for future releases.

Notable bug fixes

• Some hard-forking full verification bugs were fixed.
• Thanks to Miron, PeerGroup now performs exponential backoff for peer connections, for instance if we cannot connect to them or if they disconnect us. This resolves an annoying bug in which if the library was configured with a single peer that was down, it would spin in a tight loop consuming battery.

API changes

• Some functionality of the Wallet class was moved into separate classes under the wallet package.
• The micropayments API and protocol changed. New clients/servers are not compatible with apps running against previous releases.
• The Wallet sendCoins/completeTx methods no longer return booleans or null to indicate failure, they now throw InsufficientMoneyException or a subclass if the transaction cannot be completed. The exception object typically contains information on how much money is missing.
• Some mis-named methods in the HD key derivation API were renamed.
• The WalletEventListener interface has an extra method for watching scripts now.
• Peer discovery classes moved under the net.discovery package
• Any APIs that relied on Netty are now different.

New documentation

• An article on the networking API
• Info on testing your apps, and how to use regtest mode to make a private Bitcoin network that allows you to mine blocks instantly.
• A reference table showing which API's implement which Bitcoin Improvement Proposals (BIPs).

Please note that as I am no longer employed by Google, after 0.11 signing the Google contributor license agreement will no longer be necessary. I look forward to welcoming contributions from Andreas Schildbach now this requirement has gone away. Also, in future I plan to re-namespace the library from com.google.bitcoin to org.bitcoinj - auto-migration scripts will be provided when this is done.

[Background]

Summary: I propose that each wallet developer include a custom root cert in the set of roots they accept for the payment protocol and that we establish our own mini PKI / X.509 extensions for the Bitcoin early adopter community.


Background

bitcoinj 0.11 will soon be ready for release. Just before we release it I'm planning to merge some initial support for the BIP 70 payment protocol, though it won't be very sophisticated. In particular it won't support generating payment requests, only consuming them. But ... after a bit more work to do such as adding support to the wallet-tool command line app (the bitcoinj equivalent of sx) and ensuring that we can load the key store on every supported platform, we'll be ready.

One of the criticisms levelled at the design of the payment protocol is that it uses the PKI, a system of certificate authorities that validate ownership of "identities" (arbitrary small pieces of text, actually) and charge money for the privilege.

These days you can get free certificates for email addresses and domain names. Comodo has a very simple and easy to use way to get them based on HTML5: you just provide your email address and name, which isn't validated so it can be fake, and then your browser generates the private key locally and stores it. Then you click the verification link delivered to your email address, and the process completes with the fully signed cert being installed by the browser into your operating system keystore. It's as easy as signing up for a website and after doing that, if you use a desktop mail client like Apple Mail.app, Thunderbird etc then you can sign your mails and receive encrypted mails from other people without PGP. The same certificate can be used to sign payment requests. Try it out, it won't take long. The keygen tag actually works for any website.

Issues with the current system

Although getting an email address or domain cert is easy and free these days, there are still some inadequacies here:

• There are over a hundred CA's, of which only two issue free certs (Comodo and StartCom). Others also did in the past but they tended to get bought by Symantec which then discontinued the free services. Free is important to get wide usage.
• Often people communicate using identities which are not email addresses, like forum/reddit handles/social network profiles/IM network handles/etc. CA's do not issue certificates for these kinds of identity.
• Even for a free Comodo email address cert, you have to sign up via a web browser. There's no API to do it from apps.

What stops someone simply setting up a new CA as part of the existing system and adding all these features? In theory, nothing. In practice, a lot. Existing users of the PKI are things like operating systems and web browsers, all of which get distributed to hundreds of millions or even billions of people. Often, CA certs are put inside embedded devices like cameras or TV sets. Update cycles are slow. This makes the cost of a leaked root private key astronomically large - potentially billions of devices must be updated and millions of identities revoked and reissued.

Because the PKI system is so large, and the cost of root cert revocation so huge, browser and OS makers require a high degree of professionalism before they'll consider adding you as a root CA. Reducing risk means expensive measures are taken to preserve security:

• Root keys are stored offline and used only to sign intermediate certificates. This is a bit like a "cold wallet".
• Intermediate keys are stored in dedicated tamper-proof hardware security modules.
• CAs must allow users to mark their certs as revoked so when users get hacked or lose their private keys, people automatically stop trusting those keys. That means servers have to be funded and run to serve real-time revocation data via OCSP. The bandwidth and CPU's for this is a cost of business.
• Employees must be background checked and business processes put in place to stop rogue employees issuing fake certs to themselves.
• All the above is too hard for Mozilla/Chrome/Apple/Microsoft/Debian/etc to check themselves, so they outsource verification to professional auditing firms, who of course don't work for free.
• Because all the above is costly, CAs tend to charge for their certificates, which in turn means people expect tech support and other expensive things, raising the cost still further.

The above requirements are just a flavour of what it takes to get into the Mozilla or Windows/MacOS root cert stores. That's why you can't do it, and if you did, you'd end up charging money and selling out to Symantec as well.

An alternative

Is all the above really necessary for every use case? Sometimes the answer is definitely yes - if you see your Trezor say, "Pay 5 BTC to Overstock, Inc of Salt Lake City, USA" you want that statement to actually be meaningful and hard to forge, and Overstock can easily swallow the cost of paying someone to verify who they are. The PKI and existing CAs get us that functionality.

On the other hand, for a message like "Pay 0.5 BTC to bitcointalk user satoshi" you don't really need that level of security. You know that bitcointalk is just a web forum that gets hacked from time to time and that forum handles don't mean much, but you're probably OK with that for small purchases. And if all your communication was on this forum with a particular user handle, then seeing an email address or a real name doesn't actually help because that's not the identity you're expecting and have built trust in.

There is no way in hell that Mozilla is going to accept a root authority run by Theymos for a couple of reasons:  bitcointalk has a terrible security track record so it'd be very likely to get revoked, and forum names don't mean anything to a web browser anyway. But nothing stops wallet app authors from trusting Theymos for this purpose.

What does this mean in practice? Let's say that when bitcoinj 0.11 rolls around it checks all the OS provided root certs, AND also a set of custom root certs for various providers that the Bitcoin community uses a lot like this forum, or reddit, or the Bitcoin Foundation, etc. A final root cert owned by the wallet author (or possibly me in this case) can also be added so new providers can come online without waiting for wallet users to upgrade.

These certificates are regular X.509 certs but with a new extension field that indicates how subcerts should be displayed to the user, for instance:

Code:

   walletRenderExtension:  "bitcointalk user $TOKEN$"

Now when this forum issues someone a cert with CN=satoshi, wallet software knows to display it in the UI like this:

Pay 0.5 BTC to bitcointalk user satoshi?
Verified by bitcointalk.org

... same for reddit, #bitcoin-otc, localbitcoins, etc.

What does this look like for the user? Try it out and see. For a browser like Chrome or Safari, when the browser installs the cert it does so into a global keystore that is accessible to wallet apps too, so that's all that's required to install it.

This would upgrade the security for many common payment scenarios without much cost. Of course the chances of hacks/screwups and global revocations are pretty high, but we're still a small community mostly made up of tech-savvy enthusiasts so we can tolerate that for now.

The nice thing about making minor extensions to X.509 rather than trying to support a second PKI is that we get to reuse all the infrastructure, software and protocols built to support the existing system. For instance, if the bitcointalk admins are handling people who get their accounts hacked and helping them restore access then they could also start running an OCSP server so any certificates issued during the time the account was hacked get automatically revoked. From the perspective of wallet devs and site admins it just requires reusing existing software, so it's a small amount of extra work.

http://www.theguardian.com/technology/2014/jan/07/bitcoin-me-how-to-make-your-own-digital-currency

An article about alt coins, Matt's coingen.io site and I'm quoted talking about how alt coins demonstrate the democratic nature of cryptocurrencies. The journalist (Alex Hern) uses coingen to make his own coin and mines on it a bit.

Move over Dogecoin: the Herncoin is here. But what can making your own currency teach you about the world of bitcoin?

Yesterday afternoon Patrick and Jinyoung went to the US Federal Trade Commission to give them a Bitcoin tutorial and answer any questions they had. A lot of FTC staff turned up, probably between 60 and 70. I dialed in via conference line and gave a presentation on consumer protection techniques, specifically I talked about:

• Hardware wallets
• Dispute mediated transactions
• The payment protocol
• Micropayments

It seemed to go down OK and the questions were all pretty reasonable.

There are quite a lot of them in e.g. project development.

Hi there,

Some of us are hanging out in IRC to help with any questions or discussions you may have. Come join us!

irc.freenode.net
#bitcoinj

http://www.newscientist.com/article/dn24620-bitcoin-moves-beyond-mere-money.html#.Uo3bWLWJDAR

A short intro piece to on coloured coins, contracts etc.

Bitcoin is money – people can use it to buy anything from pizza to plastic surgery. The meteoric rise of the online currency has caused everyone from financial regulators to law enforcement to the US Senate to stand up and take notice. But a growing group of computer scientists think this is just the beginning. They are convinced that Bitcoin's real value is not in providing the world with a currency free from government intervention, but in the technology which underpins it, a secure system of verifying transactions that they believe has the potential to vastly disrupt the way we exchange goods and services around the world.

An article on the concept variously known as fidelity bonds, anonymous passports, SINs, proofs of sacrifice:

   http://www.economist.com/blogs/babbage/2013/11/internet-security

Babbage unfortunately wrote the article so it sounds like I invented this concept. It's really the result of collaborative brainstorming on this forum between many people, but Jeff Garzik and especially Peter Todd deserve a tip of the hat for their contributions.

Internet security
Buying a new identity
Nov 19th 2013, 20:44 by G.F. | SEATTLE

BITCOIN hits the headlines when the virtual currency's exchange rate hits new highs (or lows) against real-world monies. And so it did when the rate spiked to $900 from around $400 a week earlier, following some positive noises during a hearing on it and its kind in the American Senate. (It has since fallen back to around $700.) Less talked about is the potential of Bitcoin's ingenious inner workings to transform other online activities.

Take internet identities, used to shop on the web, validate e-mail addresses or create social media accounts. Mike Hearn, one of the core developers of the software that powers the Bitcoin system (whose niceties we explain here), says that creating such identities poses a conundrum. Most forms of online ID (eg, a social-media account) are verified using other forms (such as an e-mail address) which are easy to crack, hijack or forge.

Mr Hearn suggests relying instead on the cryptographic trick that ensures the security of Bitcoin transactions. Bitcoin is a peer-to-peer computer network made up of its users’ machines, similar to BitTorrent, a file-sharing system. New Bitcoins are minted, or "mined", as the computers in this network execute hard number-crunching tasks. The entire network is then used to monitor and verify both the creation of new Bitcoins through mining and the transfer of Bitcoins between users.

Every new transaction is broadcast across the Bitcoin network and appended to a collective log, called a block chain, of all previous transactions in the system. The machines in the Bitcoin network communicate to create and agree on updates to the block chain. Roughly every 10 minutes a user whose updates to the log have been accepted by the network is awarded a fixed number (currently 25) of new Bitcoins.

The system makes it computationally difficult to create a doctored block—one containing illicit transactions such as sending the same Bitcoins twice to two people, say, or reversing a Bitcoin transfer to a vendor after he had dispatched the purchased product. That is because having such forged transactions validated and attached to the globally accepted block chain would require outpacing the network's combined computing power. Only a fraudster who controls more than half of the network's total number-crunching capacity—a tall order—could achieve such a feat, and only for transactions less than about an hour old.

Mr Hearn's secure-ID scheme similarly relies on a block chain and on rewarding miners who keep it up to date. An identity would be established by performing a transaction in which no Bitcoins are transfered from the owner to another named party. Instead, the owner would donate a sum—say, $200 worth of Bitcoins—that the first miner to approve a block with this transaction in it would get as his mining fee. (Since the winning miner is always revealed at random, the owner cannot simply redirect the virtual cash back into his account.)

The donor thus possesses a receipt of the transaction that can always be verified against the public Bitcoin ledger. Stealing someone's identity would require swiping his private key. It comes in the form of a unique private cryptographic key mathematically matched to a public key embedded in the donation record. The Bitcoin-based private key then comes to resemble traditional digital signatures, which also use a combination of private and public keys to verify the holder's identity. Except, that is, that Bitcoin's anonymity ensures that the donor's identity would no longer need to be verified by an outside, signature-granting authority. It could, in other words, be confirmed without ever being revealed to anyone.

Like account-passwords for many sites, private keys are vulnerable if stored in online Bitcoin wallets (which have been hacked); much less so if maintained on a user's computer (since hacking a particular desktop, while not impossible, is harder than inflitrating the cloud). Serious Bitcoin users anyway keep their private keys in "cold" storage on unpowered hard drives that are never linked up directly to internet-connected computers.

The scheme also has another feature Mr Hearn thinks desirable: accountability. If the ID-buyer uses it to access a website only to break its rules—for instance by trolling on online forums or slandering someone on Facebook—and be banished from it, he can always go back to Bitcoin and secure a new Bitcoin ID simply by making another donation. But at least it will cost him.

http://www.wired.co.uk/news/archive/2013-11/18/peter-sunde-hemlis-political-apathy

Pirate Bay cofounder Peter Sunde spoke to Wired.co.uk about the problems with the file-sharing website in its current form, the "imminent death" of peer-to-peer and the centralised services that leave us open to NSA surveillance. He also urges people to dispel their political apathy to prevent the emergence of a new Stasi-style era of oppression.

People who are disenchanted with politics and the financial system should try and engage with the democratic process rather than turn to technology for alternative methods of doing things, says Peter Sunde, cofounder of The Pirate Bay.

"You can't beat politics with new technology all the time. Sometimes you have to actually make sure that politics are in line with what people want. A lot of people are giving up on politics and thinking they can solve issues with technology. These kind of arrogant behaviours towards the rest of the society are a bit disgusting," Sunde told Wired.co.uk in a Skype interview.

His response was provoked by a question about Bitcoin, a technology that he thinks is "interesting" and has a fascinating story behind it, but one that he feels is symbolic of a depressing widespread lack of trust in politics.

On the 18th November, which is a bit over a week from now, members of the Bitcoin community will be testifying in front of the US Senate in two committee hearings:

1) Senate Homeland Security & Governmental Affairs (HSGAC) committee

2) Senate Banking committee

The hearings have been called so US representatives can learn about Bitcoin and in particular, about its impact on law enforcement and banking. The HSGAC hearing will have two panels. The first one consists of members of US LE agencies. The second is the industry panel and will have, amongst other people, Patrick Murck of the Bitcoin Foundation on it.

For those who don't know Patrick, he is pretty much "the Bitcoin lawyer" and is one of us - he has been involved behind the scenes with Bitcoin for a long time now, I talk with him frequently and I know he will do a great job. That said, Patrick was not our first choice. Actually the Senate invitation was for Jon Matonis, who was our first choice. Unfortunately Jon couldn't make it on such short notice. Gavin would have been our second choice, but he is in Australia visiting family at the moment and also was not available.

The selection of the other panelists are also, I think, good news for us - they're people with a strong understanding of the Bitcoin space, people who have got credibility and achievements under their belt. Unfortunately my understanding is that it would be a faux pas to reveal their names here for some reason, but you'll find out who they are in a week.

edit: the names of the people appearing in front of the Senate Banking committee have now been published

Preparatory work has already begun and Foundation staff are working on some written testimony that will be submitted along with the oral testimony. Patrick will be heading to DC soon in order to start rehearsing and preparing. As executive director, Jon is of course going to be instrumental in figuring out what we're going to say, although he's being helped by other members as well of course. If you want to suggest ideas and contribute, go join the Foundation and post to the forum.

In recent times I've occasionally seen people sometimes question what the purpose of the Foundation is. Well, this is one of the reasons it was created. There are many powerful institutions in our world run by people that simply don't or won't take part in forums like bitcointalk, mailing lists and so on. The way they operate is by holding meetings, conferences and hearings like this one. The Foundation not only funds development but acts as a bridge between these two very different worlds.

Thanks,

Mike Hearn
Chair, Law & Policy committee
Bitcoin Foundation

[Open the wallet-template code in a new tab]

A few days I discovered that there's yet another SPV wallet app being developed on top of bitcoinj, meaning we have:

• MultiBit
• Bitcoin Wallet for Android
• Hive
• MacWallet
• Bitcoin Touch for Ubuntu

So I want to plug this fact and remind people that it's never been easier to design and build the wallet of your dreams. You can do it in any language on this list, which includes Python, Ruby and JavaScript with simple "out of the box" usage, and we're making it easier over time to use C/C++/Objective-C if those are your cup of tea too.

Let me show you how easy it is to build a simple, attractive wallet app. It has the following features:

• Runs on Windows, Linux and MacOS
• Can fully catch up with the block chain in a few seconds, even for new users.
• Has a progress bar that watches sync progress and slides off the screen when done. An address to send money to fades in when synced.
• Has a clickable Bitcoin address that will either open a different wallet app, or show a QRcode, or copy to the clipboard.
• A button that lets you empty the wallet out, when you're done with it.
• A widget (in the send coins screen) that validates the Bitcoin address has no typos in it, and highlights the edit in red if it does.
• It lets you spend unconfirmed transactions, although changing that is just one line. So money turns up immediately.

It is not meant to be a full wallet app and does not have a list of transactions, exchange rates or other such things, although those would not be hard to add.

Open the wallet-template code in a new tab.

It's written in Java 8, which is more or less like your fathers Java except with easy lambda functions, support for some functional programming stuff and a nice UI toolkit. You could write such an app in lots of other languages though, and the code would probably be shorter.

Take a look at Main.java and see the code that creates the WalletAppKit object. That's all you need to bring up a connection to the P2P network and synchronize a wallet with it. Easy.

Go look at the Controller class. It handles the UI logic for the main screen. It's simple - the largest method in this class simply sets up the animation that runs when the blockchain sync is finished. It also wires up the wallet balance to the UI.

Open SendMoneyController. It handles the UI logic for the send coins screen. After the user enters a valid Bitcoin address, it creates a transaction that sends all the money in the wallet to that address (you could ask the user to enter an amount of course). Then there's some code to handle popping up a crash window if something goes wrong, and updating the UI to reflect the transaction as it propagates across the network. Actual logic here is about 50 lines of code, max.

In the controls directory, you can see two classes that manage working with Bitcoin addresses. One of them can be used to make an edit box validate an address and enable/disable buttons depending on if it's valid. The other creates a clickable address widget that can also display a QRcode.

The utils directory contains a variety of misc utilities that aren't Bitcoin specific, like for popping up themed alert windows and so on. It's not relevant here.

I hope you will agree that this isn't much code. The UI layouts are all edited with the free Scene Builder app.

Put simply, if you have even basic programming experience and you aren't happy with existing wallet apps, now is the time to design the UI of your dreams. All the heavy lifting is handled for you by the frameworks and you're left to just draw on the canvas and make the app work how you want.

I wanted to formally welcome to new bitcoinj based wallets - Hive and MacWallet. Both are Mac-only wallet apps based on the Hive teams work on a Cocoa bitcoinj binding framework.

It's great to see people explore different UI ideas on top of the library. If you've been thinking you're not happy with existing wallet UIs, but  were previously put off making your own by the complexity of the Bitcoin protocol, I hope these examples inspire you.

If you're a Python or Ruby developer then it's even easier because you can use Jython or JRuby to write code as you normally would, but on top of the JVM with direct access to the entire API!

I modified my node to print out the subVer strings of connecting clients, which it has been doing since the 24th September. Here is the full list of subVers it has seen.

There's no particular point to this post. I just found it interesting and others might too. A few things that jumped out at me:

• There are some things pretending to be the Satoshi client but aren't. Satoshi:0.8.5 is like this, as is "/Satoshi:0.8.5/" with quotes. Please don't do this. If you're making your own implementation or modifying it, please select an appropriate subVer. Nothing bad will happen.
• Quite a few people are on old versions of MultiBit or the Android app, although both of them have update alerts. If you're one of these people, please upgrade! Even if there are no new features you want, it's important to keep up with bug fixes and other things in the underlying libraries.
• blockchain.info is on an old version of bitcoinj - Ben if you see this, please do upgrade once 0.10.2 comes out, it has various important bug fixes over the version you're using.
• Generally the list is biased towards bitcoinj, but that's probably because clients based on it tend to connect, use the network for a few minutes then disconnect as opposed to holding connections open for a long period of time.
• Gocoin, libbitcoin, Ufasoft Coin all feature. Neat.
• Also, Snoopy, Grokked, "Bitcoin Rooster" and btc-dev. Anyone know what these are? I couldn't find any reference to them.
• SatoshisBukkit seems to be a Minecraft plugin that lets you send money in-game: cool!

Code:

   2115 /BitCoinJ:0.10.1/Bitcoin Wallet:3.21/
   1971 /bitcoin-seeder:0.01/
   1057 /BitCoinJ:0.10.1/MultiBit:0.5.14/
    833 /BitCoinJ:0.10.1/Bitcoin Wallet:3.17/
    543 /BitCoinJ:0.8-SNAPSHOT/DNSSeed:>9000/
    527 /Satoshi:0.8.5/
    524 /Satoshi:0.8.1/
    270 /BitCoinJ:0.9/MultiBit:0.5.13/
    265 /Satoshi:0.8.3/
    210 
    162 /BitCoinJ:0.10.1/Bitcoin Wallet:3.19/
    127 /Satoshi:0.8.4/
    106 /BitCoinJ:0.9/Bitcoin Wallet:3.14/
     84 /Satoshi:0.8.2.2/
     73 /BitCoinJ:0.9/MultiBit:0.5.12/
     57 /Satoshi:0.8.0/
     49 /btc-dev:0.1/
     38 /Satoshi:0.7.2/
     37 /BitCoinJ:0.8/Bitcoin Wallet:3.04/
     35 /BitCoinJ:0.8/Bitcoin Wallet:3.08/
     31 Satoshi:0.8.5
     30 /BitCoinJ:0.9/Bitcoin Wallet:3.13/
     30 /BitCoinJ:0.8/MultiBit:0.5.9/
     30 /BitCoinJ:0.8/MultiBit:0.5.11/
     27 /BitCoinJ:0.9/Bitcoin Wallet:3.11/
     25 /BitCoinJ:0.8/Bitcoin Wallet:3.01/
     22 /BitcoinJS:0.2.8/
     22 /BitCoinJ:0.10/Bitcoin Wallet:3.16/
     21 /Satoshi:0.7.1/
     19 /BitCoinJ:0.8/Bitcoin Wallet:3.06/
     18 /BitCoinJ:0.6.1/
     18 /BitCoinJ:0.10/Bitcoin Wallet:3.15/
     16 /Satoshi:0.6.3/
     15 /BitCoinJ:0.5.1/MultiBit:0.4.2/
     15 "/Satoshi:0.8.5/"
     14 /BitCoinJ:0.9/Bitcoin Wallet:3.09/
     13 /Satoshi:0.8.99/
     11 /BitCoinJ:0.8/MultiBit:0.5.10/
      9 /BitCoinJ:0.8-SNAPSHOT/Blockchain:3.6/
      8 /BitCoinJ:0.8-SNAPSHOT/Blockchain:3.58/
      8 /BitCoinJ:0.11-SNAPSHOT/
      8 /BitCoinJ:0.10/ubc.Ubc:1.0/
      7 /BitCoinJ:0.8/Bitcoin Wallet:3.03/
      7 /BitCoinJ:0.10.1/Bitcoin Wallet:3.18/
      6 /Satoshi:0.7.0.3/
      6 /BitCoinJ:0.7.3/Bitcoin Wallet:2.48/
      5 /Satoshi:0.8.5/Grokked:1.02/
      5 /BitCoinJ:0.8/Bitcoin Wallet:3.05/
      5 /BitCoinJ:0.8/Bitcoin Rooster:0.0.2/
      5 /BitCoinJ:0.7.3/MultiBit:0.4.23/
      4 /Ufasoft Coin:0.58/
      4 /Satoshi:0.8.4/Grokked:1.02/
      4 /BitCoinJ:0.9/Bitcoin Wallet:1.0.0/
      3 /Ufasoft Coin:0.74/
      3 /BitCoinJ:0.10/SatoshisBukkit:0.2/
      2 /Satoshi:0.6.2.2/
      2 /Satoshi:0.6.0.6/
      2 /BitCoinJ:0.9/Bitcoin Wallet:3.12/
      2 /BitCoinJ:0.9-SNAPSHOT/Bitcoin Wallet:3.08-bitcoinj0.9/
      2 /BitCoinJ:0.8/TestService:1.0/
      2 /BitCoinJ:0.8/Bitcoin Wallet:3.02/
      2 /BitCoinJ:0.10.1/Bitcoin Wallet:3.17-blackberry/
      2 /BitCoinJ:0.10-SNAPSHOT/Bitcoin Wallet:3.14-bitcoinj0.10/
      1 /libbitcoin:1.0.10/
      1 /Ufasoft Coin:0.72/
      1 /Snoopy:0.1/
      1 /Satoshi:0.8.99/next-test:20130721/
      1 /Satoshi:0.8.2/
      1 /Satoshi:0.7.0.99/
      1 /Satoshi:0.6.2/
      1 /Gocoin:0.7.7/
      1 /Gocoin:0.7.6/
      1 /BitCoinJ:0.8/Bitcoin Wallet:3.08-blackberry/
      1 /BitCoinJ:0.8/Bitcoin Wallet:3.07/
      1 /BitCoinJ:0.7/MultiBit:0.4.21/
      1 /BitCoinJ:0.7/Bitcoin Wallet:2.40-blackberry/
      1 /BitCoinJ:0.7.3/Bitcoin Wallet:2.49/
      1 /BitCoinJ:0.7.1/MultiBit:0.4.22/
      1 /BitCoinJ:0.6/Bitcoin Wallet:2.33/
      1 /BitCoinJ:0.10/
      1 /BitCoinJ:0.10-SNAPSHOT/SendCoinService:1.0/
      1 /BQS:0.0.1/

From the folks who brought you ZeroCoin, here is a new paper on anonymous credentials that relies on Bitcoin (actually NameCoin). Such schemes have applicability to all kinds of things we care about like anti-sybil attacks.

http://eprint.iacr.org/2013/622.pdf

I haven't really digested it yet, so it's currently not clear to me how it's different or better to anonymous passports/SINs/proofs of sacrifice:

https://en.bitcoin.it/wiki/Identity_protocol_v1

I plan to re-read it when I have more time and think about it.

[What is the payment protocol?]

Recently Gavin merged support for BIP 70, 71 and 72 into Bitcoin-Qt. BIP 70, aka the payment protocol, is intended to be a big change to how people use Bitcoin. A lot of questions about it come up repeatedly, so here's an attempt to answer the most common ones.

What is the payment protocol?

Old timers will remember that Bitcoin v0.1, the first version ever released, allowed you to pay people in two ways. One was by entering a Bitcoin address. The other was to enter an IP address. If you entered an IP address, your computer would connect to the node on that IP and run a rudimentary payment protocol that involved asking the node for a fresh public key, then uploading the payment transaction directly.

Satoshi thought this payment protocol would be how people mostly used Bitcoin. It had some advantages, like guaranteeing a fresh address. He originally intended addresses to be used only for when the recipient was offline. But he was wrong - addresses quickly came to dominate and hardly anyone used the pay-to-IP feature. Eventually it was removed.

Why did it fail?

One reason is that it wasn't very secure, anyone who could MITM your internet connection (like someone sharing your wifi) could steal money sent this way. Another more practical reason is that back then there were no online shops that accepted Bitcoin. In fact Bitcoin was a Windows-only pure GUI app with no JSON-RPC API so nobody could even build online shops. So you never knew if the person you were trying to pay would be online or not at the time, meaning giving an address was more reliable. Also: NAT, firewalls, etc.

But it wasn't a bad idea and so now we're bringing it back, but with a better design. The hope is that over time this will come to replace Bitcoin addresses for most usages. But don't worry. Addresses aren't going to disappear. They'll still be around if you want them.

How does it work?

It's a way to format a small piece of data (think file) that contains instructions on how to pay someone (a PaymentRequest message), and then a formal specification of how to satisfy those instructions by submitting a Payment message. The data is designed to be extensible in future so we can add lots of useful features.

In future, clickable bitcoin links will look like this:

bitcoin:1EZEqFBd8yuc9ir2761987q7k3VcALC8YQ?request=https://bitcoinstore.com/r/aBcdE

When clicked, your wallet app will download the request URL and read the PaymentRequest it gets. The request message contains another URL, which is where to submit the finished transaction to (instead of/as well as broadcasting it to the P2P network).

Who is implementing the new protocol?

Support will be in the next Bitcoin-Qt release, and is being worked on for MultiBit/Android Bitcoin Wallet, CoinBase and CoinPunk. BitPay also committed to implementing it, so all merchants who use their services will get support automatically. If you're planning to support it, let me know and I'll add you here!

What's wrong with Bitcoin addresses?

Lots. They lead to privacy leaks, they are inflexible and tough to extend with new features, they aren't authenticated and they're one way only.

Why do they lead to privacy leaks?

The standard way to use an address is one address per payment received (if your wallet makes that easy to do). This can lead to privacy leaks in the following scenario.

Say you work for a small coffee shop which accepts Bitcoin payments of say 0.01 coins for a coffee. Over the month lots of these small payments get accepted. At the end of the month you get your salary, so you give your employer a fresh address. They make a payment to that address by collecting together lots of the coffee payments and generating one giant salary-sized output.

You then go to the pub and your friend says, hey mate, you owe me $10 for losing that bet we made last week (or whatever). So you send him $10 worth of Bitcoins, of course your wallet goes and selects your salary output to do that. Your friend can now look at the transaction he received and see that it came from a single large, salary-sized looking output. Now they know how much you earn.

A better way would be if you gave your employer 100 addresses, and they could then pay you with 100 transactions that re-allocate small numbers of coffee payments to your keys. Then the linkage would be much smaller. But in practice nobody does this.

How does the payment protocol solve that?

The request message allows you to request the payment be spread over multiple outputs (which don't have to be pay-to-address type outputs at that point, they could contain any script, like multi-signature scripts). It also lets the payer submit multiple transactions as part of satisfying the same payment. When an app generates a payment request (e.g. to get your salary), it knows how much money it's requesting and it can spread the money over many outputs. They payer might still generate one mega-transaction, but it's smarter for the payer to try and match up what it's got most closely with what's requested, to maximize privacy and minimise leakage.

Why does the sender submit transactions directly to the recipient?

Currently to pay someone you broadcast transactions to the P2P network and the recipient waits for them to arrive. This works OK, but can be inflexible. For instance, what if the sender doesn't have an internet connection? What if they're behind an evil firewall that only allows web traffic? What if the recipient has a deal with a specific miner and doesn't want to broadcast the transactions at all?

In the new payment protocol, the request contains instructions on how to submit the payment. Typically, the wallet will be given an HTTPS URL to submit the data too, but alternatives are easily possible. For instance, the Android wallet app already supports using Bluetooth to send transactions directly to the recipient (when both sides use Android). That's great when you're travelling/roaming and might not have an internet connection. The payment protocol will let us standardise that behaviour instead of it being specific to that one app.

What other features does it add?

In v1 of the protocol:

Refunds. The sender can submit some refund addresses to the recipient at the same time as submitting the transactions. Now if the seller wants to give the buyer a quick refund, they can do so. No more problems with trying to "guess" the users address and sometimes getting it wrong due to shared wallets. Bitcoin-Qt generates a refund address for every payment done this way, but you'll only see them if you do actually get a refund.

Memos. Clickable links can already contain short strings or labels, but their length is tightly limited by what browsers will accept and what fits in a QRcode. BIP 70 allows payment requests to contain arbitrarily long memos, which can be used to describe what you are buying. This is super useful when the payment request is authenticated ....

What is authentication about?

Bitcoin is a difficult project partly because we're moving money around with general purpose computers that can be hacked or get viruses. VISA and MasterCard have moved everyone (outside the USA) to special-purpose hardware like chip cards and dedicated readers which can't have random apps installed on them. Our approach has to be a bit different, but dedicated hardware is still coming. The Trezor device is a mini computer just for Bitcoin that plugs into a "real" computer via USB. It has a display and a couple of buttons. It holds your private keys. When you want to make a payment, the details of the payment are shown on the screen and if they're what you want, you press OK and things get signed.

There's an obvious flaw with that design when combined with Bitcoin as it is today. The "details of the payment" you'll see on screen will look like this:

  Pay 0.5 BTC to 1EZEqFBd8yuc9ir2761987q7k3VcALC8YQ?

Where did that address come from? Well, it came from your computer. The thing that probably has a virus on it. That virus could have swapped out the address sent by the online shop you're using for one owned by the virus author, and because they're just random numbers you'd never know. Although the virus can't empty your wallet immediately, it can still steal payments when you make one, and avoiding that is the whole point of using special hardware!

The payment protocol allows recipients to sign their requests under an "identity". An "identity" is just some arbitrary string, that was itself signed by some "certificate authority". The authority vends signed statements that say (simplifying a bit)  "I, Bob Smith, believe address 1EZEqFBd8yuc9ir2761987q7k3VcALC8YQ is owned by Mike Hearn". Now if your Trezor happens to trust that Bob Smith validates identities reliably, it can display:

   Pay 0.5 BTC to Mike Hearn?

and that message can't be tampered with by any virus. As you can see this is much safer.

How do receipts work?

When a payment request is signed it's not just the addresses. The memo is also signed. By keeping around the signed payment request, and the transactions you created to satisfy it, you obtain a mathematical proof of payment. The merchant cannot dispute what was paid for because the memo field contains a description, nor can they dispute that payment was delivered (unless they claim they lost control of their private keys, of course).

This is great because it fills in a missing piece for low-trust third party dispute mediation using multi-sig transactions. Currently if you tried to implement that, you'd run into the problem of a buyer saying "seller did not deliver!!" and the seller saying "the buyer never paid me!" or more problematically,   buyer saying "seller gave me something different to what I asked for" and the seller saying "I gave him exactly what we agreed on".

With receipts, it suddenly becomes much easier to figure out what happened in a transaction and recompense the right party.
 
Do payment requests have to be signed?

No. Without a signature they are basically just a container for addresses and memos.

Do payment requests get stored in the block chain?

No. Payment requests and responses are transmitted directly between buyer and seller. They are not recorded publicly.

What about other features, like tips?

The payment request and response messages use a format called protocol buffers, which is easy to extend. I compiled a list of future feature ideas here:

https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147

None of those exist today, but before they can be created we need somewhere to stash the data they require. The payment protocol is the perfect place.

How do identities work?

The protocol can be extended with multiple methods, but for v1 the only one that works is X.509 certificates. This is the same scheme used for SSL.

Essentially, anyone can get a certificate attesting to some kind of identity. Often it's just an email address or website domain name (e.g. bitcointalk.org has a certificate containing its domain name). It can also be a legal name like "Michael C Hearn" or "Mt Gox Ltd". In fact, if you have a passport with a chip in it then you already have a certificate containing your passport data, but it's not very useful because there's no private key associated with it.

Sometimes certificates are paid for and other times they are free. The certificate authorities never get your private key. Instead you generate a private key locally, then ask the CA to sign your public key. At the same time you prove your identity, if your identity is an email address then you typically receive a clickable link there for instance. If it's your name you might have to submit some paperwork.

Does this make Bitcoin less anonymous or private?

No. People always know an identity of who they're paying already. That doesn't have to be a legal identity. It can be a forum handle or pseudonym too, so even on the Silk Road this holds true - you know you're paying "Drug Dealer Dan" or whoever. But you basically never send money into the void with absolutely no idea of who it's meant to go to (outside of special protocols we're not going to address here).

Knowing the identity of who is paying you is less common, but the payment protocol doesn't establish two-way identity. Only the entity requesting payment has the option to sign (and of course they don't have to).

Can I use the PGP web of trust?

No, that's not supported in v1. However anyone can become a certificate authority, in fact Apple ships a GUI for creating and running one with every copy of MacOS. But you would have to convince people to trust you, which is the hard part. The "web of trust" doesn't solve that problem - you would still have to convince people to trust you for the purpose of signing keys.

That said, it's imaginable that trusted community members might create their own CA's and start issuing identities. For example, BitcoinTalk could issue certificates where the identity is your forum username. If wallet authors/hardware wallet designers decided to trust theymos for that purpose, you could see forum handles appear on your Trezor.

Isn't SSL horribly broken?

No, not really. Some people say it is, but there are no better systems - the X.509 PKI (public key infrastructure) reflects the result of many years of evolution and improvement. What's more, it's still being improved. Because it underpins SSL there's a lot of rich and powerful entities who want to see it get better, like Google, which pays people to work on it.

Let's make that concrete. One of the most common concerns with the X.509 PKI is that there are too many certificate authorities. This is still an improvement on the old days (early 90's) when there was only one CA, but having hundreds means that any CA can issue a cert that every user will accept. What stops a CA issuing a bogus cert to an imposter, like a hacker or a government .... or just another customer?

Currently the act of issuing a cert leaves no traces so this is a real concern, although there are remarkably few known cases of it happening given the enormous size and scale of the PKI. Google is developing a solution called "certificate transparency":

http://www.certificate-transparency.org/

It's a public post-unforgeable audit log of all certificates issued. It works a little bit like the Bitcoin block chain, in fact. Each certificate can contain a proof (some Merkle branches) linking it to an entry in the public log. Once a CA has started using the system, if a certificate is found signed by that CA which does not contain such a proof it can be rejected as invalid. This means the CA can no longer issue certificates in secret. By watching the public audit logs, you can spot if a CA issues a certificate in your name .... or even in a name that's just confusingly similar to yours (so it is a way to fight against phishing as well).

I still prefer the web of trust

You shouldn't. The PKI is the result of evolving a web of trust style system over many years, as it got real usage. It looks the way it does because of its solutions to the problems the raw web of trust model has.

For instance, let's say Bob starts signing keys using GPG. His signature is worth very little unless I happen to know and trust him. In practice as a new Bitcoin user who just saw it on CNN, I don't know Bob. However, maybe I do trust the guys making the Trezor because they are a real company and they live in a country with sane laws, etc, they have lots of happy customers, so that gives me a starting point. Then if stick and slush trust Bob, and Bob has signed the key of bitcoinstore.com then I have a chain of trust to the store.

Bob has become a certificate authority!

How trustworthy is Bob, really? Does he keep his private key on a computer running a warez copy of Windows XP that is full of malware? It would be nice if we could formalise the "stick and slush trust Bob" part of the above description. Otherwise what stops Mallory turning up and demanding that Trezor trusts him too?

A good way to resolve this conundrum is to come up with a set of best practices, like keeping your private key inside a hardware security module, and setting some rules around when Bob/Mallory should sign a public key. To increase trust in the system and stop Mallory just claiming he follows the rules when really he doesn't, we might want to create a formal audit system and an auditor organisation that verifies these guys are following the rules.

We just re-invented the WebTrust Audit:

   http://www.sslshopper.com/article-what-is-webtrust-for-cas-certification-authorities.html

Eventually as Bob and Mallory get more professional and trusted, they'll discover it's sort of hard to do it in their spare time so they'll create companies and start charging fees. They'll compete in the open market. After a long time, some of them will discover that for the most basic kind of key signing (emails and domain names) it can be entirely automated and done for free.

That's StartSSL.

As the number of trusted parties goes up and they handle more and more key signings, eventually Bob or Mallory might get hacked or pressured by the government. It'd be nice if everyone knew what keys Bob and Mallory had signed, in a more scalable way than just relying on everyone to upload all their keys to the MIT key server.

That's certificate transparency.

I hope you can see now why the PGP web of trust would eventually end up being pretty similar to the regular PKI, if it got big enough.