log☇︎
21700+ entries in 0.033s
mod6: ahh, haha. ok
mod6: Objection Argumentitive? yeah, guess it is.
mod6: !t m s.mpoe
mod6: ;;bc,stats
mod6: anyway, it's neither really here nor there.
mod6: So yeah, in the version (v0.2.1) from MPs email, that code to find the external ip is included. Also if I do a checkout of tag v0.1.5 from git, same thing. Still don't know who added it for sure though.
mod6 is out
mod6: eh, maybe i was wrong about what that email contains, i guess it's from may of 2012. ugh, too tired. my apologies.
mod6: anyway, im /exausted/. have a good night!
mod6: good point, i shouldn't speculate about weather satoshi wrote that or not without looking at MP's submission of the original bitcoin. (http://thebitcoin.foundation/ml/btc-dev/2015-February/000047.html) ☟︎
mod6: just grasping at straws. maybe the simplest answer is the correct one: he just didn't know.
mod6: yeah, no clue.
mod6: who knows why satoshi put that in there. i kinda find it hard to believe that he wouldn't have understood IP headers. perhaps he was trying to ensure that every connecting node was indeed a real host, not some spoofed packet magic. ☟︎
mod6: yeah, the network stuff (having read Stevens' stuff (UNIX Network Programming Vol 1&2)) makes me cringe.
mod6: yeah that /27 was through Qwest (now CenturyLink (usg isp)), now 1 static is included from cumcast "out of the box" iirc.
mod6: yeah i think my /27 used to be like ~$10/mo
mod6: either have I, but glibc is full of trickery.
mod6: I think trinque and I need like 2 evenings of working on it to find out how ugly its gonna be.
mod6: So, I think I'm gonna stay the course on trying to patch 4.8.4... if we get into a giant hassle with it, we'll cut bait for the time being and try to build something like 3.7 and try that.
mod6: ah, hmm. sure, we could give that a shot instead if you think its worth my/our time.
mod6: period gcc? as-in, something very recent?
mod6: or upgrade to a much more uplevel version of gcc to test and see if that works instead. iirc, version 5.x included a fix for this? maybe 4.9.x did too.
mod6: if not, we might have to McGuyver our own patch.
mod6: decimation: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00410.html < gcc patch that maybe fixed the issue << i just really hope this applies cleanly, and "works".
mod6: /usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.8.4/../../../../x86_64-gentoo-linux-uclibc/bin/ld: /usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.8.4/../../../libc.a(jmp-unwind.os): relocation R_X86_64_PC32 against undefined symbol `__GI___pthread_cleanup_upto' can not be used when making a shared object; recompile with -fPIC
mod6: by "link properly", i mean overcoming this:
mod6: <+asciilifeform> mod6: not sure how you intend to build a dns-using thing with uclibc << this is a chicken/egg problem yeah. maybe we can't get it fully built because of the whole gethostbyname libnss bullshit. but if we can at least ensure that it'll link properly, that's huge. then, even if it's not fully statuc because of that, we can amputate dns with your patches and retry.
mod6: I'll put it in the list. We'll revisit all of this soon.
mod6: Ok, no prob. :]
mod6: Does that make sense? Or am I off course here?
mod6: night
mod6: For me, doing this first is imperitive as even if the DNS amputation works, if we can't compile it with uclibc, it doesn't matter anyway.
mod6: Probably need a week to sort it out -- might take rest of month.
mod6: I, with trinque's help, need to patch gcc 4.8.4 with gentoo using /etc/portage/patches via ebuild flag(?). If that works, then I can test that the R.I. will link properly. If that works, maybe we finally have static apple pie.
mod6: I think that would be the best course of action.
mod6: So currently, I'm trying to get gcc patched to see if we can even build the R.I. with gcc/uclibc. Would it be prudent to finish that work before moving on to testing this DNS amputation?
mod6: yeah, it's good. breaks things up a bit, easier to read.
mod6: I like it.
mod6: <+mircea_popescu> mod6 we've not yet put the entire that change in yet, apparently, because one per. << makes sense. just wanted to "voice" that concern.
mod6: CAddress addrConnect("92.243.23.21", 6667); // irc.lfnet.org << would it be wiser if we spin up an ircd special for this purpose ? << i think we should make this ip non-static, configurable from a file. these IPs can change at anytime/be honeynet, etc.
mod6: well, i've run ircd hybrid many times myself. ran one for /years/. but not sure what lfnet is about really. need to look into that. but whatever it might be, it'll need to be resistant to getting packeted, unless just run for a short time for testing.
mod6 thinks
mod6: <+mircea_popescu> ben_vulpes would the foundation spin up an aws and run this ? << I can test this with my aws, sure. unless you guys are proposing something else i.e. spinning up our own ircd
mod6 looks
mod6: oh nice.
mod6: !up ascii_field
mod6: ok np. just checkin
mod6: trinque: need a link?
mod6: !up ascii_field
mod6: !up ascii_field
mod6: but overall, i agree.
mod6: <+trinque> no, that's precisely the right response << i wonder if its easier to just tell mac people to fire up a vm of linux/bsd and just use gpg inside of that?
mod6: haha
mod6: hazirafel_: along with the logs: trilema.com if you don't already
mod6: haha
mod6: the logs (see /topic ) have a wealth of knowledge too. the last 6-12 months are worth a read.
mod6: mircea_popescu: yah
mod6: in the case of pywallet.py, it looks like you just have to --dumpwallet, instead of being able to feed it a pub address and getting out a privkey right?
mod6: ^ :]
mod6: shinohai said it worked for him.
mod6: anyway, I haven't had a chance yet to try out the pywallet.py thing myself; ascii_field lettuce know if it works for ya plz.
mod6: ascii_field tried last night to backport 'dumpprivkey' and 'importprivkey' from phoundation-0.7 and found that relevant data structures are entirely different << yeah, i found the same thing back 5-6 months ago when trying to do the same thing. glad there seems to be a workaround, i'm told.
mod6: yah. for now w, i'm told this works as a temp fix: <shinohai> https://github.com/jackjack-jj/pywallet
mod6: cool!
mod6: <+asciilifeform> ben_vulpes, mod6, mircea_popescu, kakobrekla, jurov, other folks with serious servers - who wants to volunteer for node duty ? << I think the Foundation will have one, and I'll run a separate one of my own I'm sure.
mod6: <+hanbot> mod6 wunderbar! will be sure to pester as/if necessary. looks about a couple orders of magnitude slimmer than handbook at first glance, exciting << ah thx! yeah, just let me know if you run into any problems/questions.
mod6: (others are welcome to test these as well, ofc)
mod6: hanbot: anyway, thanks again, let me know if you have any questions.
mod6: Upon further successful testing of these guides, they'll be submitted to the mailing list, etc.
mod6: http://thebitcoin.foundation/gentoo-stage3-amd64-uclibc-hardened-guide-wFullExamples.txt
mod6: http://thebitcoin.foundation/gentoo-stage3-amd64-uclibc-hardened-guide.txt
mod6: Ah yeah it did. Ok, one sec:
mod6 looks at the log
mod6: Did it cut them off from my message?
mod6: Thanks for the help!
mod6: hanbot: I finally have a guide you can follow for an amd64 (x86-64) Gentoo install on physical hardware. This guide is actually part A (just the commands & notes) and part B (with examples from my own install process). trinque & I have both tested this independantly, and the steps got us to a working install. Hopefully you'll get the same result! You should probably just read through both before actually doing anything. Here are the URL's to
mod6: hah s/driving/parking/
mod6: <+ascii_field> sometimes i log in from the car. << i can just imagine you driving around the beltway with your knee irc'ing from a phone.
mod6: !up ascii_field
mod6: bah
mod6: !up assbot
mod6: i see, ok.
mod6: <+ascii_field> mod6: it was a fallback if irc fails << oh or if -noirc is used or something?
mod6: <+ascii_field> << you can ~already~ specify seeds on cmdline and config! all that remains is the removal of the built-in seeder crap << sure, you can do addnode or whatnot to connect to other nodes. but isn't the dyndns thing to tell others what your nodes ip address is? maybe i misunderstand ...
mod6: !up ascii_field
mod6: oop
mod6: <+kakobrekla> would a dedi ba seed be welcome << yeah, i think that's the idea eventually.
mod6: <+mod6> <+ascii_field> i'm in favour of keeping the irc mechanism for now, because it will handily transplant to gossipd << i'm with you here... although, just looking through irc.cpp again.. im not sure how much of that would carry over anyhow. << regardless, it doesn't mean we have to rip it out this minute. how insane of an idea is it to just snip out the checkip.dyndns.org parts and add a commandline/configfile arg to specify external ip for ☟︎
mod6: <+ascii_field> but ~somewhere~ << yup, gotcha. just putting in my 0.00000002
mod6: <+ascii_field> i'm in favour of keeping the irc mechanism for now, because it will handily transplant to gossipd << i'm with you here... although, just looking through irc.cpp again.. im not sure how much of that would carry over anyhow.
mod6: <+ascii_field> to fully scrub out the dns invocations, will have to make the irc connector configurable on command line << not that this has to be the case now, but perhaps this could be done in the config file too.
mod6: !up ascii_field
mod6: :]
mod6: That's fine. Take your time. It won't take long to get that going anyway.
mod6: np. so, i'm gonna keep focus on this Gentoo GCC patching stuff for the time being. But meanwhile I do that on my POS box (Now running Gentoo AMD64 hardened w/uclibc), I can shutdown the Gentoo aws instance and fire-up a deb6 test with these new patches before the end of the month I'm sure.
mod6: !up ascii_field
mod6: yeah, that stuff is 100% cruft.
mod6: makes sense. thanks.
mod6: *nod*
mod6: great work ascii.