log☇︎
86 entries in 0.352s
asciilifeform: mod6: oh hm. can haz dumpblock of 450-451 plox ?
asciilifeform: *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: you can approximate the effect with dumpblock/eatblock.
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
ben_vulpes: dumpblock is more useful for realtime work in my experience
trinque: dumpblock you mean, or no?
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.
asciilifeform: mod6: it'd be a fairly trivial mod of dumpblock .
asciilifeform: dumpblock also worx
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: see, http://btcbase.org/patches , where 'dumpblock' is ☟︎
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?
davout: oic, dumpblock dumps binary?
asciilifeform: http://btcbase.org/log/2016-12-30#1593682 << prb aint got dumpblock ☝︎
mircea_popescu: prb has dumpblock ?
mod6: sure, i think going block -> certainly fits into the same paradigm as eatblock/dumpblock.
ben_vulpes: i'm leaning on dumpblock to get them in chain-order
asciilifeform: http://therealbitcoin.org/ml/btc-dev/2015-June/000104.html << dumpblock with illustration.
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
a111: 54 results for "dumpblock", http://btcbase.org/log-search?q=dumpblock
asciilifeform: $s dumpblock
scriba: Logged on 2016-09-08: [04:39:50] <ascii_zimbabwe> 'dumpblock' it.
scriba: Logged on 2016-09-08: [04:39:50] <ascii_zimbabwe> 'dumpblock' it.
ascii_zimbabwe: 'dumpblock' it.
shinohai: shouldn't this be possible to an extent with dumpblock ?
asciilifeform: dumpblock, rather
assbot: mod6_fix_dumpblock_params ... ( http://bit.ly/1QQQHOC )
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
assbot: mod6_fix_dumpblock_params ... ( http://bit.ly/1QQQHOC )
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?
asciilifeform: also it is possible to hash a blockchain using dumpblock
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.
trinque: hm yeah seems like this should be bolted to dumpblock?
ben_vulpes: (see asciilifeform's comment re upper bound of dumpblock)
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: anowait, the dumpblock rpc is right there
ben_vulpes: asciilifeform: dumpblock killed my stator when i misscalled it
ben_vulpes: that was not patched with dumpblock
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
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
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.
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
ascii_field: recall, we have 'dumpblock'
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 ☟︎☟︎
ascii_field: dumpblock is non-destructive, aha
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 ☝︎
asciilifeform: ./bitcoind dumpblock 217040 217040.bin