05:46:34 <Inge-> there might be a relevant body of research on sybil attacks in p2p networks, like https://link.springer.com/chapter/10.1007/978-3-319-23829-6_14
07:14:57 <needmoney90> Proof of work on asshole peers, I'm shooting in the dark here
07:15:31 <needmoney90> But what if every time you detect an asshole peer, you perform X proof of work (determined by you), and broadcast the best hash to the network attached to their IP.
07:16:19 <needmoney90> In aggregate, the most asshole-y peers will end up having high asshole ratings, due to random chance working out for the crowd
07:16:48 <needmoney90> There's some room for people to perform work to attempt to bump nodes off the network of course, but it may be the start of an idea
11:50:02 <kenshamir[m]> <needmoney90 "But what if every time you detec"> Is it possible for me to create a huge amount of IPs, then simulate the behaviour of a bad peer for each IP and have you performing proof of work for those IPs?
11:55:36 <moneromooo> That sounds like what Chris Grayling would do.
11:56:21 <moneromooo> I think the point is to make the presumed asshole do it, rather than the one detecting it.
11:57:52 <kenshamir[m]> <moneromooo "That sounds like what Chris Gray"> Embarrassingly had to google who this was, I’m so out of touch with politics
11:58:28 <kenshamir[m]> <moneromooo "I think the point is to make the"> Oh I see, I thought the honest peer was meant to do the proof of work and send the IP of the bad peer with the proof of work
12:26:04 <moneromooo> I think you are right actually, re-reading.
19:23:32 <needmoney90> kenshamir: Of course. Arguably thats whats happening right now, and what we are trying to remedy
19:24:12 <needmoney90> Though if you have a client-set default where you want to get X good peers, I think its not an issue
19:24:28 <needmoney90> its a probabalistic thing
19:25:05 <needmoney90> I considered having nodes send PoW in order to be peers, but that has issues
19:25:24 <needmoney90> because highly connected nodes and stuff would be adversely affected
19:26:06 <needmoney90> In my case, the work is only performed if/when a bad peer is detected, and the lowest hash broadcast if below a threshold
20:09:55 <kenshamir[m]> <needmoney90 "kenshamir: Of course. Arguably t"> Oh I was not aware of the current state. Okay makes sense now, you are suggesting a reputation system that is better than the _current_ one
20:10:41 <needmoney90> Yes, users need some way of knowing which peers are known bad network wide
20:11:42 <needmoney90> My insight here is just that if we have everyone perform some small PoW when they have a bad peer, eventually high difficulty hashes will materialize
20:12:22 <needmoney90> Obviously it's gameable in some ways, but it might be the start of an idea
20:13:11 <needmoney90> Perhaps timestamps and expirations would alleviate some of that
20:15:52 <kenshamir[m]> <needmoney90 "My insight here is just that if "> Oh interesting, can you explain why high difficulty hashes would materialise eventually?
20:16:09 <needmoney90> That is how proof of work works
20:16:25 <kenshamir[m]> Who is setting the difficulty?
20:17:22 <kenshamir[m]> If I see a bad peer, how would I know how much proof of work I should do, for example?
20:18:06 <needmoney90> Any user can perform a user determined amount of hashes, and then broadcast the lowest hash (highest difficulty) to the network. You don't need to set a difficulty at all, but you can set a threshold below) above which you don't connect to peers
20:19:11 <needmoney90> We can give a number in orders of magnitude for diff
20:19:28 <needmoney90> 'my client won't connect to people whose diff exceeds 7'
20:19:32 <kenshamir[m]> Okay I think I got it, so if I see a bad peer, I can perform as much proof of work I want
20:19:54 <needmoney90> Yes
20:20:48 <kenshamir[m]> Okay makes sense, I’m still not sure that high difficulty hashes will eventually appear though, because as a node I would want to do the least amount of proof of work for the reputation system right?
20:35:46 <kenshamir[m]> <needmoney90 "We can give a number in orders o"> I think this would solve it though. If you mandate that everyone has to provide a hash of X difficulty for bad peers.
20:36:14 <needmoney90> We can't exactly mandate it
20:36:45 <needmoney90> and the 'gaming' issues I was thinking about are bad actors providing false proofs against real nodes
20:37:01 <kenshamir[m]> Maybe not mandate, but as a node, I just won’t accept your “vote” if it’s below a certain difficulty
20:39:32 <kenshamir[m]> <needmoney90 "and the 'gaming' issues I was th"> Oh I see, yeah that’s a realistic adversarial model.
20:39:51 <needmoney90> yeah ken, that was the 'order of magnitude' thing
20:40:01 <needmoney90> people can decide on their level of tolerance for bad nodes
20:40:26 <kenshamir[m]> <needmoney90 "people can decide on their level"> Oh I see, sorry I’m a bit slow
20:40:30 <kenshamir[m]> Yeah makes sense
20:41:05 <kenshamir[m]> I have not done any research into reputation systems, was just curious about your idea
20:41:15 <needmoney90> sure, I'm spitballing here
20:41:22 <needmoney90> we actually have a working CPU-based PoW system
20:41:34 <needmoney90> It would be a shame not to use it if its applicable
20:41:51 <needmoney90> this sort of scheme wouldn't work at all under any system other than randomX, because FPGAs etc
20:42:04 <kenshamir[m]> <needmoney90 "we actually have a working CPU-b"> Oh how difficult would it be to integrate?
20:42:39 <kenshamir[m]> I’m assuming you mean a working reputation system and not a working POW consensus system
20:42:45 <needmoney90> I mean the PoW system.
20:43:09 <needmoney90> Having a network of users able to do small amounts of provable work in aggregate is very useful
20:43:30 <needmoney90> If at the very least because it increases the resources required to attack it
20:43:48 <kenshamir[m]> Yeah true, I think a reputation system based on PoW is natural since you already use PoW
20:44:19 <needmoney90> PoW has a number of fun implications, like if you find the highest diff block ever discovered in btc, you can roughly estimate the total work expended by the network in aggregate
20:44:34 <needmoney90> Which is the same principle I'm using here
20:44:52 <kenshamir[m]> What if a miner decides he doesn’t like X and does a ridiculously high difficulty hash for X?
20:45:19 <needmoney90> What do you mean?
20:46:07 <needmoney90> For a miner to 'choose' a block with a ridiculous difficulty without posting intermediate blocks, they would probabalistically need to discard every non-conforming block (and burn the work)
20:46:40 <kenshamir[m]> I guess that’s how I would attack the network.
20:46:40 <kenshamir[m]> instead of competing for blocks like a shmuck, i make ridiculously high difficulty hashes for the competition, so they get blackballed
20:46:40 <kenshamir[m]> Would that work?
20:47:34 <kenshamir[m]> Or I guess alternatively, I could blackball an exchange and initiate an eclipse attack on them?
20:47:58 <kenshamir[m]> <needmoney90 "For a miner to 'choose' a block "> Oh I didn’t get my point across, rephrasing
20:48:07 <needmoney90> Ah, yes, that's my adversarial example. My suggested way of resolving that was limiting the blacklist to a fixed period of time, so after X time (if you haven't received a subsequent proof of bad behavior) it rolls off your list
20:48:14 <kenshamir[m]> So as a miner, I would stop mining for blocks temporarily
20:48:17 <needmoney90> Which would force the adversary to constantly produce those hashes
20:48:53 <needmoney90> Heck, if we drop the limit low to something like a couple hours, it might actually be viable
20:49:31 <kenshamir[m]> I would focus on the reputation system and blackball the competition, by making them look like bad actors to the rest of the network, since I have the hash power for it, then I’d win a lot of blocks since no one is talking to the competition
20:49:47 <needmoney90> This is for nodes
20:49:49 <kenshamir[m]> <needmoney90 "Ah, yes, that's my adversarial e"> Ahh I see
20:49:51 <needmoney90> Not mining
20:50:01 <kenshamir[m]> Yep for nodes
20:50:28 <needmoney90> It's possible I guess, but I'm sure people would run nodes without the rule
20:50:38 <kenshamir[m]> I was illustrating that the end goal would be to subvert the mining system through the reputation system, so there is a motive
20:50:42 <needmoney90> If it's an issue I can't imagine miners wouldn't set up a relayed service
20:50:44 <needmoney90> Relayer
20:51:25 <kenshamir[m]> During the period of time, I guess that malicious miner who blackballed the competition would win a lot of blocks?
20:51:37 <needmoney90> Doubtful
20:51:46 <needmoney90> Existing connections are a thing
20:51:54 <needmoney90> And again, not everyone would run this
20:52:00 <needmoney90> Or have the threshold low
20:52:02 <kenshamir[m]> <needmoney90 "If it's an issue I can't imagine"> Oh right, I see
20:52:42 <kenshamir[m]> <needmoney90 "Existing connections are a thing"> Yeah I guess if you made it so that nodes first checked if that node was being bad, if they are on their list, then it would be solved?
20:53:15 <kenshamir[m]> So the blackballing would be applicable only for newer connections
20:53:38 <needmoney90> Yeah, the intent is not to kick off established connections
20:53:53 <needmoney90> The asshole peers aren't established connections
20:53:57 <kenshamir[m]> <needmoney90 "And again, not everyone would ru"> I think every full node would need to run it no?
20:54:11 <needmoney90> Hm. Actually. These peers are just non-relaying
20:54:17 <needmoney90> My mental model was broken there
20:54:31 <needmoney90> It's actually an issue, because it's not just disconnecting nodes, it's non-relaying nodes too
20:55:04 <needmoney90> Every fullnode would not need to run this, it's an optional thing
20:55:51 <needmoney90> It creates a subnetwork of nodes who have a shared blacklist, and are likely highly self connected
20:56:44 <kenshamir[m]> <needmoney90 "Every fullnode would not need to"> Oh I would think it would be in their interest to run a reputation system so that they can always be connected to “live” and honest peers
20:57:21 <kenshamir[m]> <needmoney90 "It creates a subnetwork of nodes"> Oh right, that’s a good depiction. A network on top of a network
20:57:40 <kenshamir[m]> * > <@freenode_needmoney90:matrix.org> It creates a subnetwork of nodes who have a shared blacklist, and are likely highly self connected
20:57:40 <kenshamir[m]> Oh right, that’s a good depiction. A network inside of a network
20:58:04 <needmoney90> Sure, but it's a potentially adversarial environment - if no one runs a node that peers with all, then we risk malicious actors abusing that to knock peers off
20:58:23 <needmoney90> It's more a 'public service' thing
20:58:45 <needmoney90> Those nodes would prolly have higher max connection counts to combat it though
20:59:08 <kayront> are we talking about the evil peers™ that have been found not relaying txs?
21:05:40 <john_r365> kayront - yes, also affectionately known as asshole nodes
21:06:41 <kayront> so what's the theory ? annoyance? tx logging?
21:06:45 <kayront> dos?
21:07:05 <selsta> most likely tx <-> ip logging
21:07:12 <selsta> also general annoyance maybe
21:24:21 <john_r365> Seems like a lot of effort just for annoyance. From the list moneromoo shared - https://gui.xmr.pm/files/block.txt - it seemed like IPs largely came from RIPE Network Coordination Centre or OVH Hosting. tx <-> ip seems most likely. presumably D++ makes it more obvious and problematic when nodes drop tx
21:24:49 <kayront> yes, it certainly does
21:31:49 <selsta> https://github.com/monero-project/monero/pull/6936 seems quite effective at catching and dropping them
21:56:21 <nioc> neednoether90
23:44:37 <yanmaani> idea: if a node misbehaves and there's a lot of misbehaving nodes in that ASN, send it say 1GB of traffic as punishment
23:44:49 <yanmaani> This would be fine for ordinary users on home connections, who wouldn't notice much downtime
23:45:17 <yanmaani> but if they're using commercial hosting providers, they will often disconnect problematic custoemrs, or charge them extra for network scrubbing