86 entries in 0.706s
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.
mod6: If you wanna work on something here quick, get familiar with
dumpblock and dump the last 12 blocks for us perhaps.
ben_vulpes: it doesn't do too much, depends on blocks having been dumped via
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?
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
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
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.
shinohai: shouldn't this be possible to an extent with
dumpblock ?
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.
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: 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
ben_vulpes:
dumpblock, eatblock, exposure of the ancient blockchain is quiet now?
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.
☟︎☟︎ 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?