Results 1 ... 214 found in all logged channels for 'orphanage'
(asciilifeform) vex: botnet money he coulda built an orphanage with
(pest) signpost[asciilifeform]: orphanage log or something
(asciilifeform) asciilifeform: (in ancient pre-trb, incoming blocks were buffered, asciilifeform abolished this, see the 'orphanage' vpatches / discussions)
(asciilifeform) asciilifeform: the problem with accepting ~anything~ other than the immediately next block is fundamental, rather than incidental
(pest) asciilifeform ambivalent re: whether a whole buffer is even needed, it uncomfortably resembles the old pre-trb trb's 'orphanage'
(asciilifeform) asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-30#1049376 << largely for noobs, will point out that trb tolerates neither tx nor block 'orphans'. they are intrinsically a denial of service vector whereby randos can eat arbitrary memory.
(asciilifeform) snsabot: Logged on 2020-08-25 07:47:14 cgra: 2) trb's chained sync stops right after the initial cycle, because "asciilifeform_orphanage_thermonuke.vpatch" got rid of "PushGetBlocks()" in the "inv" message handler: the node being behind doesn't react to the magic current block advert anymore.
(asciilifeform) cgra: 2) trb's chained sync stops right after the initial cycle, because "asciilifeform_orphanage_thermonuke.vpatch" got rid of "PushGetBlocks()" in the "inv" message handler: the node being behind doesn't react to the magic current block advert anymore.
(therealbitcoin) asciilifeform: ( orig. 0.5.3 had a data structure called 'orphanage' , which stored ~arbitrary~ incoming turds claiming to be blocks, and ate ~100% of memory )
(therealbitcoin) asciilifeform: i introduced the term in this patch .
(trilema) mircea_popescu: the hierarchy of consume-more-than-produce young females is very strictly 1. girls who found themselves a sponsor, who fucks them and pays their rent ABOVE 2. morons living in state-run orphanage. the SAME EXACT thing applies to boys too, just because you pay your own rent doesn't change the disposition in the field, doesn't make up down and down up.
(trilema) diana_coman: possibly orphanages take but that's just shifting to a different sort of "hard"
(trilema) mircea_popescu: if this were the concern, pretty sure orphanages still take undesired children.
(trilema) asciilifeform: (e.g. orphanage snip, 'seeds' snip)
(trilema) asciilifeform: i personally removed this nonsense, as 1 of the opening shots of trb story.
(trilema) asciilifeform: prb had 'orphanage' mechanism where it accepted antecedent-less inputs 'on faith'. this opens node both to memory exhaustion and algorithmic complexity attack (i.e. crafted input can prompt machine into wasting arbitrary amt of memory, + arbitrary amt of cpu cycle walking it)
(trilema) asciilifeform: girlattorney: see also earlier thrd, and past .
(trilema) asciilifeform: nao that i think about it, iirc we indeed had thread where calculated that with 10 or so % of total hash horse , could frag the net ~by orphanage size~ ( us, 0, heathens, a range of x's )
(trilema) asciilifeform: no ooms either, ever since tossed 'orphanages' etc
(trilema) asciilifeform: ( i'm not actually certain why we do this test prior to bastardism, there's 0 point running any test on a block that fails do-we-have-its-father litmus . really this is leftover logic from removal of orphanage )
(trilema) asciilifeform: the only practical defense against this is checkpointing, afaik. ( the prb folx tried to defend with 'orphanage', but with finite ram this does not actually solve the problem in the general case, simply ensures that different noades will wedge at different times )
(trilema) asciilifeform: if receiving end were prb ( which last i knew, still had the 'orphanage' thing ) -- would balloon to fill ram
(trilema) a111: Logged on 2018-09-28 15:12 asciilifeform: even if seems that 100% of 2/3-frag packets make it through in 'laboratory' conditions, still gotta remember that the frag reassembly buffer is the ~exact~ equivalent of the pre-trb 'block orphanage'
(trilema) asciilifeform: to mathematize : if the validity of a received datum can depend not only on past , but on ~future~ data, you have a 'to allcomers' ram giveaway. precisely like the 'orphanages' etc
(trilema) asciilifeform: even if seems that 100% of 2/3-frag packets make it through in 'laboratory' conditions, still gotta remember that the frag reassembly buffer is the ~exact~ equivalent of the pre-trb 'block orphanage'
(trilema) mircea_popescu: much like whining to mommy works in the middle class "atomic family" not in the orphanage.
(trilema) a111: Logged on 2018-02-02 22:30 asciilifeform: fwiw i'm still quite convinced that errything other than GET and PUT is ~= prb orphanage.
(trilema) asciilifeform: fwiw i'm still quite convinced that errything other than GET and PUT is ~= prb orphanage.
(trilema) asciilifeform: ( in particular the orphanages amputations. good chunk of bandwidth is TO THIS. DAY. wasted , by prbtrons throwing their liquishit at trbtron )
(trilema) asciilifeform: much of what the 'power rangers' did to their bitcoin, was an elaborate dance around this problem, with a dozen pseudosolutions that guzzled memory, and -- more importantly -- destroyed the integrity of their sync ( the orphanage bullshit, the headers-first bullshit , etc )
(trilema) asciilifeform: where kid is confiscated from 'unfit' untermensch and exported to pantsuit orphanages
(trilema) BingoBoingo: <asciilifeform> ( this function requires potentially unbounded orphanage to eval ) << Well since they can get away with doing it now, they MUST
(trilema) asciilifeform: ( this function requires potentially unbounded orphanage to eval )
(trilema) mircea_popescu: the stories of people stuck dealing with the empire crapolade all sound alike, much like the stories of people stuck dealing with romania's 90s orphanages, or generally with the output of any other "realist" ideology.
(trilema) asciilifeform: it is retarded and makes for 'orphanages' and O(N^2) verifications.
(trilema) asciilifeform: mircea_popescu: not necessarily, orphanage may or may not have unwedged it, as it discards old orphans when new appear.
(trilema) mircea_popescu: did the orphanage burner ruin trb 's chances of unwedging in this situation ?
(trilema) asciilifeform: does it still, for instance, have orphanages ?! because that ain't really modern trb, in any real sense
(trilema) asciilifeform: danielpbarron: O(n^2) -- with orphanages etc. - tx verification-- suxx.
(trilema) asciilifeform: or to the orphanages ?
(trilema) phf: davout: you don't get consistent, uninterrupted, sequential chain of blocks. the actual distribution pattern is a mess, that "orphanage" was bandaiding
(trilema) asciilifeform: in the case of the orphanages, they had 0 constructive purpose. they were like the 'death glands' on that one species of octopus. snip'em and you get octopus that lives for +2 yrs and no other effect.
(trilema) asciilifeform: but some -- did. the orphanage removals certainly did.
(trilema) asciilifeform: http://btcbase.org/patches/asciilifeform_orphanage_thermonuke << did i ever tell phf how much i enjoy looking at the colours ?
(trilema) pete_dushenski: mostly because that many harem girls required a shedload of eunichs to keep a lid on things, which in turn require a whole castration and selection mechanism and doctors and nurses and orphanages and on and on and on
(trilema) phf: it is perhaps useless since we don't have orphanage anymore
(trilema) trinque: I can press up to asciilifeform_tx-orphanage_amputation.vpatch
(trilema) BingoBoingo: Dropped in low-s a month or two (mebbe 3) before trb, has -minrelaytx flag, from trb orphanage slaughters and malleus were definitely implemented. Other things but would take reading to recall them.
(trilema) phf: you get disk thrash or network thrash or both. that graph i posted some time ago shows that nuking orphanage kills disk thrash, but increases network thrash. our step one has so far been removal of disk thrash, i.e. nuke orphanage, nuke mempool. step 2 presumably is nuking network thrash by relying more on trusted peers. that still doesn't solve the problem of talking to net at large
(trilema) thestringpuller: orphanage thermonuke test 2
(trilema) assbot: 130 results for 'orphanage' : http://s.b-a.link/?q=orphanage
(trilema) BingoBoingo: Because mempool size is necessarily a problem for rPI and bigger blocks would be a solution in their bizzaro land. Need more Orphanage nike
(trilema) jurov: it would be 'asciilifeform_tx-orphanage_amputation.mod6.vpatch.sig'
(trilema) ascii_butugychag: let's start with 'asciilifeform_tx-orphanage_amputation.vpatch.mod6.sig'
(trilema) mod6: iirc, to fully sync a node /before/ -verifyall or orphanage burner were even a thing, took me ~8-10 days on a medium sized AWS server. now its a bit longer with those two in play.
(trilema) mircea_popescu: punkman but it's not necessarily surprising seeing the orphanage burner patch.
(trilema) BingoBoingo: Yeah, the orphanage kill was a great thing
(trilema) BingoBoingo: The orphanage twins were great exercise
(trilema) cazalla: i get the impression charlie lee and bobby lee are brothers in the sense some white american couple bought them from an orphanage or something
(trilema) asciilifeform: ;;later tell mod6 therealbitcoin www points out, correctly, that certain patches (e.g., asciilifeform_tx-orphanage_amputation.patch) are considered experimental; but asciilifeform_maxint_locks_corrected.patch is pretty much mandatory - node will not sync without it, afaik.
(trilema) mircea_popescu: bitcoin < asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.patch < asciilifeform_orphanage_thermonuke_2d219fdd1a0da960be38797566e9c0820df11ce6.patch < asciilifeform_tx-orphanage_amputation_6ed529e594301a791fb2f8becbe344dd2de9c45f.patch < asciilifeform_zap_hardcoded_seeds_a367b89765d0b82ce2c7f8043f52006399a1e0b8.patch < asciilifeform_zap_showmyip_crud_ebf527ba3b180b1952c4c8b5af990c1fd61e04da.patc
(trilema) BingoBoingo: <asciilifeform> this, too, is fit subject for a patch; << I imagine orphanage stomping patches will be joined with "Fuck off out of my kitchen" set
(trilema) asciilifeform: THIS is why, e.g., orphanage limits did nothing
(trilema) BingoBoingo: At least I killed the orphanages earlier this week
(trilema) BingoBoingo: So transaction orphanage not as clean to cut out of 0.7.2 but done. Bitcoin running. Now to see if it catches up.
(trilema) mircea_popescu: which is on some level funny, considering she looks like a 13yo boy escaped from a siberian orphanage, but anyway.
(trilema) mircea_popescu: "After Carlos, a 12-year-old whose father has died in the Spanish Civil War, arrives at an ominous boy's orphanage he discovers the school is haunted and has many dark secrets that he must uncover."
(trilema) assbot: [BTC-dev] (EXPERIMENTAL) Transaction Orphanage Amputation. ... ( http://bit.ly/1COYWpr )
(trilema) assbot: [BTC-dev] (EXPERIMENTAL) Full Orphanage Thermonuke. ... ( http://bit.ly/1COYYh7 )
(trilema) punkman: asciilifeform: I don't really have a theory. are we sure that nuked orphanage can't cause more wedges?
(trilema) phf: asciilifeform: it's not a permanent stuck, but a slowdown. i haven't sent out that orphanage graph that i posted some time ago, because i'm still kicking shit around, but the beahior that you can see from it, is that blocks are sent out as multiple subchains. when a subchain arrives that's missing a parent subchain, it gets rejected many times over and over, until parent subchain is filled in. i think the behavior can be improved by
(trilema) phf: re: orphanage, i'm still investigating, but there's no reason why we can't have a better initial sync block handoff strategy, that doesn't get stock, because some parent in an orphanage subchain failed to get sent out
(trilema) asciilifeform: decimation: re: the orphanages, if you have them at all, what you're doing is 'i'll store this piece of shit on your say-so, and MAYBE it will be shown to be a valid block (rx) later'
(trilema) asciilifeform: there is a basic principle which applies equally to the 'orphanage' discussions and to today's ddos thread: NEVER give derps something valuable just for showing up
(trilema) assbot: Logged on 19-07-2015 11:37:45; punkman: fwiw, I've read the patches and it all seems good. I only have reservations about the 2 orphanage burning patches
(trilema) punkman: fwiw, I've read the patches and it all seems good. I only have reservations about the 2 orphanage burning patches
(trilema) punkman: trinque: I think that's to be expected with orphanage amputations. I have those and also plenty of "ERROR: AcceptToMemoryPool() : nonstandard transaction type"
(trilema) mod6: <+punkman> ascii_field, does this sequence look right? >> 0.5.3.1-release + orphanage nuke + tx-orphanage + dnsseed_snipsnip + zap_hardcoded_seeds + zap_showmyip + dns thermonuke + irc nuke << looks right to me.
(trilema) punkman: ascii_field, does this sequence look right? >> 0.5.3.1-release + orphanage nuke + tx-orphanage + dnsseed_snipsnip + zap_hardcoded_seeds + zap_showmyip + dns thermonuke + irc nuke
(trilema) asciilifeform: thestringpuller: shooting the tx orphanage in the head rid us of the most obvious spam vector
(trilema) mod6: If we add in (officially the following): { Orphanage Thermonuke, TX Orphanage Amputation, { All DNS Thermonyukyooar Patches } }, I'd say that'd be a new milestone. And I'd propose to call it 0.5.3.2
(trilema) mod6: <+ascii_field> mod6: how are those test rigs doing ? < << If you mean the bitcoin-v0.5.3.1-RELEASE + patch(s) { Orphanage Thermonuke + TX Orphanage Amputation }, they were performed on AWS deb6 instance and have since been shutdown after full sync & performance tests completed. Main reason being to dig into compiling v0.5.3.1 + gentoo sanity patches with uclibc on Gentoo on AWS Gentoo instance. I try to only run one instance at a time to keep mo
(trilema) mircea_popescu: they're in "we thank the party for its great idea to make an orphanage in our ex country house - we would have done the same if we were as smart as it" mode
(trilema) mod6: After a profile with vanilla v0.5.3.1-RELEASE, I'll further profile with the two Orphanage Patches.
(trilema) assbot: Index of /test/perf/v0_5_3_1-RELEASE-Plus-OrphanageThermonuke-And-TXOrphanageAmputation/20150604 ... ( http://bit.ly/1RTyYnO )
(trilema) mod6: Not of this moment, ... there was a completion of a full sync completed with asciilifeform's OrphanageThermonuke & TX Orphanage Amputation patches applied to v0.5.3.1-RELEASE. Nmon charts can be found here: http://thebitcoin.foundation/test/perf/v0_5_3_1-RELEASE-Plus-OrphanageThermonuke-And-TXOrphanageAmputation/20150604/
(trilema) asciilifeform: as far as i'm concerned, nuking the tx orphanage cuts away some of the remaining 'promise' crud from the protocol, leaving the cold metal for which i for one love it
(trilema) asciilifeform: the other effect of nuking the tx orphanage is zapping the obvious ddos vector of folks crapping deliberately spurious tx into a node
(trilema) mod6: <+asciilifeform> mircea_popescu: and must nitpick, but it isn't the current therealbitcoin yet. not until patches are ratified. << we'll get there. I'd like to have a discussion at some point about the possible negitive effects of at least the TX Orphanage Amputation patch.
(trilema) mod6: yeah, previous test with only OrphanageThermonuke did have at least one spot where a "major pagefault" was detected: http://thebitcoin.foundation/test/perf/v0_5_3_1-RELEASE-Plus-OrphanageThermonuke/20150512/Page_Faults.png
(trilema) mod6: memory usage graph looks very similar to the previous run with the OrphanageThermonuke graph. That's expected, but just sayin'. Lookin good.
(trilema) assbot: Index of /test/perf/v0_5_3_1-RELEASE-Plus-OrphanageThermonuke-And-TXOrphanageAmputation/20150604 ... ( http://bit.ly/1EYMJbN )
(trilema) assbot: Logged on 04-06-2015 23:30:17; mod6: Update: bitcoin-v0.5.3.1-RELEASE + patches { Orphanage Thermonuke } + { TX Orphanage Amputation } fully snyc'd: 359443
(trilema) mod6: Update: bitcoin-v0.5.3.1-RELEASE + patches { Orphanage Thermonuke } + { TX Orphanage Amputation } fully snyc'd: 359443
(trilema) mod6: Update: v0.5.3.1-RELEASE + patches { Orphanage Thermonuke } + { TX Orphange Amputation } is up to block: 344679
(trilema) mod6: Update: v0.5.3.1-RELEASE + patches { Orphanage Thermonuke } + { TX Orphanage Amputation } is at block: 335628
(trilema) mod6: Update: full sync of v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 326594
(trilema) mod6: Update: full sync of v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 314713
(trilema) asciilifeform: mod6: i would comment that technically the block-bastardage and tx-orphanage nukes are semantically independent. but the latter was derived from a main.cpp patched with the former.
(trilema) mod6: Update: full sync of v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 280995
(trilema) mod6: speaking of sync'ing tests: my v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 256863
(trilema) mod6: And my v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 237452
(trilema) mod6: <+decimation> I see what ascii means about the flat graph (memory.png on the orphanage thermonuke) << ahh
(trilema) decimation: I see what ascii means about the flat graph (memory.png on the orphanage thermonuke)
(trilema) mod6: asciilifeform: full sync of bitcoin-v0_5_3_1-RELEASE + { OrphanageBurner } + { TX Orphanage Amputation } underway
(trilema) asciilifeform: ^ both orphanage-destroyers applied for this example run
(trilema) mod6: oh, darn. ok im compiling right now with : bitcoin-v0_5_3_1-RELEASE + { OrphanageBurner } + { TX Orphanage Amputation }
(trilema) asciilifeform: and yes, even with the count-bound, the in-practice bound on the tx orphanage bytewise is ridiculous - 5GB ?
(trilema) asciilifeform: ben_vulpes, mod6, mircea_popescu, et al: incidentally, even though 'transaction orphanage amputator' may not be a magical pill against oom-on-pogo (my preliminary investigation suggests that it is -not-) it still rips out the idiotic ddos vector that every unbounded cache of anything whatsoever is.
(trilema) mod6: I can't remember if we discussed that or not, outside of the context of your OrphanageBurner
(trilema) ben_vulpes: asciilifeform: 0.5.3 (virginal, aside from db lock patch), 0.5.3.1-RELEASE and 0.5.3.1-RELEASE + orphanage thermonuke
(trilema) mod6: And for reference, here's where you can view the performance test charts that were with the OrphanageThermonuke patched in: http://thebitcoin.foundation/OrphanageThermonukeCharts/
(trilema) ben_vulpes: Jautenim: not a great deal, i think mod6 ran one in less than 200MB of RAM recently, but that was with asciilifeform's 'orphanage thermonuke'
(trilema) mod6: ok, it's in that same directory: 'nmon_bitcoin-v0_5_3_1-RELEASE_plus_OrphanageThermonukePatch.txt'
(trilema) mod6: yup, will do. the charts are actully posted from the first test already (http://thebitcoin.foundation/OrphanageThermonukeCharts/), I'll certainly post the results/charts from the v0.5.3.1-RELEASE when it's complete as well.
(trilema) mod6: well, actually, i'd post the orphanage-thermonuke patch test data now, but it's 113 mb of raw nmon captures.
(trilema) mod6: Now, currently, I'm running a very similar test with v0.5.3.1-RELEASE (as a baseline) without your OrphanageThermonuke patch included... it did oomkill once, yesterday.
(trilema) mod6: so yes, the first performance test was me running v0.5.3.1-RELEASE with Orphanage_Thermonuke patched in. Performance test conducted with `vmstat 1` & `nmon -f s3 -c1000000`. During this test the entire sync process completed without any oomkill.
(trilema) mod6: now, it'll be interesting to see the numbers i.e. network usage (among other utilization metrics) between full sync of v0.5.3.1-RELEASE+{Orphanage_Thermonuke} & v0.5.3.1-RELEASE (currently running -- which also, as i was saying lastnight, already oom killed once)
(trilema) mod6: <+asciilifeform> ;;later tell mod6 so orphanage-thermonuke has never oom-crashed in your tests ? << nope! it was pretty exciting to see it get all the way through full sync without oomkill.
(trilema) asciilifeform: (not to be confused with much earlier orphanage burner patch)
(trilema) asciilifeform: danielpbarron: thread concerned 0.5.3.1 with orphanage-thermonuke patch.
(trilema) asciilifeform: ;;later tell mod6 so orphanage-thermonuke has never oom-crashed in your tests ?
(trilema) mod6: <+asciilifeform> mod6: please post any data you may have collected at the moment of the oomkill << so just to reiterate here, the current perf test I'm running is with the v0.5.3.1-RELEASE which oomkill'd (as it's known to do). I'll post the nmon charts, log, and vmstat log. no core file was created. However, as a reminder, the previous perf test that I ran with v0.5.3.1-RELEASE+{asciilifeform_orphanage_thermonuke.patch}(http://thebitcoin.foun
(trilema) asciilifeform: this goes for anyone else who got oomkill with orphanage-thermonuke specifically, on a box with ad libitum ram
(trilema) mod6: yeah, this is the size of the full bc sync (v0.5.3.1+OrphanageThermonuke)
(trilema) mod6: anyway, I was considering running another full-sync without the OrphanageThermonuke patch -- just a v0.5.3.1-RELEASE baseline.
(trilema) assbot: Index of /OrphanageThermonukeCharts ... ( http://bit.ly/1bNimOf )
(trilema) mod6: nmon charts from the entire v0.5.3.1+OrphanageThermonuke sync/test: http://thebitcoin.foundation/OrphanageThermonukeCharts/
(trilema) mod6: Todays update of v0.5.3.1+Orphanage_Thermonuke: http://dpaste.com/2V038DK.txt [ Full Sync Achieved ]
(trilema) mod6: here's today's update on v0.5.3.1+Orphanage_Thermonuke: http://dpaste.com/1TX25HH.txt
(trilema) mod6: asciilifeform: here's today's update from the v0.5.3.1+Orphanage+Thermonuke test: http://dpaste.com/3Q81JA6.txt
(trilema) mod6: root@ip-M-O-D-6:/mnt/btc-dev/sandbox-20150504-orphanage-nuke/bitcoin-v0_5_3_1/bitcoin/src# dmesg | head -10 | grep "Debian"
(trilema) mod6: Here's today's update from the v0.5.3.1+Orphanage_Nuke: http://dpaste.com/0W4PKEE.txt
(trilema) mod6: I started it up few days ago just after I looked over the Orphanage_Thermonuke Patch: # ps aux | grep "bitcoind"
(trilema) assbot: Logged on 07-05-2015 23:40:11; mod6: here's today's update from the v0.5.3.1+Orphanage_Thermonuke: http://dpaste.com/0MGZ7M2.txt
(trilema) mod6: here's today's update from the v0.5.3.1+Orphanage_Thermonuke: http://dpaste.com/0MGZ7M2.txt
(trilema) assbot: Logged on 07-05-2015 15:19:45; mod6: asciilifeform: just to be clear, all of your vagrind runs against bitcoind are: v0.5.3.1+Orphanage_ThermoNuke ? Or just plain v0.5.3.1 ?
(trilema) mod6: asciilifeform: just to be clear, all of your vagrind runs against bitcoind are: v0.5.3.1+Orphanage_ThermoNuke ? Or just plain v0.5.3.1 ?
(trilema) mod6: <+asciilifeform> [BTC-dev] Full Orphanage Thermonuke DHAT Output. << nice work! thanks :]
(trilema) asciilifeform: [BTC-dev] Full Orphanage Thermonuke DHAT Output.
(trilema) mod6: <+asciilifeform> [BTC-dev] Full Orphanage Thermonuke Massif Output (without 'pages as heap' flag) << thanks asciilifeform!!
(trilema) asciilifeform: [BTC-dev] Full Orphanage Thermonuke Massif Output (without 'pages as heap' flag)
(trilema) mod6: asciilifeform: here's an update as to where my test of v0.5.3.1+Orphanage_Thermonuke is at: http://dpaste.com/3J5K2JB.txt
(trilema) ascii_field: mircea_popescu: take a few min. to read the patch, if you have not. the behaviour should be logically equivalent to virginal 0.5.3 with an orphanage of zero
(trilema) ascii_field: mod6: aha i asked because you specified 'orphanage burner' - which was the 1st try of this
(trilema) assbot: Logged on 06-05-2015 15:16:19; mod6: I can't really check from here, but later tonight will give some updates as to how my v0.5.3.1+OrphanageBurner build is running. last I saw, it was using quite a bit of available ram. was >200`000 blocks, and still running, but that was lastnight.
(trilema) mircea_popescu: http://log.bitcoin-assets.com/?date=06-05-2015#1122508 << yes. because for all the pretense of "development" and "progress" and "new versions" and of course "blockchain technologees" of the #bitcoin-dev muppet orphanage, THEY.HAVE.NOT.ACTUALLY.DONE.ANYTHING.
(trilema) mod6: I can't really check from here, but later tonight will give some updates as to how my v0.5.3.1+OrphanageBurner build is running. last I saw, it was using quite a bit of available ram. was >200`000 blocks, and still running, but that was lastnight.
(trilema) mod6: <+asciilifeform> [BTC-dev] Full Orphanage Thermonuke Massif Output (Theoretically, covers entire address space of process) << great work, asciilifeform. thanks for putting that together :]
(trilema) asciilifeform: (the 'orphanage burner' one)
(trilema) davout: not sure i get "the thing walks the orphanage and finds the start of the chain"
(trilema) asciilifeform: we don't have an orphanage any more
(trilema) asciilifeform: 2) after this, when bastard block comes in, the thing walks the orphanage and finds the start of the chain, and asks for its antecedents.
(trilema) asciilifeform: [BTC-dev] Full Orphanage Thermonuke Massif Output (Theoretically, covers entire address space of process)
(trilema) asciilifeform: [BTC-dev] Full Orphanage Thermonuke Valgrind Output.
(trilema) davout: asciilifeform: really curious to see how the orphanage thermonuke patch will work in the field
(trilema) assbot: Logged on 05-05-2015 01:32:31; mod6: ok bitcoin-v0_5_3_1 + Orphanage Nuke is running with `nmon -f -s3` & `vmstat 1`, so we should have some good metrics when complete.
(trilema) mod6: I should re-iterate that I'm still waiting on a pogo to come to me...so this v0.5.3.1+OrphanageNuke test is running on AWS deb6 (amd64)
(trilema) mod6: 9d7cab14db48000ed91d12301f19341ce55e86fe919922f8a4f80f49625b881b296deb037d35ef899996e097b4f1c0ab5a035c2ced04758b9838f3924ce4ed78 asciilifeform_orphanage_thermonuke.patch
(trilema) mod6: # sha512sum asciilifeform_orphanage_thermonuke.patch
(trilema) mod6: ok bitcoin-v0_5_3_1 + Orphanage Nuke is running with `nmon -f -s3` & `vmstat 1`, so we should have some good metrics when complete.
(trilema) asciilifeform: sha512(asciilifeform_orphanage_thermonuke.patch) == 9d7cab14db48000ed91d12301f19341ce55e86fe919922f8a4f80f49625b881b296deb037d35ef899996e097b4f1c0ab5a035c2ced04758b9838f3924ce4ed78
(trilema) asciilifeform started valgrindized run of thermonuked-orphanage tester
(trilema) mod6: -rw-r--r-- 1 root root 4007 May 5 00:19 asciilifeform_orphanage_thermonuke.patch
(trilema) mod6: <+ascii_field> [BTC-dev] (EXPERIMENTAL) Full Orphanage Thermonuke. << Just saw this on the train & read patch. Great work!
(trilema) ascii_field: [BTC-dev] (EXPERIMENTAL) Full Orphanage Thermonuke.
(trilema) mircea_popescu: "a bitcoind (pseudo-static, portatronic, orphanage-burner patch with max-bastard constant value of 5 running on pogo, heathen linux.)" << i lelled.
(trilema) asciilifeform: [BTC-dev] Process mem. stats from heathen pogo running ineffectual orphanage burner (max==5)
(trilema) asciilifeform: its a standard skull'n'crossbone orphanage burner with max cap set to 25
(trilema) BingoBoingo: asciilifeform: The orphanage burning version, see if stable.
(trilema) thestringpuller: you told me not to patch in orphanage burner yet.
(trilema) asciilifeform: thestringpuller: the idiot crashy one ('classic', with memleak) or the one with questionable patch ('orphanage burner') ?
(trilema) asciilifeform: classical or orphanage-burning ?
(trilema) asciilifeform: dove in once or twice to fish out the orphanage burn thing
(trilema) the_scourge: !s "orphanage burner"
(trilema) mod6: ah, my mistake. ascii numbered the "Orphanage Burner" as v0.5.3.2
(trilema) punkman: danielpbarron: this one? "bitcoin-armv5-bastard includes the 'orphanage burner'"
(trilema) punkman: danielpbarron: with orphanage burner?
(trilema) asciilifeform: mod6, danielpbarron: in case this wasn't clear, my armv5 build still has the checkpoints (other than orphanage burner, only the basic patches are in)
(trilema) asciilifeform: mircea_popescu, davout: look through orphanage for % of blocks more than 10% off the difficulty << interesting idea
(trilema) mircea_popescu: asciilifeform if you feel like testing a 3rd approach, can you look through orphanage for % of blocks more than 10% off the difficulty ?
(trilema) mircea_popescu: <asciilifeform> the logical thing to do, for it, would be to jettison the entire orphanage if approaching the hard limit << this may be a good idea, if actually something's needed.
(trilema) asciilifeform: not in the experimental 'orphanage burner' build
(trilema) asciilifeform: the logical thing to do, for it, would be to jettison the entire orphanage if approaching the hard limit
(trilema) asciilifeform: inference, with only a small leap, is that orphanage-burner testatron would have oomkilled precisely one time, had it ran under 128M constraint
(trilema) asciilifeform: based on the footprint, the orphanage burner functions
(trilema) asciilifeform: bitcoind limited to 'orphanage' of 50 blocks (running on ordinary pc) never syncs
(trilema) asciilifeform: once grasp this, the only thing left is instrument for maximizing - at the cost of burned orphanages of any and all kinds, dead puppies, kittens - abilities of individual man.
(trilema) asciilifeform: naturally intentional. folks like huxley, etc. who imagined that the totalitarian kingdoms of the future would farm children in mass orphanages got it all wrong. the 'children of the state' are instead grown - like described above.
(trilema) mircea_popescu: wasn't he like rescued from a romanian orphanage by some french ppls ?
(trilema) wao-ender: well, I've been already helping in some orphanages
(trilema) mircea_popescu: who apparently grew up in a romanian orphanage (?!)
(trilema) mircea_popescu: Apocalyptic: "mark karpeles was raised in a romanian orphanage" << wait, WHAT ?!
(trilema) jurov: o, he's expert on romanian orphanages?
(trilema) Apocalyptic: "mark karpeles was raised in a romanian orphanage" // mircea may have some insights on that
(trilema) Vexual: its sad that one can' give money to an orphanage in cambodia without a thought
(trilema) jcpham: i steal power from the orphanage
Download hourly DB snapshot | Get Source Code