A little while ago, Stanislav began hankering for a printed copy of Satoshi's codebase and began talking to nubbins` about making that happen. Comments were made along the lines of "surely you don't want the QT source included" and Stan shortly thereafter dropped a fork of the 0.5.3 Bitcoin repository with much "crapolade" removed.
Mircea Popescu then nominated mod6 and myself to maintain and further de-crapolade the source ball in question. mod6, as he's been around forever and knows his way around C++; myself as I've been derping at the edges of #bitcoin-assets1 for some time now alternating between being useful and a distraction.
Some other cultists chipped in to create some other interesting tools: jurov's "turdolator", and http://f9beb4d9.org/. The former is a mailing list configured such that it will only forward emails signed by those in assbot's l2 trust circle, and the latter a website collecting the various resources and entrypoints to the project.
- dignork provided a patch backporting the reward overflow bug patch
- adlai deployed a git repository with merged patches on a "polish" branch2
Amusing Things that We've Discovered to Date:
- Bitcoin binaries are built with the -g3 flag by default
- Bitcoin 0.5.3 corrupts its block database
High Level Project Goals:
"Bitcoin" currently suffers from having no proper formal specification, being only (poorly) specified as a particular codebase. A line oft used in pride is that a new implementation is "bug compatible" with Bitcoin, a symptom of the rot (both in the code and the minds of those working on the previously authoritative codebase) at play in the system.
One of this project's core goals is to achieve a reference implementation of Bitcoin that an individual might study, small enough in footprint that the individual might load the entirety of Bitcoin into his or her mind. Until a codebase that meets those critera is achieved, the hope of formally specifying the Bitcoin protocol will remain forever that - a hope, with no route from the place where we are today to that mythical world with a specification that trumps the implementation.
The project's technical goals are to decruft and debug the Satoshi codebase, while preserving (or restoring) its ability to "bitcoinate".
Well-intentioned human after well-intentioned human has assaulted the Bitcoin codebase with improvements over the past five years4. These improvements have been as trivial as the implementation of UPNP so that consumer users of Bitcoin and as malignant as the "wallet" paradigm5. De-complexifying the reference implementation may also lead to a wholesale removal of the JSON/RPC architecture and its HTTP baggage, and potentially checkpoints and "alerts" as well - all things irrelevant to that which is Bitcoin.
Debugging the reference implementation is also a core goal of our group. This involves fixing memory leaks that lead to a reported crash after 8 hours of continuous running; a reported Berkely DB corruption at block 252449; and whatever crops up in the process of polishing the Satoshi codebase into something that "bitcoinates".
Whatever is produced absolutely must perform all the core functions of Bitcoin: mining; authoring transactions; maintaining an internal database of inputs and outputs that a given bitcoin user would care about; and downloading a full copy of the blockchain from the network.
On top of all of the above, Mircea Popescu published what he's calling the "Bitcoin Declaration of Independence", which I'll reproduce (typo's and all) below:
The Declaration posits a 0.1% tithe to the Foundation. Perhaps someday, if Bitcoin companies ever do serious business and ever take their position in La Serenissima seriously, that may give the lever this little Foundation needs in order to move the world. Chip fabrication facilities aren't free, you know.
So if you want to tilt at windmills6 with the cultists of La Serenissima (that is to say, the denizens of #bitcoin-assets), drop by our forum and say hello. Be advised, though, that everything you say will be permanently searchable on the permanent record.
This is a dangerous distribution method, because there's no guarantee that the patches as merged in the Git repository are the same in any regard as the patches submitted to this new Foundation thingy. Adlai's work, while interesting and useful from a tooling perspective, is but the work of one man. A man with a very fresh WoT account, at that.
Debugging symbols enabled. Why? Nobody knows.
Crypto software and other tools that support the freedoms of individuals against the oppressive and hitherto well-funded governments are routinely subject to assault by the hordes of well-meaning incompetents. The traditional conspiracy-theorists' story is that the governments who would sabotage software that might compromise their powers of control and interception do so by drowning software maintainers in a sea of patch submissions that cannot possibly be all filtered by humans. Into this patchstream is dumped a mound of code that on the surface is entirely benign and implements features that somebody must want.
Implementing the patchstream bloats the codebase rendering the whole thing unaditable, and in which small changes can be effected that render the whole project entirely worthless. The canonical example of this being the steaming heap of code that is the OpenSSL codebase and the implantation of the Heartbleed bug therein by Seggelmann and Henson.
The theory depends on another, more cynical worldview, which is that the vast majority of open source codebases are not maintained by very good programmers at all, and that by and large anything can be slipped by them.
All of the above are borne out in their entirety by the behavior of those associated with what's called itself "the Bitcoin Foundation" to date and those working on a thing called "Bitcoin Core" to date. Every month sees more cruft and complexity added to a codebase that needs less of everything, not more.
In a nutshell, the naive implementation of "wallets" in Bitcoin uses a new change address for every single transaction a user broadcasts. The similarly naive wallet generates a fixed number of these addresses at the outset, meaning that should you use your naive wallet regularly, eventually the client will be forced to create a new address to send your change. This address will not be in your first backup, rendering that backup stale.
Rather than fixing the broken "wallet" implementation, the fix was to implement "coin control"; a gui tool for selecting which inputs to use for a given transaction. Stan calls this "gluing with glass" - instead of fixing a broken paradigm, the current maintainers take a further dependency on the GUI to provide a hack to ameliorate the end-user pain caused by "wallets".
Or partake in perhaps the best Alternate Reality Game ever devised…