Blinded bearer certificates
This is an idea well-known by Bitcoin experts, based on a paper by David Chaum written in 1983. Because all of the experts are familiar with the idea and are not terribly interested in it on an intellectual level, it is not discussed much. But people who don't study this stuff probably won't know about it, and it could be very usefully applied to Bitcoin.
As applied to Bitcoin, it would work like this:
- N people who are independent and widely considered trustworthy come together to create a multisig address. You need 80% (or whatever) of the N people to agree in order to send money secured by the multisig address. This multisig group is called "the bank", though it ideally should not actually be a single monolithic organization, but rather a more decentralized selection of independent entities.
- People interested in using the system (or, more likely, people interested in acting as market makers) will send x satoshi to the bank's multisig address and receive x signed certificates, one certificate per satoshi. Each certificate is signed by the bank (ie. because the bank is a multisig arrangement, each certificate will have multiple signatures); however, the signing is done using a technique called blind signing, which makes it so that although anyone can see that the certificate was signed by the bank, the bank will not in the future know when it signed which certificate. In other words, when the bank sees a signed certificate in the future, the bank will only know that the certificate is any one of the currently-unspent certificates, not which one it is.
- People with the initial certificates can now send them to others. Simply giving someone the signed certificate is all the sender needs to do to transfer it. (Therefore, transacting over a secure channel is important.) The recipient has to then do some work in order to prevent the sender from double-spending: the sender gives all of the received certificates to the bank, creates new certificates, and has the bank blind-sign all of those new certificates. The bank marks all certificates used in this way as spent in a database, preventing the sender from successfully double-spending. If the sender tries to double-spend, the the second recipient will immediately get an error when trying to get those certificates reissued by the bank, and should therefore cancel their end of whatever transaction they were doing. Again, the blind signing prevents the bank from knowing the source of any coins transferred in this way, so anonymity is very strong.
- After any number of transactions, someone with some certificates can give them to the bank and instead of having them reissued, they can have the underlying BTC sent to their Bitcoin address.
For simplicity, above, each certificate was worth 1 satoshi. You can instead do a mixture of certificate denominations for increased space and time efficiency. If the sender doesn't have the correct denominations for a particular trade, then he can have the bank transform some higher-denomination certificates into lower-denomination certificates; there's no need for change from the recipient. For anonymity, there should be only a small number of different denominations. It's possible to make certificates divisible, but this complicates the scheme and probably harms anonymity.
Blinded bearer certificates have a number of excellent properties:
- Transactions are very anonymous, more so than basically any proposed enhancement to the decentralized Bitcoin system.
- Transactions are instant.
- It is very scalable; even the bank doesn't need particularly powerful servers. Because not much work is involved by the bank, fees would probably be very low.
- Transactions are in many ways easier than Bitcoin ever was: all you have to do in order to send money is give the recipient a file containing a bunch of certificates. If convenient denominations are used, these files may be small enough to copy/paste in the same way that OpenPGP messages are often copy/pasted. Unlike some proposed systems, there's no need for the sender and recipient to both be online when the payment is made.
- It's possible for contracts to be used, and these contracts can be much more complex than is possible on a decentralized system because the contracts will be evaluated by a small number of centralized entities. For example, you could have contracts based on the price of something according to a website, which would be impossible on any reasonable decentralized system. However, actually using contracts (which is optional) might allow the bank to link transactions, since they have to see the contract (in the absence of homomorphic encryption magic).
The obvious flaw, and the reason why this idea never took off despite being known and possible since 1983, is that the bank is a single point of failure and can steal all of the money. However, when built on Bitcoin's decentralized contracts system, it's possible to spread the trust out far more than was possible previously. If the "bank" is composed of 20 trustworthy and totally-independent entities in 20 different countries, and 80% of them have to turn evil in order to steal the money, then it seems to me that the system is secure enough for smaller values (less than a few hundred dollars in total value tied up in these centralized certificates, say). It'd additionally be possible for wallets supporting these certificates to automatically diversify among different issuing banks, spreading out the risk even more. For example, a wallet might ask the user how much money it trusts BankA with, how much money it trusts BankB with, etc., and then automatically trade certificates between all of the banks to ensure that these limits are not long exceeded.
This would be an excellent shorter-term solution to the problems of scaling and anonymity. It requires no changes to Bitcoin itself, and the technologies are not that difficult, requiring no complicated P2P network or anything. (Later on, as technologies mature, it's likely decentralized solutions such as Lightning to replace these certificates in almost all cases.)
Open Transactions already mostly implements this idea, has been criticized as being over-designed, to the extent that hardly anybody is willing to figure it out. I've long wished that somebody would write a quick-and-dirty certificate server and wallet just in order to popularize this idea, and then development on more complicated stuff can proceed from there.