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):


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.