OK. I just gave the game away by shoving it into the title. A bit late to say “spoiler alert”, I guess.

Last time I left the idea hanging that Bitcoin’s consensus rules could perhaps be expressed most effectively using Bitcoin’s own scripting language. What should give us additional confidence in this choice is that Bitcoin Script is a language that was explicitly designed for expressing distributed contracts. Surely, it would be impossible to argue that the consensus rules for Bitcoin, when taken together, are anything other than a contract?

Unfortunately, the present situation is that the contract terms that we expected to agree to is delivered to us as an unordered, highly cross-referenced, constantly changing, “book of codes” written in a language that only a minority actually understand, and which includes a massive dead weight of rules and concerns that have nothing at all to do with the contract. You shouldn’t have to suck that up; you wouldn’t just suck that up if your home insurance policy or credit card conditions were delivered to you in that form. Surely we deserve better.

So I guess the right thing to do is:

Find all the rules Write a Script for each that encapsulates that constraint Write a natural language explanation for each script Put it all in one place and in a logical order See if we actually do agree with the resulting contract

Time to get to work, right? All that should be enough for anyone to have to swallow! But wait a moment… we’re not going to let ourselves off the hook that easy. Instead, let’s go all the way and express Script itself as a protocol buffer, to see where that path takes us. As it turns out, it too leads somewhere kinda interesting.

Let’s take quick look at how you could do something this ludicrous, since you’re likely wondering about that, and the “how” bit is actually pretty easy:

message Script {

repeated Operation operations = 1;

} message Operation {

enum Code {

OP_FALSE = 0;

// and so on

OP_NOP10 = 185;

}

Code opcode = 1;

bytes data = 2;

}

OK, now we know it’s trivially possible (the full expression of the above is in the code repo on GitHub), we can talk about why you might want to — and even entertain the idea that you actually should want to.

We now have a lingua franca to launch higher level discussions, since any data structures and constraint functions now have a standard and platform-neutral format. The proto file can be used to generate the required reference client code in under a minute for pretty much any language and any platform. Each node has the capability to be exact and specific about which rules it is willing to observe, and is able to tell its peers. These consensus rules could be transmitted, accepted, loaded and executed as scripts at runtime. You know, a bit like Ethereum, but limited to deterministic, fully analyzable rules. The serialized form of a protocol buffer offers an alternative but more robust byte-accurate representation of data structures that is eminently suitable for the calculation and verification of hash digests and digital signatures.

Pretty worthwhile stuff, hunh? But before we step off the cliff, there’s a real burning issue that we need to address. What could that be? Well, weirdly, it’s about a specific systems programming language.