log☇︎
123 entries in 0.466s
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.
a111: 116 results for "eatblock", http://btcbase.org/log-search?q=eatblock
asciilifeform: !#s 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.
asciilifeform: can blkcut them and then 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: if you're looking at this chart: http://www.mod6.net/eatblock-test/trb_offline_eatblock.png
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: Eatblock test upto 363K+ blocks and into blk0019.
mod6: Update: eatblock now @ 353K+ blocks, into blk0017.
mod6: eatblock is upto 235K+ blocks.
mod6: ok here's what I had when I copied it: http://www.mod6.net/eatblock-test/debug.log
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: is this kinda what you're looking for? http://www.mod6.net/eatblock-test/ProcessBlockTimeVDBWaitTime.png
a111: Logged on 2017-04-18 05:31 pete_dushenski: http://www.mod6.net/eatblock-test/charts/Memory.png << whoa
pete_dushenski: http://www.mod6.net/eatblock-test/charts/Memory.png << whoa ☟︎
mod6: mircea_popescu, asciilifeform, ben_vulpes, et. al: Eatblock test results & blog post: http://www.mod6.net/eatblock-test/
mod6: I think I just reached the end of my eatblock test...
mod6: the offline eatblock of entire chain (or at least what I had before was getting blackholed)
asciilifeform: eatblock time plot ?
mod6: update on offline-eatblock: 431K+ and into blk0041
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
trinque: davout: there is also 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
mircea_popescu: eatblock
asciilifeform: this is actually one of the reasons i insisted on eatblock and dumpblock
asciilifeform: eatblock is a specialist tool
davout: also i'm getting a "Flushing wallet.dat" after each eatblock, eats ~50ms each time
asciilifeform: hence eatblock on airgapped box.
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: eatblock -- eats it
asciilifeform: http://btcbase.org/log/2016-12-30#1593456 << iirc it took me ~3 days to sync via direct eatblock ☝︎
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'? ☝︎
asciilifeform: and letting it 'eatblock' via shell script.
asciilifeform: (it dun care via what to 'eatblock', can be rs232)
mod6: sure, i think going block -> certainly fits into the same paradigm as eatblock/dumpblock.
asciilifeform: http://therealbitcoin.org/ml/btc-dev/2015-June/000105.html << 'eatblock'
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
ascii_zimbabwe: (index regens when you 'eatblock')
asciilifeform: mircea_popescu: recall eatblock ?
asciilifeform: anyway i kinda made this node when did the eatblock experiment.
phf: trb eatblock
mircea_popescu: oh sorry he meant eatblock-the-term-of-art
ascii_butugychag: mircea_popescu: eatblock is deterministic
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
ascii_field: 'eatblock' does exactly one shot of eating a block.
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
ascii_field: (eatblock is a locking operation) ☟︎
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?
ascii_field: gernika: eatblock!
asciilifeform: one can always 'eatblock' the thing.
pete_dushenski: so eatblock handled the magick fuzz block
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.
ascii_field: ben_vulpes: eatblock returns immediately
ben_vulpes: eatblock doesn't provide for that?
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