A disturbing idea: BitBanknotes

Prior the hack of bitcointalk.org, I received a personal message from user “btcusr” of bitcointalk asking me to take a look a thread he had started. Soon afterwards the site went down for maintenance, so I was unable to take a look. Today I did, and for my surprise I found one of those powerful ideas that are so simple, but so odd at first sight, that can go unnoticed. The idea is that people could use fiat banknotes as a medium to transfer bitcoins, for off-line Bitcoins payments. I will call these bills “BitBanknotes”. To fully explain the benefits and limits of this idea, let’s first review previous partially successful attempts. The History of physical Bitcoins

The idea to store Bitcoins in a physical object so object itself can be used for off-line payments dates back to August 2010, when the subject is discussed in Bitcointalk. The underlying idea is that the issuer stores a private-key to unlock some funds in a tamper-evident seal embedded in the physical object. So as long as the seal is unaltered, the object is said to hold the funds. At any time the seal can be opened and the funds stored used at will, leaving the physical object unable to store more funds. During 2011, Mike Caldwell began selling his Casascius coins. In late 2011, Douglas Feigelson created his Bitbills, which look like personal plastic cards. During 2013, I  created the Firmcoin, which has an embedded microprocessor and can be loaded and unloaded with funds at anytime. All this physical objects have one thing in common, a  private-key is ebedded in the object but hidden from the user: if you attempt to read the key, the object changes its state, in an evident way. Could this security be achieved by a standard fiat banknote?

No place to hide

A banknote does not have something to hide a private key, and so prevent double-spend. Btcusr tries to develop a method to allow BTC to be bound to a banknote and unbound afterwards by other users, but this is simply not technically possible Bitcoin can make payments to unspendable addresses, which means that, as the computational protocol is concerned, the BTC send are destroyed forever. In Bitcoin terms, we’ve created an unspendable “transaction output”. Nevertheless, if we transfer some BTC to a unpendable output which describes the banknote (e.g. country, denomination and serial number), we could bind the BTC to the banknote forever, as long as people believe the banknote represents those “destroyed” BTC.

The BitBanknote: A borrowed Bitcoin Banknote

Suppose that people agree that the bill’s value is now X BTC. The only party that can reliable try to cheat making a perfect counterfeit bill is a government. If governments create counterfeit bills, then they’ll be terribly exposed to loss of credibility. Therefore nobody will create a perfect counterfeit bill. To check that a bill has value, you carry a portable database of BTC-to-Bill binding outputs. Everyone agrees that to be valid, a bill binding transaction must be one day old, so everyone can carry the small database and sync it once a day. (This is the same system the Firmcoin.com uses) We would be actually using the government low-cost of manufacturing facilities to create difficult to counterfeit banknotes for Bitcoin. For example, a 100 USD banknote costs 10 cents to manufacture in a batch of a billion bills. From the economic point of view, the bill’s value is the maximum between the fiat previous value and the BTC value, so it’s seems that some value has been created from thin air, because you could just create money by accepting the fiat value, and then selling the bill by the other BTC denomination (or vice versa). In fact a BitBanknote is a BTC bill with an insurance in USD and at the same time a USD bill with an insurance in BTC. Something never seen before… By using a very low-valued bill, for example a 1 USD bill for 1 BTC, this could be mitigated, but I really don’t see how the mutual insurance can be a problem. In fact it can prevent the Bitcoin value to go below the USD value, since if this happens, the bill wiill be traded as USD instead of BTC, and that will reduce the liquidity in the BTC market, increasing its price. But there is real subtle problem. I don’t think the governments put the same security features in a 1 USD bill than in a 100 USD bill. Bitcoin value tend to rise, so for any denomination one choses for the BitBanknote, sooner or later, it will provide lower physical security than expected. As Btcusr points out, if a 100 USD bill holds 1K USD in bitcoins, and manufacturing a counterfeit 100 USD costs 80 USD, then the incentive to create the counterfeit BitBanknote is much much higher.  Nevertheless, governments won’t allow counterfeit notes to exists for much time, or would they? If BitBanknotes become common, then I really don’t know what the heck governments will do.

Implementation details

To make transactions easier we could bind a 1 USD dollar to 1 centiBTC, which is currently about 1.4 USD. Still there is a small problem with change under 1 USD, since coins are commonly used instead. We should standardize this just from the start and we should reject any BitBanknote that does not follow this convention. Using this convention we can use the denomination of banknotes as centiBTC easily. We also should build an iPhone/Android App that scans the serial numbers of banknotes (and the denomination) and responds YES if the BTC-banknote is valid and NO if it’s not (unbound or invalid denomination). Finally, for the system to work, everyone must agree that those BitBanknotes really hold the BTC value.  But you can count on me:  I would agree! Why not? Now imagine people using every USD bill in existence as a BitBanknote! Since the creation of Bitcoin, I never heard a more disturbing idea for governments than that! So let’s define a standard for the creation of dollar denominated BitBanknotes and make it a reality!! I will also propose using the Argentinian peso, whose value decreases yearly at a 20% inflation rate… To create the message in the unspendable output, one could create a pubscript using use the OP_DROP opcode, followed by OP_RETURN. A system to do this in a standard way is being developed here by the core dev team. Thanks btcusr: one never stops getting surprised by crazy ideas…that come true…