Show Idle (> d.) Chans


| Results 1001 ... 1250 found in asciilifeform for 'peer' |

billymg: asciilifeform: adjusting the peershots knob from 3 to 5 seems to have helped for certain prb nodes: http://bitdash.io/nodes/5.103.137.146-9333
dulapbot: Logged on 2021-07-17 17:53:53 billymg: and a new record for peers returned, 2504
billymg: looking at it closer i may see pretty careless mistake on my part though, i'm not de-duping this peers list as i build it
billymg: signpost: in asciilifeform's original it was used to retry the getaddr N times in case of failure (and break out when it succeeds). i modified it to just retry again regardless of success/failure because i noticed i was getting more peers that way (probably due to the magic numbers you pointed out above)
signpost will have to read the watchglass sauce and see what peershots is
billymg: and a new record for peers returned, 2504
billymg: just restarted the crawler with peershots=5, it finishes scanning all nodes in the network in about 20 minutes
billymg: ah, i see. i wonder if bumping up the 'peershots' value in watchglass would net more peers (currently i have it set to 3)
signpost: seems like if you're getting 1 address for many peers, *their* peer count is indeed low, but probably not 1
billymg: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-09#1044719 << by this were you referring to the fact that trb eventually clears out the spam peers?
asciilifeform: billymg: aha, given as very clearly visible in your thing , there are prb nodes which ~do~ return peers
asciilifeform: billymg: in re noad spamola (which carries on, tho w/out visible effect on block-eatin') -- is 2000 the max list edible by your scanner? ( dun recall whether this is simply max peer list in trb.. )
mats: looks like a relationship between peers, rather than a hegemon directing vassals
billymg: asciilifeform: as of late afternoon yesterday the trb nodes started picking up a bunch of spam peers again http://bitdash.io/nodes/205.134.172.27-8333
asciilifeform: signpost: i advocate a 'measure 7 times, cut 1nce' approach, aha, to peering.
dulapbot: Logged on 2021-07-05 10:45:13 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-05#1042780 << indeed, if you want to go beyond killfiling, and not see ~any~ conv. the fella was part of, would have to no longer be part of a net where others peer with him. this is, yes, a different experience than traditional 'palace' irc. i'm willing to live with it.
asciilifeform: the only 'special', if you will, type of packet, is where it is marked (in the current variant : packet.handle == sendingpeer.handle) as 'original' i.e. a direct peer of yours indicates that he had produced it.
asciilifeform: further pasta: 'Packets propagate from peer to peer; a set of stations such that each member of it will eventually receive a packet broadcast by any other member is referred to as a "net."'
asciilifeform: (indicating that the message did not come directly from your peer who uses this handle)
asciilifeform: 'If the Handle of an incoming packet does not equal the Handle given in the receiving station's WOT for the peer from whom it
asciilifeform: 'If the Handle in an incoming packet is equal to the Handle given in the station's WOT for the peer who had signed this packet,
asciilifeform: signpost: it differs strictly in that handle(peer from whom received, by way of hmac ver.) != handle in packet
asciilifeform: ('originator' version -- directly/authenticably from the peer who keyed it in)
signpost: of course, the solution among friends when being drowned by old dupes is 1) hey bud, fix your node and 2) fuck you, I'm unpeering.
asciilifeform: ( likbez re subj. but factually is the algo behind the irc headache -- 'no, you may not have peerings a<->b + a<->c + b<->c ! one of these is redundant! fuck you')
billymg: and i only started seeing that happen as of yesterday when i first reported it, before TRB nodes were always connected to a reasonable number of peers and a high percentage were "real" (i.e. responded with valid version msg when probed)
billymg: looking at whaack's node for example, the most recent getpeers returned a reasonable 66, but in the last 24hr it has been jumping around to the 3-4 digit range
billymg: asciilifeform: for when you return, i actually *just* made live a WIP version of the www. you can see from the historical poll results on .27 that the spam peers seem to come and go in waves http://bitdash.io/nodes/205.134.172.27-8333
billymg: !w peers 205.134.172.27
billymg: !w peers 205.134.172.27
dulapbot: Logged on 2021-07-08 11:20:15 billymg: asciilifeform: is 205.134.172.27 your node? my crawler is showing that sometime in the last hour or so it jumped from around ~40 connected peers (mostly good) to ~1200 peers (mostly fake/spam)
billymg: asciilifeform: the peer lists have been captured (the crawler is now stores probe history up to N probes, as set in conf). i'll dump the results somewhere permanent before the cap is reached
billymg: actually all of them seem to be returning significantly more spam peers in the last 1-2 hours
billymg: another trb node, 205.134.172.26, also jumped in the same timeframe (from an average of around ~175 connected peers to now 1885 in the most recent poll - most of which appear to be spam)
billymg: asciilifeform: is 205.134.172.27 your node? my crawler is showing that sometime in the last hour or so it jumped from around ~40 connected peers (mostly good) to ~1200 peers (mostly fake/spam)
dulapbot: Logged on 2021-07-01 18:14:44 asciilifeform: was laying this out on chalkboard, and currently stuck on the puzzler of 'how do peers know 'the current difficulty' ?'
dulapbot: Logged on 2021-07-05 18:43:54 punkman: https://peerlinks.io/protocol.html << perfect of example of "blockchain engineering"
asciilifeform: '(TODO(indutny): find a mechanism to deter peers from spamming each other. Rate limit does not work, because the peer cannot be identified consistently in MultipeerConnectivity)' << lol
punkman: https://peerlinks.io/protocol.html << perfect of example of "blockchain engineering"
dulapbot: Logged on 2021-07-05 11:40:50 punkman: p2p net is for thinking men strictly << so 10 of 20 unpeer vex, his packets keep being relayed, the 10 that unpeered vex, now have to block relayed vex packets, or else their "unpeering" does nothing. If they do, then we have situation like /ignore. You see people having monologues, when they are talking to vex.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-05#1042848 << i gotta bite this : 'the 10 that unpeered vex, now have to block relayed vex packets' is not factual; the 10 have to a) unpeer the people who continue to relay'em b) live with killfile filtration c) there neither is nor ought to be a (c).
dulapbot: Logged on 2021-06-18 18:35:02 asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
dulapbot: Logged on 2021-07-05 10:45:13 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-05#1042780 << indeed, if you want to go beyond killfiling, and not see ~any~ conv. the fella was part of, would have to no longer be part of a net where others peer with him. this is, yes, a different experience than traditional 'palace' irc. i'm willing to live with it.
punkman: p2p net is for thinking men strictly << so 10 of 20 unpeer vex, his packets keep being relayed, the 10 that unpeered vex, now have to block relayed vex packets, or else their "unpeering" does nothing. If they do, then we have situation like /ignore. You see people having monologues, when they are talking to vex.
asciilifeform: the major open q is what to do with messages relayed by a peer which do not correspond to an entry in one's wot config. there are 2 obvious variants : 1) drop 2) display, with 'parens' (see upstack) or similar marking.
asciilifeform: so instead of symm.encryption, you have shared key play the role of 'S' ^ above. result is that you have 'unopposable' authentication between you and peer -- either can craft a message which purports to be ~to~ him ~from~ the other; but strictly within that relationship.
asciilifeform: a network where erryone is direct-peer to erryone will result in no 'rumour' messages displayed to clients, with the exception of a case where a direct-msg packet is lost.
dulapbot: Logged on 2021-07-05 10:41:59 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-05#1042779 << a++ q. folx will exchange shared key over pgpgram, where, naturally, signed. so a ~direct~ message from a peer is reasonably known to be authentic. indirect (relayed) imho oughta be displayed with a mark denoting this, e.g. '(asciilifeform): kick me' etc.
dulapbot: Logged on 2021-07-05 07:31:58 punkman: the answer I've seen is "just unpeer vex". and what does it mean to "unpeer vex"? wouldn't all the peers have to "unpeer vex"
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-05#1042780 << indeed, if you want to go beyond killfiling, and not see ~any~ conv. the fella was part of, would have to no longer be part of a net where others peer with him. this is, yes, a different experience than traditional 'palace' irc. i'm willing to live with it.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-05#1042779 << a++ q. folx will exchange shared key over pgpgram, where, naturally, signed. so a ~direct~ message from a peer is reasonably known to be authentic. indirect (relayed) imho oughta be displayed with a mark denoting this, e.g. '(asciilifeform): kick me' etc.
punkman: the answer I've seen is "just unpeer vex". and what does it mean to "unpeer vex"? wouldn't all the peers have to "unpeer vex"
asciilifeform: verisimilitude: imho the practical 'direction to dream in' there would be to select for yerself peers w/ correct grammar etc. but naturally q is b/w you and odin.
asciilifeform: the answer to these is to not peer w/em.
asciilifeform: this is a problem b/w you and peers.
asciilifeform: i don't give a shit if 2 messages ~visually~ duplicates. if you catch your peers sending these, the thing to do is to ask'em to stop, and if they do not, unpeer'em.
dulapbot: Logged on 2021-06-18 18:35:02 asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
dulapbot: Logged on 2021-07-04 19:40:17 punkman: so each peer has logical clock. when it wants to send message, it increments own clock, then makes a list of own clock and last observed clocks of N other peers. then send msg + list-of-clocks. When you receive msg, you check if your last observed clock of those N peers equals list-of-clocks. If not, you wait until you get the missing messages,
punkman: I don't want total order. I guess each peer sending only its own logical clock, will work ok. But again peer must delay sending alf's msg #5 before alf's msg #4 to irc client.
punkman: flood fill in the peer network? peer only delays sending to irc client, can push immediately to other peers
punkman: so each peer has logical clock. when it wants to send message, it increments own clock, then makes a list of own clock and last observed clocks of N other peers. then send msg + list-of-clocks. When you receive msg, you check if your last observed clock of those N peers equals list-of-clocks. If not, you wait until you get the missing messages,
dulapbot: Logged on 2021-07-04 16:02:13 asciilifeform: re: 'hour in the past' -- i'd rather use per-peer incremented counters, rather than political time (which introduces ye olde sync question)
punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-04#1042524 << the universal pill is: master does the ordering for all peers. which is of course not p2p. As an example, paxos,raft and other such "consensoos" algos, then add "if master dies, elect new master" on top of that.
asciilifeform: punkman: i imagine it'll get a little annoying when each peer is on different planet. but i do not expect to find us in this or similar situation any time soon.
asciilifeform: consider the typical case where your pathgraph to the bot is shorter than to the peer who issued the command. the bot will relay the command to peers, which includes you, before issuing its answer.
asciilifeform: for cutoff, i'd use simple algo: any message which passes the dupe litmus (i.e. not found in the circular buffer) but with a counter value 'older' than the oldest (optionally -- for-peer) message in the buffer, is rejected.
asciilifeform: re: 'hour in the past' -- i'd rather use per-peer incremented counters, rather than political time (which introduces ye olde sync question)
punkman: I think msg ordering is the gnarly problem in this. Suppose your peer gets a message with a timestamp of 1 hour (or 1 minute) in the past. Does it emit this to your IRC client as new msg? Suppose my peer has better connection to bot than alf, and I always get bot replies before whatever alf said that triggered the bot.
asciilifeform: what i'm proposing is much simpler, known as 'flood routing', where an incoming message, after determined to be authentic -- and novel (i.e. not equal to any of N previous received messages) is sent to all peers save for the one who brought it to begin with.
asciilifeform: in the most common form, peers randomly converse and sync a db of some kind ('do you have x?' 'no' 'here's x' etc)
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-07-04#1042466 << observe that irc peering already suffered from this.
asciilifeform: if that's how many you intend to directly peer with -- then yes
thimbronion: asciilifeform: Ah. And that would be with UDP for peers, and IRC emulation for clients?
dulapbot: Logged on 2021-06-18 18:35:02 asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
dulapbot: Logged on 2021-07-03 16:30:39 signpost: suppose you require that there is *some* WoT-peering-path for any rando that wants to talk with you (not unlike the +1 given to n00bs in the old days)
signpost: perhaps rando "discovers" difficulty by doing e.g. binary search upward, sends packets of increasing difficulty, until acknowledgement comes from you along WoT-peerings to him.
signpost: suppose you require that there is *some* WoT-peering-path for any rando that wants to talk with you (not unlike the +1 given to n00bs in the old days)
thimbronion: asciilifeform: I suppose this depends on exactly what 'current' implies. Will a peer's difficulty change often?
dulapbot: Logged on 2021-07-01 18:14:44 asciilifeform: was laying this out on chalkboard, and currently stuck on the puzzler of 'how do peers know 'the current difficulty' ?'
dulapbot: Logged on 2021-06-18 18:35:02 asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
gregory4: another way is to use network-history to seed a PRNG, and use that to give permission to a particular peer to determine the difficulty of the next epoch.
gregory4: let every peer manually troubleshoot his connection to every other peer. it is a one-time effort (per peer).
asciilifeform: gregory4: peer can't 'set own difficulty' because this would require answering packets which come in w/ insufficient pow
gregory4: the other way is simply for each peer to set his own difficulty in his configuration-file, and risk ostracism of other peers, if set too high.
asciilifeform was laying this out on chalkboard, and currently stuck on the puzzler of 'how do peers know 'the current difficulty' ?'
gregory4: asciilifeform: your product would basically listen on two ports: one for peers, and one for clients.
gregory4: server saves last N messages received from peers. refuses to pass on identical messages.
gregory4: assuming that you are able to turn off mandatory SSL for peering of "unreal," I could serve as bridge between "dulapnet" and "xrsenet" for a while.
gregory4: asciilifeform: oh, it only requires SSL for peering.
dulapbot: Logged on 2021-06-18 18:35:02 asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
snsabot: Logged on 2021-06-18 18:35:02 asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
asciilifeform: BingoBoingo: speaking of modern era, i rec to prep a box for peering w/ dulapnet. at some unspecified time undead-fleanode will croak.
asciilifeform: looks like peered w/ signpost's box, presently
dulapbot: Logged on 2021-06-18 18:35:02 asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
signpost: asciilifeform: thing claims we are peered now
asciilifeform: gregorynyssa: or how about where the thing disconnects machine operator rather than peers
asciilifeform: if a peer eggogs, disconnect peer.
signpost: cool, thimbronion and I are peered up
asciilifeform: trinque: i built 3.0.9 from src, but did not even make it to attempt at peering, got stuck in earlier setup
trinque: it's weird that I was able to peer my two instances with no problems, but others had this problem with the SERVER command
gregorynyssa: I was able to get peering working with thimbronion, with him using ratbox, and myself using another IRCD.
gregorynyssa: asciilifeform: there is an error in the peering code of ratbox, version 3.0.10.
asciilifeform: *UNPEER (ip)
asciilifeform: anyways to complete the thread: oughta support, optionally, two more hypothetical commands, PEER (ip) (pw) and UNPEER (io). self-explanatory. but can do w/out these, edit configs with hands.
snsabot: Logged on 2021-06-18 18:35:02 asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
dulapbot: Logged on 2021-06-19 11:53:05 signpost: http://logs.nosuchlabs.com/log/asciilifeform/2021-06-18#1039960 << the flatness here supposes equals among freely-associating peers, not all-comers.
signpost: http://logs.nosuchlabs.com/log/asciilifeform/2021-06-18#1039960 << the flatness here supposes equals among freely-associating peers, not all-comers.
signpost: minimal standard is best standard when coordinating among friendly peers; no need to tell billymg what to do in his house if the parties don't spill into my wine cellar uninvited
dulapbot: Logged on 2021-06-18 14:22:20 asciilifeform: PeterL: my other notion is that erryone who wants to be taken seriously oughta run a relay & peer w/ others.
asciilifeform: Aerthean: you wouldn't want to park secrets on a vps, but in this case the secrets (peering creds) aint very valuable.
asciilifeform: ... and someone to peer with.
asciilifeform: net participants only have reason to care re who is transmitting garbage (and to certain degree can mute it w/out unpeering, as w/ 'killfiles' on good ol' usenet)
asciilifeform: if he starts spamming/flooding , yer peers politely ask you to drop him.
asciilifeform: at the risk of repeating myself -- no 'policies' either, at any level beyond individuals and their personal preferences for which others to peer with.
asciilifeform: the troo p2p topology i propose removes all kindsa fundamentally palace-flavoured concepts -- 'joining', 'kicking', 'banning' -- and replaces simply w/ freedom of association, i.e. peering & unpeering.
asciilifeform: btw this is a golden time to point out that even THIS doesn't have to be 'world standard for all time' -- simply, any two relays who want to peer will have to agree on certain constants.
asciilifeform: no 'users', ideally, similarly, just peers.
asciilifeform: who is careless and tolerates spamola, etc. -- will get unpeered by his peers.
asciilifeform: who wants to be on it -- let him bake a relay & find peers.
asciilifeform: PeterL: my other notion is that erryone who wants to be taken seriously oughta run a relay & peer w/ others.
signpost: alrighty, I've got two of these things peered, was easy
asciilifeform: signpost: pretty surprising, tbh erry irctron i came across was either a massive deps hog or barebones to the point of 'i could write this in a day, but it won't even peer b/w machines..'
signpost: will let y'all know later how peering more than one together goes
signpost: at least this situation of peered servers among WoT is better than freenode
asciilifeform: individual people operate relays; peer by mutual agreement; like in '89.
asciilifeform: i expect we'll have additional peers in this net in near future but probably not this wk.
asciilifeform: currently asciilifeform's priority for this item is to get a peer ~outside of asciilifeform's dc~ -- given as irc is my primary means of contact w/ subscribers.
asciilifeform: a minus of irc is that peering requires a somewhat laborious process for each link; and my understanding is that also relies on sslism.
asciilifeform: trinque_ (and other not-poor folx who have colo boxes in various geography) lemme know if want to peer w/ it
snsabot: Logged on 2021-06-13 14:40:07 whaack: But tbh I don't understand how trb finds peers. I just restarted trb again with the command: LC_ALL=C /home/whaack/v/trb054/bitcoin/build/bitcoind -daemon -logtimestamps -myip=$myipd -verifyall &
shinohai: I do have termux on this stupid phone, and kinda weird because pulled random address above and ran `nmap -p 8333 --script bitcoin-getaddr 192.151.158.26` and it returns whole slew of prb peers it sees.
shinohai: Best I understand it, once you connect to another node it will run 'getaddr' to find other peers and add 'em.
whaack: But tbh I don't understand how trb finds peers. I just restarted trb again with the command: LC_ALL=C /home/whaack/v/trb054/bitcoin/build/bitcoind -daemon -logtimestamps -myip=$myipd -verifyall &
snsabot: Logged on 2021-06-12 18:13:56 trinque: 100% agree that peerings with as many cryptographically-identifiable friendlies as possible is a good thing. plenty of old threads on lifting trb onto a hypothetically wotnet
trinque: 100% agree that peerings with as many cryptographically-identifiable friendlies as possible is a good thing. plenty of old threads on lifting trb onto a hypothetically wotnet
asciilifeform: 1 problem is that the protocol itself (where all newly-received blox are blindly force-fed to all connected peers) is extremely braindamaged/wasteful of bw
snsabot: Logged on 2021-05-09 15:01:20 billymg: and for me, just seeing that table sorted by len(peers) desc made it plainly, undeniably obvious that trb nodes are the only real nodes on the network
billymg: and for me, just seeing that table sorted by len(peers) desc made it plainly, undeniably obvious that trb nodes are the only real nodes on the network
billymg: in my results 2691 nodes returning a single (self) peer
billymg: not sure if this something you've observed before, where node returns only one peer in response to getaddrs, and that peer is self
billymg: asciilifeform: btw, reason i filtered those results only on peers > 1 is because all but handful of nodes returning only a single peer returned a non-self ip http://paste.deedbot.org/?id=ljL4
billymg: as if majority of nodes on network are in a sort of "client only" mode, receiving peers from this small group of mega spam nodes
billymg: what i found interesting is that only a handful of nodes on the network actually return peers
asciilifeform: billymg: really only makes sense to add ip to db once it answers at least once (rather than immediately when reported as peer)
billymg: have a look at some of the results http://paste.deedbot.org/?id=hG11 -- there's an interesting pattern wrt number of peers returned
billymg: ^ two nodes i noticed with some mega peer lists
watchglass: 208.94.240.42:8333 : reported peers: 211.43.8.168 212.129.56.216 213.89.176.153 213.109.238.156 217.7.247.90
watchglass: 208.94.240.42:8333 : reported peers: 176.9.59.199 178.62.8.113:8555 185.224.80.108 186.50.162.74 188.27.173.192 188.117.245.195 192.151.158.26 203.132.94.196 207.180.225.253 209.204.20.46
watchglass: 208.94.240.42:8333 : reported peers: 144.76.2.87 148.251.110.54 151.106.34.139 151.248.220.127 158.69.227.12:28643 162.213.248.233 162.253.153.211 164.68.119.129 165.227.162.81 167.99.179.226
watchglass: 208.94.240.42:8333 : reported peers: 108.200.255.200 109.154.60.29 109.236.91.236 110.54.204.195 113.67.179.132 113.116.177.17 113.218.232.232 114.95.53.8 116.202.227.86 143.202.160.10
watchglass: 208.94.240.42:8333 : reported peers: 94.199.173.120 95.33.255.238 95.216.243.138 95.217.41.235 95.217.194.209 96.48.243.148 96.255.161.23 97.93.59.56 101.108.11.131 106.250.188.106
watchglass: 208.94.240.42:8333 : reported peers: 85.214.185.51 85.230.75.30 87.97.114.233 87.103.14.238 87.123.131.50 88.99.209.230 91.181.52.200 92.98.201.80 94.23.248.168 94.172.162.192
watchglass: 208.94.240.42:8333 : reported peers: 71.231.145.228 74.129.229.9 77.166.83.167 79.76.72.5 79.248.104.219 80.218.199.202 82.73.208.95 82.79.58.192 84.115.141.72 85.212.186.167
watchglass: 208.94.240.42:8333 : reported peers: 51.75.149.207 51.89.47.219 52.64.105.31 64.225.74.47 66.27.81.90:8555 66.198.209.243 68.56.203.112 68.58.176.25 68.183.6.64 69.114.1.70
watchglass: 208.94.240.42:8333 : reported peers: 34.241.176.144 35.208.208.188 35.212.168.144 35.241.116.147 43.225.62.107 45.63.4.71 47.91.246.186:8334 49.176.168.68 50.34.167.217 50.45.232.189
watchglass: 208.94.240.42:8333 : reported peers: 1.32.107.130 2.132.145.76 3.34.4.73 3.89.143.143 5.9.48.243 5.188.56.61 23.253.164.224 24.182.52.147:8555 31.46.231.174 34.89.57.152
billymg: !w peers 208.94.240.42
watchglass: 82.79.58.192:8333 : reported peers: 212.83.35.173 213.93.176.58 222.135.176.219
watchglass: 82.79.58.192:8333 : reported peers: 189.121.172.220 190.220.16.92 192.151.158.26 192.166.219.200 195.201.95.119 198.245.60.212 205.134.172.26 206.189.23.60 206.189.32.48 212.51.146.55
watchglass: 82.79.58.192:8333 : reported peers: 159.65.132.97 162.144.35.84 163.158.202.112 165.227.145.138 167.71.11.57 176.9.28.155 176.9.104.69 176.196.98.66 185.210.224.102 188.191.103.67:6333
watchglass: 82.79.58.192:8333 : reported peers: 104.194.9.86 138.68.237.102 140.82.62.166 144.76.82.16 145.239.0.81 145.239.103.151 148.251.87.112 149.202.83.78 152.168.235.3 158.181.73.151:8555
watchglass: 82.79.58.192:8333 : reported peers: 85.193.135.111 87.184.58.233 88.214.57.95 91.237.77.5 94.130.69.46 94.174.64.12 95.33.255.238 98.109.159.216 103.99.170.198 103.239.19.142
watchglass: 82.79.58.192:8333 : reported peers: 69.139.69.253 70.131.38.109 75.56.8.205 77.56.68.181 78.46.191.14 78.199.108.157 79.76.72.5 79.98.105.138 81.236.246.232 82.118.17.190
watchglass: 82.79.58.192:8333 : reported peers: 54.199.164.163 58.158.0.86 59.1.12.35 62.210.132.30 63.227.116.162 63.250.36.66 64.225.19.231 64.227.10.167 68.58.176.25 68.115.150.3
watchglass: 82.79.58.192:8333 : reported peers: 47.98.38.66 47.99.158.238 47.108.21.116 47.108.30.126 47.205.77.147 50.5.46.195 50.53.250.162 50.125.240.9 51.77.226.110 52.169.238.66
watchglass: 82.79.58.192:8333 : reported peers: 35.200.167.38 35.208.208.188 35.245.143.50 37.187.117.135 41.96.234.48 46.20.2.222 46.27.209.139 46.101.249.7 47.5.170.67 47.89.21.168
watchglass: 82.79.58.192:8333 : reported peers: 32.214.183.114 34.70.138.19 34.74.24.33 34.84.70.7 34.91.188.86 34.122.17.53 34.125.190.73 34.218.45.5 35.181.8.232 35.199.65.64
watchglass: 82.79.58.192:8333 : reported peers: 2.132.145.76 3.16.37.222 5.9.13.37 5.9.155.73 13.210.184.202 15.164.181.146 15.207.108.70 23.251.64.80 24.182.52.147:8555 27.102.115.132
billymg: !w peers 82.79.58.192
billymg: this can be used for debug/investigative purposes, and the proggy uses it to determine a "version message strategy" (i.e. whether or not it includes the prb byte and which self version it advertises) to coax peers out of the interrogated node
billymg: i'm also now storing the last list of peers returned by each node as a step towards being able to build a graph of the network
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)
asciilifeform: billymg: you'll want to consolidate the version & peers thing into 1 session.
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)
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: 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
asciilifeform: this of course strictly if the peer answers.
asciilifeform: given as any publicly-reachable node can be polled for peers, and for height, inventory; and some do answer
billymg: actually not 100% true, these 3 gave a single peer result (itself): http://paste.deedbot.org/?id=LfmO
billymg: but i ran against a hundred or so prb nodes and none were returning peers when advertised version was set to '99999'
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
asciilifeform: in my (undeployed) variant where polling of prb for peers, it happens only if trb-style poll returns 0 peers
asciilifeform: billymg: really 'trb heuristic' has to be about ~avoiding~ certain behaviours -- e.g. if peer triggers 'malleus' -- it aint trb. etc
asciilifeform: billymg: the 'proof of the pudding is in the eating' -- if a peer behaves ~precisely~ like trb, then for all practical purposes it is indistinguishable. so far not found any that do this but not advertised as trb useragent.
asciilifeform suspects that all kinds of custom proggies in the wild present heathen-like useragent, simply to fool crawlers and whatever other heathen peers
billymg: asciilifeform: yeah, for 'peers' cmd -- good to know
asciilifeform: billymg: the 'peers' cmd ? correct
billymg: perhaps that's why so many are returning 0 peers
asciilifeform: it makes for illusion of '0 peers' when polling'em
asciilifeform: (specifically in 'peers' cmd)
billymg: i started with a seed list of the nodes that you poll in this channel, and all the rest have been grabbed from running peers recursively
asciilifeform: billymg: i rec to look at the 'peers' knob, can use it to recurse.
adlai occasionally wonders whether the editors of mathematical textbook publishers actually go through the book as though they were students, instead of merely weighing it, estimating its relative beauty on various possible shelves, and farming out 'peer review' to their rolodex
snsabot: Logged on 2021-02-26 21:26:14 asciilifeform: shinohai: the 1 on lulazon took almost 30m to find the peers
shinohai: http://logs.nosuchlabs.com/log/asciilifeform/2021-02-26#1032507 <<< still was unable to find peer after leaving open overnite, so guessing gonna hafta try from "seedbox" server when I have chance.
asciilifeform: shinohai: the 1 on lulazon took almost 30m to find the peers
asciilifeform: verisimilitude: afaik only carries dht peer tracking via udp. (and even this, optional)
asciilifeform: dpb: does your client permit manual adding of peer ?
dpb: yes i am leeching, and i'm only getting it from one peer/seed -- am i configured wrongly?
shinohai: magnet:?xt=urn:btih:SUA4AWPBH6EOF6RYVHKOVBNPOVAYTAAK&dn=trbdb&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce <<< shows 1 peer, 1 seeder indeed.
asciilifeform: i expect depends heavily on your isp / its peerings
trinque: I would expect peer nodes with high ratings to begin collaborting more often, proceed longer, etc
snsabot: (therealbitcoin) 2020-05-15 asciilifeform: wrote 'aggression' patch. which seemed to help (changed logic to 'ask for blocks' at time new peer connects, rather than the idiot bootup )
trinque: at any rate, I'll happily fix anything wrong with deedbot. atm I'm wrapping my gourd around luby and raptor coding, would like to end up with an item that fires udp or raw IP packets of either directly to friendly peers, in place of IRC.
mats: maybe its a peer group peculiarity, i dunno. i've had a lot of photos taken of me without explicit consent, and that's fine even in this context because i'm not an interesting target for stalking. but i could see it becoming a problem for people i know
asciilifeform: PeterL: this already happens : "ProcessBlock() : already have block %d %s from peer %s"
PeterL: so would it save time to have a list of hashes of recent blocks checked so it would not try verifying the same new block from all the peers? Or would that not save anything?
snsabot: (trilema) 2019-07-18 a111: Logged on 2018-10-30 18:16 asciilifeform: more interestingly, there was even 1 of 10/30/18 17:05:41 ERROR: ProcessBlock() : CheckBlock FAILED from peer 213.148.193.153
asciilifeform: l. receive any other blocks, and connection to peer often breaks.
asciilifeform: cgra: there are 3 afaik main headaches in sync w/ current trb. (1) unsolicited 'latest' blocks occupy bandwidth, and are sent by ~all peers at ~all times. (2) peers do not reliably continue feeding next-needed-block in response to 'aggressive' PushGetBlocks (3) trb is effectively single-threaded; gets $block, then can pause for up to 3min during which cannot do anything, inc
snsabot: Logged on 2020-08-25 07:47:22 cgra: 3) if parallel sync is desired, some kind of buffering must be reintroduced - perhaps just the block hashes the source peers advertise in their "inv" responses. i have no obvious fix to offer, i just wanted to get this out sooner rather than later.
cgra: 3) if parallel sync is desired, some kind of buffering must be reintroduced - perhaps just the block hashes the source peers advertise in their "inv" responses. i have no obvious fix to offer, i just wanted to get this out sooner rather than later.
snsabot: Logged on 2020-08-17 13:28:43 trinque: re: IRC, I don't imagine there are no improvements left to be made, but it'd also be mighty nice to get our own network peerings going before long, rather than relying on e.g. fleanode.
trinque: re: IRC, I don't imagine there are no improvements left to be made, but it'd also be mighty nice to get our own network peerings going before long, rather than relying on e.g. fleanode.
mats: maybe you need more peers
watchglass: asciilifeform: my valid commands are: src, uptime, help, probe, peers, version, poll
asciilifeform: (and don't get advertised as peers by peers)
snsabot: Logged on 2020-05-06 14:28:35 asciilifeform: !w peers 205.134.172.27
asciilifeform: ^ trb nodes. (by no means all, simply the ones asciilifeform's nodes peer with.) none of'em support, or will ever support, 'ln', 'segwit', etc.
asciilifeform: btw updated 'watchglass' page w/ vpatch corresponding to currently-deployed bot (w/ 'peers' cmd.)
watchglass: asciilifeform: my valid commands are: src, uptime, help, probe, peers, version, poll
watchglass: 205.134.172.27:8333 : reported peers: 203.129.27.87 208.94.240.42 213.109.238.156
watchglass: 205.134.172.27:8333 : reported peers: 174.114.124.12 177.74.189.121 177.96.224.194 177.206.254.253 178.14.17.17 179.113.85.13 190.177.114.36 192.164.247.23 194.14.246.200 199.247.7.208
watchglass: 205.134.172.27:8333 : reported peers: 77.8.57.5 78.99.137.154 78.110.73.83 83.99.245.20 91.45.93.126 91.134.145.202 91.219.25.232 92.117.182.4 93.6.41.59 142.196.232.55
watchglass: 205.134.172.27:8333 : reported peers: 18.141.160.175 23.239.0.21 31.48.249.2 34.219.185.136:9595 34.220.232.128 46.88.183.195 46.229.165.143 65.96.222.54 69.118.65.228 71.34.1.183
asciilifeform: !w peers 205.134.172.27
asciilifeform finds it pretty handy, not only for monitoring own nodez, but to determine whose nodes actually work, and makes sense to peer with
asciilifeform: ideal building block , is a box w/ 2 nic jacks, 1 eats gb/s from firehose (heathen net) and other emits only what passed 1+2+3 , to preconfig'd list of peers. ideally over a separate physical pipe indep. from the former's.
jurov: There is vpatch as peer-reviewed development system, how to best grease it.
asciilifeform: config a set of pubkeys and a set of peers. when any of the latter have new material, $node loads, verifies, and interns it.
asciilifeform: another thing prb apparently doesn't do, is to discard old/dead peers from its addr set.
asciilifeform: what it doesn't do, is bring in peer addrs
asciilifeform: ( which would explain why folx who set their trb to advertise 7xxxx do not see perceptibly moar peers )
asciilifeform: one could say that peers who don't appear on such a listing, are strictly 'downstream', i.e. being connected to'em does nothing for you
asciilifeform: shinohai: my interest in this whole thing is to eventually map out all publicly-networked trb-compat. noades. but this might require being able to get peers from prbistic ones.
asciilifeform: (this means trb won't get peers from node of that type either)
asciilifeform: interesting. evidently it breaks protocol (i.e. trb's traditional one) somewhere, and gets hung up before emitting any parseable peers to 'watchglass'
asciilifeform: !w peers 187.115.249.96
asciilifeform: ( they returned 'empty' on 'peers' )
shinohai: http://logs.nosuchlabs.com/log/asciilifeform/2020-03-01#1008171 <<< not in some time, the !w peers cmd jogged my memory and made me remember that. Might be interesting to pull some prb ip's from trb debug.log and see what it returns.
watchglass: 205.134.172.27:8333 : reported peers: 111.242.11.215 116.85.55.129 143.202.160.10 149.233.173.179 162.247.100.93 178.8.88.227 178.11.45.211 188.193.117.32 188.232.116.225 198.48.229.200
watchglass: 205.134.172.27:8333 : reported peers: 86.135.81.125 87.10.131.129 88.217.125.21 89.0.105.30:8334 91.3.79.239 92.117.141.243 93.137.206.222 95.216.227.92 98.249.119.108 103.36.92.112
watchglass: 205.134.172.27:8333 : reported peers: 5.167.252.144 24.5.66.79 24.84.54.120 24.140.234.183 46.239.18.87 62.158.241.149 77.185.51.107 82.207.206.210 84.133.124.10 84.184.252.242
shinohai: !w peers 205.134.172.27
asciilifeform: the q is, does prb in fact have some entirely incompat. means of same thing -- or is given peers strictly from gavin hq.
asciilifeform: 'watchglass' speaks deliberately only the protocol spoken by trb. so if it dun get peers from a $node -- trb won't either
asciilifeform: the mega-q is : where the fuck does a prb noad get peers ?
asciilifeform: he Internet from which you don't have many other peers). Previously, Bitcoin Core banned the IP addresses of misbehaving peers for a period of time (default of 1 day)...' )

|