So here’s the thing. The more you dig into this, the more interesting this becomes.

After a first article on this, I set up a GitHub repo to track this, as I think there’s an awful lot more to be said.

After a first pass at a “bitcoin.proto”, I took the obvious next steps of setting up obvious default values and adding in enums to the definition, you know, simple stuff like:

message InventoryVector {

enum VectorType {

ERROR = 0;

TRANSACTION = 1;

BLOCK = 2;

FILTERED_BLOCK = 3;

}

VectorType type = 1;

bytes hash_reference = 2;

}

…so I added that version of the definition as “bitcoin-1.proto” to the repo. I took it one step further and turned the message wrapper’s command field from a (zero-padded) string into an enum as it seemed the most natural thing to do — a source of discussion for another time, methinks.

We could (and no doubt will) argue all that stuff out line-by-line, field by field… but I suspect there would be little room for dissent after the fact. I mean how many political positions can you take on a version number or a timestamp? Some things likely need a bit more explanation, for instance, I peeled out Coinbase, since it’s not just a transaction — it’s always the first transaction; it can have only one input; and that input has all that hacked-in special sauce in its sig_script.

All in all, those kinds of discussions seem eminently solvable, and often with fairly trivial logic.

A few things started to occur to me in fairly short order. It started with the observation that a lot of the concerns in the protocol are a direct result of it being originally coded in C/C++ (and a few of the bugs too), and frankly, it seemed that this was a case of the choice of implementation language tying people in mental knots. Shrug. Then I started to wonder…

…what if the Bitcoin protocol was actually implemented as a protocol buffer?

Well, I guess that was a cool thought, since this is what drops out: