Setting up VPN on an iPhone with a Mikrotik RouterOS VPN server

I’ve spent quite a bit of time over the last few days getting a VPN to work from an iPhone, so I thought I’d document the process to avoid anyone else in the same boat trying to row up the same creek.

I have a specific setup that made things more difficult:

  • An iPhone as the client device
  • A Mikrotik router running RouterOS
  • The Mikrotik router behind an ISP-provided router

The reason for the router-behind-a-router setup is that I want to access the internet through the ‘official’ ISP-provided router – for several reasons, not least because when something goes wrong with my net connection and I’m cast into tech support Hell I don’t get immediately kicked back by “I’m sorry, we don’t support third party routers”. I also get a bit more comfort knowing that to break into my network requires two routers to be broken.

The odd setup means that the VPN server is behind NAT and reached by port forwarding. This works just fine for PPTP but unfortunately the protocol is so broken that iOS now warns about setting up a PPTP connection. That’s a no-go.

L2TP is the other VPN protocol that iOS supports natively but this is a huge pain, being a tunnelling protocol containing IPsec packets. IPsec packets are an ancient attempt to secure IP, designed back before NAT and of course NAT screws with packet headers (by definition) which causes IPsec to fail. In the era of IPv4 address scarcity NAT is going to become more and more prevalent so L2TP is also a no-go.

That kills off the iPhone native VPN support. Fortunately, there’s OpenVPN. This is supported by Mikrotik and also there’s an OpenVPN app for iOS, which accesses the VPN API of the iPhone. Unfortunately, it’s not quite as easy to set up as people say.

Instead of giving detailed step-by-step instructions, which will no doubt become invalid after some software update somewhere, I shall give a description of what’s trying to be achieved and then link to some of the more useful posts I’ve read with detailed instructions. A few small ‘gotchas’ got me, and so I’ll describe those too.

Right. First principles. OpenVPN uses Public Key Infrastructure. Which means there’s some faffing with certificates to be done (if you’ve ever tried to get a web server running HTTPS you’ll know about this). Fortunately, it’s not too difficult once you understand what’s going on.

The first step is to get a server private and public key pair, and to get a certificate with the public key signed by a certificate authority (CA). The CA basically says “yeah, we’ve checked out these people and we’ve signed this certificate that describes their server”. Your device (i.e. your iPhone) has a list of CAs that it accepts as trusted people (in the form of a collection of root certificates). So you can generate a certificate for your server then pay one of these guys to sign it for you. It’s basically money for old rope – except you don’t get any rope. And it’s difficult for a new CA to come along and bust up the cartel because the new guy has to get Apple, Google, Microsoft etc. to include them in the list of trusted CA guys. But I digress.

You can go another way, make yourself up as a CA yourself, then tell your device “hey you can trust this CA because it’s really me and I’m a good guy”. There are two ways to do this: tell your iPhone to do the trusting or tell just the OpenVPN app to do the trusting. The latter is the better way to go (because it confines the damage if the private key behind your CA certificate gets stolen).

The Mikrotik VPN server needs a CA certificate, a server certificate (signed by the CA) and the server private key. You can make these certificates by following the instructions here:

https://openvpn.net/index.php/open-source/documentation/howto.html#pki

Note that if you’re using Ubuntu Linux there’s a problem, as described here:

http://ubuntuforums.org/showthread.php?t=2218935

You need to add this line:

export KEY_ALTNAMES="something"

to the last line of the vars file before running it.

Push over to the Microtik router the three generate files:

ca.crt
server.crt
server.key

Put them into the folder ‘pub’. Then you set up the OpenVPN server as described here:

https://major.io/2015/05/01/howto-mikrotik-openvpn-server/

Note that you can access the command line to the router by using ssh (with default username ‘admin’ to your router). By the way, make sure you’re running the latest RouterOS firmware: you don’t want to be hitting bugs that were fixed (I hit one that wouldn’t let me rename the certificates – which went away when I updated).

The VPN client on the iPhone needs an .ovpn file. It’s a pain to try and copy over several files, so you probably want to embed the client certificates and key directly into the .ovpn file. This is explained here:

https://www.brainfart.sg/index.php/2012/05/embedding-certificate-into-openvpn-config/

OK, so far so good. A few more gotchas to go though.

I used the template .ovpn from the OpenVPN HOWTO page listed above. Set it to use TCP because Mikrotik’s OpenVPN implementation doesn’t support UDP:

proto tcp
;proto udp - not supported

And make sure all compression options are turned off. One more thing you need to add into the file:

auth-user-pass

This tells the client to ask for a username and password (to match what you set the PPP secret to). This is a must-do: without it the client won’t authenticate and the server will stonewall. The client app will store the username and password away in the iPhone’s keychain so it’s as secure as any other password on your iPhone.

On the Mikrotik router you’ll want to set the VPN encryption profile as follows:

  • Set the Local Address to the LAN address of the router. By the way, you’ll probably want your LAN to be a random 10.x.x.x address. If you use 192.168.0.x for your LAN it’s going to go horribly wrong when you’re on holiday and the hotel’s WiFi hands out 192.168.0.x addresses – the VPN client won’t know what to do with the IP packets when the address ranges clash.
  • Set the Remote Address to the DHCP pool (assuming you’re using the DHCP server in Mikrotik router to manage IP addresses on your LAN)

You’ll also need to tell the router to proxy ARP so that your client on your VPN can find the other devices on your LAN. You do this under Bridge.. then select interface ‘bridge-local’ then set ARP to ‘proxy-arp’.

OK, on to the iPhone client side now. Install the OpenVPN client from the Apple App Store. To get the .ovpn file into the app you can do what the OpenVPN guys suggest and use iTunes but I found iTunes just sat there spinning away and not listing my apps (oh I so hate iTunes!). Instead I used Dropbox, selected the .ovpn file and opened it in the OpenVPN app. I think you could use AirDrop too. Or even email it to yourself and pick it up in the Mail app (although this isn’t ideal from a security perspective..)

A couple more things are still needed before it works. Go to the iPhone Settings and scroll down to OpenVPN. Here you’ll need to change a few things. Firstly, set Compression to ‘no’. Set Protocol to ‘TCP’. Turn off ‘Force AES-CBC ciphersuites’. It will connect using AES256 anyway but trying to force it seems to cause problems with the Mikrotik implementation.

Almost there: just the port forwarding now. On your ISP-facing router forward TCP port 1194 to the Mikrotik router. And on the Mikrotik router add a firewall entry (under IP.. Firewall) to chain input on port 1194 for the TCP protocol. Make sure this rule is high enough up in the firewall list so that the default discard rules don’t get evaluated first (you do this by dragging and dropping the rule after adding it to the bottom of the list). That should be everything and you can now connect remotely. Turn off WiFi on your iPhone in order to do a proper test of remote access.

It’s possible that you’ll find a hotel WiFi that blocks port 1194 so you can move OpenVPN over to using port 443, which is where HTTPS sits and so this is unlikely to be blocked (it’s possible with advanced traffic analysis to tell the difference between HTTPS and OpenVPN but the usual rubbish hotel IT is unlikely to do anything so advanced).

On the idea of a digital currency issued by a central bank

