21000+ entries in 0.039s
mod6: <+gernika> mod6 stator with mods for OpenBSD. Blockheight=168000 << if it's a problem in block 168`001, i'm sure we hit this problem in february. but it should be resolved with openssl 1.0.1g.
mod6: gernika: what version are you running? what's your current block height, 363897?
mod6: classic stator, i.e. no dump/eat block
mod6: ok thanks for clairifying for me
mod6: oh your just using addnode? or what?
mod6: so asciilifeform you're just stuck on 363734 even though you're seeding via irc again ?
mod6: danielpbarron: great! thanks
mod6: mp, you're right, should test the new dump/eat tools with the orphan blocks
mod6: <+danielpbarron> height=363856 << your v0.5.3.1ish node has this height?
mod6: haha. yeah, that too.
mod6: <+mircea_popescu> here's what's the idea : after botching the soft fork, it seems illogical that the entire bip system should continue at all. << Very much agreed. If someone wants to change something they should write to The Foundation's btc-dev mailing list and submit a patch. And if they can't because they're not in the WoT, well they're not in the WoT. They can make a personal appeal here in person.
mod6: shinohai: is that with your v0.5.3.1-RELEASE node?
mod6: thx for posting dpb
mod6: <+asciilifeform> has anybody as of this moment received a block past 363734 from mircea_popescu's node ? << im a day a way or so yet
mod6: <+phf> apparently gcc doesn't always include all the necessary pthread bits (not just openbsd but other unixes), which results in segfault on launch << on my obsd 5.6 on x86-64 that's the same problem i kept running into; segfault at execution time.
mod6: <+asciilifeform> phf: you may be the first to achieve openbsd build! consider posting recipe << please do!
mod6: my stator is @ 281k
mod6: i put it out there on derp-media too
mod6: yeah, i should have just pointed him to your blog.
mod6: anyway, you think i should have just called him out instead of saying "reasons"?
mod6: <+ben_vulpes> << this still hurts, every time i see it << awe!
mod6: ok mp says he can see signing that statement ben_vulpes. go ahead, he'll even sign later when he gets on his other box.
mod6 doublechecks the SoBAs
mod6: otherwise we had issues on 168`001 iirc
mod6: s/must be considered/is a/ ?
mod6: sure, dpaste 'em up for maxtime
mod6: mine is currently sync'ing against mp's seed.
mod6: the hope was to find if he can verify if v0.5.3.1 rejected or accepted the blocks in question; 363738
mod6: shinohai: is your v0.5.3.1-RELEASE node up to dayte?
☟︎ mod6: <+ben_vulpes> Bitcoin 0.5.3 is the canonical reference implementation. If a fork occurs and one side validates on the 0.5.3 codebase while the other does not, the chain that validates under 0.5.3 is the only valid chain. << I have nothing further to add to this at this time.
mod6: maybe even 4.0.4 (if it'll build)
mod6: ah, i can give it a go with something as old as like 4.5.4 for sure.
mod6: any idea how old of a version is required?
mod6: <+asciilifeform> mod6, ben_vulpes ^^^ who wants to try << i might be able to give it a go later this weekend ... maybe.
mod6: <+mircea_popescu> jitter actually fixed by plug-unplug. da fuck. << good deal. maybe just needed reinitialization for whatever reason
mod6: <+trinque> and hey, I got a static bitcoind << nice!! i'll give this a shot here tonight yet
mod6: otherwise, it could be something with the surface that you're using it on... like if its some how refracting in some strange way
mod6: ah, ps2. maybe just try disconnecting it and re-connecting it?
mod6: sometimes a hair gets stuck in mine, and I have to pull it out.
mod6: trinque: aight, thanks!
mod6: and if that doesn't work, maybe I can give 'hardened/linux/musl/amd64' (i don't see a non-hardened one available atm)
mod6: trinque: sometime this month I'll try to pay with 'default/linux/uclibc/amd64' instead.
mod6: <+trinque> suggests it's maybe a matter of the hardened toolchain eh? << yeah, i think this is a clue
mod6: except this is with glibc huh
mod6: ty_v0' can not be used when making a shared object; recompile with -fPIC ]
mod6: weird. that's basically the same problem i had with uClibC [ libpthread.a(pthread_cond_wait.o): relocation R_X86_64_32 against `__gcc_personali
mod6: punkman: you may want the kills_integer_retardation in there, as well as nubs`'s gentoo sanity, at least the part with the copying over of the headers & libs in auto.sh check those out here:
mod6: <+punkman> ascii_field, does this sequence look right? >> 0.5.3.1-release + orphanage nuke + tx-orphanage + dnsseed_snipsnip + zap_hardcoded_seeds + zap_showmyip + dns thermonuke + irc nuke << looks right to me.
mod6: thanks for your help shinohai
mod6: !v assbot:mod6.rate.trinque.2:169cd6f50f90268d762985db26d2684aae73f0608210b216475944c337511014
mod6: !v assbot:mod6.rate.shinohai.1:166411dcdc19e0619447eec6756b67e99dd3dd7c8ac794832a8fdf651173e770
mod6: !assbot:mod6.rate.shinohai.1:166411dcdc19e0619447eec6756b67e99dd3dd7c8ac794832a8fdf651173e770
mod6: !rate trinque 2 Provided much assistance with Gentoo
mod6: !rate shinohai 1 Helping to test the bitcoin Reference Implementation
mod6: phf: was this the page you were trying to follow?
mod6: not that I have any better ideas at this point.
mod6: oh yeah, now that page was the one i was referring to; i find it pretty unhelpful at all unless you're looking for just who submitted/signed & the sig.
mod6: it can't hurt anyway
mod6: and really, if you wanna follow along, it helps to have the historical timeline 'in head' as well by reading the logs since last October.