log☇︎
20200+ entries in 0.054s
mod6: !up ascii_field
mod6: I made brief mention of dignork's patch in the SoBA from December: http://thebitcoin.founation/ml/btc-dev/2014-December/000017.html
mod6: this patch was submitted: http://thebitcoin.foundation/ml/btc-dev/2014-October/000004.html but it is /already/ applied in v0.5.3 base, we never applied this patch. Here's the spot: http://btc.yt/lxr/satoshi/source/src/main.cpp#0665
mod6: are you talking about the subsidy overflow?
mod6: ok pulling blocks past 366662
mod6: ok restarting & connecting to dulap and incitatus
mod6: !up ascii_field
mod6: ah ok
mod6 tries
mod6: ?
mod6: <+ascii_field> http://btc.yt/lxr/satoshi/source/src/net.cpp#1263 << Ah! so just -connect=dulap -connect=other
mod6: forgot.
mod6: ah right, there's a message about that.
mod6: i'm wondering if i shouldn't just: A: 1) shutdown bitcoind, 2) restart bitcoind. If no further blocks are pulled, B: 1) shutdown bitcoind, 2) update time, 3) restart bitcoind ☟︎
mod6: <+ascii_field> at any rate, we desperately need a multi-node version of '-connect' << this would be great!
mod6: restart, etc.
mod6: i could perhaps just try to restart it, but just wanted to let you know first before I shut it off or do anything else.
mod6: http://thebitcoin.foundation/misc/debug-log-snip-20150724.txt
mod6: sure. give me a bit here...
mod6: yeah dulap
mod6: -connect
mod6: been stuck on block: 366662 for ~12 hours (since I restarted this patched up through verifyall gentoo build lastnight)
mod6: ;;later tell jurov nevermind, i reformatted it a bit and resent, went through this time.
mod6: ;;later tell jurov can you check the btc-dev list and see if I have an email stuck in there?
mod6: i think the turdolator ate my email
mod6: <+asciilifeform> mod6: patch the result of my patch << will do!
mod6: <+asciilifeform> mod6: i'd prefer if you patched my patch << huh, ok. i kinda figured it'd be less messy the other way around. but... sure.
mod6: asciilifeform: re: << looks fine. << want me to send this up then? http://dpaste.com/3B706XK.txt
mod6: hanbot: actually make sure to use this one: 000130.html -- the original one was setup for macos
mod6: i dunno, maybe im wrong.
mod6: you know... it looks to me from that dpaste that it might not be finding the openssl/boost headers
mod6: hmm
mod6: oh.
mod6: then this is what we used to get the deps setup on debian 6 -- the package names might be similar on ubuntu:
mod6: but on debian, which is similar in a way to ubuntu with `apt-get`, you need to first update apt-get (anyone correct me if I'm wrong): `apt-get update` and `apt-get upgrade`
mod6: if anyone has built this on v0.5.3.1-RELEASE feel free to pitch in here...
mod6: ok, you're on ubuntu right? ☟︎
mod6: <+asciilifeform> (hanbot was asking various things re: patches, etc) << ahhh right. hanbot, did you have any luck getting any of the patches applied?
mod6: i have a replacement patch ready to go if you're alright with that change.
mod6: thoughts?
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: currently on block: height=366125
mod6: sorry for the delay. lol, had to find block number.
mod6: and it sync'd against your dulap with -verifyall all the way up to 365454, then wedged for ~36 hours or so. but this evening, restarted it and continued sync'ing just fine.
mod6: so I had this build that i created on the 13th: 20150713-v0531-patched-glibc-gentoo-statorBuildScript
mod6: sorry.
mod6: ooh no.
mod6: i think i misunderstand your comment "hanbot's node ?" then. i thought you were trying to indicate that I was syncing against the wrong IP
mod6: i thought that was the dulap?
mod6: what am I missing here. is that hanbots node?
mod6: nosuchlabs.com. 1800 IN A 195.211.154.159 ☟︎
mod6: wait
mod6: <+asciilifeform> http://log.bitcoin-assets.com/?date=23-07-2015#1210981 << hanbot's node ? << awe f. how i grabbed the wrong ip ... gfdi ☝︎
mod6: asciilifeform: up to, height=365462 now. and my other obsd build has been connected the whole time and still chugging along: height=224116
mod6: asciilifeform: the build we were discussing earlier is now up and running against 195.211.154.159 and seems to be pulling blocks again just fine. ☟︎☟︎
mod6: !up ascii_field
mod6: !up asciilifeform
mod6: thanks kakobrekla
mod6: i don't have much more info than that right now. can revisit later though for sure.
mod6: -connect -myip -verifyall
mod6: -connect
mod6: http://log.bitcoin-assets.com/?date=22-07-2015#1209148 ☝︎
mod6: it was: gentoo x86-64 glibc: v0.5.3.1+{ these patches in this order: http://dpaste.com/1CSFS1A.txt } built with stator build script. connected to: 195.211.154.159:8333 running with verifyall - ran great up until a few days back. we discussed this.
mod6: <+asciilifeform> 366601 at this time << ah ok. i'll start mine back up later. i had shut it down because it had been on the same block for >36 hours.
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: from my pastebin: http://pastebin.com/raw.php?i=9U2VHnRx
mod6: 1629931 ERROR: ConnectInputs() : 2c2314f353 VerifySignature failed
mod6: trinque: we're talking about the origina barf on 168`001
mod6: http://btc.blockr.io/tx/info/2c2314f353013f920d8fbfde242d7d23ba4cb9b97dc24f481dd0ccfd8f56324c
mod6: sec
mod6: sure
mod6: <+asciilifeform> plz details ? << log.bitcoin-assets.com/?date=06-02-2015#1009754
mod6: that /should/ tell the tale
mod6: if you need to check that you have indeed statically linked in openssl 1.0.1g into your binary, you can do this: hexdump -C bitcoind | grep "1.0.1g"
mod6: punkman: good find
mod6: well, if you see it again, let us know. thanks!
mod6: hmm. alright.
mod6: s/that's/this is/
mod6: im sure it didn't. that's really bad.
mod6: This goes for all: If you get wedged for some reason while running the R.I. please stop in and ask right away. Back up the debug.log for us too plz.
mod6: and in your memory you don't remember seeing the "Verify Signature failure" in there?
mod6: you got wedged on the 168`001 block? aka: you were stuck on block 168`000 according to this.. although, i dont' as of yet see a Verify Signature failure in here...
mod6: holy yikes gernika
mod6: gernika: sure, we should be beyond that now with 1.0.1g but, we'll see.
mod6: punkman: good q.
mod6: my one gentoo (all ascii's patches through verifyall x86-64/glibc) build got all the way up to where nsl is wedged. but my openbsd one is crawling along on verify all also... so far: height=220047 ☟︎
mod6: that's good.
mod6: for us we thought that the 168`001 verify signature issue at first was due to the fact that 168`000 is the last checkpoint. but totally unrelated. threw us off for a bit though.
mod6: it barfs on tx fb0a1d8d34fa5537e461ac384bac761125e1bfa7fec286fa72511240fa66864d in block 124`276 ☟︎
mod6: it didn't barf on 124`275
mod6: thanks gernika
mod6: <+mod6> this tx: fb0a1d8d34fa5537e461ac384bac761125e1bfa7fec286fa72511240fa66864d
mod6: <+mod6> ok so those happen a bit... then you hit block 124`275 and then fail to verify a tx in block 124`276 to no avail
mod6: nice. put it somewhere for me to look at.
mod6: do you hvae the log?
mod6: any idea what block number it was? or txid?
mod6: we saw stuff like that before with the 168`001 Verify Signature fail too. most of the time it failed for us... the three of us who were independantly testing it. But sometimes, it'd pass. Maybe 30% of the time. I was pulling my hair out. ☟︎
mod6: gernika: you just restarted it and then it it verified the sig?
mod6: <+gernika> mod6 stator, openssl-1.0.1g. << what did you do to get around this?
mod6: asciilifeform: ^^