tmsr - Search: orphanage

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.

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)

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 )

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 )

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 )

asciilifeform: if receiving end were prb ( which last i knew, still had the 'orphanage' thing ) -- would balloon to fill ram

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'

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' ☟︎

mircea_popescu: much like whining to mommy works in the middle class "atomic family" not in the orphanage.

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.

asciilifeform: fwiw i'm still quite convinced that errything other than GET and PUT is ~= prb orphanage. ☟︎

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 )

BingoBoingo: <asciilifeform> ( this function requires potentially unbounded orphanage to eval ) << Well since they can get away with doing it now, they MUST

asciilifeform: mircea_popescu: not necessarily, orphanage may or may not have unwedged it, as it discards old orphans when new appear.

mircea_popescu: did the orphanage burner ruin trb 's chances of unwedging in this situation ?

phf: davout: you don't get consistent, uninterrupted, sequential chain of blocks. the actual distribution pattern is a mess, that "orphanage" was bandaiding

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.

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

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

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.

mircea_popescu: punkman but it's not necessarily surprising seeing the orphanage burner patch.

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

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.

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

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

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.

mircea_popescu: which is on some level funny, considering she looks like a 13yo boy escaped from a siberian orphanage, but anyway.

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."

assbot: [BTC-dev] (EXPERIMENTAL) Transaction Orphanage Amputation. ... ( http://bit.ly/1COYWpr )

punkman: asciilifeform: I don't really have a theory. are we sure that nuked orphanage can't cause more wedges?

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

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

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

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

punkman: fwiw, I've read the patches and it all seems good. I only have reservations about the 2 orphanage burning patches ☟︎

punkman: trinque: I think that's to be expected with orphanage amputations. I have those and also plenty of "ERROR: AcceptToMemoryPool() : nonstandard transaction type"

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.

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

asciilifeform: thestringpuller: shooting the tx orphanage in the head rid us of the most obvious spam vector

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

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

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

mod6: After a profile with vanilla v0.5.3.1-RELEASE, I'll further profile with the two Orphanage Patches.

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/

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

asciilifeform: the other effect of nuking the tx orphanage is zapping the obvious ddos vector of folks crapping deliberately spurious tx into a node

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.

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

mod6: Update: bitcoin-v0.5.3.1-RELEASE + patches { Orphanage Thermonuke } + { TX Orphanage Amputation } fully snyc'd: 359443 ☟︎

mod6: Update: v0.5.3.1-RELEASE + patches { Orphanage Thermonuke } + { TX Orphange Amputation } is up to block: 344679

mod6: Update: v0.5.3.1-RELEASE + patches { Orphanage Thermonuke } + { TX Orphanage Amputation } is at block: 335628

mod6: Update: full sync of v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 326594

mod6: Update: full sync of v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 314713

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.

mod6: Update: full sync of v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 280995

mod6: speaking of sync'ing tests: my v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 256863

mod6: And my v0.5.3.1-RELEASE + patche(s) { Orphanage Thermonuke } + { TX Orphanage Amputation } is up to block: 237452

mod6: <+decimation> I see what ascii means about the flat graph (memory.png on the orphanage thermonuke) << ahh

decimation: I see what ascii means about the flat graph (memory.png on the orphanage thermonuke)

mod6: asciilifeform: full sync of bitcoin-v0_5_3_1-RELEASE + { OrphanageBurner } + { TX Orphanage Amputation } underway

mod6: oh, darn. ok im compiling right now with : bitcoin-v0_5_3_1-RELEASE + { OrphanageBurner } + { TX Orphanage Amputation }

asciilifeform: and yes, even with the count-bound, the in-practice bound on the tx orphanage bytewise is ridiculous - 5GB ?

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.

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

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'

mod6: well, actually, i'd post the orphanage-thermonuke patch test data now, but it's 113 mb of raw nmon captures.

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.

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)

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.

asciilifeform: ;;later tell mod6 so orphanage-thermonuke has never oom-crashed in your tests ?

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

asciilifeform: this goes for anyone else who got oomkill with orphanage-thermonuke specifically, on a box with ad libitum ram

mod6: Todays update of v0.5.3.1+Orphanage_Thermonuke: http://dpaste.com/2V038DK.txt [ Full Sync Achieved ]

mod6: here's today's update on v0.5.3.1+Orphanage_Thermonuke: http://dpaste.com/1TX25HH.txt

mod6: asciilifeform: here's today's update from the v0.5.3.1+Orphanage+Thermonuke test: http://dpaste.com/3Q81JA6.txt

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"

mod6: Here's today's update from the v0.5.3.1+Orphanage_Nuke: http://dpaste.com/0W4PKEE.txt

mod6: I started it up few days ago just after I looked over the Orphanage_Thermonuke Patch: # ps aux | grep "bitcoind"

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

mod6: here's today's update from the v0.5.3.1+Orphanage_Thermonuke: http://dpaste.com/0MGZ7M2.txt ☟︎