The Bank of England has today issued a research report (PDF) that discusses many things, but one of them is a short note on a central bank issuing its own digital currency. This has become topical after a report by Paul Mason that Greece might be issuing its own digital currency to escape its travails. The report stems from a blog post by the (now) Greek finance minister Yanis Varoufakis from a year ago where he talks about how a parallel digital currency, denominated in euros, could be issued by Greece, backed by future tax revenues (Tim Worstall gives a more sober assessment of the idea).

The Bank of England’s question seems absurd: what’s the point of a digital currency that’s actually run by a central bank? The Bank gives a few answers:

  1. It could be used as a new interbank settlement system (I find this a weak argument: What is so wrong with the existing settlement system? Is it insecure? Does it cost too much to run? Is there a problem of access?)
  2. It could be used as a parallel system to banknotes (which actually are a peer-to-peer payment system, albeit a flawed one).

I quite like the second idea: remitting currency abroad is a very costly affair with the existing players, and indeed some politicians are campaigning to cap transfer fees. And there are plenty of other niches where banknotes don’t work (machine-to-machine payments, for example). And using a ‘real’ currency avoids today’s problem of Bitcoin as money (e.g. the risks of using it as a unit of account, something that people holding mortgages in Swiss Francs have also been discovering).

An obvious point is that a blockchain run by the Bank of England wouldn’t make a decentralised digital currency – it would just be a cloud-hosted database with an open API, which is pretty much what the existing credit card systems provide (although I’d hope something built from scratch would be a lot neater and easier to use). To eliminate a single point of failure the construction of that cloud-hosted database would need to be distributed and hardened against security attacks, and so probably a blockchain being operated by multiple organisations would be a good design anyway.

The differences between this Bank of England blockchain scheme and Bitcoin would then be:

  1. The operators of the blockchain would be licensed by the Bank of England.
  2. The currency would be the £ and money would be ‘parachuted’ into the blockchain by the Bank of England rather than mining.
  3. The operators of the blockchain could not be remunerated with seignorage: they would have to be paid by the Bank of England or take fees.
  4. They would have no incentive to invest in powerful mining rigs. Indeed, one of the Bank’s goals would be to avoid ‘socially inefficient over-investment in transaction verification‘ (although I did some analysis that showed Bitcoin mining energy consumption isn’t as bad as people think).

The nature of the regulation and funding of the operators of the Bank of England’s blockchain is an open issue. If the operators are third parties remunerated by fees then there ought to be a real-time market for the fees to prevent regulatory capture (either by collusion amongst the operators or by the Bank of England). If the operators are remunerated directly by the Bank of England then the issue of subsidies would have to be addressed (particularly with regard to compliance with EU state aid regulations).

If the Bank of England were to create its own successful blockchain payments system then it would inevitably disrupt the existing payments market. The Bank of England is concerned about the effect on the existing inter-bank payments but it would also affect companies like Western Union. At the very least a state actor creating a new system to deliberately undermine an existing market raises political questions.

The Bank of England also notes the usual suspects of regulation (Anti Money Laundering, Know Your Customer, etc.). For the Bank of England blockchain to work the regulators would need to ensure that wiring £2 to a relative in Indonesia did not require the paperwork that ordinary people opening bank accounts today enjoy. If the Bank of England blockchain can be designed from scratch perhaps it could be interfaced with a competent identity system and be designed to not require onerous identity burdens for small sums (NB: the UK Government does not have a good track record in operating a competent identity system). Alternatively, the regulators might stop believing in the myth that Bitcoin is anonymous and relish the idea of a ledger openly documenting transactions that would hitherto have been conducted with pieces of paper (even if sometimes banknotes are tracked by GPS)

In one sense the Bank of England is asking the same QTWTAIN that others have posed in response to Bitcoin: “Can we have a centralised decentralised system that has all the advantages of Bitcoin but none of the disadvantages?” But a better question which the Bank is hinting at is “Can a central bank be inspired by Bitcoin to create an egalitarian payment system that has features that the Internet Age needs?” Answering that question will be fascinating.

If you liked this article then this is the not-Bank-of-England-blockchain address of my tip jar: 166vkDz7EqLV27g3aEqER2Z81vx43sYMp7

Microcontroller Interconnect Network (MIN) version 1.0

Some time ago I was doing some work on embedded systems firmware for a small control board using an 8-bit microcontroller. It had to control some motors and a laser, and had to send back sensor readings to a PC. I was looking for a simple peer-to-peer serial protocol that was robust against noise and other failures. Basically, I wanted an answer to a commonly-asked Stack Overflow question.

I didn’t want anything too complex and it all had to work in a tiny 8-bit ATmega AVR microcontroller (so there was no space for large packet buffers). I couldn’t find anything suitable so taking inspiration from CAN and LIN, I decided to roll something myself. I’ve called it MIN and uploaded a reference implementation to GitHub. MIN is pretty small and robust (about 200 lines of code) and in this post I want to help people quickly get a “hello world” program using MIN up and running.

I’ve built the test program using an Arduino Mega 2560 board (it runs a 16MHz ATmega2560 AVR 8-bit CPU) and wired it up to a bit of breadboard with a pushbutton, a serial-to-USB breakout board, and an LED. I’ve also used JTAG as the debugger connector to a Windows PC running Atmel Studio 6. Also running on the PC is a little Python-based test program that talks to the Arduino board.

Here’s the kit on my bench:

2015-02-18 15.02.16

The Arduino board is the blue one. It’s plugged into USB for power (it’s not connected for anything else). TX0 and RX0 on the Arduino are wired to a serial-to-USB breakout board on the white breadboard. The serial board is a really neat little board that takes 5V (or 3.3V) level serial pins and converts to USB using the serial protocol (which means that the embedded board turns up on the PC as a COM port, COM4 in my case).

The Arduino board doesn’t have a JTAG connector so I wired the CPU’s pins with fly leads directly to the JTAG connector on the Dragon board. I’ve included a photo here so that anyone wanting to replicate this setup can do so easily:

2015-02-18 15.02.52

The breadboard also contains a pushbutton that floats open until pushed, connecting PA6 on the Arduino to GND. The firmware sets this up with a pull-up resistor so that it reads ‘1’ until the button is pressed. The test program calls this a ‘deadbeef switch’ and sends a MIN message with payload 0xDEADBEEF to the other end when pressed. Every two seconds the test program also sends an ‘environment report’ message (containing hardwired values for temperature and humidity).

I also ran an output pin to my oscilloscope, toggled in the firmware every 8ms, that’s the first level of debugging to test if code is running. You can see the nice square wave here:

2015-02-18 15.03.31

The test program on the PC end is written in Python (I used version 3.4) and has an interactive mode. Pressing ‘p’ sends a MIN frame that’s treated as a ‘ping’ request by the firmware – the application just sends the frame back. When ‘m’ is pressed a ‘motor request message’ is sent, which is interpreted by the firmware as an instruction to light an LED on the breadboard for 1 second (about as close to printing “hello world” as embedded software gets).

The test program also decodes and prints out MIN frames it receives from the Arduino (the deadbeef switch message, the environment report and the ping message):

mincap

I’ve used this for real where MIN is sending continuous sensor data and taking complex commands in a real embedded system that runs in a noisy environment. It’s worked well and I hope other people find it useful too.

Bitcoin, Europe and digital colonisation: an analysis of the EBA report

