tmsr - Search: eatblock

dorion: after restarting with -caneat, bitcoind eatblock 588012.blk returns: error: {"code": -2, "message":"Safe mode: WARNING: Displayed transactions may not be correct! You may need to upgrade, or other node may need to upgrade."

asciilifeform: ( often -- 0, people tend to stand'em up via eatblock )

asciilifeform: mod6: re backups -- if one absolutely must make a hand-cranked copy of a node, the correct method is 'dumpblock' (on donor end) and 'eatblock' (on recipient) , dun require taking down either.

mp_en_viaje: girlattorney, you can just use eatblock, have it synced from known-good chain in a day or so

mod6: my personal node corrupted again. I'll be pulling it off the list of nodes until it's rebuilt... takes about 10 days with eatblock.

asciilifeform: you can approximate the effect with dumpblock/eatblock.

mod6: i think i'm just gonna cutblock all the blk*.dat files, and eatblock 'em.

mod6: for instance, i have a R610 running with ssd, and when doing eatblock (sucking in all the blocks cut up via cutblk), I can process like 15k-20k blocks per day. more importantly, the IO timings are WAAAAAY lower.

asciilifeform: just like how, e.g., asciilifeform_and_now_we_have_eatblock coalesces mod6_fix_dumpblock_params and asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip

asciilifeform: will even observe, that it is possible to have a bitcoin net with only sneakernet connectivity, with cmdline eatblock-ing nodes.

asciilifeform: ( granted i could've filled it up with eatblock in <2days. but it's been some years since i synced 'from wild' and thought 'why not test..' )

mod6: i basically did a recent full sync with nothing but feeding into eatblock, from cut blk files, took ~6 days iirc.

asciilifeform: mircea_popescu: if the build has eatblock, there's not really any setup needed, just needs the 'can eat' flag on warmup

mod6: however, i might try a hand at keeping all but the most recent blk###.dat files, cutting them up with blkcut, then feeding them back in with eatblock.

a111: Logged on 2017-08-11 00:18 mircea_popescu: http://btcbase.org/log/2017-08-10#1696875 << it is conceivable you can reuse prb blockchains, if you care. not that there's anything wrong with rechecking the chain if oyu're in no hurry. expect a coupla months tho. and i suppose look into eatblock etc while at it.

mircea_popescu: http://btcbase.org/log/2017-08-10#1696875 << it is conceivable you can reuse prb blockchains, if you care. not that there's anything wrong with rechecking the chain if oyu're in no hurry. expect a coupla months tho. and i suppose look into eatblock etc while at it. ☝︎☟︎

asciilifeform: eatblock doesn't replicate the unknown stream of wild sewage that thing ate.

mod6: Wasn't a total loss this month being able to do some FG testing and eatblock testing.

mod6: It wouldn't take much more effort to add the AcceptBlock values into the trb_offline_eatblock.png if that's wanted.

mod6: Ladies and Gentlemen of The Most Serene Republic: My Second Offline Eatblock Sync Test is complete (with DB Read Wait Stats): http://www.mod6.net/eatblock-test/

mod6: my re-run of eatblock is complete... will re-post stats etc here in a bit

mod6: shinohai: sure will do. it's just the eatblock test. once it's complete, i'll re-run all of the charts & metrics

mod6: In other news, my eatblock re-test is at 433K+ & into blk0042; not much more to go there...

mod6: also, eatblock test is no around 411K bocks and into blk0034... so should be done in a day or two.

mod6: alright, mircea_popescu & asciilifeform ; full offline eatblock test is running again

mod6: i'm up for a full re-eatblock. just want to make sure I'm not missing anything this time :]

mircea_popescu: nevermind the bunch of these, i want the whole eatblock'd blockchain.

mircea_popescu: asciilifeform possibly time to re-do this whole eatblock instrumentation with a per-line timing profiler.

mod6: mircea_popescu, asciilifeform, ben_vulpes, et. al: Eatblock test results & blog post: http://www.mod6.net/eatblock-test/

mod6: the offline eatblock of entire chain (or at least what I had before was getting blackholed)

shinohai imagines eatblock pausing .... "Please insert disk 30 ...."

asciilifeform: tested, btw, by taking a multitude of blocks (from eatblock), parsing'em in, then back out, and diff.

asciilifeform: and trinque has it : i've put up nodes that communicate outside the house ~only~ via eatblock

asciilifeform: ^ if anyone recalls the 'eatblock' thread -- i found that my blkxxxx.dat differed, in a handful of places, from mircea_popescu's, and yet again from every other trb node's.

asciilifeform: i suppose one way to rebuild the index using existing mainline trb would be to nuke the .bitcoin dir entirely, and refeed the node via 'eatblock'.

asciilifeform: mircea_popescu: might be interesting to extend my eatblock experiment to modern height

asciilifeform: this is actually one of the reasons i insisted on eatblock and dumpblock

davout: also i'm getting a "Flushing wallet.dat" after each eatblock, eats ~50ms each time

davout: i'm still curious what would make this kind of setup where i script "prb dumpblock | hex2bin | trb eatblock" much faster than syncing from network if the bottleneck is indeed the block verification?

asciilifeform: all of my nodes, fwiw, descend from the eatblock experiment

asciilifeform: ben_vulpes: you can replicate same effect using 'eatblock'

ben_vulpes: http://btcbase.org/log/2016-12-19#1585810 << asciilifeform didn't you do a whole run of eatblock? 'deterministic sync'? ☝︎

mod6: sure, i think going block -> certainly fits into the same paradigm as eatblock/dumpblock.

a111: Logged on 2015-06-30 19:12 ascii_field: in other nyooz, 'dumpblock' for the sums.txt.gz mircea_popescu set 0..n and subsequent 'eatblock' in brand-new stator - works

asciilifeform: anyway i kinda made this node when did the eatblock experiment.

phf: it seems like a cool profiling target, how long it takes to eatblock entire chain across different ssds on some test hardware

phf: ascii_field: saw it of course. i wanted to cut out the whole blkcut -> block -> eatblock roundtrip, plus i want to see how fast it can eat at saturation. which is surprisingly not fast at all

assbot: Logged on 24-09-2015 22:12:13; ascii_field: (eatblock is a locking operation)

phf: i don't have intuition for complete eatblock time, but 3 weeks does sound like surprisingly long time, even with all the checks enabled

gernika: Right. So I made it to 368xxx and got stuck on the large block syncing from one of your nodes over the network. I then (probably) had a bad shutdown and corrupted the db. I then used eatblock to sync from what I had on disk up to that point.

ascii_field: the correct way to use eatblock is with dumpblock coming from an already synced LOCAL node.

ascii_field: as in, where did the blocks fed to 'eatblock' come from ?

assbot: Logged on 24-09-2015 19:30:42; gernika: Friend is claiming he can do a full sync in 6-8 hours using the phoundation client (non-ssd), while it took my OpenBSD box 3 weeks using eatblock. Not sure what I'm doing wrong.

ascii_field: http://log.bitcoin-assets.com/?date=24-09-2015#1284966 << headers-only sync is not sync. the phoundation client is not a bitcoin implementation and hasn't been for ages. on the other hand, a box that takes 3 weeks to sync FROM EATBLOCK ON DISK has something seriously wrong with it. ☝︎

gernika: Friend is claiming he can do a full sync in 6-8 hours using the phoundation client (non-ssd), while it took my OpenBSD box 3 weeks using eatblock. Not sure what I'm doing wrong. ☟︎

mod6: you know... actually, i think im still on to something here... i just didn't mean 'asciilifeform_and_now_we_have_eatblock.vpatch', ... but im going back over all of this again. the paste above & stuff was brain fart.

mod6: ;;later tell asciilifeform I've been testing/looking at 'v' quite a bit. Re-implementing on my own for better/full understanding (since I'm not a python guy). I'm confused about why here 'asciilifeform_and_now_we_have_eatblock.vpatch' is not listed as a descendant of mod6_fix_dumpblock_params.vpatch : http://dpaste.com/08X2Q6P.txt

gernika: ascii_field so do something like bitcoind dumpblock i | bitcoind -datadir=somewhereelse eatblock i?

mod6: Have a bunch of automated tests (cucumber) that now builds the new test bundle, verify, check binary, test -connect, dumpblock, eatblock. ima post a log here in just a bit.

mod6: ascii only has 3 patches post blockdump (eatblock, rm testnet, verifyall)

phf: ascii_field: i don't think that's the case. i changed block processing to return false when the block is bastard, and eatblock started returning false for those.

decimation: I'm syncing stator+eatblock+dumpblock on some node, just cleared 200k blocks

ben_vulpes: dumpblock, eatblock, exposure of the ancient blockchain is quiet now?

asciilifeform: if you want 'dumpblock' and 'eatblock', those are not included in stator

asciilifeform: trinque: you're only ~really~ replaying history if you 'eatblock' from mircea_popescu's raw blkxxxxen