tmsr - Search: dumpblock

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.

asciilifeform: theoretically if you built with 'dumpblock', can debug this scenario by hand.

asciilifeform: simply dumps block hashes, without racking up ssd wear as dumpblock/hash/erase to do same job would

asciilifeform: the 1 thing it'd do for current, is to give easy means to determine that errybody actually has same blox. but the read-only knob already gives this ( and arguably 'dumpblock' already gave a much slower version of same )

asciilifeform: ^ and if anyone has a handy dumpblock-derived list with which to populate known_blocks , plox to sign & post, otherwise i'ma bake one laters

asciilifeform: ( what it was, was simply a btc block and tx reader, i fed an entire noad's 'dumpblock' chain into it, plus a buncha randomly bitflipped mutilations, behaved correctly )

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

TomServo: mod6: Sadly neither. I need to make time to wrap my head around dumpblock.

asciilifeform: mod6: the knob isn't strictly necessay, you can pipe dumpblock into sha512

mod6: If you wanna work on something here quick, get familiar with dumpblock and dump the last 12 blocks for us perhaps.

a111: Logged on 2017-03-03 19:03 asciilifeform: see, http://btcbase.org/patches , where 'dumpblock' is

ben_vulpes: it doesn't do too much, depends on blocks having been dumped via dumpblock.

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

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?

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: and we had this entire test where my node ate a total dumpblock of mircea_popescu's

mircea_popescu: http://104.131.72.249/patches/mod6_fix_dumpblock_params << this is rapidly becoming very sweet. mind adding the select javascript too ? :D

phf: so i added inline patch display to my patch display displayer instead http://104.131.72.249/patches/mod6_fix_dumpblock_params

mod6: I've made a patch to remove high-S, added in patch, recompiled, restarted bitcoind and then sent a tx. here's what I'm looking at from a dumpblock of that tx:

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

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?

ben_vulpes: however the build i made on 7-15 with the dumpblock patch boots from the same datadir.

kakobrekla: i dont see why save all html files beforehand if you can just dumpblock on the fly, its a stupid operations it gets done fast.

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.

assbot: Logged on 24-07-2015 01:51:42; mod6: asciilifeform: so we'd like to have dumpblock go into the release if possible -- both dump and eat need a bunch of testing and I've got some automated test scenarios working around dumpblock already. but I ran into the seg fault lastnight with too few parameters, i think i fixed it with this simple change: http://dpaste.com/2SRW78V.txt

mod6: asciilifeform: so we'd like to have dumpblock go into the release if possible -- both dump and eat need a bunch of testing and I've got some automated test scenarios working around dumpblock already. but I ran into the seg fault lastnight with too few parameters, i think i fixed it with this simple change: http://dpaste.com/2SRW78V.txt ☟︎

mod6: ok i think i fixed the dumpblock param issue, but it'll hvae to wait until tomorrow or when i have a bit more time to test

mod6: so dumping the first four blocks with `dumpblock' into each their own .bin files, then using xxd and shovling them all into one file, here's the result: http://dpaste.com/1B1H1PC.txt

ben_vulpes: the funny thing about my stator is that i have a binary called bitcoind-7-11-patched-with-dumpblock

phf: ben_vulpes: i started writing a patch that would let dumpblock accept cut's number range syntax, i.e. 1,7-100,200- but didn't think anyone would need it. i can pick it up again in a day or two, though i suspect you need it now?

ben_vulpes: ascii_modem: forgive the idiocy, i don't see any scriptage around the `dumpblock'ing

ben_vulpes: hate to interrupt, but ascii_modem did you ever post a hack for speedily dumping all blocks via a -dumpblock analog or am i misremembering?

assbot: Logged on 03-07-2015 17:50:03; phf: i was exploring block storage format, so i wrote some lisp code to read blocks out of .dat in sequence or directly from dumpblock'ed file http://paste.lisp.org/+38JG. i'm not sure where i'm going with it, so i'm leaving it here for interested parties.

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

gernika: mod6 I can dumpblock 168000, but not 168001. 168000 is available here: http://exusiae.kicks-ass.net/bsdwedge.bin. I'll share it differently if you'd rather I sign it and post it to the mailing list or anywhere else.

asciilifeform: ;;later tell danielpbarron wouldja mind dumpblock-ing a few blx at the wedgepoint ? ty

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

mod6: it should allow you to sync off of mp's blockchain w/the appropriate cmdline params and then do dumpblock/eatblock when it's finished or whatever you like.

mod6: ex: are you trying to patch v0.5.3 to get to v0.5.3.1? (You can just download the release tarball). Are you trying to patch v0.5.3.1-RELEASE with alf's patches? (must read emails to figure out the deps, OR you can just build the stator which includes all of alf's patches with exception of dumpblock & eatblock), those must be patched post extraction of the stator tarball -- of which im actually testing now.

phf: i was exploring block storage format, so i wrote some lisp code to read blocks out of .dat in sequence or directly from dumpblock'ed file http://paste.lisp.org/+38JG. i'm not sure where i'm going with it, so i'm leaving it here for interested parties. ☟︎☟︎

asciilifeform: ben_vulpes, mod6, mircea_popescu, et al: anomaly from last night ~wasn't~ replicated. eater successfully ate blocks through 217336 (shat the day before using 'dumpblock' from earlier sync with mircea_popescu's node)

ben_vulpes: asciilifeform: this whole eatblock/dumpblock/compare hashes thing really is stellar

phf: fwiw dumpblock is expensive, because walks blockchain in order. a "dumpdb" that iterates over mapBlockIndex and does ReadFromDisk/<< for each block might be a reasonably fast way to split .db into separate block files

phf: right, eatblock/dumpblock lets you construct any arbitrary correct chain, block by block, including the known blockchain, in a fully deterministic way. seem like important building blocks of proper engineering.

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

BingoBoingo: <jurov> ascii_field probably isn't aware that exactly the same thing as dumpblock output is the phoundation's bootstrap.dat << As far as I'm aware the "bootstrap.dat" never got implemented in a way that worked beyond the first 2GB of blockchain on pre-v0.8 clients

jurov: ascii_field probably isn't aware that exactly the same thing as dumpblock output is the phoundation's bootstrap.dat

ascii_field: in other nyooz, 'dumpblock' for the sums.txt.gz mircea_popescu set 0..n and subsequent 'eatblock' in brand-new stator - works ☟︎☟︎

ben_vulpes: and flip-cover for eatblock because state of running bitcoinator is mutated by its use, while the dumpblock does not mutate and so does not need a flag?

asciilifeform: 'Using 'dumpblock' and 'eatblock', it is now possible to move blockchains around via various direct channels (e.g., pigeon.)'

asciilifeform: http://log.bitcoin-assets.com/?date=30-06-2015#1181387 << my igprof patch for therealbitcoin is almost certainly b0rked by the 'dumpblock' addition. but fixing it ought to be trivial - good project for any of the less-experienced folks here ☝︎