13:53:28 <br-m> <radanne:matrix.org> update. https://github.com/monero-project/research-lab/issues/147
16:00:05 <br-m> <articmine> I have to disagree with this. A DDOS attack is trivial to run in parallel. One can simply run an instance of the attack per thread. > <@jeffro256> I also want to move on, but for the record, parallel processing does nothing to mitigate the issue of invalid proof verification DoS 
16:00:05 <br-m> <articmine> If the defense is using the same processor as the attack, and there is no parallel processing on the side of the defense the advantage for the attack is simply the number of threads in the processor. For example for a 64 core / 128 thread processor the attack has a 128x advantage.
16:02:36 <br-m> <jeffro256> This isn't true since the p2p code won't let you open 128 connections from the same IP address 
16:08:59 <br-m> <jeffro256> The attacker in effect is single-threaded from the perspective of your node if they only have one IP. But attacker CPU speed doesn't mean anything at all since it takes 0 CPU power to construct an invalid FCMP++ proof. Thread count of the attacker is irrelevant. What matters is how many IP addresses the attacker can send messages from 
16:12:49 <br-m> <jeffro256> I believe you're still of the misconception that it takes CPU power to construct an invalid FCMP++, which is where you got the 128x figure from. It takes 0 CPU power. All I have to do is send bytes which can be deserialized as a potential FCMP++ transaction. In other words, the bytes just have to be the right "shape". There's  [... too long, see https://mrelay.p2pool.observer/e/koDhorsKdE1GSXVK ]
16:14:42 <br-m> <jeffro256> Then if I send you 128 variations of that transaction, each from a different IP address, then I will have to do 128 attempts at FCMP++ verification. Ostensibly, my node will ban those 128 IPs for a time (24 hours by default IIRC)
16:31:22 <br-m> <articmine> My point is that the attacker can do parallel processing for the POW "defense" making it irrelevant 
16:32:59 <br-m> <articmine> Temporary IP banning by the node is the correct way to deal with this attack. My objection is to the user POW as a so called defense 
16:33:55 <br-m> <jeffro256> It doesn't make it irelevant. My node current has 8 cores. If you send 128 invalid high-input FCMP++ ts and they each take 1s to verify on my slow machine, even with parallel processing, you can stall my node completely for 16s. And you spent 0 CPU time to do so 
16:37:19 <br-m> <articmine> The POW is irrelevant since I can perform the POW at zero cost in over 25% of the residential addresses in Canada during the winter 
16:37:35 <br-m> <articmine> With the same machine 
16:38:19 <br-m> <articmine> By the way it is the number of threads not cores that is relevant 
16:39:14 <br-m> <jeffro256> Without PoWER, you can do it for zero cost all the time, everywhere. And there's not zero cost with PoWER, even with free electricity in a cold environment. There is opportunity cost of not mining XMR. Without PoWER, there is 0 opportunity cost 
16:42:28 <br-m> <articmine> The opportunity cost of not mining XMR is minimal. The price of the electricity is irrelevant if one is using electricity for space heating 
16:45:50 <br-m> <articmine> What I see here with PoWER is nothing more than a classic security theatre. One goes completely overboard to try to mitigate one risk without any consideration of the downsides of the " security".
16:45:50 <br-m> <articmine> We have a valid solution for this attack anyway. with IP temporary bans
16:47:50 <br-m> <boog900> @articmine: We have 1 entity with 2000 ipv4 addresses on the network right now
16:49:08 <br-m> <articmine> Let me guess a blockchain surveillance company. 
16:50:34 <br-m> <articmine> Let them try this attack, get their IPs banned and put an end to their malicious spying
16:50:46 <br-m> <boog900> There are cheaper ways to heat a house, you still have to pay the difference in cost to run a PoW spammer. If you count electricity as free then you are still missing out on potential xmr rewards
16:50:51 <br-m> <boog900> @articmine: No lol
16:51:08 <br-m> <boog900> @articmine: Maybe 🤷‍♂️
16:51:34 <br-m> <articmine> A classic case of an opportunity cost on the side of the attacker 
16:51:44 <br-m> <jeffro256> I personally don't want them sending my node 33 straight minutes of CPU work every 24 hours for free 
16:51:56 <br-m> <boog900> @boog900: They have this many IPs when the incentive isn't even that great
16:53:57 <br-m> <articmine> @jeffro256: Then increase the ban time for repeat  offenders
16:54:55 <br-m> <articmine> In any PoWER will not stop this 
16:54:55 <br-m> <boog900> @articmine: You are limiting our security to the scarcity of the address space, enforcing ipv4 till the end of time
16:54:58 <br-m> <articmine> Case
16:55:22 <br-m> <jeffro256> That may work on the clearnet, but we also have to think about anonymity networks like Tor and i2p for which addresses can generated on the fly 
16:56:30 <br-m> <jeffro256> Tor recognizes this risk and itself has PoW for connections already. If you have used Tor recently, you have been running PoW code on your machine
16:56:52 <br-m> <boog900> Proxies, VPNs, Tor exits would all have to be blocked 
16:57:15 <br-m> <boog900> as the spam can be done just off of inbound connections 
16:58:12 <br-m> <articmine> @jeffro256: There is already user POW in anonymity networks that can still be easily attacked. In my view the only real solution for anonymity networks is burning small amounts of XMR
16:59:05 <br-m> <jeffro256> You can't determine if a transaction burns XMR or not without attempting to validate it first!!!!
17:00:05 <br-m> <articmine> Yes but one can validate a small transaction to allow for a large transaction 
17:00:20 <br-m> <articmine> In Verification time terms
17:00:50 <br-m> <boog900> @articmine: ok malicious node black holes big tx now what? 
17:00:59 <br-m> <boog900> small tx still pays but no big tx 
17:01:34 <br-m> <boog900> if you tie the small tx to the big tx then you are back at the original problem 
17:01:45 <br-m> <jeffro256> I'd much rather spend 2s doing PoW to get onboarded to the network than have add chain bloat, spend TX fees, and wait 20mins for confirmation to use my big tx 
17:02:51 <br-m> <articmine> @jeffro256: Even if the POW does not solve the problem
17:03:43 <br-m> <sgp_> We have to at least agree that using CPU resources has an opportunity cost, or else we need to completely throw this out and start over. Using CPU resources simply does have an opportunity cost, even if environments were electric heating is used. Idk if we need an actual call to sort this basic premise out; whatever it takes, since this circular conversation keeps happening
17:04:00 <br-m> <sgp_> *even in
17:05:51 <br-m> <articmine> This assumes that there are no idle CPUs
17:06:14 <br-m> <sgp_> "unlimited no-cost compute" is not a realistic assumption to go off
17:06:55 <br-m> <articmine> My argument is that the is no opportunity cost for trivial amounts of CPU time 
17:07:07 <br-m> <jeffro256> Idle CPUs are also paying opportunity cost of not mining if they have free compute and "free" electricity (or electricity which would otherwise be used for space heating)
17:07:11 <br-m> <boog900> its not trivial to do this on a big scale 
17:07:19 <br-m> <boog900> per tx per connection 
17:07:35 <br-m> <articmine> Actually it is 
17:08:05 <br-m> <articmine> As far as the PoWER part 
17:08:08 <br-m> <boog900> I'll put 1 XMR on it? 
17:08:26 <br-m> <boog900> you spam with enough power to overcome this on the whole network for free 
17:08:35 <br-m> <boog900> you get my 1 XMR 
17:11:38 <br-m> <sgp_> Am I missing something, or is the solution to this concern about low broadcast cost (including a low opportunity cost) one or both of the following: 1) hike the PoW resource cost to make it non-trivial, and/or 2) restrict transactions to require small enough input counts that they're trivial to verify
17:11:43 <br-m> <articmine> Spamming the Monero network is not my cup of tea
17:12:04 <br-m> <boog900> @articmine: no I'll set up a test 
17:12:45 <br-m> <articmine> @sgp_: Realistically yes
17:13:09 <br-m> <articmine> 2) is a valid option 
17:13:28 <br-m> <boog900> 2 was the original choice but people wanted more inputs 
17:13:46 <br-m> <sgp_> Yeah, I know there was some pushback to strict limits
17:14:31 <br-m> <articmine> ...and then the compromise was PoWER  over 8 inputs 
17:15:02 <br-m> <articmine> Then people are pushing for PoWER for all inputs 
17:15:20 <br-m> <boog900> no PoWER on p2p connections that want to broadcast txs 
17:15:31 <br-m> <boog900> wallets still only over 8 for RPC 
17:16:14 <br-m> <articmine> PoWER to broadcast on over you own node 
17:16:42 <br-m> <articmine> Pushing node centralization 
17:16:44 <br-m> <boog900> yep, which is ontop of already verifying every tx your node sees (a much bigger cost) 
17:17:26 <br-m> <boog900> @articmine: this is so minimal I bet it wouldn't even show on things taking the most CPU 
17:18:16 <br-m> <articmine> The better solution is to trivialize the cost of verification time with parallel processing of verification time on CPUs and Open CL GPUs
17:18:27 <br-m> <boog900> do it then.
17:18:54 <br-m> <boog900> at a certain point there is a limit 
17:18:55 <br-m> <sgp_> Can I propose something super simple? Can we all agree to just add a factor to the verification time? So instead of trying to match it, maybe try 2x, 5x, 10x etc
17:19:06 <br-m> <sgp_> Whatever number
17:19:42 <br-m> <boog900> @sgp_: PoW is not per tx FWIW it is per connection 
17:20:12 <br-m> <boog900> so we need to go with the max cost a tx can give 
17:20:21 <br-m> <sgp_> Got it
17:21:04 <br-m> <sgp_> If doubling from 1x to 2x gets this agreed to, that seems reasonable enough to me tbh
17:21:12 <br-m> <sgp_> Better than circular convos
17:21:25 <br-m> <boog900> we could scale based on number of bad txs seen but that is more complication 
17:21:45 <br-m> <kayabanerve:matrix.org> I'm willing to propose 8 inputs, 4 outputs, AND the introduction of POWER
17:22:00 <br-m> <kayabanerve:matrix.org> Why not have trivial verification time and make spamming non-feasible?
17:22:10 <br-m> <articmine> No to PoWER
17:22:20 <br-m> <kayabanerve:matrix.org> I'm also willing to leave the room and let y'all continue your debate :p
17:22:41 <br-m> <sgp_> No to power in entirety is the same as heavy tx restrictions
17:22:55 <br-m> <boog900> @boog900: could be an on/off scaling 🤔
17:23:12 <br-m> <kayabanerve:matrix.org> I don't see a reason to be against PoWER. It may be ineffective, yet letting nodes choose a target per their CPU burden should allow it to be reflexive to the point it's sufficient.
17:23:31 <br-m> <kayabanerve:matrix.org> I'd rather discuss improving PoWER until effective than not doing anything.
17:23:51 <br-m> <kayabanerve:matrix.org> Also, even if proofs are instant to verify, I'd still see reason to justify receiving a TX and attempting verification.
17:24:20 <br-m> <kayabanerve:matrix.org> These are largely separate systems. The desire for this one is impacted by the other, but this can exist regardless.
17:25:31 <br-m> <articmine> I accepted the compromise of PoWER for over 8 inputs
17:25:42 <br-m> <kayabanerve:matrix.org> And because these are independent systems, I believe we should:
17:25:42 <br-m> <kayabanerve:matrix.org> - Move forward with PoWER
17:25:42 <br-m> <kayabanerve:matrix.org> - Limit to 8/4
17:25:46 <br-m> <kayabanerve:matrix.org> But I'll primarily focus on advocating for systems like PoWER for now.
17:26:36 <br-m> <ofrnxmr> Why stop there? Limit to 1-2
17:26:58 <br-m> <articmine> You mean more than 8 inputs or 4 outputs. I accept that 
17:27:28 <br-m> <articmine> @ofrnxmr: This is why I have taken a hard line on PoWER
17:27:47 <br-m> <kayabanerve:matrix.org> I think 4/3 is the lowest which is feasible, and the next powers of two are 8/4 ofrnxmr, but don't tempt me with a good time
17:28:27 <br-m> <kayabanerve:matrix.org> (It's actually 2/3 IIRC, yet I want inputs' limit explicitly greater than outputs')
17:30:20 <br-m> <kayabanerve:matrix.org> Because we definitively don't have sufficient agreement on such limits though, PoW to justify TX transmission makes sense.
17:37:50 <br-m> <sgp_> I'm putting my realistic hat on:
17:37:50 <br-m> <sgp_> 1. Retail wallets won't use Power, since they don't want mining algos to be flagged. So they won't use it.
17:37:50 <br-m> <sgp_> 2. Institutions/exchanges won't want to pay for connections and the complexities with that, so they'll probably try to work with mining pools to get these larger transactions confirmed (eg sending them the raw tx)
17:37:50 <br-m> <sgp_> [... more lines follow, see https://mrelay.p2pool.observer/e/jLKYpbsKNjk4V0pv ]
17:39:11 <br-m> <boog900> it will be required on P2P connections that want to relay txs 
17:39:29 <br-m> <kayabanerve:matrix.org> I mean, we can have nodes do one PoW per connection to pay for any invalid TX. That, combined with a disconnect on invalid TX propagation?
17:39:34 <br-m> <boog900> it'll use equi-X, so not a PoW used for crypto mining (?) 
17:39:38 <br-m> <kayabanerve:matrix.org> Then wallets don't have to do it all.
17:40:36 <br-m> <kayabanerve:matrix.org> *I haven't actually read PoWER and am solely here to advocate for PoW as an anti-spam measure. Apologies if I am in fact describing PoWER or discussing a 'solution' which is known to not work.
17:40:46 <br-m> <boog900> for 2. the cost will be so small compared to the cost to build the tx/run a node 
17:41:16 <br-m> <boog900> so PoW shouldn't be a push from any of these if a user wanted to pay the cost anyway 
17:44:39 <br-m> <boog900> I forget the exact time to prove a FCMP tx with many inputs but it wayy longer than the cost to verify it, and for RPC the cost will only be paid on initial connection 
17:44:55 <br-m> <boog900> allowing you to hold the connection for multiple txs 
17:45:05 <br-m> <jberman> something like 4s * n inputs
17:47:13 <br-m> <sgp_> ArticMine so is PoWER a go then? It's acceptable for >8 in your view?
17:47:23 <br-m> <kayabanerve:matrix.org> Right, so there shouldn't be any concern by wallets nor institutions
17:48:25 <br-m> <sgp_> another stupid question: should nodes have a flag to disallow incoming power connections, if they don't want to use this?
17:50:34 <br-m> <boog900> @sgp_: PoW only on outbound connections 
17:50:43 <br-m> <boog900> otherwise trivial DoS 
17:51:06 <br-m> <boog900> PoW checked on inbound connections, done on outbound 
17:51:20 <br-m> <sgp_> I mean a node rejecting all incoming txs >8 and effectively opting out of power
17:52:03 <br-m> <boog900> nodes do PoW for all tx relay but yeah they should be able to opt out and not send any tx-pool txs 
17:52:15 <br-m> <hinto> in 2. if institutions/exchanges were to relay like this using RPC it would effectively be PoW per TX > <@sgp_> I'm putting my realistic hat on:
17:52:40 <br-m> <hinto> I am also concerned with this adding complexity on their side
17:53:39 <br-m> <sgp_> @boog900: yeah, seems fair enough
17:55:55 <br-m> <boog900> @boog900: I suppose you wait for the incoming nodes PoW first, still don't think it is needed for inbound connections tho 
17:56:21 <br-m> <boog900> @hinto: you can hold RPC connections tho 
18:02:13 <br-m> <hinto> daemon RPC?
18:03:14 <br-m> <boog900> yeah 
18:06:59 <br-m> <hinto> Can you explain how? It's stateless as well so each TX would need PoW
18:12:47 <br-m> <boog900> @hinto: we already track RPC payments? 
18:13:35 <br-m> <boog900> that legacy pay by hash system 
18:22:52 <br-m> <boog900> connection_context is also passed during each request
18:25:52 <br-m> <boog900> @hinto: I don't really know what you mean by how, but monerod will keep the connection open and keep responding to request down it 
18:42:57 <br-m> <hinto> AFAIK it closes the socket after response and there is no keep-alive support
18:44:15 <br-m> <hinto> I see how state would be held though
18:47:29 <br-m> <boog900> @hinto: we had a vuln some months ago where you can spam RPC requests and monerod would fill its internal buffer with the responses if you didn't read them 
18:48:30 <br-m> <kayabanerve:matrix.org> That's limited to 100MB now though
18:52:19 <br-m> <boog900> thats the per response limit, I thought the internal buffer had a different limit 🤔
18:52:49 <br-m> <boog900> spam on a single connection* 
21:51:20 <br-m> <articmine> Very good points. I had not thought about the Windows anti virus blocking POW. Your point about direct minier submission is also very valid. > <@sgp_> I'm putting my realistic hat on:
21:51:20 <br-m> <articmine> It is one of my biggest concerns with abusing the node relay, especially for something that does not really have consensus.
21:52:24 <br-m> <articmine> We are forcing centralization on the Monero network 
21:56:12 <br-m> <articmine> By the way a top of the line CPU has 384 threads with 512 thread processors in the pipeline. This is a far cry from the single core single thread Pentium II processors of the late 1990s
22:00:08 <tevador> How is a PoW based DoS protection centralizing? Especially if only applied to >8 input transactions, which are rare.
22:01:41 <br-m> <boog900> he is saying the increased cost to nodes is centralizing, we had loose consensus last meeting on doing PoW on all p2p connections that want to relay txs 
22:03:07 <br-m> <boog900> if this is centralizing (it is not) then FCMP is centralizing, any protection against reorgs that adds any verification cost is centralizing .. etc etc 
22:06:59 <br-m> <boog900> > Your point about direct minier submission is also very valid.
22:06:59 <br-m> <boog900> did you not ready my replies
22:07:01 <br-m> <boog900> 😭
22:07:16 <br-m> <boog900> read*
22:15:56 <br-m> <articmine> If the POW is to have real teeth it is centralizing because it encourages users to connect directly to the miners 
22:15:56 <br-m> <articmine> I am willing to compromise in requiring PoWER only  for transactions with greater than 8 inputs. I would also suggest adding stronger teeth to PoWER in this case. 
22:15:56 <br-m> <articmine> The one strong argument for large input transactions is the consolidation of mining outputs. So in reality the cost of PoWER should be compared to the cost of mining those outputs that are being consolidated 
22:19:34 <br-m> <boog900> @articmine:monero.social: a 128 input tx takes ~512 seconds to build, in what world would a 1 time PoW that takes 1 to 2 seconds for all txs they want to send during that connection going to make them connect directly to miners
22:21:25 <br-m> <boog900> Average p2p connection time is what 20 to 30 mins, 1 second PoW every 20 to 30 mins is not centralising 
22:25:43 <br-m> <articmine> This brings me to my next point. It is how long it takes to verify the 128 input transaction, that is the real reason for PoWER. For this to deter an attack using parallel processing while the defense is on a single thread one would need a factor of at least 384 or more 
22:26:37 <br-m> <boog900> ughhhhh
22:26:38 <br-m> <articmine> So parallel processing of verification time becomes a must here
22:27:56 <br-m> <boog900> one point at a time please 
22:28:30 <br-m> <jeffro256> You can't easily split up the verification time of a single proof. Is that what you're suggesting we do?
22:29:13 <br-m> <boog900> @articmine:monero.social: does this answer why it is not realistic that tx creators will go directly to miners > <@boog900> @articmine:monero.social: a 128 input tx takes ~512 seconds to build, in what world would a 1 time PoW that takes 1 to 2 seconds for all txs they want to send during that connection going to make them connect directly to miners
22:30:14 <br-m> <jeffro256> For reference, there is 1 membership proof (the slow part) per transaction regardless of the number of inputs in the transaction. This 1 membership proof does get bigger with more inputs, but is not easily broken up to verify 
22:31:36 <br-m> <jberman> (PR to batch verify multiple FCMP++ proofs in parallel at a time, that also has no rational relevance to PoWER: https://github.com/seraphis-migration/monero/pull/101) 
22:33:57 <br-m> <articmine> @jeffro256: No. The threat is not a single invalid transaction but a flood of them. So verification of multiple proof in parallel is what I am suggesting
22:36:59 <br-m> <boog900> @articmine: If someone sends you multiple bad txs and you batch verify them you have now increased the amount of time you will waste
22:37:47 <br-m> <boog900> verifying 1 tx then dropping the other 99 if its invalid or verifying all 100 together then dropping them all 
22:37:49 <br-m> <jeffro256> Multi-threaded verification/handling of incoming pool txs already done. But unless your CPU has >2000 threads, then you will be outmatched by the LinkingLion entity
22:38:56 <br-m> <boog900> @jeffro256: I don't think it is? unless you mean for FCMP?
22:40:19 <br-m> <jeffro256> Is the cryptonote protocol handler not asynchronous / multi-threaded ?
22:40:34 <br-m> <boog900> ah I was thinking for a single connection 
22:40:52 <br-m> <boog900> I don't know when the txpool lock is taken 
22:41:39 <br-m> <jeffro256> I meant that if 200 connections send you 1 tx each, they will be verified in parallel up to your CPUs available concurrency 
22:41:52 <br-m> <jeffro256> lemme check when the lock is taken 
22:43:10 <br-m> <jeffro256> oh jk tx_memory_pool::add_tx() is mutually exclusive
22:44:43 <br-m> <boog900> damn, should probably be changed at some point 
22:44:58 <br-m> <boog900> Cuprate does it already :p
22:46:16 <br-m> <jeffro256> Yeah ideally the only thing the mempool should be locking for is reading relevant chain state: ring member output data, heights, used key images, etc 
22:48:37 <br-m> <boog900> making use of LMDBs readers to get a consistent view would be the best solution but I think it might be too late for that deep a change
22:49:25 <br-m> <jeffro256> True