The European Banking Authority (EBA) recently published its opinion on virtual currencies (they include Linden Dollars and other gewgaws in the definition, but it’s really only Bitcoin that is of consequence). The EBA’s considered opinion is that European financial institutions should shun Bitcoin like a dead skunk and go nowhere near it until the ‘scheme operators’ are persuaded to change Bitcoin to be managed by a wise and omniscient regulator. To understand why their opinion is so ridiculous we have to delve into the report and uncover just what paucity of understanding there is within the EBA of how things work.

1. One of the tasks of the EBA, in accordance with Article 9 of its founding regulation, is to monitor new and existing financial activities and to adopt guidelines and recommendations with a view to promoting the safety and soundness of markets and convergence in regulatory practice.

The EBA was founded in 2011, two years before the banking crisis in Cyprus led to capital controls and bank deposit confiscations. This failure happened on the EBA’s watch yet when listing a large number of risks (which are actually very few, as we shall see) there is a portrayal that “more than 70 risks” are uniquely risks to do with Bitcoin. It’s possible that the EBA has some kind of institutional blindness to this because of the general failure of European regulators in the financial crisis.

The EBA doesn’t demonstrate a strong grasp of how Bitcoin works:

3. In their decentralised variant, VC schemes tend to be created online using powerful computer hardware, which allows users to ‘mine’ small amounts of the currency by solving deliberately complex algorithms.

Bitcoin doesn’t ‘solve algorithms’. Sloppy wording of technical matters of this kind betrays the facile understanding of a non-technical person. The uncertain tentative wording used in some places confirms this. For example:

The increase in the supply of VC units in the decentralised VC schemes that exist is said to be fixed by a mathematical protocol.

So it is ‘said to be fixed’? Does this mean the authors spoke to someone with expertise but couldn’t really follow them or didn’t really trust them? Or because they tried to read a newspaper article about how Bitcoin works but didn’t really understand it? If the latter this is inexcusable since for some time there have been some very good articles that in general terms but with precision explain how Bitcoin works.

Similar hesitant language is used throughout the report:

For Bitcoins, the total process time is said to be between 10 and 60 minutes.

Again and again through the report there are misunderstandings of how Bitcoin works:

Only small amounts are released over time, and the computing power required to mine a unit increases over that time.

This isn’t true: the computing power required is scaled up or down to ensure a fixed transaction rate. The only reason is has been increasing is that mining has become a gold rush. One day in the future it’s perfectly possible to see the computing power of the Bitcoin network to fall. How mining plays out in the final stages is difficult to foresee and there are different scenarios possible. This doesn’t prevent the EBA from drawing its own conclusions based on no particular knowledge of mining:

Other subtle aspects of Bitcoin seem not to be understood at the EBA:

23. VCs can be (i) transferred from one user to another via electronic means, (ii) stored on an electronic device or server and (iii) traded electronically. However, it does not exclude physical transfers, the storage of copies in other forms (e.g. paper, minting and engraving) or that the VC is traded in other ways.

Bitcoins cannot be ‘copied’ by physical means. The private key used to sign a transaction can be given to someone on paper, but all this does is let them transfer bitcoins – it does not prevent the sender doing so beforehand (because there is no way to prove they have not retained a copy of the key). Physical embodiments of bitcoins are merely a novelty for amusement purposes only (or for providing stock photography to illustrate newspaper articles). This is a subtle issue that will not be understood by a cursory examination of Bitcoin and goes to the heart of precisely how Bitcoin is secure.

This apparent lack of understanding of how a blockchain is secure then leads the EBA to draw some bizarre conclusions:

46. Due to the absence of intermediaries, VC transactions can currently be achieved at lower costs than other means of payment, such as payment cards or bank transfers. This is partly due to the absence of any regulatory requirements that would guarantee the safety of those means.

In other words, Bitcoin can’t be secure because it’s not being told to be secure and therefore it’s skimping on essential compliance and that’s why it’s cheaper.

Such a bizarre lack of perspective by a regulator is commonplace through the report. It’s almost as if the EBA cannot conceive of a finance world that is not structured as it always has been. For example the EBA gives this crazy view of how Bitcoin is controlled:

34. A scheme governance authority is a legal person establishing and governing the rules for the use of a VC scheme, maintaining a central payment ledger, and who is responsible for the integrity of the scheme.

This view is carried over to their recommendations for regulation of Bitcoin:

155. A governance authority may, at first, appear incompatible with the conceptual origins of VCs as a decentralised scheme that does not require the involvement of a central bank or government. However, the mandatory creation of a scheme governance body does not imply that VC units have to be centrally issued. This function can remain decentralised and be run through, for example, a protocol and a transaction ledger.

When you have a hammer, everything looks like a nail. When you’re a regulator, everything looks like it can be regulated by an authority. The EBA doesn’t accept that a blockchains can be secure (obviously, given the hesitant cursory understanding demonstrated earlier) but it believes that dominant participants can emerge to control Bitcoin anyway:

If it is true that the decentralised VC schemes are secure, it should be possible for market participants to establish themselves as scheme governance authorities.

But if nothing can control these participants then don’t go blaming the regulator:

However, if a legal person is not able to exercise authority over market participants and is therefore unaccountable to a regulator for compliance purposes, it would be unreasonable to expect a regulator to guarantee integrity in their place.

In other words it’s a case of “Don’t come telling us that Bitcoin has no central control. That’s crazy. Someone must be in charge, and we’ll tell them what to do. But if they don’t obey, it’s not our fault, OK?”

It’s all very odd. I suspect that this huge misunderstanding of Bitcoin stems from a lack of expertise within the EBA. Of course, lack of competence within a regulator is not an unknown problem.

The EBA doesn’t seem to understand Bitcoin fees:

VCs can also be less expensive for merchants as payees as well as for payers to whom transaction costs may be partially passed on. Although reliable and independent data on the exact costs of VC transactions is difficult to ascertain, some anecdotal suggestions have been made that average transaction fees on the Bitcoin network tend to be less than 0.0005 BTC, or 1% of the transaction amount.

The transaction fee market in Bitcoin is still nascent because at present miners are incentivised by minting new bitcoins rather than fees. At present transactions can be run for no fee at all, but in no case are fees a percentage of the transaction. It’s inexplicable how the EBA arrives at this view of fees.

49. However, several caveats need to be made about these alleged benefits. Firstly, the cost advantages are not guaranteed, as miners of popular decentralised VCs such as Bitcoins currently tend to be compensated by both transaction fees and a share in recently mined VC units. It is reasonable to assume that, as the number of newly issued VC units decreases over time, miners will have to rely more on transaction fees to recoup their investment of processing power. It is therefore reasonable to assume that transaction fees will increase in the future.

The use of the passive tense “it is reasonable to assume” is a giveaway that unjustified assertions are being sneaked in. The truth is that it’s not reasonable to assume this. Even a cursory examination of the economics of mining today show that the investment in hardware is amortised over a period measured in weeks rather than months. Quite how mining plays out in the end game where no new coins can be minted is open to debate. I wrote at length about the energy consumption of mining because one of the end-game issues is whether mining will turn into a commodity business driven by comparative advantage on electricity and cooling costs (e.g. data centres in Iceland). One view of fees comes from seeing them as bids in a transaction auction, where pending transactions compete for transaction slots. Another view says that current transaction rate limits will be lifted in the future making them cheap (amortising marginal mining costs over a much larger number as Bitcoin becomes widely adopted, thereby lowering fees). Regardless of the outcome, one thing is certain: it’s not reasonable to assume that fees will increase in the future.

