edgecase_datafeed 136 2020-02-21 This is the date at the time of creation of this datafeed article. A checkpoint article containing a hash of this datafeed article may be created on this date or at a later date. 106 8 2019-04-27 bitcoin cd3f7f4c5d2b44dd03ad0ad59109376aaabe13d81acdac1700d374086fc920c0 573429 1HtwyqFWNVDoSEVqZwjBRRAV2oEsi8aQXr 16awNgyNAoqjhVjenPGZY8QZtKQKHgzwJa
A_brief_history_of_The_Real_Bitcoin_(TRB) stjohn_piano 2020-02-21 yes 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 article Compiling_bitcoind_(trb_0.5.4)_on_Debian_7.11 edgecase 21 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: article Codebase:_TRB_0.5.4 edgecase 135 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. asset_of_another_article Compiling_bitcoind_(trb_0.5.4)_on_Debian_7.11 edgecase 21 genesis.vpatch genesis.vpatch f9fda03bd06efc260b0fde2e03a44aeda33e6a9822c38ff2cb08b719d9a8e15d Asset: The Bitcoin 0.5.3 source code. asset bitcoin-0.5.3.tar.gz bitcoin-0.5.3.tar.gz 30e3198b7a6b88fa356a5a390296220f3757373d80379b7f7432aba5ef121faa Source of the previous asset: Browse to hyperlink http://github.com/bitcoin/bitcoin/releases/tag/v0.5.3 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 hyperlink http://thebitcoin.foundation 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: hyperlink http://btcbase.org/log 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. hyperlink http://btcbase.org/log/2017-03-20#1629992 btcbase.org/log/2017-03-20#1629992 to hyperlink http://btcbase.org/log/2017-03-20#1630001 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. ) hyperlink http://btcbase.org/log/2015-12-05#1336916 btcbase.org/log/2015-12-05#1336916 to hyperlink http://btcbase.org/log/2015-12-05#1336922 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. hyperlink http://btcbase.org/log/2018-09-21#1852652 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 ) hyperlink http://btcbase.org/log/2015-12-25#1352853 btcbase.org/log/2015-12-25#1352853 to hyperlink http://btcbase.org/log/2015-12-25#1352854 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 hyperlink http://btcbase.org/log/2015-08-16#1239766 btcbase.org/log/2015-08-16#1239766 to hyperlink http://btcbase.org/log/2015-08-16#1239769 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. Emergence of the idea of the signed patch system: hyperlink http://btcbase.org/log/2014-10-22#888443 btcbase.org/log/2014-10-22#888443 to hyperlink http://btcbase.org/log/2014-10-22#888460 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. 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: hyperlink http://cascadianhacker.com/02_a-brief-history-of-the-bitcoin-foundations-activity-from-102014-through-42015 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. hyperlink http://btcbase.org/log/2014-11-09#915374 btcbase.org/log/2014-11-09#915374 to hyperlink http://btcbase.org/log/2014-11-09#915389 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 hyperlink http://btcbase.org/log/2014-10-31#905103 btcbase.org/log/2014-10-31#905103 to hyperlink http://btcbase.org/log/2014-10-31#905132 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 hyperlink http://btcbase.org/log/2014-02-13#499716 btcbase.org/log/2014-02-13#499716 to hyperlink http://btcbase.org/log/2014-02-13#499717 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. hyperlink http://btcbase.org/log/2014-02-13#499769 btcbase.org/log/2014-02-13#499769 to hyperlink http://btcbase.org/log/2014-02-13#499793 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. hyperlink http://btcbase.org/log/2014-02-13#499833 btcbase.org/log/2014-02-13#499833 to hyperlink http://btcbase.org/log/2014-02-13#499839 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 hyperlink http://btcbase.org/log/2014-12-03#944208 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. hyperlink http://btcbase.org/log/2014-10-21#885782 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 hyperlink http://btcbase.org/log/2016-05-30#1473624 btcbase.org/log/2016-05-30#1473624 to hyperlink http://btcbase.org/log/2016-05-30#1473628 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. hyperlink http://btcbase.org/log/2016-01-21#1380023 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.) hyperlink http://btcbase.org/log/2015-11-27#1332533 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 article Codebase:_TRB_0.5.4 edgecase 135 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 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: hyperlink http://therealbitcoin.org/ml 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: hyperlink http://therealbitcoin.org/ml/btc-dev/2014-October/000003.html 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: hyperlink http://therealbitcoin.org/ml/btc-dev/2015-July/000133.html 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: \ -----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: \ -------------- next part -------------- A non-text attachment was scrubbed... Name: rotor.tar.gz.sig Type: application/pgp-signature Size: 490 bytes Desc: not available URL: \ -------------- next part -------------- A non-text attachment was scrubbed... Name: bitcoind.gz Type: application/x-gzip Size: 1822681 bytes Desc: not available URL: \ -------------- next part -------------- A non-text attachment was scrubbed... Name: bitcoind.gz.sig Type: application/pgp-signature Size: 490 bytes Desc: not available URL: \ The conversion of 'chicken' into genesis.vpatch. Link: hyperlink http://therealbitcoin.org/ml/btc-dev/2015-August/000148.html 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: \ -----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: \ -------------- next part -------------- A non-text attachment was scrubbed... Name: genesis.vpatch.sig Type: application/octet-stream Size: 490 bytes Desc: not available URL: \
iQIcBAABCgAGBQJeUGJxAAoJEC8RP+HmG9MX+xMP/3zd/+oJp57Qq6sD4JP9+CGx bhGKwsMeDDPARXqta+Ps13dOqsm3FacVJ/d6dlXkiOy7tJUZa7iQbmoVosUv5+Rh 6MgrzkZJPg6eoc7A7YBFIVbz/zqbW1KDEfpJFkefWv9uyZnW1hCdsXqtFgLIyjDM 01sjZn2h5tvVY1OHDKo1nXlN/i1tOELGh7yrW/Z+lDYeKo8hX1yKOc3FLoM5qb9j xKv05Qv4GDIzVslKC0i1KzPbUP4OGcDR2zDP4KuHWUENmfLS8ZGDHni/dCZZebN1 weqyIL6evoeyCqVW0d9JXK8Q2xiEB6mGiE9+Zh3d0cjd09xfzQZyFjIJObfAyfSH arvDQ5Y4xvhoxaJxxNgczWHYxiDuBx2IAQN+JmR1DC3wlab5YBkao/P389BDJ1dO 5ljQ/7mlbxt0RCnKf4jbitmhjBtH8FMWms3UG7Q3lD5XPDmcRhezLiC1APyPoO82 FMt4BeUcCf5ze2DCg9yVJ/L5+Yqiznq6S3JRgtkaole7GJri5uFHLYtRaXaoAoYB aGpk0xCCWGwEKV1Sjd/JjkG38SLn/EZuSvxeVwi2DbXLlo82dfRIsBXPtYH0XDzw 67jAF0u0cZhCpG066s0DIfSZR6D8q2aoSzGrPEKefnVcFYZb1z1Ef+4ZynlL+92k INWxcrY5K1n4SmDy3yXG =Mzd4
iQIcBAABCgAGBQJeUGLOAAoJECL1OzZgiBhwBicP+wbwK6N4Aws05+GqCX9lkvre etuMTn6QEXTGklD4yX/9p+myVLaDdbWFkbNB18Ja5mHHHT9aEbC2jDX5HEgx57s1 6vmsXkufCcIjylHRZ1u9Ht3DoFU8aS53mOpNA40TuoKIfvGDVi9G53cLgXuv5+VZ F602s3mB43xKmloVSjmYn/GDSbXs4zbseUYFrwJLu1qVPCuRs7rtFmPve/7Du21e Si4WvOlTgOIKwNKTx0ehr4+i7f5yQylNo1ZEjXSnLo8F2gt7JKlLkXi5CxV0piS4 of+3sRaTdXPawEEvI3RSs+8kEDBspBzzh0NaxvRj9mNPX1ahnrwrJKAK3Rns6diL T7a1/vRbSnyrIJxundU4XDNtS5jQl/fzWZ+BdunqPymvmYpqB0a7mtagZwBswEfZ yov+x4vk5cFBxQhQGttBjR6ZU7RRwwwO4NBujVkbdYg53oOeMzdArFdDuOqdbrse qR6EFEfiAk4WbtWMtJumVFAr+H/sHD9LWKWLy3DjBfJjClO6rfVwRC+0cvUMI1gE NwBf0OMGYp//8QUav1iF4OVnXASB7iG7VerPqO/E2gAKQ+Xb6HdBPdQ18UNZiRLW n/OMmWKzyuhyqDWu52lept9chqWs3G9ID59V/aQWNChFtimYDJIIliRn9LrLBLbp EtBEgDksQe9ViYaY92da =4lbV