January 25, 2015

What does it mean to "bitcoinate"? And just as importantly, what does bitcoinating not include?

Filed under: Uncategorized — @ 12:00 a.m.
What does it mean to "bitcoinate"? And just as importantly, what does bitcoinating not include?

The pumperos with whom I'm hacking on the 0.5.3 codebase coined the word "bitcoinate"1, to describe what an implementation of the bitcoin protocol2 must do in order to be considered "battle ready"3.

The question I intend to infect you with today is "what does it mean to bitcoinate?"4

I'm growing fonder of the notion there must be two components of the bitcoinator - one (call it bitcoind-node) that: downloads the blockchain, validates the blockchain, relays transactions and otherwise participates in the network at large, and the other (call it bitcoind-wallet) responsible for creating and signing transactions5.

A tentative list of what a thing in the vein of the above-described "bitcoind-node" must before being considered to "bitcoinate" follows6:

  • download blocks from the network
  • validate blocks in the blockchain
  • return a block corresponding to a given hash
  • relay transactions and otherwise participate in the p2p network protocol7

Nice to haves:

  • describe the tree of chains8

There's another implicit list here - "what does bitcoind currently do that is not, strictly speaking, necessary?". Let's attempt to enumerate that one as well9:

  • all wallet functionality
  • anything multisig related
  • anything wallet related
    • balance
    • addresses
    • {pub/priv}-keys
    • importing addresses
    • "key pool" related functionality
    • "accounts"
  • anything related to the creation or signing of transactions
  • fee estimation
  • priority estimation
  • the "single chain" paradigm

I bring this up to solicit input. If you've rants or screeds on what bitcoin should or should not do, drop me a line. If your comments have any merit, I'll manually append them to this document somewhere.



I am generally against word inflation, or the destruction of language by the assinging of arbitrary concepts to arbitrary sequences of letters or portmanteaus but in this case I will begrudgingly relent and only use the scare quotes here and there. I'm willing to do so in this case because when I am done (not with this blog post, but perhaps at the end of my life) "bitcoinating" will be a well-defined concept (unlike "mansplaining", which might be better phrased as "the barking of untrained dogs", or "the meaningless prattle of morons laboring under the effect described by Dunning and Kruger" - although that woudn't satisfy the politburo's agenda now, would it?).


Amusingly, while the protocol exists, it has not actually been written. The protocol has been implemented in various forms and by various people with varying degrees of success (bitc, Conformal's btcd, cbitcoin, libbitcoin, haskoin), but nobody's gone so far as to formally define the various protocols.

For a further mindfuck, consider that there is not one protocol, but actually three:

  • the network communication protocol (how nodes communicate with one another)
  • the block acceptance protocol (rules governing what constitutes a valid block)
  • the transaction acceptance protocol (rules governing what constitutes a valid transaction)

Note that "battle ready" does not necessarily mean "battle tested" much less "battle hardened", as a reference implementation may suffer from all kinds of warts. This would be the difference between a piece of software that can respond to an HTTP request, and Nginx (or Apache, if you're into that kind of thing). One HTTPates (if you will), and the other is a robust HTTP server that can handle an ungodly number of concurrent requests on commodity hardware.

For an example more relevant to our shared interests, the 0.5.3 codebase currently relies on an unauditable (in that it is very long, and just who owns a given IP address anyways?) list of DNS seeds that a new node may contact and from which it may begin to download blocks or whatever, that list is not a configurable thing, and it was written by people whose judgement, skills, and allegiances I don't trust worth a single satoshi. It also generates transactions in a nondeterministic fashion (not actually random, but crazy enough to be unpredictable by our mortal selves), and arbitrarily fails to create transactions without even so much as a useful message as to why. There are more of these, and I'll get to them in due time. Point being, there's much work to be done before the fork wars loom in seriousness.


This is very distinct from "what cool! innovative! disruptive! things could we contort Bitcoin into doing?" - a line that only ever serves as cover for the agents of darkness who would otherwise corrupt the only scarce and precious commodity in a world of plastic, paper gold, and inflation. Remember, when they say "blockchain 2.0", they mean "Bitcoin, but with inflation.".


This very definitely implies some data duplication. Were I to write this "bitcoind-wallet", it'd be a little thing that (maybe):

  • walks the blockchain tree from block zero to all final nodes
  • lets users retrieve any transaction (with outputs in the unspent pool) by TXID (aka: transaction hash)
  • lets users create raw transactions out of arbitrary entries in the unspent pool

Mind you, all of the above is entirely speculative. Until we get 0.5.3 into a shape where it can return blocks on demand, even building a wallet against it is asking too much, too soon.


Your comments are, as always, welcome via email. Rest assured that I'm aware of the inadequacy of this system. While you wait for me to fix this, bother me on IRC or send me an email.


This is actually worthy of its own full spec. Precisely which commands to which a bitcoind node is expected to respond and how is encoded in the source of course, but insisting that people read "idiomatic cpp" in order to distill the spec is just about as bad as things get in software.


As wiser heads said this evening:

Mircea: think of it as "chain of pointers" and now tell me who the fuck doesn't flunk the idiot that actually keeps an enumeration array for the chain

Stan: satoshi did not go in for book-learning, it seems, esp. re: data structures, but that doesn't mean that we have to forget school

Consider a fork on block validation rules (entirely likely if Gavin gets his way, which [sadly?] seems less and less likely on a daily basis). Imagine for a moment, that the inflation-prone miners actually work this chain for a long enough time that their coinbasen are approaching spendable. While this goes on, a small band of radicals and their oddball miner friends continue to mine on the other chain. There's less hashpower on it, it grows more slowly, whatever. At some point, Mircea Popescu and his scads of MPEx coins show up at all exchanges foolish enough to be clearing transactions with Gavincoins, selling them into the dirt. Popescu's play lasts far longer than any of the dumps orchestrated by the USG or any price suppression powered by Buterin's anemic waterfall. Forgive the cultish boosterism, but I'm well-convinced that Popescu can crush the price of Gavincoins to a low enough number and for a long enough time that all miners still profitable in the 150 range would panic (if not go straight out of business) and point their rigs right back at the One True Blockchain.

In this model we have not 2 chains, but rather a tree! There was once a block (A), from which someone mined the first > 1MB block, and from which the cultists continued to mine < 1MB blocks.

Wouldn't it be great if your Bitcoin software could somehow show you the full tree? All chains that'd ever been mined? All heights of all chains? All of the differences between them? Consider this data problem, look at that with which Andresen et. al have blessed you, and weep. Weep for that which could have been, that which should be, and that which damn it all to hell will, eventually, be.


List derived from 0.10.0 documentation.