Secondly, most merchants that accept VCs tend to convert them immediately into their local FC, an activity that also incurs costs (estimated to be 1% of the amount to be exchanged).

The high spreads on Bitcoin conversions is due in part to limited liquidity. This would be improved by more participation in the market by existing financial institutions – something the EBA seeks to prevent with this report. It is a little like the son who murdered his parents asking the court for clemency because he’s an orphan.

For the EBA, Bitcoin isn’t doing anything new but rather cheating the system:

Thirdly, the higher fees for other means of payment transactions are partly due to the regulatory requirements imposed on the regulated entities that provide them, as a result of security measures, corporate governance, internal control measures, prudential requirements and more.

Should VCs schemes be regulated as a financial service, associated (although perhaps not identical) costs will inevitably impact upon VC service providers as well. These compliance costs will negate at least some of the cost advantages that VC systems are currently enjoying.

This is a theme repeated through the report: that Bitcoin has nothing new to offer because all it’s doing is avoiding the necessary costs of doing business. That is, of course, a complete misunderstanding of how Bitcoin works (although a natural conclusion if you believe that Bitcoin is really controlled by Satoshi in his lair). As an aside, it is nice for the EBA to so clearly lay out that in the end the cost of regulation falls squarely on the users of financial services rather than the financial institutions – something they might like to tell their colleagues who are forcing through the Financial Transaction Tax.

The “Bitcoin has nothing really new to offer” conclusion is augmented by a shameless “we don’t need Bitcoin in Europe anyway because the banks here are going to be wonderful” self-promotion:

As of spring 2014, the SEPA consists of 34 countries, including the 28 EU member states. Furthermore, the EU regulation on the equality of charges for cross border payments eliminates the differences in charges for cross- border and national payments in euros. As a result, the costs arising for payers and payees when making cross-border transactions through conventional payment services is already low or, indeed, free, therefore significantly reducing the cost advantages of VCs in Europe.

I am sure ordinary people in Cyprus will be thrilled to hear this.

The EBA seems very confused about Bitcoin transactions being irrevocable:

53. VC schemes allow merchants to avoid having to refund transactions, particularly those that are based on an alleged non-fulfilment of a contract. In conventional FC payment systems in some jurisdictions, merchants have been reported to complain about large numbers of consumer-initiated payment charge backs that were based on false claims that a product had not been delivered.

54. The downside of this benefit is that, for payers, the irrevocability of transactions does not allow consumers to be protected against error or fraud resulting from the merchant or other actors.

Already today a huge number of payments have no recourse: cash. The world gets along with cash and knows the risks of paying with cash. For large sums, people use electronic payments with some kind of insurance and recourse for when things go wrong. Bitcoin in its basic use is no different to cash, but unlike cash it also allows for counter-signing of transactions. This means a third-party dispute resolution service could exist to either enforce a refund or enforce payment to a merchant. Because Bitcoin is in a nascent state this isn’t happening yet, but we are already beginning to see cloud wallet services use countersigning (by the customer) as a mechanism to stop systematic fraud and theft.

These features of Bitcoin are largely unknown to ordinary people (I’ve never seen them discussed in newspaper articles) but they will become more and more important as Bitcoin becomes more widely adopted. Damning Bitcoin today because of ignorance of the possibilities is not what we are entitled to expect from a regulator that should have acquired expertise in the topic.

One of the consistent themes in the EBA report that clearly worries the authors is of anyone being able to create a virtual currency:

User suffers loss when the exchange they interact with does not exchange VC against FC (A02)
71. The risk can arise because anyone can anonymously create (and subsequently change the functioning of) a VC scheme.

It’s clearly astonishing to them that Dogecoin, Stalwartbucks and Dr. Evil Dollars can be created at whim. It doesn’t seem to have occurred to them that running up “Bank of Toytown” notes on an inkjet fools no-one and that similarly no-one is going to be fooled into thinking Stalwartbucks are worth anything either. Selling a cow for a pocketful of magic beans is a fairy tale, not the foundation of a financial risk assessment system. In any case, it’s not a risk for Bitcoin since it has already been created and Satoshi Nakamoto can’t change the scheme rules.

Most of the reports I have read on the EBA opinion cite ’70 risks’ for Bitcoin:

67. Approximately 70 risks can be identified as arising from VCs. Some of these are similar, if not identical, to risks arising from conventional financial services or products, such as payment services or investment products, while others are specific to VCs.

In fact, many of the 70 or so risks are in fact general financial risks. For example:

User experiences drop in value of VCs due to significant or unexpected exchange rate fluctuation (A03)
72. Several different drivers can create this risk, including that VC markets, and the price formation therein, are relatively opaque, and that the VC price formation on exchanges can easily be manipulated, including by a concerted effort of a small number of large VC holders.

Is there anyone that doesn’t understand that exchange rates can be volatile? Yet this forms part of the basis for an opinion that the institutions that knew this already should stay clear of Bitcoin. But shouldn’t institutions with expertise in forex actually be encouraged to participate in a Bitcoin exchange market and thereby improve it (by providing more liquidity, for example)?

Quite a few of the risks cited are caused by regulators acting unfairly. For example:

User holding VCs may unexpectedly become liable to tax requirements (A04)
73. The legal and regulatory treatment of VCs is unclear and inconsistent, as is their tax treatment. The taxable event and geographic location of the taxable event may also be unclear. This may potentially lead authorities to treat VCs as property, forcing users to track and pay capital gains.

Most amusing is that identity requirements to meet regulatory compliance rules might lead to identity theft:

User’s identity may be stolen when providing identification credentials (A13)
83. Some VC schemes require users to identify themselves on the internet or at VC cash machines when buying/selling VCs, through passport scans, iris scans or finger printing.

This, of course, never ever happens with existing financial institutions.

More bizarrely is:

However, these identification measures are not subject to regulations or data protection laws,

Really?

nor is the underlying IT software subject to safety standards.

I’ve never seen a bank IT system built to safety standards (are they conformant to IEC61508? I don’t think so).

Other risks reflect a bizarre worry about ordinary business relationships. The EBA is strangely fixated on miners in a consortium getting paid:

However, a fair distribution of the mined units (or the equivalent in converted FC) to which each member is entitled might be subject to manipulation by the mining pool owner.
Similarly, members might be exposed to other forms of unequal treatment, due to a lack of transparency in business practices.

Should songwriters be ordered to steer clear of dealing with recording studios because royalty payments might not be fair or transparent?

Other risks include generate IT risks applying to any business:

75. Any automated, IT-based distribution mechanism may, in turn, be subject to errors, fraud and hacking

Risks the EBA has chosen to ignore include tornadoes, earthquakes, civil insurrection and the Year 2038 bug.

Some of the risks are due to a misunderstanding of how Bitcoin works and the role of companies offering Bitcoin services. For example, custodian risk:

Market participants suffer losses of VC units held in custody by others (A17)
87. The risk arises because the custodian is insolvent, behaves negligently or fraudulently, lacks adequate governance arrangements to oversee transactions, fails to keep adequate records, or has inadequate own funds to repay creditors. Also, transactions are not reversible. The priority of the risk is medium.

This is very odd, since there are no custodians necessary with Bitcoin (it’s possible that someone else holds your private keys – a cloud-hosted wallet for example – but that’s not a custodian in this sense). It’s almost as if the EBA has misunderstood the very essence of Bitcoin and the whole purpose of the blockchain.

Similarly counterparty risk is listed:

