Show Idle (>14 d.) Chans
← 2021-05-03 | 2021-05-05 → ↓
gregorynyssa: http://logs.nosuchlabs.com/log/asciilifeform/2021-05-03#1035345 << my interest in this matter is more anthropological than economic. if the ruling class goes through a generational religious shift, I consider that significant
snsabot: Logged on 2021-05-03 15:39:28 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-05-02#1035174 << not sure why to suppose that this was for any other than electoral pr purposes
feedbot: http://thetarpit.org/2021/on-the-utter-death-of-musical-arts << The Tar Pit -- On the utter death of musical arts
asciilifeform: gregorynyssa: makes sense.
asciilifeform: $ticker btc usd
btcinfobot: Current BTC price in USD: $55038.96
asciilifeform: !w poll
watchglass: Polling 15 nodes...
watchglass: 185.85.38.54:8333 : Could not connect!
watchglass: 205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.021s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=681904
watchglass: 185.163.46.29:8333 : Could not connect!
watchglass: 205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.084s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=681904
watchglass: 108.31.170.100:8333 : (pool-108-31-170-100.washdc.fios.verizon.net) Alive: (0.096s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=681904 (Operator: asciilifeform)
watchglass: 205.134.172.26:8333 : Alive: (0.145s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=681535
watchglass: 205.134.172.28:8333 : Alive: (0.084s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=681904 (Operator: whaack)
watchglass: 192.151.158.26:8333 : Alive: (0.146s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=681904
watchglass: 208.94.240.42:8333 : Alive: (0.162s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=681904
watchglass: 143.202.160.10:8333 : Alive: (0.223s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=681904
watchglass: 213.109.238.156:8333 : Alive: (0.273s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=681904
watchglass: 84.16.46.130:8333 : Violated BTC Protocol: Bad header length!
billymg: asciilifeform: just for testing this i modified mk_btc_ver_msg() to include the extra byte at the end. i'm running it against nodes in the db and not having any luck
snsabot: Logged on 2020-03-01 14:38:20 asciilifeform: shinohai: this btw confirmed. i did experiment, if one sends that extra byte, prb noades do in fact send addrs. (and yes some of'em ipv6, have to be thrown out)
billymg: any idea what i might have missed?
asciilifeform: billymg: you forgot to include the field for struct.pack for that byte
billymg: i added '?' to the end of pformat to add the boolean at the end, and i added the last argument, True, to the struct.pack() call
billymg: will look at the docs again
asciilifeform: hm theoretically oughta work. (keep in mind that it'll choke trb-compat. nodes tho. there is no header that will work for both)
asciilifeform: in my (undeployed) variant where polling of prb for peers, it happens only if trb-style poll returns 0 peers
billymg: asciilifeform: yes, after getting this to work i was going to add something in that alters the message depending on whether the node identifies as trb or prb in the version message
billymg: asciilifeform: i saw that too re: won't work for trb -- i must be doing something wrong because a test trb node is still returning peers with this extra byte
billymg: hey, whaddya know, i left as is and only changed my advertised version from '99999' to '70001' and now it works
asciilifeform: billymg: interesting; did not observe this effect in my test
asciilifeform: (>=70001 is req'd, tho, per the spec, for prb)
billymg: asciilifeform: ok, interesting. i've confirmed with this prb node that both the extra byte in the version message AND an advertised version of '70001' is required
asciilifeform: billymg: what happens if e.g. 70003 ?
billymg: lemme try
billymg: works
asciilifeform when last tried this (see linked log earlier) observed that prb appeared to need only >=70001 and the 'relay' byte
billymg: 99999 should be > 70001 though
asciilifeform: billymg: pretty interesting, gotta wonder whether 'latest' prb includes a boobytrap specifically against trb
billymg: perhaps slipped in an extra if != '99999'
asciilifeform: (which defaults to 99999, i personally set it to this for no particular reason)
asciilifeform: well not quite 'no reason', at the time the prb req. was, per spec, >=70001.
asciilifeform: at any rate, interesting, see if you can find the booby
asciilifeform: billymg: quickest way would be to catalogue, using your surveyer, the nodes which behave this way
asciilifeform: collect their useragents.
billymg: from here i'm just going to proceed with making the crawler send the correct version message depending on whether it's trying to reach a trb or prb node. but yes, perhaps could write it so it tries once with '99999' then tries with '70001' and records result
asciilifeform: trb btw doesn't give a damn re version
asciilifeform: (so long as not antedeluvian, i fughet which)
billymg: but i ran against a hundred or so prb nodes and none were returning peers when advertised version was set to '99999'
asciilifeform: interesting.
billymg: actually not 100% true, these 3 gave a single peer result (itself): http://paste.deedbot.org/?id=LfmO
billymg: but all the rest, []
asciilifeform: billymg: my original half-baked attempt at this, had the aim of being a ~realtime graph of nodez, such as to determine how the hell blox actually propagate, and to what extent is possible to determine just from where, and other pertinent facts
billymg: asciilifeform: regarding spamming nodes with requests, anything you discovered in terms of a "minimum time between requests" value? to avoid my ip getting banned
asciilifeform: given as any publicly-reachable node can be polled for peers, and for height, inventory; and some do answer
asciilifeform: billymg: did not discover any obvious instances of being banned. i expect you will be , though, if do not follow through with the handshake as given in my orig. wg
billymg: asciilifeform: that sounds cool
asciilifeform: out of general principle i wouldn't bother hitting same box moar than 1ce in 10m
billymg: asciilifeform: ok, yeah, i'm relying on the watchglass methods for all protocol level interactions so that should be ok
billymg: 1ce?
billymg: once
asciilifeform: this of course strictly if the peer answers.
asciilifeform: if not answers (recall, single-threaded proggy) but does accept connection, chances are it's busy
asciilifeform: billymg: upstack -- in principle there's no reason why one couldn't write a www-displayable noad mapper, which reveals peers (and by implication, nodes which lie about peer set) and propagation info
billymg: asciilifeform: hrm, so regarding the once/10m rule, i'd like to collect the "probe" data from the version message response, as well as the peers from get_addrs. using watchglass's methods this means i'm hitting each node twice
asciilifeform: the other thing i wanted to do was a random test that'd ask, at random, a peer to retrieve a particular block, and see if able to (and what latency, and does the returned block match the actual)
asciilifeform: billymg: meant 'once' as in 'one session' rather than strictly 'one command'
asciilifeform: billymg: you'll want to consolidate the version & peers thing into 1 session.
billymg: asciilifeform: yeah, that's what i was thinking
billymg: from what i can see now i'll need a new watchglass method, basically the current getpeers_node but that also returns the version message response data (instead of only using it for the handshake)
thimbronion: Anyone gotten php/mysql working on a gentoo created using http://www.loper-os.org/pub/dulap_construction_kit_r4.txt?
billymg: thimbronion: i got the full mp-wp stack working on BingoBoingo's old rockchips, which i believe were running something very close to that (asciilifeform would likely know the differences)
billymg: what part is it stuck on?
thimbronion: Got apache built. Tried to build php-5.6.32, but failed when trying to download app-eselect/eselect-php-0.9.2.
verisimilitude: What's so compelling about this Wordpress fork?
billymg: thimbronion: i've found in the past with portage sometimes first emerging the stuck dependency before emerging the target package works (don't know why though)
billymg: in my dulap (from that guide) eselect-php-0.9.2.ebuild is present at /usr/portage/app-eselect/eselect-php/eselect-php-0.9.2.ebuild so should be on yours too
billymg: do you see the ebuild at that same path on yours?
thimbronion: billymg: I do
billymg: thimbronion: trying now on my box...
billymg: `emerge -av =app-eselect/eselect-php-0.9.2` worked for me, hrm..
thimbronion: billymg: oh can you check the log and see where you got it? Or maybe you already had it?
billymg: i hadn't installed php on this one, so it grabbed it from somewhere
billymg: lemme look
billymg: from `cat /usr/portage/app-eselect/eselect-php/eselect-php-0.9.2.ebuild` it looks like `SRC_URI="https://dev.gentoo.org/~mjo/distfiles/${P}.tar.xz"` (i'm assuming that's where it pulled it from then)
billymg: ahh
billymg: well i also have that at `/usr/portage/distfiles/eselect-php-0.9.2.tar.xz`
billymg: so right, must've used the local copy since that url is dead
thimbronion: yeah I ain't got it
thimbronion: I was too slow lol
billymg: well now that i have that dependency i'm just gonna try to `emerge -av =dev-lang/php-5.6.35-r1` and see what happens
billymg: thimbronion: thing is, i installed that eselect-php-0.9.2 for the first time just now. so not sure how the tar.xz was already in distfiles unless it came with the dulap setup
thimbronion: billymg: what's the timestamp on the file, out of curiosity?
billymg: 2016 something or other
billymg: jul 26
billymg: thimbronion: fwiw that php emerge just finished successfully
← 2021-05-03 | 2021-05-05 → ↑
Random(asciilifeform) | Download hourly DB snapshot | Get Source Code