Goal
To compile a brief / useful history of The Real Bitcoin (TRB) codebase from available sources.
Goal
- Goal
- Contents
- Summary
- Downloadable Assets
- Project Log
Summary
In the project Compiling bitcoind (trb 0.5.4) on Debian 7.11, I used the Bitcoin codebase TRB 0.5.4-RELEASE [x86-64].
Link to codebase storage article:
Codebase: TRB 0.5.4
In this article, I have explored and recorded some of the history of this codebase.
The rest of this section contains my summary of this history.
Stanislav Datskovskiy, also known as asciilifeform, wanted to have the Bitcoin code in book form.
This led to:
- The need for a reference implementation of Bitcoin, which could be printed.
- The choice of Bitcoin version 0.5.3 as an initial starting point. Rationale: 0.5.3 was the oldest still-functioning artifact that did not have any obvious catastrophic (exploitable) bugs.
- Stanislav Datskovskiy produced 'chicken', a cleaned version of 0.5.3. The cleaning included the removal of any binary data (i.e. non-printable ASCII). Mircea Popescu provided the original copy of 0.5.3.
- The decision to create a versioning system ('V') in which every patch is digitally signed.
- The choice to focus on a static build, and therefore the archival of specific versions of the necessary dependencies.
- Stanislav Datskovskiy, along with various other people, including Shane Kinney (also known as mod6), did a lot of work to produce a static build version of TRB, encapsulated in its own tiny Linux operating system, along with all the necessary dependencies (particularly a reliable version of the GCC compiler), via the use of the
buildroot
tool. TRB 0.5.4 requires ~4 GB of RAM to run and does not have memory leaks. It lacks: leveldb, p2sh, dns, glibc.
Additional notes:
- "the only devices a hypothetical bitcoin x86 os needs to comprehend is disk and nic".
- A custom filesystem for a Bitcoin node would need only a raw block device to which the node process can read/write.
- Looks like 'stator' is the core Bitcoin code (bitcoind), and 'rotor' is the set of dependencies that must be assembled underneath in order for the core Bitcoin code to run.
Downloadable Assets
Asset: The vpatch containing the cleaned Bitcoin 0.5.3 source code.
genesis.vpatch
Asset: The Bitcoin 0.5.3 source code.
bitcoin-0.5.3.tar.gz
Source of the previous asset: Browse to
github.com/bitcoin/bitcoin/releases/tag/v0.5.3
(Version 0.5.3 release), expand the Assets dropdown list, and click the "Source code (tar.gz)" link.
Project Log
The TRB codebase, also known as The Bitcoin Reference Implementation, is maintained by The Bitcoin Foundation, which is affiliated with The Most Serene Republic of Bitcoin (TMSR).
TRB stands for The Real Bitcoin.
TMSR runs an IRC chat channel called #trilema ("the forum") and a web of trust ("the wot"). Identities consist of GPG public keys and names. On IRC (Internet Relay Chat), names are called "nicks" (from "nickname").
The #trilema channel is on the Freenode IRC network. An IRC user chooses a nick and registers it with Freenode.
Browse to the #trilema chat channel logs:
btcbase.org/log
Note: This log site is maintained by phf.
I'll select various log excerpts that document / indicate / explain the history of TRB.
btcbase.org/log/2017-03-20#1629992
to
btcbase.org/log/2017-03-20#1630001
lulcoinz: my understanding is this group doesn't really support segwit or BU
lulcoinz: what is a trb node (sorry for my ignorance)
shinohai: lulcoinz: http://thebitcoin.foundation/trb-howto.html
lulcoinz: trb specifically (I know what a btc node is)
ben_vulpes: yeah ~right. segwit, aka "blockchains that don't validate" isn't a thing, and "bitcoin unlimited" wtf is that even
ben_vulpes: trb is "the real bitcoin"
ben_vulpes: the 0.5.3 codebase, dug out of the ground, polished and oiled into ~usability
asciilifeform: lulcoinz: it's the bitcoin you used in 2011. ~21,000 lines, and shrinking. ( and no 'headers-first' pseudo-verification idiocy, no leveldb, no p2sh, no githubism, no dns, no glibc, various other 'noes'. large collection of exquisite noes.)
shinohai: Just bitches and noes.
asciilifeform: no memory leaks, either (there's fragging, and it needs ~4GB to run, but will stay within the 4GB , indefinitely. )
lulcoinz: what is a trb node (sorry for my ignorance)
shinohai: lulcoinz: http://thebitcoin.foundation/trb-howto.html
lulcoinz: trb specifically (I know what a btc node is)
ben_vulpes: yeah ~right. segwit, aka "blockchains that don't validate" isn't a thing, and "bitcoin unlimited" wtf is that even
ben_vulpes: trb is "the real bitcoin"
ben_vulpes: the 0.5.3 codebase, dug out of the ground, polished and oiled into ~usability
asciilifeform: lulcoinz: it's the bitcoin you used in 2011. ~21,000 lines, and shrinking. ( and no 'headers-first' pseudo-verification idiocy, no leveldb, no p2sh, no githubism, no dns, no glibc, various other 'noes'. large collection of exquisite noes.)
shinohai: Just bitches and noes.
asciilifeform: no memory leaks, either (there's fragging, and it needs ~4GB to run, but will stay within the 4GB , indefinitely. )
btcbase.org/log/2015-12-05#1336916
to
btcbase.org/log/2015-12-05#1336922
asciilifeform: adlai: 0.5.3 was chosen as starting point on account of being the oldest still-functioning artifact having no obvious catastrophic (exploitable) bugs.
[...]
asciilifeform: if it doesn't agree with the established blockchain to the last bit, it isn't bitcoin.
asciilifeform: if it admits tx that 0.5.3 will not admit, it isn't bitcoin.
asciilifeform: etc.
asciilifeform: anybody trying to convince you of the opposite is after yer money.
[...]
asciilifeform: if it doesn't agree with the established blockchain to the last bit, it isn't bitcoin.
asciilifeform: if it admits tx that 0.5.3 will not admit, it isn't bitcoin.
asciilifeform: etc.
asciilifeform: anybody trying to convince you of the opposite is after yer money.
btcbase.org/log/2018-09-21#1852652
asciilifeform: technically asciilifeform was responsible for 'chicken' ( the procedure whereby mp's 0.5.3.tar.gz was transformed into genesis but if mircea_popescu is willing to answer for it, i have 0 prob, lol )
btcbase.org/log/2015-12-25#1352853
to
btcbase.org/log/2015-12-25#1352854
mircea_popescu: http://log.bitcoin-assets.com/?date=25-12-2015#1352791 << it's true, i never picked 5.3 per se. my contribution was that i said no later than 6 series ; foundation held an informal hearing, decided to go the earliest possible rather than latest possible route, supoena'd me for historical copies which i provided and htey used.
assbot: Logged on 25-12-2015 09:15:18; ben_vulpes: the link you cite as mircea_popescu picking 0.5.3 is a response to a request for a copy of the source of a particular vintage
assbot: Logged on 25-12-2015 09:15:18; ben_vulpes: the link you cite as mircea_popescu picking 0.5.3 is a response to a request for a copy of the source of a particular vintage
btcbase.org/log/2015-08-16#1239766
to
btcbase.org/log/2015-08-16#1239769
asciilifeform: try to remember the basic reason why we're using 0.5.3 as foundation rather than starting from empty.
[...]
asciilifeform: it is a steaming pile of shit, but has one saving grace: it existed prior to the war.
asciilifeform: prior to bitcoin being dear.
[...]
asciilifeform: it is a steaming pile of shit, but has one saving grace: it existed prior to the war.
asciilifeform: prior to bitcoin being dear.
Emergence of the idea of the signed patch system:
btcbase.org/log/2014-10-22#888443
to
btcbase.org/log/2014-10-22#888460
mircea_popescu: gpg commits!
mircea_popescu: get everyone used to checking sigs.
mircea_popescu: nonw of this ssh bs
mircea_popescu: none*
jurov: via irc bots! bring the noize!
asciilifeform: mircea_popescu: i rarely if at all run openbsd tho << now we know, he has personal os and btc apparatus! with alien technology.
bounce: no idea how that works. you'd have to have git check against valid gpg sigs from blessed keys or something?
asciilifeform: gpg commits << yay! somebody Gets It
mircea_popescu: jurov might be a good idea via bots, so people can commit from here directly, but even w/o that : a contrib that is signed is signed permanently.
mircea_popescu: a contrib that is submitted via ssh WAS, maybe, perhaps, signed at some point.
bounce: no real point trying to go through bots when git can do it right away
jurov: i have to look into how signed commits are done
mircea_popescu: bounce only because people see it in the logs.
mircea_popescu: jurov it can just be wrapped in gpg --clearsign you know ?
bounce: you can have git trigger a log whatnot and feed that to the other end of a bot
mircea_popescu: certainly.
jurov: mircea_popescu: but iirc it signs the diff, not just commit message
asciilifeform: how to do signed commits << the barbarian way. everyone who read a patch file (yes) and is willing to sign under it, signs. this gets posted. whoever wants, can apply the patches to get a merged turdball.
mircea_popescu: get everyone used to checking sigs.
mircea_popescu: nonw of this ssh bs
mircea_popescu: none*
jurov: via irc bots! bring the noize!
asciilifeform: mircea_popescu: i rarely if at all run openbsd tho << now we know, he has personal os and btc apparatus! with alien technology.
bounce: no idea how that works. you'd have to have git check against valid gpg sigs from blessed keys or something?
asciilifeform: gpg commits << yay! somebody Gets It
mircea_popescu: jurov might be a good idea via bots, so people can commit from here directly, but even w/o that : a contrib that is signed is signed permanently.
mircea_popescu: a contrib that is submitted via ssh WAS, maybe, perhaps, signed at some point.
bounce: no real point trying to go through bots when git can do it right away
jurov: i have to look into how signed commits are done
mircea_popescu: bounce only because people see it in the logs.
mircea_popescu: jurov it can just be wrapped in gpg --clearsign you know ?
bounce: you can have git trigger a log whatnot and feed that to the other end of a bot
mircea_popescu: certainly.
jurov: mircea_popescu: but iirc it signs the diff, not just commit message
asciilifeform: how to do signed commits << the barbarian way. everyone who read a patch file (yes) and is willing to sign under it, signs. this gets posted. whoever wants, can apply the patches to get a merged turdball.
Ben Vulpes published an account that covers much of the history of the codebase. I'll copy it in full here.
Title: A brief history of the Bitcoin Foundation's activity from 10/2014 through 4/2015
Author: Ben Vulpes
Link:
cascadianhacker.com/02_a-brief-history-of-the-bitcoin-foundations-activity-from-102014-through-42015
Date: May 2, 2015
Last October (after my foray into bitcoind archaeology), mod6 and I took stewardship of the Satoshi, issuing a build of what we call the "Reference Implementation".
A rough chronology:
- October:
-- I publish an overview of changes to the Satoshi codebase since 0.3.1
-- Mircea Popescu proposes that mod6 and I head up what turns into the sanest collection of work on the Satoshi codebase.
-- mod6 and I publish the charter for La Serenissima's Foundation, determined to draw and hold a line against further USG-sponsored shitgnomery
-- mod6 and I contract with jurov to handle Foundation funds
-- asciilifeform transmits "chicken", the manifest of which mod6 uses to prune the USG Foundation's codebase into (some semblance of) sanity.
-- jurov builds and deploys a gpg-enabled mailserver for the Foundation
-- dignork submits the first patch to the Foundation's mailing list, backporting a fix for the mining overflow bug
- November:
-- mircea_popescu publishes the Bitcoin Declaration of Sovereignty
-- asciilifeform pushes a mess of patches to the turdolator
-- mod6 reconfigures BDB to pass the wedge at block 252450
- December:
-- Bastard block memory exhaustion bug surfaces
-- the Foundation starts working to cut a "release"
- January:
-- myriad scripts and patches to said are written
-- asciilifeform writes `auto.sh` and patches the Satoshi makefile for cross-architecture compiling
-- asciilifeform backports the orphanage burner
- February:
-- asciilifeform writes a patch snipping DNS from the Satoshi codebase
-- asciilifeform starts publishing notes from his work on the Pogo project
-- The Foundation discovers that Bitcoin depends on a specific version of OpenSSL (1.0.1g is what we're working with for now)
- March:
-- People insist that static builds are a hard requirement, Foundation gets to work
-- The Foundation releases a source tarball as a base for further work
- April:
-- asciilifeform discovers that: GCC is not producing static builds due to "getaddrinfo" and "gethostbyname" dependency on system libraries at runtime, gcc + libnss madness
-- Everyone knocks off to get their shit together in preparation for the conference
That's all!
The original impetus seems to have been asciilifeform's desire to have a printed book version of the Bitcoin code, which led to the need for a reference implementation, a versioning system based on signed patches, and an enumeration of the necessary dependencies.
btcbase.org/log/2014-11-09#915374
to
btcbase.org/log/2014-11-09#915389
RagnarDanneskjol: can you pls direct me to jurov's requirements?
RagnarDanneskjol: or the rules of contention
asciilifeform: RagnarDanneskjol: http://therealbitcoin.org/mailman/listinfo/btc-dev
RagnarDanneskjol: oh that ok
asciilifeform: described in 'submitting patches'
RagnarDanneskjol: right got it
asciilifeform: the only thing not mentioned there, is the absolute need for patches to be readable
RagnarDanneskjol: i see
asciilifeform: that is, it must address a specific thing, and patch is not really considered worthwhile until other participants are willing to sign it.
RagnarDanneskjol: should be interesting
asciilifeform: (which others must sign? this question has not been formally answered yet. on account of there not being a real maintainer.)
asciilifeform: i did the last merge personally, and i think a few folks here are using it
asciilifeform: but i'm not an 'official' anything.
asciilifeform: (other than being the devil who led these folks into the temptation of trying to craft a 'reference implementation.')
RagnarDanneskjol: heh
asciilifeform: i also wrote a few of the simple patches found on jurov's site right now
RagnarDanneskjol: or the rules of contention
asciilifeform: RagnarDanneskjol: http://therealbitcoin.org/mailman/listinfo/btc-dev
RagnarDanneskjol: oh that ok
asciilifeform: described in 'submitting patches'
RagnarDanneskjol: right got it
asciilifeform: the only thing not mentioned there, is the absolute need for patches to be readable
RagnarDanneskjol: i see
asciilifeform: that is, it must address a specific thing, and patch is not really considered worthwhile until other participants are willing to sign it.
RagnarDanneskjol: should be interesting
asciilifeform: (which others must sign? this question has not been formally answered yet. on account of there not being a real maintainer.)
asciilifeform: i did the last merge personally, and i think a few folks here are using it
asciilifeform: but i'm not an 'official' anything.
asciilifeform: (other than being the devil who led these folks into the temptation of trying to craft a 'reference implementation.')
RagnarDanneskjol: heh
asciilifeform: i also wrote a few of the simple patches found on jurov's site right now
btcbase.org/log/2014-10-31#905103
to
btcbase.org/log/2014-10-31#905132
mod6: so, since we're talking about it, what would be the most idea env for such a reference implentation? a fully stripped openbsd with a custom fs & drivers?
[...]
BingoBoingo: mod6: OpenBSD on its own is prolly hostile enough to dev in
asciilifeform: mod6: custom fs doesn't require an os-level turd, just a raw block device that the process is permitted to r/w.
mod6: s/openbsd/*bsd
asciilifeform: mod6: idea being, among other merits, that in the future shedding the os entirely will be considerably easier.
mod6: so you wouldn't say, want to strip kern mods out or whatever?
mod6: what about wintel eth drivers?
asciilifeform: that's a separate work
mod6: what about like 69000 other things?
asciilifeform: what other things?
BingoBoingo: What ken mods? OpenBSD offers two kernels bsd and bsd.mp, if you want more fuck you
asciilifeform: the only devices a hypothetical bitcoin x86 os needs to comprehend is disk and nic
asciilifeform: disk - see example posted earlier (< 1 kb asm)
mod6: eh..nm
asciilifeform: nic - similar. see example in 'bare metal os' (bsd license, iirc)
asciilifeform just wanted a fucking book
BingoBoingo: asciilifeform: Problem is book has wants too
[...]
asciilifeform: 'first the man takes a drink, then the drink takes a drink, then the drink takes the man'
asciilifeform: (jp?)
BingoBoingo: Indeeds
BingoBoingo: Prolly universal
asciilifeform: one of the things pretty much no one (save possibly mircea_popescu) seems to comprehend is that bitcoin is, what old timers call - 'safety critical code'
asciilifeform: as in, would you want a multithreaded os like unix on, e.g., pacemaker ?
asciilifeform: safety critical means not always death, but wors
asciilifeform: e
BingoBoingo: Actually... in cariac replacement parts, mechanical failures tend to kill first.
asciilifeform: like, your whole reich goes down
[...]
BingoBoingo: mod6: OpenBSD on its own is prolly hostile enough to dev in
asciilifeform: mod6: custom fs doesn't require an os-level turd, just a raw block device that the process is permitted to r/w.
mod6: s/openbsd/*bsd
asciilifeform: mod6: idea being, among other merits, that in the future shedding the os entirely will be considerably easier.
mod6: so you wouldn't say, want to strip kern mods out or whatever?
mod6: what about wintel eth drivers?
asciilifeform: that's a separate work
mod6: what about like 69000 other things?
asciilifeform: what other things?
BingoBoingo: What ken mods? OpenBSD offers two kernels bsd and bsd.mp, if you want more fuck you
asciilifeform: the only devices a hypothetical bitcoin x86 os needs to comprehend is disk and nic
asciilifeform: disk - see example posted earlier (< 1 kb asm)
mod6: eh..nm
asciilifeform: nic - similar. see example in 'bare metal os' (bsd license, iirc)
asciilifeform just wanted a fucking book
BingoBoingo: asciilifeform: Problem is book has wants too
[...]
asciilifeform: 'first the man takes a drink, then the drink takes a drink, then the drink takes the man'
asciilifeform: (jp?)
BingoBoingo: Indeeds
BingoBoingo: Prolly universal
asciilifeform: one of the things pretty much no one (save possibly mircea_popescu) seems to comprehend is that bitcoin is, what old timers call - 'safety critical code'
asciilifeform: as in, would you want a multithreaded os like unix on, e.g., pacemaker ?
asciilifeform: safety critical means not always death, but wors
asciilifeform: e
BingoBoingo: Actually... in cariac replacement parts, mechanical failures tend to kill first.
asciilifeform: like, your whole reich goes down
btcbase.org/log/2014-02-13#499716
to
btcbase.org/log/2014-02-13#499717
asciilifeform: mike_c: i'd love to read 'Bitcoin, the book.' with rationales. but it would be of little worth without a strictly-minimal, brain-loadable reference implementation.
asciilifeform: with no sharp edges.
asciilifeform: with no sharp edges.
btcbase.org/log/2014-02-13#499769
to
btcbase.org/log/2014-02-13#499793
asciilifeform: the question is not of a 'perfect' implementation,
mircea_popescu: but of a definite one.
mircea_popescu: something natural language will never be.
asciilifeform: but of one that can actually be understood, by a reasonably-intelligent person, with reasonable effort.
asciilifeform: the way one understands a kalashnikov.
asciilifeform: (what values of 'reasonable', depends on the intrinsic complexity of the problem.)
MisterE: mike_c: at this point in time I agree
asciilifeform: 'natural language' only has a place here as a teaching aid.
MisterE: eventualy you have to ship
asciilifeform: and never as a substitute for mechanics.
mike_c: yes. and perhaps satoshi could write that. barring that, i think the order should be: we agree on the rationale, then are capable of writing the kalishnikov version.
mircea_popescu: no, because this is not art an we aren't making a vase.
mircea_popescu: this is science, we're describing an actual real process.
asciilifeform: the only truly unambiguous definition of a computation is the computation itself.
mircea_popescu: it's not a matter of agreeing how we'd like the vase to look, but a matter of representing how gravity actually and in fact does work
mike_c: you don't build the perfect factory by starting to build the machines. you figure out the overall process first, the steps. then you build the robots.
mircea_popescu: why are you so focused on the building and implementation notional universe ?
mike_c: the fricking white paper came before the code
mircea_popescu: seems odd, a state machine is an abstraction.
asciilifeform: we've got the robot. with a warehouse's worth of extraneous junk welded to it.
asciilifeform: and parts held together with tape.
mircea_popescu: mike_c i suspect the code only came because the response to the paper was a particular brand of retarded.
mike_c: asciilifeform: ok.. so you are saying reverse engineer instead of start from the top.
[...]
asciilifeform: mike_c: you could certainly phrase it that way.
mircea_popescu: but of a definite one.
mircea_popescu: something natural language will never be.
asciilifeform: but of one that can actually be understood, by a reasonably-intelligent person, with reasonable effort.
asciilifeform: the way one understands a kalashnikov.
asciilifeform: (what values of 'reasonable', depends on the intrinsic complexity of the problem.)
MisterE: mike_c: at this point in time I agree
asciilifeform: 'natural language' only has a place here as a teaching aid.
MisterE: eventualy you have to ship
asciilifeform: and never as a substitute for mechanics.
mike_c: yes. and perhaps satoshi could write that. barring that, i think the order should be: we agree on the rationale, then are capable of writing the kalishnikov version.
mircea_popescu: no, because this is not art an we aren't making a vase.
mircea_popescu: this is science, we're describing an actual real process.
asciilifeform: the only truly unambiguous definition of a computation is the computation itself.
mircea_popescu: it's not a matter of agreeing how we'd like the vase to look, but a matter of representing how gravity actually and in fact does work
mike_c: you don't build the perfect factory by starting to build the machines. you figure out the overall process first, the steps. then you build the robots.
mircea_popescu: why are you so focused on the building and implementation notional universe ?
mike_c: the fricking white paper came before the code
mircea_popescu: seems odd, a state machine is an abstraction.
asciilifeform: we've got the robot. with a warehouse's worth of extraneous junk welded to it.
asciilifeform: and parts held together with tape.
mircea_popescu: mike_c i suspect the code only came because the response to the paper was a particular brand of retarded.
mike_c: asciilifeform: ok.. so you are saying reverse engineer instead of start from the top.
[...]
asciilifeform: mike_c: you could certainly phrase it that way.
btcbase.org/log/2014-02-13#499833
to
btcbase.org/log/2014-02-13#499839
herbijudlestoids: i was under the impression that the existing implmentation was pretty well coded (at least from a security perspective) but it seems like most on here disagree
herbijudlestoids: for if it was good we would not be having this discussion
mircea_popescu: herbijudlestoids the original stuff was poorly written by one unexperienced coder with a lot of system design experience.
mircea_popescu: it has since been "fixed" in the hands of mediocre coders with no system design comprehension whatsoever.
mircea_popescu: the resultant mess is unusable past about 0.6.x or thereabouts, for these reasons.
pankkake: the initial code was horrible, couldn't get it to compile, full of wxwindows crap where there shouldn't be. stayed away :/
pankkake: just having bitcoind with no GUI code was than achievement
herbijudlestoids: for if it was good we would not be having this discussion
mircea_popescu: herbijudlestoids the original stuff was poorly written by one unexperienced coder with a lot of system design experience.
mircea_popescu: it has since been "fixed" in the hands of mediocre coders with no system design comprehension whatsoever.
mircea_popescu: the resultant mess is unusable past about 0.6.x or thereabouts, for these reasons.
pankkake: the initial code was horrible, couldn't get it to compile, full of wxwindows crap where there shouldn't be. stayed away :/
pankkake: just having bitcoind with no GUI code was than achievement
btcbase.org/log/2014-12-03#944208
asciilifeform: so, the bitcoind cleanup thing is conceivably useful, because end result could be the book i asked for, and a year or so from now i (or someone else) can read it, and build rational design.
btcbase.org/log/2014-10-21#885782
asciilifeform: ;;buy 1 "Printed and bound copy of Bitcoin ver. 0.6 source; organized into chapters by file, coloured for syntax." at 1 BTC
btcbase.org/log/2016-05-30#1473624
to
btcbase.org/log/2016-05-30#1473628
asciilifeform: long ago i wrote an article re the undisputably higher quality of hardware products vs software, on account of the impossibility of patching hardware
asciilifeform: a similar effect applies to the book
asciilifeform: which could not be fixed remotely (legends of 'great soviet encyclopaedia' owners being sent razor blade and list of what to censor notwithstanding)
asciilifeform: hence more effort is put in, prior to printing
asciilifeform: likewise the expense of printing/binding (and in the age of living culture it was quite expensive) was a pretty good bozo filter.
asciilifeform: a similar effect applies to the book
asciilifeform: which could not be fixed remotely (legends of 'great soviet encyclopaedia' owners being sent razor blade and list of what to censor notwithstanding)
asciilifeform: hence more effort is put in, prior to printing
asciilifeform: likewise the expense of printing/binding (and in the age of living culture it was quite expensive) was a pretty good bozo filter.
btcbase.org/log/2016-01-21#1380023
asciilifeform: (boost exists largely because cpp is not actually programmable in without using something like boost. which has been largely incorporated into the recent standard.)
btcbase.org/log/2015-11-27#1332533
ascii_field: my original purpose for asking nubbins for The Book, if anyone remembers, was so that i could rewrite.
List of patches from Codebase: TRB 0.5.4:
asciilifeform-kills-integer-retardation.vpatch
asciilifeform_add_verifyall_option.vpatch
asciilifeform_and_now_we_have_block_dumper_corrected.vpatch
asciilifeform_and_now_we_have_eatblock.vpatch
asciilifeform_dns_thermonyukyoolar_kleansing.vpatch
asciilifeform_dnsseed_snipsnip.vpatch
asciilifeform_lets_lose_testnet.vpatch
asciilifeform_maxint_locks_corrected.vpatch
asciilifeform_orphanage_thermonuke.vpatch
asciilifeform_tx-orphanage_amputation.vpatch
asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch
asciilifeform_zap_hardcoded_seeds.vpatch
asciilifeform_zap_showmyip_crud.vpatch
bitcoin-asciilifeform.1.vpatch
bitcoin-asciilifeform.2-https_snipsnip.vpatch
bitcoin-asciilifeform.3-turdmeister-alert-snip.vpatch
bitcoin-asciilifeform.4-goodbye-win32.vpatch
bitcoin-v0_5_3-db_config.6.vpatch
bitcoin-v0_5_3_1-rev_bump.7.vpatch
bitcoin-v0_5_3_1-static_makefile_v002.8.vpatch
genesis.vpatch
makefiles.vpatch
malleus_mikehearnificarum.vpatch
mod6_der_high_low_s.vpatch
mod6_fix_dumpblock_params.vpatch
programmable-versionstring.vpatch
rm_rf_upnp.vpatch
asciilifeform_add_verifyall_option.vpatch
asciilifeform_and_now_we_have_block_dumper_corrected.vpatch
asciilifeform_and_now_we_have_eatblock.vpatch
asciilifeform_dns_thermonyukyoolar_kleansing.vpatch
asciilifeform_dnsseed_snipsnip.vpatch
asciilifeform_lets_lose_testnet.vpatch
asciilifeform_maxint_locks_corrected.vpatch
asciilifeform_orphanage_thermonuke.vpatch
asciilifeform_tx-orphanage_amputation.vpatch
asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch
asciilifeform_zap_hardcoded_seeds.vpatch
asciilifeform_zap_showmyip_crud.vpatch
bitcoin-asciilifeform.1.vpatch
bitcoin-asciilifeform.2-https_snipsnip.vpatch
bitcoin-asciilifeform.3-turdmeister-alert-snip.vpatch
bitcoin-asciilifeform.4-goodbye-win32.vpatch
bitcoin-v0_5_3-db_config.6.vpatch
bitcoin-v0_5_3_1-rev_bump.7.vpatch
bitcoin-v0_5_3_1-static_makefile_v002.8.vpatch
genesis.vpatch
makefiles.vpatch
malleus_mikehearnificarum.vpatch
mod6_der_high_low_s.vpatch
mod6_fix_dumpblock_params.vpatch
programmable-versionstring.vpatch
rm_rf_upnp.vpatch
27 patches in total.
17 contain the name "asciilifeform" and were presumably written by him.
2 contain the name "mod6" and were presumably written by him.
asciilifeform also made the genesis.vpatch file.
The mailing list (on which various patches were exchanged) is archived at:
therealbitcoin.org/ml
I'll reproduce some of these emails here.
The emergence of 'chicken', the item that asciilifeform derived from Mircea Popescu's copy of version 0.5.3 of the Bitcoin source code.
Link:
therealbitcoin.org/ml/btc-dev/2014-October/000003.html
[BTC-dev] chicken proper
Stanislav Datskovskiy stas at loper-os.org
Thu Oct 30 00:12:57 UTC 2014
[...]
-------------- next part --------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
asciilifeform's chicken recipe.
The cook must, regardless of what else, gut chicken and remove turds.
But first,
- --- First, Steal A Chicken: ---
- -------------------------------
Obtain:
https://codeload.github.com/bitcoin/bitcoin/legacy.tar.gz/v0.5.3
sha256:
aab1f8ea8c7f131ff69dfa3b9437ba35531018be760132dd6373f41a591f6382 bitcoin-bitcoin-v0.5.3-0-gd05c03a.tar.gz
now, from here on:
bitcoin-0.5.3.sha256.manifest ------------- contains hash manifest for above.
bitcoin-0.5.3-no-crud.sha256.manifest ----- with crapolade snipped out.
- --- Cook the chicken: ---
- -------------------------
1) Prepare the tree reflected by bitcoin-0.5.3-no-crud.sha256.manifest.
2) Obtain patches, verify signatures.
3) Apply patches in the customary way.
4) Build.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBAgAGBQJUUDw8AAoJELmCKKABq//HCkUIAISGM0f2U7CglNWIc/uo3uDv
P7GnZWII0Q5RgPm0TUkw0Swy9JbOls8FOb0S8yKXc33lnIJJf5ySt4+OIWwbWeKu
BXNx+QnnZ9/act4KueK0xW3nJ8mipLNSJ48drtdr6Q+NuHdHycon83R2zmv/wpiH
Q11JQcaBLo8hZEkvRZcZMPfL806Calsq2vO1GySC7ahNy/ROIyR0AznPds4eCUST
dRWIPiiRTA1v1xHO1KPelIriWLU5f3gTZEuTw3lvwJlHcw6PYd4jHyeH5Qcn+RIP
38NgRD1tQAMC7g56FnjIsK0RDLRhM79IKb/Viv0Pj9c71hRTacKRGHcmn2tRL5c=
=3kTd
-----END PGP SIGNATURE-----
The emergence of the 'stator' / 'rotor' combination. Looks like 'stator' is the core Bitcoin code (bitcoind), and 'rotor' is the set of dependencies that must be assembled underneath in order for the core Bitcoin code to run.
Link:
therealbitcoin.org/ml/btc-dev/2015-July/000133.html
[BTC-dev] Rotor!
Stanislav Datskovskiy stas at loper-os.org
Mon Jul 27 21:15:52 UTC 2015
[...]
Name: README_s.txt
URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20150727/README_s_14971be368dc231e73f704f3d4c71d30836b1646.txt>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Meet 'Rotor.'
This is the full orchestra at last.
It will build a fully-static, DETERMINISTIC bitcoind,
using a DETERMINISTIC gcc (!!!) of your choice [1],
on any reasonable unix, on any reasonable machine,
optionally cross-compiled TO any reasonable machine. [2]
The buildroot .config given below is configured for musl!
It works.
But you can change it to glibc or uclibc if you like.
Read these instructions very carefully.
The exact placement of the files in this tarball to your subdirs is critical.!
Get buildroot-2015.XX.tar.gz from http://buildroot.uclibc.org/download.html :
$ sha512sum buildroot-2015.05.tar.gz
c42fdd39cb2bc46804a86a7d7b2605bd3cd9ddcb365c4e5a1fb147eb02b234fc31a70c8140be2f4d27cd371c84e0c6701f8cb47697dd1c18dd0e0cce784aa07a buildroot-2015.05.tar.gz
1) Check my pgp sig.
2) Check his pgp sig.
3) Put on a kettle of tea
4) Make a directory to hold everything in, e.g., /home/luser/rotor
5) Make a subdir in it, for the toolchain, e.g,, /home/luser/rotor/toolchain
6) in it, set up a stator dir, e.g.,
/home/luser/rotor/stator
and fill distfiles with tarballs, etc. as before.
7) copy buildroot-2015.05.tar.gz to the rotor base dir (from step 4)
8) tar xvfz buildroot-2015.05.tar.gz
9) copy my rotor_buildroot_dot_config to the now-untarred buildroot dir as '.config'
10) cd to the above dir
11) make
12) ...... tea time ......
.... gcc, toolchain, etc. will LOAD FROM THE NET!
.... TODO: we need to freeze all of it in time. and sign.
............................................................
13) you now have a custom toolchain (gcc, binutils.)
if you don't like musl for some reason, can change .config.
14) you are now read to build 'stator' with the new toolchain:
you will need to copy these to your ~stator~ dir:
1) openssl-004-musl-termios.patch
2) rotor.sh
3) rotor_bitcoin_only.sh
Also this is when you should apply your favourite patch set,
to get the kind of bitcoin you want.
15) Run:
A) ./rotor.sh to build the whole orchestra.
B) ./rotor_bitcoin_only.sh to build ONLY bitcoind
(given that you have already built the deps.)
16) Finish your tea...
- ----------------------------------------
$ objdump -T bitcoind
bitcoind: file format elf64-x86-64
objdump: bitcoind: not a dynamic object
DYNAMIC SYMBOL TABLE:
no symbols
- ----------------------------------------
IF YOU ARE HAVING 'LOCALE' ISSUES:
17) LC_ALL=C ./bitcoind -myip=xxx.xxx.xxx.xxx -addnode=195.211.154.159 &
*******
Attached is a proof-of-concept bitcoind (patches ONLY through classic 'stator'),
build using the above procedure.
- -------
[1] [2] edit the buildroot .config. RTFM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBCgAGBQJVtp8UAAoJELmCKKABq//HIzgH/2NXyqwnZsnzgn+In+3ZMSnY
D7KstGy3aAjxt8YawBlpsAOXh/XYDglhXig9UShSuv+7Xr1yiune3ULzQiCtmTPZ
kodeqITMTqgjU/vA7HXkC2IE1Bz0azKRSrRG9ZIV7zs2NWseywaAU2y6Gyi1gls9
QxBqcNuouqS4CX+s32/qdgv/XVBZMdLmlSGdTATkBGJikJXw5CSWuU5MxKr0j5ed
x2/u4jqoJ1J+lTzwBehgJlpNIdSM3IkfkEKwskswuHBVWG1FUTZmVi9GaQf6fzCz
6/+vo3FDge5wMQzAYkpGPPLSSL4yIXHjJTnv9QoZ3UZKSl3rc/wx7iqQoe/CpOc=
=kXP9
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rotor.tar.gz
Type: application/x-gzip
Size: 10976 bytes
Desc: not available
URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20150727/rotor_4c86b82236ebc4926a6ace8fb8310f37b948c8f1.tar.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rotor.tar.gz.sig
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20150727/rotor_b5a9f18591eff649d632065fc53ba5bc0c23d9ab.tar.gz.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitcoind.gz
Type: application/x-gzip
Size: 1822681 bytes
Desc: not available
URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20150727/bitcoind_c7843763b5d2d62f10915cd12d024649ed43e788.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitcoind.gz.sig
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20150727/bitcoind_aff34e8a08189c498f1d6158d0e6e49e12682143.gz.sig>
The conversion of 'chicken' into genesis.vpatch.
Link:
therealbitcoin.org/ml/btc-dev/2015-August/000148.html
[BTC-dev] V Genesis
Stanislav Datskovskiy stas at loper-os.org
Thu Aug 20 01:22:33 UTC 2015
[...]
Name: readme.txt
URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20150819/readme_06be35ae8d26a91f0691ad1e9a32a2f9cf5d44f7.txt>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
~~~~~~~~~~~~~~
~~ Genesis. ~~
~~~~~~~~~~~~~~
The point of this seemingly strange item is to harmonize the orchestra such that
EVERYTHING becomes a vpatch. Including the origin of the universe.
And so, this apparatus creates, from a vacuum, the universe previously seen in 'chicken' [1] for use with 'v' versioning system. [2]
The result is attached, 'genesis.patch'. But you are expected to VERIFY using the old 'chicken.'
Here is how:
1) Obtain [3]
0.5.3 [Origin Codebase] SHA256: aab1f8ea8c7f131ff69dfa3b9437ba35531018be760132dd6373f41a591f6382
... and extract it to a directory. Everything else shall be done there.
2) Obtain bitcoin-0.5.3-no-crud.sha256.manifest
sha512:29ee0f488fcc253cc80b85059ef7f248bbd9bd60931f68cc22763e6f355ec206c584bd2f864dffb8659e536e97fa74a3b55d7d77afe2f62d8b2ae0e3e58bcca0
also from [3].
3) genesis.sh:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/bin/bash
mkdir a;
mkdir -p ./b/bitcoin;
cd bitcoin-bitcoin-a8def6b;
for i in `cut -d ' ' -f 3- ../bitcoin-0.5.3-no-crud.sha256.manifest`; do
cp --parents $i ../b/bitcoin;
done
cd ..;
vdiff a b > genesis.vpatch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4) Naturally, ./genesis.sh
And of course vdiff.sh (Get it from [2]) is in your path, right?
5) Diff your genesis.vpatch with mine. (attached)
6) When satisfied, gpg (armoured, detached .sig) the genesis.vpatch.
7) Post your (6) to therealbitcoin mailing list!
8) Try to understand what we did here, and why.
From now on, any 'v' action which produces a tree, shall begin with applying genesis.vpatch to an empty space...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[1] http://therealbitcoin.org/ml/btc-dev/2014-October/000003.html
[2] http://therealbitcoin.org/ml/btc-dev/2015-August/000146.html
[3] http://thebitcoin.foundation/v0.5.3-0-gd05c03a.tar.gz
Or from your own disk! (best). Or from your WoT.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBCgAGBQJV1St8AAoJELmCKKABq//HCUEH+wcyfEG/lZnVZ/XXMxmBq7nm
LfR6AvpiM65IZmwYqIIep90VubILpi1egcHBApFDft+JNu7Aus7G1xI1b0YV/GWp
FdaEiuVNiq89R7AwUqWwk2TS7tk1GHHFBtHHTFpvIEpg8wV1GkGB0jfMFgcnXkSg
cur18zqOLvyNFgmSs0n07qlbzSJVfr6o4CAETV7mIaTNM4IlURrC/PEr9tY00GX9
AFMrikO2o3Ka2pcpZ/dvxJEPdjpnSUulHnmY8aDQ9BTNe6G/36NOfKcUHFbxEgTy
0VKOrs4bWtDB+yOz+URSjggt47lcWSd4h8nh+wSZqRC51kIvfl8BtqK05UCUHKA=
=yJaN
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: genesis.vpatch
Type: application/octet-stream
Size: 865818 bytes
Desc: not available
URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20150819/genesis_2cba721ced8108cf65ab7d045081237ecda4602a.vpatch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: genesis.vpatch.sig
Type: application/octet-stream
Size: 490 bytes
Desc: not available
URL: <http://therealbitcoin.org/ml/btc-dev/attachments/20150819/genesis_20ca5bfe1ca62d0c263f534058051b270e4012f4.vpatch.sig>