Matthew Roberts

Former Bitcoin guy. Did some work on timechains, DAOs, and smart contracts.

Read this first

Atomic kidney-swap contracts to improve exchange liquidity across blockchains

If you’ve ever used a cryptocurrency exchange before you will have noticed a broad and dizzying array of new currencies. At the time of this writing there are hundreds of currencies being creating including new blockchains, colored coins, ERC-20 tokens, counter-party tokens… the list goes on. You can imagine that as these currencies proliferate it becomes harder and harder to directly match up traders on an exchange.

A standard exchange uses a limit-based order book to match up sellers and buyers by checking if the price per coin is compatible against a given currency pair. This means that limit orders can only be used to match up two traders if the currency pairs are the same so: Alice has x and wants y whereas Bob has y and wants x – simple.

This relationship works well where there are only a few major currencies but it doesn’t work well for things like commodity trading or

Continue reading →

What I think ShapeShift’s new Prism platform will be like

In about 12 days will announce details of their new system “built entirely on smart-contracts.” I don’t want to jump to conclusions here but if this is what I think it is – this could be the start of a very, very significant trend towards the big players in cryptocurrency exchange providing their customers with a much higher level of security.

For anyone who has been following these technologies you’ll notice that there hasn’t been any major companies trying to tackle “decentralized exchange.” I know of only a few companies who have tried to do this since 2013 and none of them managed to raise more than a few hundred K.

There are a few different reasons for this but what I think it comes down to is cost: it is far cheaper and easier to build a regular exchange and market it as a high security exchange then it is to do the opposite. So with ShapeShift’s Prism - I think it

Continue reading →

Turning back the clock on timechains - a follow-up

Notice: I removed subscribers and disabled subscriptions because I don’t like the idea of Subtle spamming people every time I make a post.

In 2015 I introduced the concept of a timechain as a solution to certain trust problems in smart contracts to mixed reviews. People like Greg Maxwell pointed out the uncertainty in the design which is something that would have made the timechain unsuitable for complex contracts whereby the timing of the clock needs to be within a certain range of accuracy [0].

But thinking about this some more I think there’s some very obvious solutions to this problem. There’s two main issues with my proposal:

  1. Serial hashing can be sped up on processors with faster clock speeds so the timechain will be broken faster than expected and
  2. The initial trust required in generating the chain.

Problem number 1 really needs to be considered in the context of two very

Continue reading →

Hundreds of lines of complex Bitcoin hacks reduced to a simple Solidity contract. Wow.

A couple of years back I was working on a smart contract in Bitcoin that implemented pay for private key contracts. The idea was that you can setup a contract to pay someone for releasing the details that allow a particular ECDSA Bitcoin private key to be extracted and payment is obviously conditional on the solution being correct.

In Bitcoin this is really damn complicated for a number of reasons. The first reason is that transaction IDs in Bitcoin can be randomly mutated so that chains of unconfirmed transactions can be invalided [0]. And the second reason is that all of the OP_CODES you need to create complex contracts in Bitcoin are either disabled or too limited to use.

That meant that the only way I could figure out how to get this contract to work on Bitcoin was to:

  1. Rely on a theoretical segwit existing (it’s not deployed yet) and
  2. Build a chain of transactions in such a way

Continue reading →

A coin for security

Here’s another idea for a cryptocurrency - a coin that rewards people for the practices they use to secure their cryptocurrencies on other blockchains.

This can all be done without trust because many aspects of cryptocurrency security already depend on cryptographic proof. A brief list of things that a cryptocurrency like this might check for includes:

  • N factor auth and hardware devices used for multi-sig signing.
  • Fail-safe theft recovery procedures
  • Password complexity and rotation checks (like revealing hash-locked inputs.)
  • Cryptographically provable wallet backups.
  • Use of privacy enhancing protocols.
  • Use of secure exchanges to purchase coins.
  • Other, e.g. provably secure constructs, possibly with trusted computing.

There are so many different ways to protect crypto-assets and I’ve put a lot of thought into working them all out over the years. But in spite of this the biggest

Continue reading →

Events are arbitrary

When I first got into Bitcoin my main area of interest was in smart contracts. I used to marvel at how the blockchain could be used to eliminate trust between people and I’d despair whenever an OP_CODE was removed (making the former harder to do.) But that’s only because I didn’t understand one subtle quality of how a blockchain works: events are arbitrary.


The blockchain really only has two qualities worth mentioning:

  1. It can securely order events on a network of untrusted computers.
  2. It defines an event called a transaction.

The second quality is optional [0]. It just so happens that in the case of Bitcoin enough information is already included with the software to describe what a “transaction” means so that now its become impossible to separate the network definition of “the blockchain” from “a transaction” [1].

But if you understand why this is then you understand that the

Continue reading →


Update: 19/02/2017 - added discussion on hacker news.
I also added an example.
Update: 21/02/2017 - added discussion of obfuscated exploits, early disclosure penalties, incentives, and scalability

Bug bounties suck. Researchers routinely don’t get paid for their work and vendors continue to get away with the same shitty behavior. It’s a system that lacks any kind of accountability and only benefits the company.

Solution: Do it as a smart contract on a blockchain.

 An example

  1. A smart contract to audit a C-based program is written. It includes a test case to see if a file with a specific name has been created under the process’ permissions. It also includes information about the program.
  2. A researcher finds a bug and uses it to write a buffer overflow exploit. The exploit is designed to pass the test case and is written using a special domain specific language for exploitable code for

Continue reading →

Some simple smart contracts to dispel the hype

In the past I’ve said that “smart contracts” are protocols for exchanging crypto-payment for some kind of specialized product or service without the need for trust. But within the Bitcoin-space I still see many examples of things that shouldn’t really be called a smart contract at all.

So here are some examples of some smart contracts that clearly show how payment can be given for some kind of service that has then been intertwined with payments so closely that trust is removed.

I’ll start with the simplest contract I know of and move on to some new contracts that help demonstrate the idea behind universal verifiability in trustless trade protocols. Here is the first contract.

 Example 1: Paying for a hash collision

value1 = get_input()
value2 = get_input()
btc_address = get_input()

# Values need to be different to prove a collision.
if value1 == value2:


Continue reading →

Hijacking consensus in Bitcoin with social engineering

Censorship in Bitcoin has become a massive problem [0]. There are only a number of places where people can speak their minds and be heard by the majority of Bitcoin users, and so far all of these places have become censored and controlled by only a handful of people [1].

If Bitcoin were suppose to be a technological response to trust in third-party financial companies then so far every Bitcoin user is still in the banking age of communication technology. And that is a very bad thing if you care about how centralization will effect Bitcoin in the future.

Without a decentralized medium for discussion anyone is able to control what information other people are allowed to post which creates the perfect opportunity to influence (and subsequently control) the ecosystem without ever having to compromise the blockchain directly.

This is possible because consensus in Bitcoin doesn’t just

Continue reading →

What if smart contracts were a new web standard = new achievement unlocked?

Edit: thought of a catchy name for this – Smart REST.

Smart contracts are all about formalizing trust relationships in an effort to try reduce critical points of failure within an agreement. The idea is that instead of trusting that a person will carry out a given function - we clearly segregate and define those responsibilities which can then be tied to the conditional release of collateral, the change of reputation, the conclusion of a legal contract, and even actions taking place within the real world.

To do this we use cryptographic ledgers which offer us a way to securely and publicly record relationships between individuals. In the case of financial relationships – some of these relationships can be made 100% trustless by using cryptography (a godsend to finance) - and in other cases its usually possible to reduce the amount of trust involved by using things like distributed

Continue reading →