24100+ entries in 0.045s
mod6: selenium doesn't really do perf testing if that's what you're looking for. it mainly can just drive through html like a browser.
mod6: asciilifeform: pretty long bumper sticker
mod6: whaack: you can pm gribble too.
mod6: BingoBoingo: fwiw it looks like alerts.[h/cpp] appear in v0.7.0
mod6: asciilifeform: when you get a chance, you should do a new submission to the list for the alert & win32 patches. thx in advance.
mod6: re: alerts.cpp etc.
mod6: it seems that alerts were probably moved out to their own file in later versions.
mod6: no need to worry about r00tkit, r00tkit pre-installed!
mod6: im looking forward to that discussion, as well as the BDB removal discussion
mod6: yeah, some well thought out decisions to be made for sure. :)
mod6: mircea_popescu: haha.
mod6: <+asciilifeform> back to the boojum - do i misunderstand or did the thing unwedge when moved to 'modern' openssl ? << yup, that's what unwedged it. move from openssl v0.9.8o -> openssl 1.0.1g
mod6 does a data round-up & updates openssl on AWS instance
mod6: So, yeah, there are a number of topics that we look forward to discussing with you about future of the R.I. We'll get there. :]
mod6: right, then there was that whole discussion.
mod6: where you can connect to 'bitcoind' with a wallet of your choosing. if that's what you mean.
mod6: something to that effect, perhaps. yes.
mod6: asciilifeform: One school of thought is to take the wallet, and place it outside of the R.I. as a seperate entity.
mod6: <+asciilifeform> roll in the five or six pieces that are actually used. << I want to collect some more data on this issue. But I'm open to discussing this option going forward.
mod6: <+mircea_popescu> this is pretty massive if true. mod6 do you feel like testing for this insanity specifically ? << yes, im sure that i'll dig into this further
mod6: and now wedges for some crazy reason. now I'm gonna upgrade to 1.0.1g there as well (just upgraded my deb6 on vbox vm to start with) and try to pass the wedge too.
mod6: so thats ^^^ my version of openssl on my aws instance, and i've sync'd successfully at lesat a dozen times in the last 4 months on there
mod6: so far. it's really weird still though, because i wasn't having this problem before. and we've always been using an old ssl.
mod6: it's old. this is what was included with ben's script to configure deb6.
mod6: which was from the orig debian 6 iirc
mod6: OpenSSL 1.0.1g 7 Apr 2014
☟︎ mod6: root@debian-test:~# openssl version -a
mod6: i just got a chance to work on it again here now.
mod6: am now on block 168,011
mod6: i just passed block 168,001
mod6: ah, my mistake. ascii numbered the "Orphanage Burner" as v0.5.3.2
mod6: it's the portotronic version v0.5.3.2 right?
mod6: thanks for the updates danielpbarron
mod6: this is what i need every morning. a good dose of solid lulz.
mod6: 30 out of 40 people say gox & ripple guy is mega-genius and in same class with Turing!!11
mod6: fluffypony: ahh, yet another "genius" thinks he's going to replace bitcoin. *snore*
mod6: so I'll keep digging in the blk0001.dat file to see what I can find in there.
mod6: hmm. anyway, ok. anyway, that's pretty much the latest.
mod6: yeah, i mean, as recently as the 26th of january I was able to full sync and send/receive with: v053+patches { 1, rm_rf_upnp, 2, 3, 4, & 6 } and other people have gotten past it as well. so its not consistant as far as I can tell.
mod6: which version, which patches?
mod6: you testing on your end?
mod6: im just gathering data as best/quickly as i can
mod6: i can still provide some sort of binary dump.
mod6: well, im just trying to pin it down to where we go wrong.
mod6: maybe its 168,001 that's hosing us.
mod6: maybe it's not a diddled 168,000 block
mod6: something in block 168,001 makes it puke perhaps from that failed VerifySignature
mod6: block 168,000 was accepted
mod6: mircea_popescu: correct.
mod6: and bag-o-snakes doesn't turn up 168,001 which makes sense, since it chokes on somethingthere
mod6: ok, i've dumped block 168000
mod6: na, just saw a bunch of those in there when looking through the hex of blk0001.dat, i think it's an OP_ script of some type maybe
mod6: tail -500000 blk0001.dat | xxd | grep "G0D" | wc -l
mod6: has anyone else seen the "G0D" magic number?
mod6: anyway, thanks guise.
mod6: looks like 'i've only got 1: blk0001.dat, 985Mb
mod6: (This was from inside where it does VerifySignature())
mod6: think that's the one to check?
mod6: during debugging, i did see something that mentioned "blk%04d.dat" when looking at the txout.scriptPubKey vector:
http://dpaste.com/1E4QQ9A mod6: i'll carry on tomorrow. im like X_X at this point.
mod6: i've basically run and break when nBestHeight=167999 and then go from there, but not turning anything meaningful up yet. however, i'm sure i'm not sure how to dig into these vectors properly yet.
mod6: ok all, not getting much of anywhere with debugging.
mod6: not sure exactly what to be looking for... but turning over a few 'stones' might find something.
mod6: seems to be: 2c2314f353 VerifySignature failed ... invalid block=0000000000000a40136b height=168001
☟︎ mod6: perhaps what i can do here, is take the copy of the blockchain that i tried to sync day-before yesterday (copied @ ~160000 blocks) and use gdb to try to see what's going on with that that block
mod6: mircea_popescu: ok. i'll check back in tonight, see what I can do.
mod6: ah. ok yeah, i can do that tonight.
mod6: i can't do much more from where i'm at right now, 'cept google perhaps.
mod6: dig it up from ? the debug log?
mod6: anyway, just thought i'd stop in and update you quick. thanks for looking!!