05:35 |
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 |
| |
↖ |
05:35 |
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 |
| |
~ 1 hours 32 minutes ~ |
07:07 |
feedbot |
http://thetarpit.org/2021/on-the-utter-death-of-musical-arts << The Tar Pit -- On the utter death of musical arts |
| |
~ 3 hours 46 minutes ~ |
10:54 |
asciilifeform |
gregorynyssa: makes sense. |
10:54 |
asciilifeform |
$ticker btc usd |
10:54 |
btcinfobot |
Current BTC price in USD: $55038.96 |
10:54 |
asciilifeform |
!w poll |
10:54 |
watchglass |
Polling 15 nodes... |
10:54 |
watchglass |
185.85.38.54:8333 : Could not connect! |
10:54 |
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 |
10:54 |
watchglass |
185.163.46.29:8333 : Could not connect! |
10:54 |
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 |
10:54 |
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) |
10:54 |
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 |
10:54 |
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) |
10:54 |
watchglass |
192.151.158.26:8333 : Alive: (0.146s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=681904 |
10:54 |
watchglass |
208.94.240.42:8333 : Alive: (0.162s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=681904 |
10:54 |
watchglass |
143.202.160.10:8333 : Alive: (0.223s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=681904 |
10:54 |
watchglass |
213.109.238.156:8333 : Alive: (0.273s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=681904 |
10:55 |
watchglass |
84.16.46.130:8333 : Violated BTC Protocol: Bad header length! |
| |
~ 6 hours 10 minutes ~ |
17:06 |
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 |
17:06 |
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) |
17:09 |
billymg |
any idea what i might have missed? |
17:09 |
* |
asciilifeform looks |
17:12 |
asciilifeform |
billymg: you forgot to include the field for struct.pack for that byte |
17:12 |
asciilifeform |
see also. |
17:13 |
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 |
17:14 |
billymg |
will look at the docs again |
17:14 |
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) |
17:15 |
asciilifeform |
in my (undeployed) variant where polling of prb for peers, it happens only if trb-style poll returns 0 peers |
17:17 |
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 |
17:18 |
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 |
17:22 |
billymg |
hey, whaddya know, i left as is and only changed my advertised version from '99999' to '70001' and now it works |
17:23 |
asciilifeform |
billymg: interesting; did not observe this effect in my test |
17:23 |
asciilifeform |
(>=70001 is req'd, tho, per the spec, for prb) |
17:27 |
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 |
17:27 |
asciilifeform |
billymg: what happens if e.g. 70003 ? |
17:28 |
billymg |
lemme try |
17:29 |
billymg |
works |
17:29 |
* |
asciilifeform when last tried this (see linked log earlier) observed that prb appeared to need only >=70001 and the 'relay' byte |
17:29 |
billymg |
99999 should be > 70001 though |
17:29 |
asciilifeform |
billymg: pretty interesting, gotta wonder whether 'latest' prb includes a boobytrap specifically against trb |
17:29 |
billymg |
perhaps slipped in an extra if != '99999' |
17:30 |
asciilifeform |
(which defaults to 99999, i personally set it to this for no particular reason) |
17:30 |
asciilifeform |
well not quite 'no reason', at the time the prb req. was, per spec, >=70001. |
17:30 |
asciilifeform |
at any rate, interesting, see if you can find the booby |
17:31 |
asciilifeform |
billymg: quickest way would be to catalogue, using your surveyer, the nodes which behave this way |
17:32 |
asciilifeform |
collect their useragents. |
17:33 |
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 |
17:33 |
asciilifeform |
trb btw doesn't give a damn re version |
17:33 |
asciilifeform |
(so long as not antedeluvian, i fughet which) |
17:33 |
billymg |
but i ran against a hundred or so prb nodes and none were returning peers when advertised version was set to '99999' |
17:34 |
asciilifeform |
interesting. |
17:35 |
billymg |
actually not 100% true, these 3 gave a single peer result (itself): http://paste.deedbot.org/?id=LfmO |
17:35 |
billymg |
but all the rest, [] |
17:38 |
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 |
| |
↖ |
17:39 |
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 |
17:39 |
asciilifeform |
given as any publicly-reachable node can be polled for peers, and for height, inventory; and some do answer |
17:39 |
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 |
17:39 |
billymg |
asciilifeform: that sounds cool |
17:40 |
asciilifeform |
out of general principle i wouldn't bother hitting same box moar than 1ce in 10m |
17:40 |
billymg |
asciilifeform: ok, yeah, i'm relying on the watchglass methods for all protocol level interactions so that should be ok |
17:40 |
asciilifeform |
aha |
17:40 |
billymg |
1ce? |
17:40 |
billymg |
once |
17:40 |
billymg |
ok |
17:40 |
asciilifeform |
once |
17:41 |
asciilifeform |
this of course strictly if the peer answers. |
17:41 |
asciilifeform |
if not answers (recall, single-threaded proggy) but does accept connection, chances are it's busy |
17:42 |
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 |
17:44 |
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 |
17:44 |
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) |
17:44 |
asciilifeform |
billymg: meant 'once' as in 'one session' rather than strictly 'one command' |
17:45 |
asciilifeform |
billymg: you'll want to consolidate the version & peers thing into 1 session. |
17:45 |
billymg |
asciilifeform: yeah, that's what i was thinking |
17:46 |
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) |
17:46 |
asciilifeform |
aha |
17:47 |
* |
asciilifeform bbl |
| |
~ 19 minutes ~ |
18:07 |
thimbronion |
Anyone gotten php/mysql working on a gentoo created using http://www.loper-os.org/pub/dulap_construction_kit_r4.txt? |
| |
↖ |
18:15 |
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) |
| |
↖ |
18:15 |
billymg |
what part is it stuck on? |
18:19 |
thimbronion |
Got apache built. Tried to build php-5.6.32, but failed when trying to download app-eselect/eselect-php-0.9.2. |
18:24 |
verisimilitude |
What's so compelling about this Wordpress fork? |
| |
↖ |
18:24 |
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) |
18:25 |
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 |
18:27 |
thimbronion |
Sadly http://dulap.xyz/gentoo/distfiles/eselect-php-0.9.2.tar.xz not found. |
18:30 |
billymg |
do you see the ebuild at that same path on yours? |
18:31 |
thimbronion |
billymg: I do |
18:35 |
billymg |
thimbronion: trying now on my box... |
18:35 |
billymg |
`emerge -av =app-eselect/eselect-php-0.9.2` worked for me, hrm.. |
18:35 |
thimbronion |
billymg: oh can you check the log and see where you got it? Or maybe you already had it? |
18:36 |
billymg |
i hadn't installed php on this one, so it grabbed it from somewhere |
18:37 |
billymg |
lemme look |
18:38 |
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) |
18:40 |
thimbronion |
For example, https://dev.gentoo.org/~mjo/distfiles/eselect-php-0.9.2.tar.xz fails for me. |
18:40 |
billymg |
ahh |
18:43 |
billymg |
well i also have that at `/usr/portage/distfiles/eselect-php-0.9.2.tar.xz` |
18:43 |
billymg |
so right, must've used the local copy since that url is dead |
18:44 |
thimbronion |
yeah I ain't got it |
18:44 |
thimbronion |
I was too slow lol |
18:48 |
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 |
18:51 |
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 |
18:58 |
thimbronion |
billymg: what's the timestamp on the file, out of curiosity? |
18:58 |
billymg |
2016 something or other |
18:58 |
billymg |
jul 26 |
| |
~ 25 minutes ~ |
19:24 |
billymg |
thimbronion: fwiw that php emerge just finished successfully |
| |
↖ |