PeterL: In section 3.1, where you discuss breaking a long message into two messages, correct me if I am wrong: these are not going to get reassembled back into one IRC message by the receiving peer, they get transmitted to the console as two IRC messages?
asciilifeform: apeloyee: some of the things you mentioned (e.g. messages signed 'for' one peer but also, 'on outside of envelope', 'for' another, to be relayed) are arguably useful. and i thought about them. but they are ~costly~ in complexity. moving parts are a cost, and not counting this cost is why literally every traditional high-level protocol, starting with tcp, is garbage, imho.
asciilifeform: and if a station is destroyed, it all has to be done again. for each peer.
asciilifeform: apeloyee: it is presumed that you ~always~ can contact any peer out of band (i.e. outside of pest)
apeloyee: l2 compromise shouldn't mean you disconnect your peer (and lose the ability to talk to him). I'll think if your fix is enough.
asciilifeform: apeloyee: the 1st thing you'd do is to set max-bounces to 1. then talk to the peer who was relaying liquishit.
apeloyee: btw. let's say a station in your L2 is compromised and starts to send mountains of garbage. what now, disconnect all common peers?
asciilifeform: apeloyee: how would you have the station decide when to start sending these sandwiches to one peer, rather than the usual kind to all ?
apeloyee: high packet loss, say >70% (i.e. DoS). if you include MACs over plaintext for all (or some subset thereof) your peers, *in addition* to primary one over ciphertext, you can get auth'd packed out, even via an untrusted peer
asciilifeform: apeloyee: it isn't that i can't picture a situation where a simple proxy (eats packets from $ip1, forwards to $ip2, and vice-versa) is useful; but i don't see why to make it part of pest, complicating the protocol and creating multiple types of peering
apeloyee: right. Why shouldn't there be "peers" which are only trusted to relay auth'd material from *actual* peers? (as a way to have lots of IPs, as you suggest).
asciilifeform: apeloyee: the way to have petrol tank that aint full of holes -- machines that cannot be brought down by arbitrary liquishit pumped in at line rate -- is to give NOTHING to the stranger. i.e. you're not in the peer set ? you don't even get ping answer. there is no other way.
apeloyee: I meant that not-trusted *direct* peers are routinely used to relay stuff. the internet works that way, in fact. but not Pest.
dulapbot: Logged on 2021-09-19 16:24:26 apeloyee: so, Pest isn't designed to operate under high packet loss, or with peers trusted only as far as you can throw them. what else?
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-19#1058690 << the second clause also not factual -- you can communicate with 'not trusted further than you can throw' fella ~for so long as one of your peers~ (or your peer's peers, up to $depth) peers with him.
asciilifeform: (you get packet with 'selfchain' which doesn't correspond to the predecessor -- you issue getdata to the peer)
apeloyee: so, Pest isn't designed to operate under high packet loss, or with peers trusted only as far as you can throw them. what else?
punkman: asciilifeform: I got a poorly defined bit from spec "the AT is automatically updated by the station when a cryptographically-valid packet is received from a new address.". If you update AT just after verifying crypto, but not checking for dupes, wouldn't that mean I can send you replay from new ip and essentially blackhole any peer?
apeloyee: you don't bother to verify unless in message MAC'd by peer.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-19#1058631 << this is correct, but explicitly handled -- a massively ddosed line will simply look like a very slow and lossy modem from the peer's pov. because the garbage does not impose any additional cost other than occupying bw.
apeloyee: Transmitting an RSA signature in addition to MAC, as discussed a few days before? We have established that to big traffic goes through relays, so the assumption that you can RSA-verify everying your peers transmitted to you is quite reasonable
dulapbot: Logged on 2021-09-19 15:40:28 apeloyee: Blocking huge ranges of IP addresses is S.O.P. here. And your protocol requires me to trust the peers then.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-19#1058630 << what would a protocol that ~does not~ 'require trusting the peers' look like ?
punkman: apeloyee: simple file transfer would be more like direct message to single peer
apeloyee: finally, using this for large file transmission looks stupid. (it will just clog your pipe, transmitting the same thing to each of your peers; worse than bittorrent in that regard)
apeloyee: Blocking huge ranges of IP addresses is S.O.P. here. And your protocol requires me to trust the peers then.
asciilifeform ftr thinks that a scenario where you can only -- and for appreciable length of time -- contact one or two of your peers -- is sufficiently exotic, and dire, that your text oughta consist of a gpggram informing yer wot that you're stuck in war zone, or the like
asciilifeform: as for indirect messages, so long as you can reach a ~subset~ of your peering -- yer in biz.
asciilifeform: what does apeloyee suppose is the meaning of 'peer, but no direct connection' ?
asciilifeform: if he's your peer, you have a direct connection definitionally. and vice-versa.
apeloyee: I'm talking about peer you don't have direct connection to
asciilifeform: conversely, if someone is no peer of yours, you have no shared key with which to mac with him
asciilifeform: and if you have a shared key with someone, and can use a mac, that person is a peer of yours
asciilifeform: you still need 1 per peering
asciilifeform: can add, delete peers, issue SCRAM and wipe 100% of own storage.
asciilifeform: if the drive is stolen, drowned, or burns down, you gotta rebuild your peerings.
asciilifeform: this is important esp. in a protocol with rekeys, where in fact you lose your peerings if you lose storage. and cannot be backed up meaningfully.
asciilifeform: bomolochus: the way asciilifeform sees it, some items (i.e. per-peer packet counters) may be volatile; others -- may not. specified which may not.
asciilifeform: punkman: i can't think of very many uses for a signed chat where the signing doesn't help against the gnarliest problems of 'is this genuine packet? should i flood it to peers?' etc
asciilifeform: aaaand this'd be ~in addition~ to the key-for-every-pairing-of-peers chore !
dulapbot: Logged on 2021-09-16 06:29:31 punkman: having pubkey per peer also gives us collision-free speaker identities, and automatic symmetric keying
punkman: having pubkey per peer also gives us collision-free speaker identities, and automatic symmetric keying
dulapbot: Logged on 2021-09-15 14:40:37 PeterL: would the getdata only be for things that peer had said, or for any data? IE, would I only be required to hold onto my own history, rather than keeping everything I had ever seen?
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058228 << stations oughta answer getdatas on a 'cycles available' basis. in principle very little will be lost if ~no one~ answers'em, you will simply have a very small amount of outright lossiness. and very little ability to follow unbroken chains if your/peer's uptime aint 100%.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058233 << mno. you getdata on the self/net chain of your last packet received (in the case of (a) -- from anyone on your net; in the case of (b) -- from the peer in question.)
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058231 << you keep at minimum 30min of log, separately, for a) your net b) direct (priv.) messaging sessions w/ each peer.
dulapbot: Logged on 2021-09-15 14:40:37 PeterL: would the getdata only be for things that peer had said, or for any data? IE, would I only be required to hold onto my own history, rather than keeping everything I had ever seen?
PeterL: would the getdata only be for things that peer had said, or for any data? IE, would I only be required to hold onto my own history, rather than keeping everything I had ever seen?
asciilifeform: ... and imho oughta be done; the price is small, while the gain (read log to beginning of time! for so long as even 1 peer has it and willing to answer) is substantial.
asciilifeform: each such peer counted is effectively equivalent to that msg carrying that peer's sig.
asciilifeform: anyways i utterly , thoroughly fail to grasp the point of this horror show, when one can simply print the # of peers who duped-with-bounces==1 a given hearsay. as detailed yest.
punkman: 1 in 100 false positive with 100 people, means if I generate message+random bloom filter, I need to send to ~100 peers for 1 to believe in forgery, then you can also add in that "bogosity" measure
asciilifeform: the crypto is to function identically regardless of # of peers. or it's hokum.
asciilifeform: right now the only limit for peer count is how many cpu cores you can spare
asciilifeform: punkman: likely not. but not prepared to say 'well you oughtn't have moar than x.. and btw probability of forgery will go up geometrically with # of peers'
punkman: do you suppose you will ever have 500 peers, meaning 500 people with GPG keys, and exchange secrets with all of them?
punkman: not great for 500 peers
dulapbot: Logged on 2021-09-14 08:16:50 punkman: so Peer3 must be able to verify that the Bloom filter has a small enough false positive rate
asciilifeform: if i have 500 peers, and the aggregate is only 4x larger than a standard hmac, what do you suppose will happen.
dulapbot: Logged on 2021-09-14 05:20:19 punkman: suppose we put an HMAC(Message) next to Message in Red Packet. Maybe Peer1 can somehow aggregate one HMAC for each of his peers, into a single HMAC(Message) that doesn't take up N*64 bytes
punkman: so Peer3 must be able to verify that the Bloom filter has a small enough false positive rate
punkman: if Peer2 wants to send "Peer1 says he luvs cock" to Peer3, he could generate a filled up bloom filter with a XX% false positive rate, and then HMAC(K3<->1, FakeMessage) will pass the test XX% of the time.
dulapbot: Logged on 2021-09-13 14:25:56 asciilifeform: punkman: say asciilifeform has peers a,b,c. punkman has peers x,y,z. asciilifeform and punkman became peers.
PeterL: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-13#1057913 << RE. handle collisions: you can ask politely that one of the two change their name, but iiuc that would require setting up new connections with each of their peers?
punkman: so new peer can only getdata directly from you, and doesn't even need the inner AGGREGATE-HMAC to verify it's coming from you
punkman: now if you peer with a new person and he tries to getdata, neither you or other peers can send him the old packets, they must be reground by original speaker so AGGREGATE-HMAC includes HMAC for the new peer.
punkman: maybe Peer1 can make a Bloom filter that can hold (number of peers)*2 64byte strings, he calculates HMAC(K_N, Message) for each peer, puts it in Bloom filter, and uses that as the AGGREGATE-HMAC
punkman: now Peer2 can forward Peer1's message to Peer3, and Peer3 checks for "is HMAC(K_1, Message) in AGGREGATE-HMAC(Message)", and can thus verify that the forwarded message was indeed signed by Peer1
punkman: suppose we put an HMAC(Message) next to Message in Red Packet. Maybe Peer1 can somehow aggregate one HMAC for each of his peers, into a single HMAC(Message) that doesn't take up N*64 bytes
dulapbot: Logged on 2021-09-13 14:36:02 punkman: if we forget about packet size limitation, I suppose message could contain N encrypted copies, one for each peer, and hearsay broadcast now has meaningful sig for recipient, even if not received directly
asciilifeform: nao a forgery would need to be injected via the peripheral (i.e. non-common) peers of N of your peers ~simultaneously~, to have a shot of fooling you.
asciilifeform: 4) if this number is 3 or less, the message is displayed in the format e.g. ' asciilifeform(cgra,signpost,punkman): .... ' where the handles in the parens are the peers who sent in the bounces==1 hearsay copies of the msg
dulapbot: Logged on 2021-09-13 16:38:33 asciilifeform: in fact already specified this in 4.1.2.2.2. In-WOT Hearsay. simply, now also count the # of peers from whom got bounce<=1 dupes of a given msg.
asciilifeform: 3) within this interval, the number of distinct peers who sent a bounces==1 duplicate of the message is counted.
dulapbot: Logged on 2021-09-13 16:28:23 asciilifeform: per this lemma, you now have a useful number associated with any hearsay message : the # of peers from whom a dupe of said message , having bounce <= 1, was NOT received.
asciilifeform: 1moar refinement to the scheme -- only count as bogowitnesses (peers who did NOT bring a dupe of the hearsay msg) such peers as, within last 15m, have sent in ~anything~ (let's define'em as 'online'.)
asciilifeform: and imho entirely appropriate. want folx to see low bogometer reading? peer with moar people in that net.
asciilifeform: ... if you got ~more~ dupes than you have peers, you now know that you have a traitor in your wot, who sent a bogon with bounce==0.
asciilifeform: in fact already specified this in 4.1.2.2.2. In-WOT Hearsay. simply, now also count the # of peers from whom got bounce<=1 dupes of a given msg.
asciilifeform: but if in fact one of, say, shinohai's camwhores is impersonating asciilifeform , you will see ' asciilifeform(shinohai)(-12) ' supposing you have 13 peers.
asciilifeform: e.g. in this example, if you received gen1 dupes of the msg from all but 2 of your peers, you will see e.g. ' asciilifeform(signpost)(-2) : ... '
asciilifeform: if this number (call it B... bogosity?) != 0, it is displayed in parens following the handle(peer) string.
asciilifeform: per this lemma, you now have a useful number associated with any hearsay message : the # of peers from whom a dupe of said message , having bounce <= 1, was NOT received.
asciilifeform: lemma : a station can only receive as many duplicates of message M, such that have a bounce==1, as it has peers.
dulapbot: Logged on 2021-09-13 14:25:56 asciilifeform: punkman: say asciilifeform has peers a,b,c. punkman has peers x,y,z. asciilifeform and punkman became peers.
asciilifeform: punkman: returning to your 'fishing' example -- one way to distinguish a genuine from a squatter broadcast is that the latter will nearly inevitably get relayed by ~only one~ peer
asciilifeform: ... in the above case, the genuine and the sham are at least in ~some~ way distinct. but suppose that both are connected to the net via same peer !
asciilifeform: i.e. without authenticable (in any sense) hearsay, we have a star topology again. where the only packets that can have any meaning are such that are sent between direct peers.
asciilifeform: meanwhile packets from cgra are able to reach asciilifeform's entire net. cgra has a peer 'nebuchadnezzar', who is not a peer of asciilifeform or anyone else currently on dulapnet. nebuchadnezzar is peer with shalmaneser, who also not peer w/ anyone else. the latter decides to impersonate asciilifeform.
dulapbot: Logged on 2021-09-13 14:25:56 asciilifeform: punkman: say asciilifeform has peers a,b,c. punkman has peers x,y,z. asciilifeform and punkman became peers.
punkman: SG tells me that one from group signed the hearsay, but I already know this, peer signed and peer is from group
asciilifeform: punkman: the commitment would be impervious for direct peers, and ~pretty good~ for indirect
asciilifeform: ... K gets an additional 256bit component, G; and msgs get an additional 256b field, SG. G is shared with all peers; SG is HMAC signature using G. all of your peers can now authenticate (or impersonate) your hearsay.
punkman: it's the same problem again, so you commit to secret for next broadcast msg, the commitment only good for direct peers
asciilifeform: you somehow gotta be able to leverage the fact that direct-peer msgs are ipso facto authentic.
asciilifeform: even if packets could be MBs in size, this'd be nonsense, it doesn't scale to even coupla dozen peers
punkman: if we forget about packet size limitation, I suppose message could contain N encrypted copies, one for each peer, and hearsay broadcast now has meaningful sig for recipient, even if not received directly
punkman: if I join separate net, I don't bring peers with me
asciilifeform: punkman: say asciilifeform has peers a,b,c. punkman has peers x,y,z. asciilifeform and punkman became peers.
asciilifeform: i.e. zero useful communication except between direct peers.
punkman: we can only verify msg from direct peer, there is no magic way to verify hearsay for free
asciilifeform: ( a spec-compliant noad will not permit two+ direct peers having colliding canonical (i.e. recorded in WOT) handles. but is powerless to prevent the use of whatever handles, incl. colliding, in hearsay msgs )
asciilifeform: (this in re: hearsay -- messages directly received from a peer, with his handle in'em, are prima facie authentic)
dulapbot: Logged on 2021-09-12 20:20:15 verisimilitude: Storing encrypted messeges in the deduplication buffer is an obvious optimization; I've been thinking about per-peer deduplication buffers, but there doesn't seem to be justification for them.
verisimilitude: Storing encrypted messeges in the deduplication buffer is an obvious optimization; I've been thinking about per-peer deduplication buffers, but there doesn't seem to be justification for them.
dulapbot: Logged on 2021-09-11 23:58:05 asciilifeform: initial unpublished draft had 'addkey'/'rmkey' but i like the consistency of 'unkey'/'unpeer'/'ungag'/'unaka'
asciilifeform: the only point of the selfchain with direct peer is to be able to request a missing msg in the event of packet loss.
asciilifeform thinking further, there's 0 point to there being such a thing as a fork alert re a ~direct peer~.
asciilifeform: your peers notice that your self/net chains are outta sync. they request the missing msgs but lolno, because they're old.
billymg: asciilifeform: question re: spec, in 4.1.2.3, when a message is rebroadcast up to the bounces limit, does this include the originator of the message (who also receives an ACK/receipt)? or would it only be rebroadcast to every WOT peer excluding the originator of the message?
dulapbot: Logged on 2021-09-11 11:52:56 asciilifeform: and, relatedly: if we have ACKs, then possibly oughta reject in-wot hearsay pertaining to a 'live' peer, categorically ? (how then define 'live' ? when to accept in-wot hearsay again ?)
signpost: dunno it's undesirable. you have pretty good assurance that your buddy said w/e if you're directly peered.
signpost: with a direct peer, it seems I should be able, just like in a phone conversation that temporarily loses connection, "hey buddy, I lost ya for a moment. what did you say?"
signpost: when not peered with friends, better yeah, start from dawn of history
signpost: why not work backwards from what you're seeing in the present moment, assuming your peers are friends. which in this case they are.
asciilifeform: because otherwise, what, will embargo every incoming message from that peer, forever, until someone deigns to answer..?
asciilifeform: you gotta time it out at some pt and declare $peer forked, if can't get an unbroken selfchain for him w/ getdata
signpost: regarding forks, can I simply getdata my peers for the history I've missed?
dulapbot: Logged on 2021-09-11 11:51:15 asciilifeform: also reworking the 'fork' handling mechanism, in light of above -- simply because your station was switched off for a day does not mean that it oughta mark all yer peers as forked -- if it can successfully retrieve unbroken selfchains for all of'em
asciilifeform: i.e. unpeering w/out gagging will still have you picking up same thing as hearsay if even one peer still peers with $victim
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057666 << great question -- (UN)PAUSE is for a peer; (UN)GAG is for any message in general incl. hearsay. currently they're uncoupled, but possibly some kinda coupling is justified
dulapbot: Logged on 2021-09-12 12:16:13 signpost: asciilifeform: re-digesting pest. it comes to mind that were the station aware of wot ratings, it could weight the capacity it's willing to dedicate to each peering, but I think this is something to deal with once problem's had, if at all.
signpost: am I correct that PAUSE means "ignore the output of this peer and do not forward"?
signpost: I am more willing to dedicate repeater capacity to your packets than some newb I let peer up for the first time.
signpost: asciilifeform: re-digesting pest. it comes to mind that were the station aware of wot ratings, it could weight the capacity it's willing to dedicate to each peering, but I think this is something to deal with once problem's had, if at all.
billymg: i noticed that pattern also, but i thought it worked with 'peer' and 'pause' because those work as verbs, e.g. "to peer with someone" means to add them as a peer
asciilifeform: initial unpublished draft had 'addkey'/'rmkey' but i like the consistency of 'unkey'/'unpeer'/'ungag'/'unaka'
dulapbot: (trilema) 2014-06-10 asciilifeform: '...what I find among the modern novices is that they do not feel the same way about the experts -- they want an expert-free world where their ignorance is not painful, where their inexperience is not used against them, where they get all the jokes, where nobody uses literary references that elude them, where every one of their ideas is accepted by their peers as just as novel as they think it is...'
asciilifeform: and, relatedly: if we have ACKs, then possibly oughta reject in-wot hearsay pertaining to a 'live' peer, categorically ? (how then define 'live' ? when to accept in-wot hearsay again ?)
asciilifeform also reworking the 'fork' handling mechanism, in light of above -- simply because your station was switched off for a day does not mean that it oughta mark all yer peers as forked -- if it can successfully retrieve unbroken selfchains for all of'em
asciilifeform: (via third peer)
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057468 << asciilifeform agrees, tho with the proviso that at least 1 peer in a pair gotta have a reliable (and staticly ip'd) connection
dulapbot: Logged on 2021-09-11 04:27:35 punkman: if we add current timestamp to ping/pong, we can also see how close our clocks are with any given peer and possible emit msg to operator if clock difference is larger than X seconds
asciilifeform: (the AT is updated when a packet is received. and 'Ignore' packets will be received (tho i did not specify how often..) from every peer with a working connection)
asciilifeform: if at least one of a pair of peers has a static ip, it will never 'lose' the other
asciilifeform: be known to the other peer.']
dulapbot: Logged on 2021-09-11 03:51:43 punkman: asciilifeform: I think a ping-pong mechanism might be useful for Pest. Case: I start station up, ping all peers in Wot, if X or Y doesn't answer, I can go and look for their new IP address. Case 2: I have received no messages for a couple hours, I do "/ping ALL" and see if any stations are still online, if I need to reconfigure something, etc
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057449 << this, otoh, is quite unnecessary, on account of the AT mechanism -- recall, [http://www.loper-os.org/pub/pest/pest_FE.html#22-peers-and-keys]['Additionally, at least one of the peers must have a routable, static address (here and below: IPv4 address and port, in a.b.c.d:p notation), and it must
dulapbot: Logged on 2021-09-11 05:29:11 punkman: why not have hash of last msg from peer in "3.1.3.2. NetChain (Direct Messages)"?
punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-11#1057452 << meant last direct message from peer, in case it wasn't clear
punkman: why not have hash of last msg from peer in "3.1.3.2. NetChain (Direct Messages)"?
punkman: if we add current timestamp to ping/pong, we can also see how close our clocks are with any given peer and possible emit msg to operator if clock difference is larger than X seconds
punkman: asciilifeform: I think a ping-pong mechanism might be useful for Pest. Case: I start station up, ping all peers in Wot, if X or Y doesn't answer, I can go and look for their new IP address. Case 2: I have received no messages for a couple hours, I do "/ping ALL" and see if any stations are still online, if I need to reconfigure something, etc
asciilifeform: so long as one works -- you're linked with yer peers.
signpost: rather than per peer rates, one might think about a maximum bandwidth the entire node is permitted to use.
asciilifeform: the important thing to note is that a net of say 100 people will contain quite a bit moar (largely dupe) traffic than you'd ever want in your console -- but still useful for multipath propagation/resilience. so any per-peer rate limit must affect only console imho.
asciilifeform: unrelatedly, thought re introducing concept of a 'semi-peer' -- someone from whom ~only direct messages~ accepted, and to whom net broadcasts are not relayed.
asciilifeform: *per peer
asciilifeform: i.e. you don't, except indirectly, while choosing peers/wife
asciilifeform: imho the 'problem' of 'how do i keep my peers from spamming me' is rather like 'how do i prevent my wife from cutting my cock off while i sleep'
asciilifeform: if by 'profit' means 'all your peers unplug you within 5min' then yes
PeterL: actually, reading their comment more closely, a rogue peer would be someone not running per the spec and not putting in the correct selfchain field. I don't see how that would cause problems for anybody else though?
asciilifeform: the solution is to unpeer.
asciilifeform: as it is, i don't consider flooding by a peer to be a problem that needs a complex techno-solution;
asciilifeform: PeterL: one can easily rate-limit peers, but i left this outta the spec.
dulapbot: Logged on 2021-09-10 14:13:21 asciilifeform: can someone explain wtf a 'rogue peer' is supposed to be ?
PeterL: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-10#1057349 << rogue peer, I would guess, is enemy agent that has penetrated your wot, and wants to break your comunication system?
punkman has a "peerfinder" standalone proggy on todo list, will share in a few weeks
asciilifeform: ... someone you peered while his pistol in yer mouth ?
asciilifeform: can someone explain wtf a 'rogue peer' is supposed to be ?
asciilifeform: 'Can a rouge peer just come in, fork everyone, and leave?'
asciilifeform: as well as folx who simply can't read... 'I also don't see much DDOS proofing in this. Best I can find is that you can unpeer people, but since every message is rebroadcasted by everyone, that doesn't seem like much of a protection.'
signpost: it would be a mighty fine thing if even spooks were brought into sane human relationship with named-and-known peers.
signpost: there is zero benefit to that. explain it as you make actual relationships with people and peer up with them.
asciilifeform: thestringpuller: 1.2 -- 'Pest stations exchange authenticably-encrypted messages exclusively with an operator-configured set of peers...'
asciilifeform: so let's suppose a dishonest or sabotaged peer, verisimilitude
asciilifeform: verisimilitude: or do you mean constructedly from action of 1 peer? if so how ?
asciilifeform: so one possible solution is , 4 types of rekey msg, a', b', a, b. a' carries hash of a's 512b. b' -- hash of b's. from that point, carried on as in earlier example, with proviso that h(a) must == a', and h(b) == b', or peer refuses rekey.
asciilifeform considered also to make each peer 1st send a hash of his random 512b -- to prevent a sabotaged client of peer Y from forcing the resulting xor to a zero. but not sure whether worth it.
asciilifeform: if X received the rekey-b, does likewise. when peer X validates a packet with new key, it zaps the old; and Y - likewise.
asciilifeform: peer Y receives. generates similarly 512b of FG output, sends to X as 'rekey-b', and immediately adds (512b from rekey-a) xor (512b or rekey-b) as a new key for peer X.
asciilifeform: suppose node X wants to (ideally, probabilistically) initiate a rekey. generates 512b of FG bits, sends as rekey-a to peer Y.
asciilifeform: that way can ask peer to fill in the missing msg.
asciilifeform: (whether all peers received)
dulapbot: Logged on 2021-09-07 00:17:44 punkman: asciilifeform: is there something to gain by trying keys at random in 4.1.1? you would know which key a given peer uses, unless they send from new unknown IP.
punkman: asciilifeform: is there something to gain by trying keys at random in 4.1.1? you would know which key a given peer uses, unless they send from new unknown IP.
asciilifeform: so, to elaborate, if you have only 'asciilifeform' for me next to my wot key, but i switch my nick to 'bzzrpphft', you will see 'bzzrpphft(asciilifeform): foo...' when i speak, just as if bzzrpphft were a peer of mine but not of yours and were being relayed.
dulapbot: Logged on 2021-09-05 11:54:32 signpost: it'd probably be dependent on nodes having uniquely identifying "station keys", but would be nice to have a node develop a sense of reputation of peers, such that the edges of the network graph thicken along the most useful peerings.
dulapbot: Logged on 2021-09-05 11:53:22 signpost: cgra: it's been a long time since I looked at trb's code for selecting peers, but as I recall it wasn't very smart.
dulapbot: Logged on 2021-09-05 11:25:31 cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-04#1056475 << that asciilifeform's original "reported peers" is prolly good, because you wouldn't know about a particular node anyway, despite what is in trb's/prb's/any published code
signpost: it'd probably be dependent on nodes having uniquely identifying "station keys", but would be nice to have a node develop a sense of reputation of peers, such that the edges of the network graph thicken along the most useful peerings.
signpost: cgra: it's been a long time since I looked at trb's code for selecting peers, but as I recall it wasn't very smart.
cgra: i originally ran to this while trying to peer-seed my test node from a single trb node: all i was getting were prb nodes which were banned immediately, and i ended up with a single peer, the seeder
cgra: i was wondering whether most trb nodes were running without malleus_mikehearnificarum, because i saw a lot of prb peers in their "connected" lists. but it's likely, because the trb ProcessMessages() will refresh an outbound addr age already on receiving "version", ie. before the prb peer gets banned. so prb node addrs keep staying fresh, as long as trb don't have 8 outbound peers.
cgra: what trb does though, for what i can tell, reports addrs at most 3h old (measured in "adjustedTime"). trb only updates active outbound peers' addr ages, not inbound. also, when a peer advertises addrs to trb, it will mostly accept the peer-provided addr ages as is, will just add a 2h extra to their age. i dunno if peers do this, but they could advertise 0-age addrs, and they would stay 1h in trb's report set.
dulapbot: Logged on 2021-09-04 13:33:36 billymg: or at least recently connected (though this would also mean it's a misnomer to refer to them as 'connected peers' as that implies currently connected)
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-04#1056475 << that asciilifeform's original "reported peers" is prolly good, because you wouldn't know about a particular node anyway, despite what is in trb's/prb's/any published code
billymg: cgra: ^ essentially that list, though asciilifeform's watchglass has a configurable knob for 'peershots', my crawler has that set to 5, not sure what alf's watchglass is set to
watchglass: 205.134.172.26:8333 : reported peers: 208.94.240.42
watchglass: 205.134.172.26:8333 : reported peers: 54.95.111.227 60.48.190.216 71.224.191.142 76.103.7.22 79.186.94.254 88.80.145.201 88.99.65.182:8343 96.225.66.73 125.120.88.191 152.231.121.118
billymg: !w peers 205.134.172.26
billymg: or at least recently connected (though this would also mean it's a misnomer to refer to them as 'connected peers' as that implies currently connected)
billymg: cgra: hrm, technically you might be right, i had always assumed before that meant the node was also connected to those peers
cgra: so "connected nodes" here is more like "peers the node knows of"?
cgra: billymg: bitdash.io seems to somehow figure out what peers a node is connected to: like here, section "connected peers". how do you do it? or does it mean smth else?
asciilifeform: thimbronion: in asciilifeform's algo, incoming packets are identified solely by which hmac key they verify by. so peers in fact req'd to have distinct keys.
PeterL: oh, I had assumed each remote would be unique since those are generated by the other peer, right?
PeterL: in the example testnet you have the same local_secret for both other nodes, but in real use you would use a different local_secret for each peer, yes?
signpost: asciilifeform: I will shoot you a peer stanza for my node shortly
asciilifeform: noades oughta be rsapeered.
dulapbot: Logged on 2020-03-19 12:33:43 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.
scoopbot: New post on cgra's: TRB OOM Patch - no_peer_dumpster
asciilifeform: thimbronion: supported if nick is in direct peer set
dulapbot: Logged on 2021-08-12 09:13:49 cgra: fwiw, judging by the amount of OOM holes in trb, and absence of other issues similar to the 'wedge', seems to me the wedge was just someone pulling blocks in maximum force, for whatever reason, unaware of the lethal side effects. all these added up, obey_sendbuffersize may have been better off not rating such peers for misbehavior
cgra: fwiw, judging by the amount of OOM holes in trb, and absence of other issues similar to the 'wedge', seems to me the wedge was just someone pulling blocks in maximum force, for whatever reason, unaware of the lethal side effects. all these added up, obey_sendbuffersize may have been better off not rating such peers for misbehavior
cgra: asciilifeform: haven't tested this, but i suspect that an obey_sendbuffersize node (A), when catching up blocks, may end up banning peer (B) with >2x the sendbuffersize, if B advertises blocks with full capacity, in response to A's "getblocks"
asciilifeform: 'On my modest Rockchip with max_sockets set to 800 it completes a full scan (including ~half a million spam peers—I have not implemented blacklisting yet) in around 90 minutes ' << notbad!!
dulapbot: Logged on 2021-08-10 19:46:53 asciilifeform: '...the US has a much stronger economy than almost all global peers. The US has been home to most of the wealth generated from the recent secular growth period fueled by software and computing innovation, a fact you can confirm by looking at the deviation between the S&P500 and all other global indices over the last 30 years' << rofl
asciilifeform: '...the US has a much stronger economy than almost all global peers. The US has been home to most of the wealth generated from the recent secular growth period fueled by software and computing innovation, a fact you can confirm by looking at the deviation between the S&P500 and all other global indices over the last 30 years' << rofl
asciilifeform: cgra: the correct way to do mempool is -- 1) fixed, operator-config'able memory size 2) tx relayed by known peers hard-prioritized over all others
asciilifeform: cgra: a p2ptron where unknowns can connect will always to some degree remain sybilable. hence asciilifeform's past attempts to introduce notion of 'known' peer to trb.
cgra: asciilifeform: otherwise yeah, but still need time to grasp where can put a peer fence, without blocking convoluted, but vital, moving parts. otoh, also, while ~every part, still appear enumerable...
dulapbot: Logged on 2021-08-01 15:27:34 asciilifeform: cgra: the common theme here is that a peer ought not to be able to eat arbitrary ram. and that the correct end of the funnel to plug, is to actually measure the consumption, and kickban mercilessly. rather than trying to find each and every one of 'over 9000' places where shitoshi&co defined a type that can stretch to infinity
cgra learned today, fwiw, that trb's almost every peer-accessible rubber variable can be inflated by a random bypasser/coordinated inbound peers, until ~OOM. not unlike previously noted... got tired of demonstrating every individual case
adlai: now, editor of a 5Kg monograph on metallurgy, whose work primarily consisted of farming out peer review to professors specializing in each different niche -- sure, might be a glorified secretary
adlai: it's closer to "actively seeks out the consensus of first-world peer pressure"
asciilifeform: 'link the IP address of a node with particular transactions. This is done by spamming peer lists as we discussed above, and then attributing transactions to the node that first shares the transaction via p2p with the spying nodes' << what part of 'plaintext packets are public' do morons not grasp, lol
asciilifeform: 'inject their malicious nodes into valid node peer lists and consists of only sending malicious nodes via their own peer lists when requested by valid nodes while spamming very large peer lists' << lolwat only nao usg-spamola in that shitcoin ?
asciilifeform: cgra: the common theme here is that a peer ought not to be able to eat arbitrary ram. and that the correct end of the funnel to plug, is to actually measure the consumption, and kickban mercilessly. rather than trying to find each and every one of 'over 9000' places where shitoshi&co defined a type that can stretch to infinity
dulapbot: Logged on 2021-08-01 14:50:07 asciilifeform: cgra: imho the Right Thing is a 'peer may use this-many kB and if more, disconnect+permaban'
asciilifeform: 125 peers oughta be able to use 125MB at a time. 1 each. and not more.
asciilifeform: cgra: imho the Right Thing is a 'peer may use this-many kB and if more, disconnect+permaban'
cgra: still, separately need fixing the issues of 1) unbounded agent string, and 2) std::vector internal capacity not automatically reducing -- because you wouldn't want 125 simultaneous peers to consume >2GB of RAM
dulapbot: Logged on 2021-08-01 12:21:40 asciilifeform: cgra: seems to me that the correct pill would be a per-peer memory odometer.
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2021-08-01#1049627 << this is where the stale peers accumulate, and if such a dumpster didn't exist, my previous exploits wouldn't work. re the dumpster, i must get a better grasp of c++ networking to understand the why and the how-to-replace.
asciilifeform: cgra: seems to me that the correct pill would be a per-peer memory odometer.
cgra: bloated vSend of hundreds of stale, abrutply disconnected peers (all from same address)
cgra: umm no, actually. not a capacity leak in same sense. but a straight stale peer data abuse
asciilifeform: ftr the linked prb patch against this booby -- sucks. instead oughta simply reject variable-length entities above 1e6 bytes (block size) ~and~ drop any peer which exhausts some arbitarry memory usage (say, 2 sd above avg)
cgra: version parsing doesn't specifically limit the agent string size; GetRefCount() is special and plays a part; all the stale peer details (agent strings included) get kept in RAM for extra 15 minutes, after being disconnected (vNodesDisconnected).
shinohai: channel.py client.py funcs.py infosec.py peer.py __pycache__ server.py
dulapbot: Logged on 2021-07-24 16:29:42 punkman: The complexity of the state machine is currently its archille's heel, but this can be solved with more eyes on, as well as a re-think in developer procedures and peer-review. Thanks all for support, there's only one way forward."
punkman: The complexity of the state machine is currently its archille's heel, but this can be solved with more eyes on, as well as a re-think in developer procedures and peer-review. Thanks all for support, there's only one way forward."
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.
asciilifeform: billymg: possibly if were 1e6 spamola peers -- might notice
signpost: clearly the trb node reputation system needs work. this pissing of useless peers should be a ban.
dulapbot: Logged on 2021-07-20 12:42:36 signpost: tbh separating crawling-for-peers from trb might be worthwhile.
signpost: the peer-crawler could just do a polite sanity-check on peers, then say goodbye and write to addr.dat
signpost: tbh separating crawling-for-peers from trb might be worthwhile.
asciilifeform: punkman: fake as in there's suddenly 'over 9000' of'em and they don't emulate even prb convincingly, don't return peers, etc
punkman: fake peers as in prb nodez?
signpost: asciilifeform: in watching the logs of my node, it appears that I'm getting flooded with fake peers.
dulapbot: Logged on 2021-07-10 17:48:28 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')
signpost: asciilifeform appears to not give a shit about the economic phenomenon bitcoin, and cares only that a particular protocol is operating among peers in a wot, presumably to perform w/e transactions between them
billymg: notice all the previous probes returning only 1 peer