Market participants suffer losses due to counterparties/intermediaries failing to meet contractual settlement obligations (A16)
86. The risk arises due to the anonymity of (some) counterparties, which can undermine the enforcement of any legal contracts that may exist, the lack of ‘payment vs. payment’ procedures, the lack of settlement finality, the decentralised set-up of VC schemes, the fact that counterparties have insufficient own funds, and that VC markets become temporarily illiquid. The priority of the risk is high.

As highlighted earlier, this seems to be down to not understanding how Bitcoin transactions can be more complex than just simple push payments, and can allow for different types of settlement (Richard Gendal discusses this in more detail).

Of course, counterparty risk is something that is always going to be an issue in any financial system. It’s not a risk of Bitcoin per se.

Another class of risks listed can be called “people are too stupid to work stuff out for themselves”. For example, it’s a risk that an ATM machine breaks:

User experiences loss of FC units when using a VC cash machine (A22)
90. When exchanging VCs for FCs at a VC cash machine, users cannot guarantee that the VC or FC units will be correctly credited to their benefit.

A customer could spend bitcoins on an espresso macchiato and then find that they got a latte macchiato instead. That’s a risk too. In reality a customer would simply complain and get a refund (with the slight risk that the operator went bust in the short time between the fault and the complaint). Or maybe they wouldn’t because:

No effective complaints or redress procedures are in place either.

People are also too stupid to ask if a merchant takes bitcoins:

User has no guarantee that VCs are accepted by merchants as a means of payment on a permanent basis (A23)
91. The risk arises because merchants are required to accept only legal tender in notes and coins, but they are not required to accept non-legal tender such as VCs. Furthermore, merchants may decide to vary the acceptance of alternative VCs over time, switching between various VC schemes. Merchants may also deem the overall costs and risks of VCs too high or too uncertain. The priority of the risk is high.

And people fall for Ponzi schemes:

User suffers loss when investing in a fraudulent or Ponzi VC investment scheme (A44)
101.The risk arises because the individuals involved in the underlying asset can conceal their identity and are therefore not subject to any probity requirements, nor are they required to disclose the risks to which the investor is exposed, etc. Furthermore, the nature of VCs leaves investors more vulnerable to abuse by a Ponzi scheme based on VCs than other, regulated forms of investments. Finally, the user may have no access to redress schemes. The risk is of medium priority.

Correct me if I’m wrong, but the first Ponzi scheme didn’t rely on not being able to identify Charles Ponzi.

Another class of risk listed where no laws exist that didn’t come from financial regulators. For example:

User cannot access their VCs on an exchange that is a going concern (A27)
95. The user may temporarily store their VC units on an exchange that is a ‘going concern’ i.e. is still functioning without an immediate threat of liquidation. However, they may find themselves unable to access them, because the exchange is not bound by any legal contract

So if a Bitcoin exchange isn’t regulated, no legal contract exists – no tort law, no implied contract, nothing?

Then there are risks that have just plain weird assertions thrown in:

User cannot execute the VC exchange order at the expected price (A46)
103. The risk arises because VC exchanges tend to be cash poor.

Or the more bizarre:

After accepting VCs for payment, the merchant is not reimbursed (B21)
108.The risk arises because of the ‘double-spending problem’: unlike FC that has a physical representation in coins and notes, VC units are only digital files. Therefore, the act of spending a VC unit does not remove its data from the ownership of the original holder.

And yet:

By design, no central authority exists in a VC scheme. To prevent double-spending, VC schemes tend to use a decentralised system with separate nodes that follow the same protocol. The authenticity of each transaction is verified by adding it to a transaction ledger, called the block chain, which is to ensure that the inputs for the transaction have not previously been spent.
110. However, there is no guarantee that a particular VC scheme uses this verification approach, nor is it certain that if this approach is used, it is completed securely and is not compromised,
for example through ‘blocking’ individual users from the VC network.

I don’t know what to say. This is such a bizarre view of Bitcoin and blockchains.

There are of course the risks of the usual suspects: terrorists, criminals and tax evaders. For example:

Criminals are able to launder proceeds of crime because they can deposit and transfer VCs anonymously (C01)
118. The risk arises because senders and recipients can carry out VC transactions on a peer-to- peer basis that do not require personal identification as there are no names attached to wallet addresses. Furthermore, there is no intermediary that could notify authorities of suspicious transactions. The priority of the risk is high.

It’s a complete myth, peddled mostly by newspaper articles, that assert Bitcoin is anonymous. It’s not anonymous largely because the blockchain is a public ledger and easily inspected for data patterns. Indeed, this is how the winning bid in the recent US Marshal auction of Dread Pirate Roberts bitcoins was uncovered.

Similarly:

Tax evaders are able obtain income denominated in VCs, outside monitored FC payment systems (C19)
133.VC transactions are not recorded and are anonymous, global and irrevocable. Also, decentralised VC transactions are not dependent on entities on which financial regulations could be imposed. The priority of the risk is medium.

With the NSA’s access to IP traffic, Bitcoin is pretty much an open book. I’m sure the security services would be only too pleased to see terrorists shift from cash to bitcoins. And I’m sure the tax authorities would love tax evaders to hide all their transactions in plain sight in a public ledger.

I also note that it was a supposed risk of Bitcoin that personal identification information was at risk of leaking to identity thieves, and yet here no personal identification information is needed at all.

The most amusing class of risk is the risk the regulators won’t get it right:

140. The risk can arise if the analysis of the risks and the identification of the regulatory response have been incomplete, if the regulatory approach was arbitraged by market participants acting from outside the regulator’s jurisdiction, or if the regulatory measures chosen were not suitable to mitigate the risks. The priority of the risk is medium.

With all these bizarre risks and misunderstanding of how Bitcoin works, it’s no surprise that the EBA has a very confused proposal for long-term regulation of Bitcoin. We saw earlier how “someone take charge of Bitcoin” is the risible approach proposed. Naturally the EBA expects fitness and probity standards for these superheroes who will run Bitcoin, and that these people should be incorporated.

Some of the proposed regulations are quite sensible. The Know Your Customer rules should to apply to exchanges etc.:

156. The risk driver b), which concerns the anonymity of payers and payees could be addressed, at least within the EU, by requiring exchanges, and any other non-user market participants that interact with FC, to comply with CDD requirements.

Authorisation would be required for exchanges:

162. To address risk driver p), market participants such as scheme governance authorities and exchanges (and perhaps others) would need to be registered and authorised before beginning to provide VC services.

And capital requirements would be placed on any deposit-holding institution:

164. To ensure that market participants have sufficient funds to meet financial obligations in VC as well as FC, to compensate creditors during bankruptcy (risk driver l), and to absorb losses and facilitate an orderly wind-down, capital requirements will need to be placed on those participants that hold VC units on behalf of others. The requirements should consist of a fixed as well as a variable component that increase with business volume. The capital should to be held in a FC.

(I’m not sure holding it in ordinary currency alone is wise, but still).

Client funds should be separated:

165. To address risk driver m), market participants that hold VC units on behalf of others would be required to segregate their client VCs from their own VCs, complete periodic reconciliations of VC trading systems and VC stock held, and to keep appropriate records of reconciliations and transactions.

There is also a call for proper IT:

Evidence of secure IT systems
166. Given the exclusively digital-based nature of VCs, the IT security of a VC scheme is of utmost importance. Scheme governance authorities would be required to document the way in which they intend to guarantee the integrity of the transaction ledger, the protocol, the IT infrastructure and any other relevant components.

