24200+ entries in 0.064s
mod6: 1805961 InvalidChainFound: invalid block=0000000000000a40136b height=168001 work=243841112905690411140
mod6: or internal log number: 1805961
mod6: mircea_popescu: mod6 persuing your error log : it would seem to me that for some reason your peers keep pumping you with blocks height=168002 and over, whereas yotu never get height=168001. << see line 40 of this paste:
http://pastebin.com/iweEQCpu mod6: << completely misunderstanding that. << ok gotcha.
mod6: no worries, gotta run though, will test direct against a 50300 later tonight.
mod6: for the record, its: v0.5.3 + patches { 1, rm_rf_upnp, 2, 3, 4 & 6 }
mod6: im gonna leave this sync run overnight.
mod6: i must have done something wrong. but anyway, I'll give it a shot tomorrow.
mod6: PASS: 0; FAIL 313500.
mod6: yeah, using 2nd version. thanks!
mod6: second one was active 1.34.180.245
mod6: first one is muerte
mod6: asciilifeform: oh the sipa txt is super old 'eh
mod6: as opposed to these:
mod6: ok well asciilifeform, I think I'll try the first one in your list since it's 100% sync'd
mod6: aight. time to test this out.
mod6: good-ole ATC taught us that :]
mod6: is there an easy way to feed bitcoind a list of nodes that we want to use for seed?
mod6: anyway, guess it doesnt matter
mod6: ok. interesting. wonder if that relates to this:
mod6: (that starts after this line: (Warning - long. You can safely skip to the end.))
mod6: asciilifeform: so is the thought to connect to nodes that are fully-sync'd? and the issue is that we're connecting, by chance to nodes that do not have full sync?
mod6 digs through debug.log
mod6: thanks for the links asciilifeform
mod6: it seems like the growing thought seems to be to get a list of 50300 active nodes and seed those directly into the R.I., or am I misunderstanding that??
mod6: hmm. i remember this bit of code in main
mod6: yeah, two seperate runs
mod6: I could try it again.
mod6: oh yeah, i stopped it for now. i'll mess with it later tonight.
mod6: still some 32400 nodes out there
mod6: i guess maybe one other time it ran a long time like this until it ran out of memory and blew its brains out
mod6: i'll put together some log snippits when it does
mod6: well, sooner or later this turd is gonna fail
mod6: still no error?! wth
mod6: this is strange, last like 5-6 times i got wedged at 168,000 it errored out pretty quickly (like the snippit in the matrix doc), but now, taking a good while...
mod6: yeah. really weird.
mod6: basically wedged at 168,000: just waiting for it to error out.
mod6: well, but also, i like i was saying, it's inconsistant. because TomServo has checkpoints included and he got through the gauntlet, and I did as well lastweek before the version patch.
mod6: 130k...will stop @ 150 and backup .bitcoin/*
mod6: yeah, i wanna re-iterate here, all of the wedging issues ben and I had were /with/ checkpoints included. if we apply the rm_checkpoints patch, no longer a problem.
mod6: we must get this patched RI repeatable (and it was before a few days ago) before we can cut release.
mod6: but danielpbarron: good to know tho. thx.
mod6: yeah, totally different beast
mod6: is it the portotronic?
mod6: and we were using same build scripts .. and me building by hand even once.
mod6: i.e. TomServo having total success, and ben & I having weding problems.
mod6: hmm, but yeah, really /was/ weird that it was inconsistant.
mod6: yeah, well, still is the plan i should say :)
mod6: or, at least, we'll start with that.
mod6: yeah. that's the new plan. all magic numbers in a config file.
mod6: i've got mutiple good v0.5.3 chains saved, but ... just was regression testing to ensure full sync with the v0.5.3.1 patch before release sign & cut
mod6: I wasn't fully sure that it wasn't our build script or something wonky screwing it up... but a hand-build showed the same result.
mod6: We wanted to collect as much data as possible before we let other know in #b-a. Hence the delay until now.
mod6: but then i applied the rm_checkpoints patch and then it continued on np.
mod6: this was on Saturday night.
mod6: one time i got wedged at like 27,5XX !?
mod6: got 100k blocks to go until i probably re-wedge @ 168k
mod6: had a tinfoil hat on and everything heheh
mod6: i was getting pretty paranoid at first.
mod6: will have a fresh one in an hour or two
mod6: i probably do, but I'm making a fresh sync now.
mod6: asciilifeform: there is a snippit in the matrix one. not sure if I have a full one still.
mod6: so if anyone else sees any wedging on a checkpoint block like the following, let me know right away, pm me if required:
http://dpaste.com/1N3NPT9 mod6: <+asciilifeform> mod6: not once have i seen the wedge at 168000 << us either, until 72 hours ago
mod6: so, like we were saying, its not consistant. and perhaps we need to point directly at v0.5.3 nodes... not sure.
mod6: and TomServo was able to run with the following config and just achieved full sync: v0.5.3 + {1, rm_rf_upnp, 2, 3, 4, 6, 7}
mod6: but, its weird, because a week ago i ran a full sync of: v0.5.3 + {1, rm_rf_upnp, 2, 3, 4, 6} and sync'd just fine, as you can see in the matrix notes (was able to send/receive here:
http://pastebin.com/raw.php?i=FSA9gxs8) mod6: we also note that if you do remove checkpoints, obv, this is no longer a problem.
mod6: also, v0.5.3. + patches {1, rm_rf_upnp, 2, 3, 4, 6 & 7} (which includes the version update)
mod6: we're interested to see if anyone running: v0.5.3 + patches {1, rm_rf_upnp, 2, 3, 4, & 6 (db_config) } runs into the same issues.