Main menu

Introducing A New Bitcoin Foundation

Vessenes's Bitcoin Foundation maintains a notoriety for many questionable actions and behaviors. There is even a candidate running for the foundation's board on the platform of dissolution. Due to the oversights of Vessenes's Bitcoin Foundation, #bitcoin-assets recently formed its own foundation for the preservation of the Bitcoin reference implementation.

The new foundation notarized their charter in the Bitcoin blockchain using the #bitcoin-assets deed system, and will intake patches and commentary through their mailing list. Anyone in nanotube'sWeb of Trust that has a favorable Level 2 rating from assbot may submit a patch for consideration to be merged.

Owner and operator of CoinBr, jurov, volunteered to operate the mailing list, and will also be serving as the foundation's first treasurer, controlling the foundations assets in compliance with a GPG contract. Donations are only accepted in Bitcoin, at the address 1FundZy7m7b8begbh9haCguKJcAdFopRJ9. Mircea Popescu donated 10 BTC earlier this week at the foundation's launch stating, "I encourage anyone interested in the ultimate success of Bitcoin to contribute themselves."

The #bitcoin-assets Foundation also has a small website to act as a roadmap for individuals interested in the project.

Many mishaps have been perpetrated by Vessenes's Bitcoin Foundation such as, Mike Hearn almost merging HeartBleed into the reference client, directly causing 2013's blockchain hard fork, and Gavin proposing a future hard fork. Growing concerns of the frequency of these severe events fueled the inception of the foundation's core objectives. The mission of #bitcoin-assets Foundation is to vigilantly maintain "a reference implementation that is lightweight, coherent and cruft-free".

The objective section of the charter concludes by defining the operating principle of the foundation:

"That if and when any other thing conflicts with Bitcoin, that other thing must either be discontinued or amended in such a way as to no longer conflict with Bitcoin."

Qntra reached out to ben_vulpes one of the co-chairs of the newly formed foundation with a few interview questions:

thestringpuller: Tell us a little about how the mailing list will operate. Will everything be GPG encrypted and/or GPG signed?

ben_vulpes: The list won't broadcast messages that aren't GPG signed, so in that sense all messages must be so signed and with keys associated with entities who have positive ratings with respect to `assbot`'s L2.

As a side note, when the IRC channel #bitcoin-assets (on irc.freenode.net) switched over to this model for letting people contribute, there was much froth about how this would quash discussion and quell dissent. In my experience, the froth is all stuff and nonsense: the -asseteers bring people into the fold frequently and aggressively. Our patience is so great that only when miscreants have thoroughly hung themselves with the rope so given do we bother to ban them from our discussions (see the contributions of Robert Viragh aka ninjashogun for concrete examples).

thestringpuller: Patches submitted will be GPG signed by contributors with identities within the Bitcoin Web of Trust, how do you think this will affect what is submitted?

ben_vulpes: That patches are signed is far less important than that this project is only interested in patches signed by GPG keys associated with #bitcoin-otc WoT identities with positive trust from the `assbot` entity in the WoT.

`assbot` l2 trust alone however will be inadequate for patch merging. Patches will additionally have to bear signatures from *other* WoT entities I (and presumably `mod6`) trust before they're eligible for merging into what we're referring to as the "reference implementation" codebase.

thestringpuller: Do you anticipate any backlash from Gavin and Vessenes's Bitcoin Foundation?

ben_vulpes: Gavin et. al are involved in what they're calling the "reference client" (source: https://bitcoin.org/bin/0.9.0/README.txt). mod6 and I are interested in a stripped down "reference implementation". I can't speak to what Gavin and company mean when they say "reference client", but what I mean when I say "reference implementation" is a simple piece of software with minimal dependencies that a single technically competent individual can review and understand the entirety of. There's clearly a gap between the source tree that we're currently working on and the ideal of a "reference implementation" as stated above, but that's part and parcel of the immense task that we've taken on here.

Several of Gavin and company's implementations will illuminate the difference between the goals of our two groups:

– – – the "reference client" comes laden with a JSON-RPC client and concomitant set of calls that are, strictly speaking: entirely irrelevant to the reference implementation; bloat the codebase unnecessarily with HTTP calls; and justify the inclusion of such known-bad-libraries as openssl.

– – – the "reference client" has a dependency on `miniupnpc`, a library that nobody on our end has time to audit at even a surface level. UPNP (the protocol that `miniupnpc` implements) is the "Universal Plug and Play" library that allows a piece of implementing software to talk to consumer-grade routers in order to tunnel through to the internet. This decision is entirely understandable within the context of modifying Satoshi's original codebase such that consumers can run it on their home computers, and entirely irrelevant to the goals of creating a lean, mean, easy-to-understand reference implementation of the Bitcoin protocol. We expect anyone who would run code derived from our project in production (or for entertainment) to be able to configure communication between the internet at large and the bitcoin process in question.

– – – The "reference client" comes complete with a Graphical User Interface that takes a dependency on the immense QT library. As a reference implementation of the underlying Bitcoin protocol, our project will likely discard the entire GUI in the near future.

Expecting a team of volunteers focused on a stripped down implementation of the bare protocol with as few additional moving parts as are absolutely necessary to understand and audit unnecessary features and the libraries upon which they depend (I'm looking at `miniupnpc`, QT and libqrencode-dev here in particular) is entirely unreasonable.

I expect Gavin and company to dismiss us as a bunch of crackpots hacking on dumb shit in which nobody has any interest, while he and his merry band work to "Bring Bitcoin to the Masses(tm)".