Good luck with that.

Related requirements may also need to be placed on other market participants, such as exchanges and e-wallet providers.

This is more sensible. Shockingly bad IT was a major factor in the Mt. Gox collapse, and Bitcoin has suffered in general from very amateurish IT development. However:

It will be a resource intensive task for regulators to check the adequacy of the systems and controls.

I suspect this is the major stumbling block with the EBA proposals. Some international cooperation and joint industry efforts would help (since every participant has the incentive for the market as a whole to be free of the shoddy systems). The regulators could confine themselves to requiring recognised certification from groups with necessary IT expertise.

There is also a requirement for refunds on error:

Payment guarantee and refunds
167. In the case of an unauthorised VC transaction, market participants involved in the transfer of the funds are required to refund to the payer immediately the amount of the unauthorised payment transaction and, where applicable, to restore the debited VC account to the state it would have been in had the unauthorised VC transaction not taken place.

A number of implementations for this are suggested (with ‘proxy’ intermediaries). Counter-signatory approaches aren’t mentioned (unsurprisingly).

A Glass-Steagal for Bitcoin is proposed:

Separation of VC schemes from conventional payment systems
169. Risk driver r) regarding the interconnectivity between VC and FC schemes should mainly be addressed by the mitigation measures in pre-existing oversight requirements for payment systems. However, complete mitigation can only be assured by requiring regulated financial institutions that decide to provide VC services to establish a separate entity for the VC- related business. This is to make sure that VC activities do not impair the financial soundness and settlement obligations of the regulated financial entity.

The merits of this are questionable, particularly when the size of the Bitcoin market is so tiny: eliminating the possibility to diversify risk over a much larger financial institution arguably reduces the identified risks of being unable to make good on guarantees and refunds.

The Bitcoin central authority is expected to develop standards and quality marks:

170.Risk driver l), regarding the lack of definitions and standards, could be addressed by regulators defining broader terms, and for the scheme governance authority to develop more specific standards, quality marks and definitions, and to make this party responsible for public information. Drivers n) and o) could be mitigated by requiring firms to set up complaints and redress schemes that are akin to those already in place for regulated VCs.

This might be a good role for an industry body where participants in Bitcoin act collectively and members agree to define and apply such quality marks. There might even be a plurality of bodies, and it would be for the market as a whole to decide how things developed.

The EBA also proposes market and other information be published, suspicious transactions be reported, etc.:

171. Drivers k) and q) regarding the lack of reporting requirements and resultant non-objective information could be addressed by requiring relevant market participants to submit specified
documents to regulators, including the results of their transaction monitoring, data on the amount and exchange rate applied to executed transactions, in addition to an obligation to report suspicious transactions. The data and information provided can be used to produce more objective and reliable information for market participants. Some market participants would also be required to disclose terms and conditions of their services to consumers.

The EBA distrusts Bitcoin so much that even after regulation (and even with the Bitcoin central authority) people will have to be warned it’s not legal tender. Scottish banknotes aren’t legal tender in England yet the Bank of England doesn’t run full-page advertisements in newspapers to tell us this (and in fact shops take the notes anyway, an indication that money doesn’t have to be officially legal to still be money).

Clear and transparent regulation
172. The risk driver of unclear regulation (h) would be addressed implicitly once the other risk drivers have been addressed and regulatory requirements along the proposal above have been put in place. However, even in this scenario, continued warnings to the public are likely to be required to make them aware of those risks that remain deliberately unmitigated, such as VC not being legal tender.

Most of the activities proposed by the EBA above are already being done (or in the process of being adopted) by the serious players in the Bitcoin market. And yet the EBA thinks:

175. The comprehensive regulatory approach outlined above would be highly resource-intensive. Moreover, this approach may take considerable time to develop, fine-tune and implement, depending (amongst other things) on the development of the VC market.

Either this is a call to expand the funding of the EBA, or else it is extra specially ill-equipped to examine the Bitcoin market. Perhaps it has its hands full with the Cajas and Länder banks? Who knows. Nevertheless, for an easy life the EBA recommends:

that national supervisory authorities discourage credit institutions, payment institutions, and e-money institutions from buying, holding or selling VCs, thereby ‘shielding’ regulated financial services from VCs.

The Bitcoin market is a tiny pinprick compared to the regulated financial services market. It’s hard to see how any kind of Bitcoin risk could exceed that already present in the market. This notwithstanding, legislators must deal with exchanges right now:

178. The EBA also recommends that EU legislators consider declaring virtual currency exchanges as ‘obliged entities’ that must comply with anti-money laundering and counter terrorist financing requirements set out in the EU Anti Money Laundering Directive.

But legislators mustn’t go too far because that would give credibility to Bitcoin:

79. Furthermore, the EBA cautions against drawing similarities between existing payment and payment-related services and some VC-based services. The decentralised nature of many VC schemes, the fact that the functioning and rules of a VC scheme can be changed, and the absence of a redeemer of last resort means that VCs are not comparable to conventional payment or electronic money services. As a result, they give rise to risks that do not exist in these services. Declaring some actors as falling into the remit of a specific national or EU law may therefore lend credibility to these actors and, by implication, to VC schemes themselves that may not necessarily be warranted.

In short, the EBA doesn’t really understand Bitcoin, is worried by the unknown, has exaggerated the risks, wants Bitcoin to go away and not be part of the European financial system in any way (except for all those annoying ID checks to open accounts).

A few days after the EBA report was published was a piece in the FT about how the European Commission is very concerned that Europe is being ‘digitally colonised’ by the US and other countries and how can Europe fight back. Duh.

If you liked this fisking of the EBA report then feel free to chuck me some bitcoins in my tip jar (hurry, because when all that lovely new SEPA banking stuff is in place I’m sure I’ll be switching to an EBA-regulated tip jar):

166vkDz7EqLV27g3aEqER2Z81vx43sYMp7

Bitcoin vs. Gaia smackdown: how Bitcoin miners aren’t killing the planet

There’s been a lot of yadda about how Bitcoin is destroying the planet by doing all this ‘pointless’ mining, so it’s worth looking at how much Bitcoin is hurting Gaia now and the trends, then putting all that wicked nerdish debauchery into perspective (Note: I’ve done my estimates from scratch by looking back over the last year, but there have been other approaches that looked at it from a different perspective). You can probably guess from my tone the TL;DR from this: that the “oh noes!” is wrong and that Bitcoin compares favourably with Western Union and other economic activities (and it’s not a patch on the impact of gold and silver mining).

Firstly, let’s make it clear what Bitcoin mining is for. From a miner’s perspective mining is about making money from minting new bitcoins and collecting fees. From a Bitcoin user’s view mining is about providing a global payments system that’s practically free (compared to Visa and Western Union, at any rate). Indeed, the perspicacious Fed economist David Andolfatto points out that the latter is the purpose, and supplied by the self-interest of the former (in my opinion just one example of Satoshi’s genius in designing Bitcoin). That self-interest runs to about $2m/day at present:

Image

Almost exactly a year ago I wrote about how Bitcoin mining works and gave some data for the (then) state-of-the-art in mining rigs: the 300MH/s of a GPU on a PC at 250W power consumption being replaced by the first generation of ASICs with 65GH/s at 350W. Here we are a year later where Avalon’s new rig does 1TH/s for 650W (about a hundred times more efficient than the GPU mining). The economics of mining have changed too. That GPU mining rig of 300MH/s costs 90¢/day in electricity to run and the revenue would be just 1¢/day (the owner would almost certainly be a part of a consortium to even achieve that). This is because the difficulty has shot up over the last year as ASICs came to replace GPUs:

Image

It’s this ‘arms race’ that changes the economics and forces out inefficient mining rigs. Since only fools and governments spend 90¢ to make 1¢ it’s pretty certain that GPU mining has died out. A year ago the first ASIC rigs were making about 3.75BTC a day ($500 back then, $1500 today). Those same rigs today would be making 0.0053BTC a day (that’s $2.05) with a cost of $1.26. If I had one of those rigs I’d probably have scrapped it by now.

From this we can get a perspective on the energy efficiency of the Bitcoin network as a whole: it must be way better than the 833W/GH/s of the GPU rigs, better than the 5W/GH/s of the first ASIC rigs and worse than the .65W/GH/s of the newest generation. A year ago the whole Bitcoin network could do 62TH/s, and if that was done at 833W/GH/s then the Bitcoin network electricity consumption rate would have been 51MW. Today the new Avalon 1TH/s rig has an efficiency of 0.65W/GH/s and if this reflected the entire Bitcoin network efficiency that would imply a consumption at a rate of 35MW (that won’t be the case, but it can’t be that far off either). Overall, then, it’s reasonable to assume that the Bitcoin network as a whole consumes electricity at a fairly constant rate, and that efficiency improvement is a zero-sum game (as far as electricity consumption is concerned).

So let’s go with 50MW as an estimate of power consumption of the Bitcoin network and see what that looks like vis a vis kicking Gaia in the ovaries. The UK Government has produced a figure of 0.44548 kg of CO2e per kWh of grid electricity (PDF). That would imply 534 tonnes of CO2e per day, about the same as 4000 US households. Another comparison is with other related activities in the economy: Carnegie Mellon University has created the Economic Input-Output Life Cycle Assessment (EIO-LCA) method for estimating the impact of an activity based on its economic value. Putting $2m/day (the Bitcoin mining revenue) into the model gives 1320 tonnes CO2e (gold and silver mining), 200 tonnes CO2e (securities, commodity contracts, investments), and 788 tonnes CO2e (amusement parks and arcades). Bitcoin hurts Gaia far less than gold mining and even the frivolous unworthwhile activities of enjoying a ride in an amusement park. Those EIO-LCA model numbers put the economic value of the bitcoin transactions validated by the mining process as zero which is clearly wrong: this is the whole point to Bitcoin but it’s a starting point for looking at the impact. The Bitcoin mining CO2e emissions are roughly fixed so as Bitcoin scales up from 0.5 transactions per second to 2000 per second the CO2e per transaction will fall dramatically. Just for comparison Western Union did 28 transactions per second in 2012 (PDF) with 7000 employees to obtain $5.7bn of revenue. If its carbon footprint is in line with the rest of the finance industry that’s 1710 tonnes CO2e a day to run their payment network, three times that of the Bitcoin mining network (I suppose it is only fair to point out that there’s more to Bitcoin’s carbon footprint than just the mining: just as Western Union’s carbon footprint will include gadding about in corporate jets and sales conferences on how to leverage the brand in Nigeria, Bitcoin also has to account for all those SF startup launch parties with ironic vodka for the hipsters).

In short, Bitcoin does not have the “carbon footprint from hell“: a footprint of 534 tonnes CO2e/day compares favourably with other economic activities and other payment networks.

If you liked this post here’s the address of my tip jar:

166vkDz7EqLV27g3aEqER2Z81vx43sYMp7

Beyond Bitcoin as just money: how even machines will be on the blockchain

The basic Bitcoin system as it’s used today is in essence pretty simple: it’s a distributed contracts ledger storing all the transactions (with a bit of pruning). Yet it has lead to a wild ride where stunning amounts of hard cash are exchanged for numbers in this abstract ledger. In May 2010 a pizza was bought for 10,000 BTC. By January 2013 bitcoins were trading at $10 each. In December 2013 they exceeded the price of gold. With all these crazy numbers it’s easy to focus on just the bitcoin (i.e. the currency) price speculation and ignore the bigger picture. Bitcoin blockchain transactions are far from being limited to simple A-to-B transfers. They can contain much more information, such as multiple payers, multiple payees, and rules on the signatures required for a payee to collect. There are even time locks that dictate how long a transaction can be valid. This allows quite sophisticated systems to be constructed, such as escrow agents for customer/merchant dispute resolution, co-signatories to accounts, time-limited deposits and even the equivalent of post-dated cheques. All of this sophistication is part of the Bitcoin system itself and requires no central authority.

All this is by itself is enough for a revolution in the finance industry, eliminating a whole class of payment intermediaries. But an even more radical change can be seen if we step back and look at the Bitcoin system itself in a different way. We can separate the bitcoin currency from the underlying system by realizing that the currency is the just the first ‘app’ to run on the Bitcoin system, and there can be more. Just as with the launch of the iPhone, the built-in apps are soon eclipsed by those that come from innovation the system unleashes. The key reason for this is that Bitcoin allows ‘permissionless innovation’ – where the only thing holding someone’s idea back is their own imagination (OK, so Apple’s app store rules hold people back too, which is why there aren’t any bitcoin wallets on iPhones, but I digress). The internet itself is the best example of permissionless innovation. In the mid-90s it was far from clear the internet was going to be so important (Krugman said that the internet would have no more impact than the fax machine), and most people were using a network called CompuServe (derided at the time as Compu$erve for being so focused on money). But to add something fundamental to a proprietary system requires agreement from the owner. And anyone who has tried to get large corporations to do something new will tell you just how easy that isn’t. This is why I think Bitcoin, warts and all, is the future for financial systems: because it’s here today, it works, and anyone can join in and do stuff with it without getting permission from some central authority. And I think that colored coins is one of the most exciting things that will be done with the Bitcoin system.

The concept of colored coins uses the Bitcoin system to store and manage the ownership of assets outside the Bitcoin system itself. These might be anything from shares to cars. The idea is that a particular bitcoin is ‘colored’ to signify the ownership of a particular asset. Because the block chain is public it is possible to then track that bitcoin ownership through all the transactions involving it and to derive the current ownership. The number of bitcoins included in the transaction is purely a token amount so a tiny value can be used, a little like writing an IOU for a car on a dollar bill and then storing it in a wallet designed to hold dollar bills.

Each particular coloring scheme has its own rules on how it interacts with Bitcoin, such as who is allowed to issue the colored coins, how they are redeemed, what type of transactions are permitted, etc. This is a flexible approach that even allows organizations to cooperate on a shared scheme (for example, a group of airlines jointly issuing flying points that can be redeemed, with the airlines outsourcing to Bitcoin the trading of those points). This is a big change in the way such schemes are run: the network is decentralised and can be used so that no single entity has control and so there is no opportunity to block competition and extract monopoly rents.

One really interesting use for coloured coins is for smart devices to connect up to the Bitcoin system. Today a box that streams movies from the internet must connect to a central server (e.g. the iTunes servers) to implement Digital Rights Management (DRM) to check what movies a user has bought before playing them. This means the producers of a movie can only sell to the user through that central service. If the operator of that service shut down for whatever reason then the user is left without access to the movies they bought. This has already happened for music: in 2008 Microsoft announced it would shut down its MSN Music service (using its ironically named PlaysForSure DRM system) and that its customers would no longer be able to transfer their music to any new computers they bought (soon after, Yahoo torched its DRM servers too). The Ultraviolet system, a joint venture by several Hollywood studios, is an attempt to do a better DRM system where the control of the central DRM server is wrested from the grasp of a single entity like Microsoft and put under the control of a group of companies. But Bitcoin could be better still: colored coins for movies would step around any need for a proprietary central DRM system: the blockchain would hold the entitlements. A customer’s video player could look at the blockchain directly (by embedding a Bitcoin client into the firmware of the player) to see what movies its owner had bought and then could prove to any server storing the movie that they were entitled to play it. The full features of Bitcoin transactions could be then used, enabling a movie to be rented, sold, re-sold, loaned, and so on. The issuer of the coloured coin for a movie would be the movie studio and they would control the terms of the market for their own movies (perhaps demanding a ‘droit de suite’ fee when it was transferred). Because the rules of the scheme would be open and transparent and the ownership rules (such as requiring the issuing studio to countersign transfers) embedded directly into the blockchain it would then be possible to define just what ‘ownership’ of a movie means. This would allow a proper market to develop and over time a proper balance between the rightsholders and consumers would be struck (and instead of the courts ruling on what Bruce Willis can do with his music it would be the transactions in the Bitcoin blockchain that made it clear).

The use of colored coins on top of the Bitcoin network is a bit of a kludge and obviously it would be better engineering to design something to support colored coins in a more direct way using a new Bitcoin-like network. But generally speaking things that work right now are preferred to grand things that will work in the future. While Al Gore was talking about the Information Superhighway we had the wheezing dialup modem internet much mocked in Doonesbury cartoons. But it was the internet that actually became that superhighway. Similarly, the Bitcoin network exists today with its thousands of specialist transaction processing computers worth a fortune and so there is nothing to stop companies using it to introducing new products and services right now.

Colored coins will likely follow the trend that started with the internet to weaken the power of intermediaries in markets. So much of the finance industry today is predicated on trusted central services for trading, for asset registers and for clearing. With a public blockchain and decentralized trading, the Bitcoin network has the potential to shake things up. Imagine a company issuing its own shares as colored coins: the ownership and trading of those coins is taken care of by the Bitcoin system, so what will existing organizations do? Will registrars offer ancillary services (e.g. for collecting dividend payments on behalf of an shareholder)? Will nominee services disappear? Will new ‘low cost’ venues emerge for trading small business shares by cutting out a large part of the cost of IT infrastructure? Predicting how this will shake out is a fun game, and this ‘wargaming’ is something that venture capitalists are going to be playing a lot in the near future.

My thoughts on Bitcoin, colored coins and DRM were previously published in the 13th December 2013 issue of MoneyWeek magazineIf you liked this post here’s the address of my tip jar:

166vkDz7EqLV27g3aEqER2Z81vx43sYMp7

Bitcoin and transaction limits

The Bitcoin blockchain has been worrying me for some time. I’m by background an embedded systems guy and I used to work in the automotive industry where 1K RAM was considered a lot. So the blockchain growing infinitely through time gives me the heebie jeebies (particularly after I read Charles Stross’ book Neptune’s Brood, which is basically about post-human robots thousands of years in the future transacting on the Bitcoin blockchain distributed across the Milky Way at the speed of light). Then I read a tweet by Joe Weisenthal asking about UBS’s comments on Bitcoin transaction rates:

Bitcoin can handle more than a transaction per second. But if Bitcoin is to scale to Visa-levels (let’s say an average of 2000 per second) then what will happen to the blockchain size (where these transactions get stored)? What will happen to miners who have to download the whole blockchain to participate in the Bitcoin network? If the blockchain grows so big that they can’t download it faster than it grows then Bitcoin is dead-ended. So I did some very simple modeling to see what might happen when Bitcoin scales out to a Visa-scale operation.

Just before we look at the model assumptions, though, we have to just cover a few Bitcoin basics. A block is added to the blockchain every ten minutes or so (the Bitcoin protocol scales the difficulty of mining – which is the process by which blocks are added – so that no matter how many miners or how powerful their rigs, it’s always about ten minutes). A block contains a whole bunch of newly-validated transactions but is also limited in size to 1MB. Individual transactions can vary in size (depending on several factors) and the maximum rate of transactions is between 5.2 and 10 per second. But this isn’t very helpful when looking to the future: it can be raised simply by making the blocks bigger. The worry is what happens to the size of the blockchain when we do that.

The data from blockchain.info shows that over the last 12 months on average each transaction added just under 500 bytes to the blockchain (and at an average rate of about 0.5 transactions per second – I think that’s what UBS are referring to with their “less than one transaction per second” remark). I wanted to model Bitcoin growing to Visa-scale over ten years (if you look at the speed of innovation, with things like smart phones, or the uptake of the internet itself, it’s about the right amount of time to go from small-scale to “I can’t remember what it was like before”). So that’s going from 0.5 transactions per second to 2000 over 120 months – a 7% month-on-month growth.

Over the last year the blockchain has grown from 5.7GB to 14GB and stored nearly 18 million transactions. There is a pruning mechanism that allows the blockchain to discard storing certain old transactions, but if we assume that the shape of future transactions is like the current ones then the blockchain will continue to grow with the same per-transaction storage costs. I worked out the size of the blockchain for each month, assuming those growth rates. The results are in the chart below:

size

Ten years out, the blockchain will be 40TB in size. That’s big, to be sure, but not that big (especially so with Year 2024 storage technology). To see how big it is here is the chart of the days required to download the blockchain at a domestic 100Mbit/sec internet connection:

Download

Basically an individual person could with a domestic ISP connection could join the mining business for some years yet (although it might take them a couple of weeks to download the blockchain to get started). I also worked out the minimum bandwidth to stay up-to-date with the blockchain:

Mbit

This is negligible by today’s standards, let alone ten years out.

Even when the size of the blockchain exceeds domestic internet speeds for downloading it there will still be the option of co-locating mining equipment in specialist data centres (much as we have evolved today for web servers). And no doubt it would even be possible to sync with the blockchain by sending a substantial part of it on a hard disk in the mail (as Andy Tanenbaum famously remarked: “Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway”).

The growth in the number of transactions would level out in the end (nothing can sustain 7% month-on-month growth). Quite where that point is no-one can say for sure (it might be very much higher than Visa and Mastercard if cash gets replaced with Bitcoin transactions, or it might be a lot lower if Bitcoin ends up in a niche of web micropayments). It’s also not obvious just how prevalent ‘off blockchain’ transactions will be (for example, very quick transactions between accounts within a network of cloud wallet providers). It may be that Bitcoin becomes an open version of something like TARGET2 where the blockchain primary stores just the major inter-cloud-wallet-provider clearing payments (c.f. inter-bank payments). For comparison, right now TARGET2 is running at about 4 transactions per second (PDF) – a rate that Bitcoin can already do.

So in short, Bitcoin can grow to the transaction scale of Visa without any foreseeable network or storage barriers.

If you liked this post here’s the address of my tip jar:

166vkDz7EqLV27g3aEqER2Z81vx43sYMp7

UPDATE:

There’s a wiki page on Bitcoin scalability at the Bitcoin wiki that also discusses some CPU load issues too.