16:08:15 <Rucknium[m]> There is a meeting in this channel in one hour
16:08:15 <Rucknium[m]> https://github.com/monero-project/meta/issues/665
17:00:10 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/665
17:00:11 <UkoeHB> 1. greetings
17:00:11 <UkoeHB> hello
17:00:31 <selsta> hi
17:00:34 <rbrunner> Hello
17:01:27 <jdefgh[m]> hi
17:03:24 <Rucknium[m]> Hi
17:04:16 <UkoeHB> it looks like jdefgh[m] has a proposal about pool mining to discuss https://github.com/monero-project/monero/issues/8181
17:04:25 <r4v3r23[m]> yo
17:04:30 <jdefgh> yes
17:05:09 <Rucknium[m]> Yes I think it would be a good time to brainstorm ideas for limiting mining pool centralization.
17:05:46 <selsta> banning pool mining has been discussed often in the past, it also was deployed on wownero, but it has downsides
17:06:16 <selsta> it doesn't help against botnets, it basically only makes it impossible for smaller miners to contribute to the network as they don't get any rewards for ages
17:06:37 <rbrunner> Yeah, I wonder how that propposal compares to what Wownero has live for a while
17:06:42 <Rucknium[m]> Previous discussion here:
17:06:42 <Rucknium[m]> https://libera.monerologs.net/monero-research-lab/20220120#c65308
17:06:45 <UkoeHB> It sounds like the idea is to sign block headers. Since EC operations are pretty expensive, I imagine that would allow ASICs to gain an advantage (one signature per nonce).
17:07:10 <sech1> EC operations are 4-5% of hash time in Wownero
17:07:39 <UkoeHB> wow that's a beefy hash then lol
17:08:33 <UkoeHB> is that like 1-5ms hash time?
17:08:50 <sech1> 1-2 ms, depending on CPU
17:09:00 <rbrunner> That's RandomX for you :)
17:11:17 <merope> Unless somebody figures out a p2pool implementation that work with nonce-signing, it's a no-go in my opinion
17:12:12 <Rucknium[m]> My question is whether anyone here has scoured the academic literature on this topic. There have definitely been papers published (and working papers uploaded but not technically published) on this topic. I did a quick search and found plenty.
17:13:47 <merope> There are 5-6 orders of magnitude of speed difference between a high-end cpu and the whole network. It would take somewhere between several months and several years for anyone mining on a single cpu to find a block. On average
17:14:18 <rbrunner> I think people differ widely how dire and bad they see the pool situation, with equally differing readiness to accept drastic solutions like this one
17:15:05 <merope> This is not sustainable for small miners who need to pay their power bills, while big mining farms/botnets would be unaffected
17:15:25 <merope> So it would both severely weaken the network and increase hashrate centralization
17:15:30 <rbrunner> I for one would jugde halving the network hashrate or so because of making mining harder a larger problem than that 50% pool right now
17:15:37 <selsta> It only punishes small miners.
17:16:13 <rbrunner> Destroying the village in order to save it, or how did that saying go?
17:16:46 <sech1> nonce-signing doesn't work with p2pool. You can't know secret keys of other miners to sign for them
17:16:57 <rbrunner> I think Wownero as a quite small coin were threatened in their viability, they might not have had a choice. We are not in the same situation.
17:17:34 <rbrunner> sech1: So did already think that through?
17:17:53 <sech1> all coinbase tx outputs must be signed with corresponding keys
17:17:57 <Rucknium[m]> So no one has looked deeply into the existing research on this? Maybe we should do that.
17:18:09 <sech1> even if 1 output is not signed, centralized pools can use that output to get block reward
17:18:14 <ArticMine> I believe we need to be very careful with any consensus change here
17:18:16 <Rucknium[m]> Maybe there is a paper out there that solves the problem that we don't know about.
17:18:19 <wowario[m]> correct. before the fork, one pool had over 70% of the network hash 
17:18:40 <rbrunner> Which problem exactly do you mean, Rucknium?
17:18:53 <merope> Rucknium: any interesting papers that you've found?
17:18:55 <Rucknium[m]> rbrunner: Mining pool centralization.
17:19:19 <rbrunner> So not making pools impossible, just keeping them from "centralizing".
17:20:01 <sech1> I just searched on google, and 4 out of 5 "How to mine Monero" guides mention minexmr as either a go-to pool or "one of popular pools"
17:20:33 <jdefgh[m]> the block reward system could be somehow modified to resemble p2pool's logic
17:20:35 <Rucknium[m]> endor00: Not anything that struck me as a silver bullet, but I just looked for a few minutes. I'm just saying that we shouldn't just rely on our own brainstorming to approach this.
17:20:46 <rbrunner> Yes, that's the result if you do good work for many years.
17:21:30 <sech1> there are a few pools that are arguably better than minexmr
17:22:05 <rbrunner> So more of a first / early mover advantage?
17:22:33 <sech1> yes, also many guides are copy/paste from many years ago, they just update the date to 2022
17:22:56 <Rucknium[m]> Something that would actually solve this is for mining pools to "voluntarily" establish an increasing pool operator fee if their share of hashrate got above a certain level. For example, 0-33% share of hashrate, set fee to 1% (or whatever). From 33% to 50% share of hashrate, set it to an exponential function rising from 1% to 100%.
17:23:24 <sech1> From 25%
17:23:28 <Rucknium[m]> That's the "economical" way to deal with it. Change the incentives for individual miners.
17:23:35 <sech1> or we can get two 33% pools that together can do 51%
17:23:42 <merope> hell, there are some copy-paste guides "updated to 2021" that still talked about mining Cryptonight using an RX480 using minergate
17:24:58 <Rucknium[m]> sech1: Sure. The exact parameters could be up for debate. Just use a sensible mining pool operator fee policy to push miners away from big pools. That's "voluntary" though.
17:24:59 <rbrunner> Usually, if you can't get to #1 on Google organically, you throw money at the problem and buy advertising. A CCS for p2pool ads on Google?
17:25:06 <merope> Rucknium: the problem with that system is that it would be completely voluntary, and miners would have an incentive to join a pool that doesn't implement such additional fees
17:25:32 <selsta> rbrunner: let's not feed google with money :D
17:25:41 <rbrunner> Just brainstorming :)
17:26:06 <rbrunner> Maybe less worse than murdering pool mining
17:26:41 <merope> The integration of p2pool in the gui wallet is a step in the right direction imo: reduce the barrier of entry to the point where it's just plain easier to do the right thing "by default" rather than having to do extra work
17:26:54 <merope> Which makes me think: why not include p2pool in xmrig instead?
17:27:05 <UkoeHB> Does hybrid PoS/PoW mitigate the issue?
17:27:25 <merope> Make it the default option, so that people would have to go out of their way to pick a different pool instead
17:27:39 <rbrunner> How do we stand with the xmrig dev(s), quite in general? Are they open for proposals?
17:27:44 <merope> And it wouldn't require keeping the wallet always open while mining
17:28:11 <sech1> integrating into xmrig doesn't make sense, you still need Monero node
17:28:31 <sech1> if you set up Monero node, you can just as well set up p2pool
17:28:40 <rbrunner> UkoeHB: PoS is quite a red flag for many people
17:28:45 <sech1> "do one thing and do it well" (c)
17:28:55 <merope> Right, but you don't need to run a third piece of software in addition to monerod (which you already have, because you need the wallet) and xmrig (which you already have, because you're mining)
17:29:33 <UkoeHB> rbrunner: I'm not well versed in the dynamics of PoS, just wondering if anyone knows how well it handles the 51% issue.
17:30:00 <sech1> If someone gets 51% in PoS, they will always have 51%
17:30:08 <merope> Keep in mind that the goal is reducing the entry barrier for people who barely know/understand anything about crypto - the same people who blindly join minexmr based on the first guide they found on the internet, because they don't know any better
17:30:19 <UkoeHB> There are really only three options for consensus: PoW, PoS, federated Byzantine agreement (SCP or similar). All have relative pros/cons.
17:30:33 <sech1> actually, half of minexmr hashrate comes from HUGE whale miners
17:30:37 <sech1> I'm talking 100+ MH/s
17:30:38 <merope> (The same people who have significant difficulties even running their own node, or need handholding while setting up xmrig)
17:30:47 <sech1> why they don't mine solo, I have absolutely no idea
17:30:57 <merope> Well, yes, there's that too
17:31:25 <merope> But botnets like using public pools because there are no traces leading back to them that way
17:32:07 <merope> And some botnet operators are just skiddies who figured out how to download "silentxmr" from github or whatever, so their technical skills are quite limited
17:32:27 <rbrunner> In any case p2pool is so new it barely had a good chance to improve the situation. And yet, it's already the 4th largest pool.
17:33:03 <rbrunner> I as the CEO of Monero would pour time and energy first into pushing that, before I burry the pools ...
17:34:23 <Rucknium[m]> Are we aware of this paper? "Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin Mining Coalitions"
17:34:23 <Rucknium[m]> https://dl.acm.org/doi/abs/10.1145/2810103.2813621
17:35:12 <wowario[m]> how about increasing the cost of running a mega pool by increasing the hashing blob size? 
17:37:34 <sech1> we can't increase to more than what get_block_template returns
17:37:37 <rbrunner> That cost would be proportional basically to the number of miners?
17:37:40 <UkoeHB> wowario[m]: I'm not sure that fundamentally changes anything. Blob size is a per-miner cost, so increasing the size just pushes out marginal miners.
17:37:41 <sech1> this is 1-5 KB
17:39:20 <jdefgh[m]> Changing parameters isn't really going to change much. The affected miners would just keep mining and the distribution would be affected only slightly
17:39:20 <rbrunner> So everybody has more communication, not only mega pools
17:41:36 <UkoeHB> We are pretty far along in the meeting now. Are there any other topics people want to bring up? It seems we are getting pretty close to ready for the next HF.
17:42:05 <UkoeHB> maybe is h4sh3d around to give an update on 7877 review?
17:46:31 <Rucknium[m]> A while ago I brought up the idea of having a collaborative repository of papers about Monero. I think I may have found some open source software that could do it:
17:46:31 <Rucknium[m]> https://wikindx.sourceforge.io/web/trunk/
17:46:55 <Rucknium[m]> Anyone with any experience with WIKINDX or a similar system? Any comments on the matter?
17:49:04 <UkoeHB> sure, if you get it set up I can help add papers
17:50:11 <r4v3r23[m]> i'd like to bring attention to #8179, AirGap team is keen on building a QR standard for monero offline txs and this is PR goes along way in making that possible
17:50:19 <r4v3r23[m]> https://github.com/monero-project/monero/pull/8179
17:51:44 <rbrunner> Must have a look how that amazing reduction was achieved ...
17:52:04 <UkoeHB> would be nice to have a summary of changes in the PR...
17:52:39 <r4v3r23[m]> reduces the output file sizes drastically so they can fit on animated QR codes
17:52:51 <UkoeHB> that's the outcome, not the change
17:53:29 <rbrunner> Either you are from the inner circle, or you are not :)
17:53:50 <r4v3r23[m]> this is mooo's work, ive just been testing it on random wallets
17:56:55 <UkoeHB> ok seems like we are done; thanks for attending everyone
18:03:18 <tevador> There is a relatively small change that can be done to RandomX to make pooled mining a lot more difficult: The 256-MiB cache that is currently generated using Argon2 can be instead generated by putting together random pieces of the blockchain. This would make mining more tightly coupled to running a node.
18:03:46 <tevador> It would also require making the RandomX epoch much shorter, probably ~64 blocks. Pools cannot afford to upload a 256 MiB blob to each miner every 2 hours. If miners are forced to run their own nodes, they might as well join p2pool.
18:06:12 <merope> What if the contents of that random blob were tied to the contents of the coinbase transaction, and/or extra_nonce? That way, a single pool providing a different extra_nonce template to each miner would have to do a ton of work, but an individual miner mining by itself would only have to do it once (or a few times, at most)
18:10:14 <tevador> ^That would be problematic because each block could potentially require a new cache to be constructed, making PoW verification much slower.
18:11:27 <tevador> The purpose of the RandomX epoch is to use a fixed cache per certain number of blocks so that the cache generation is amortized when verifying.
18:11:44 <merope> Hmmm, right
18:13:10 <sech1> pools will use torrents to distribute new cache
18:13:19 <sech1> it's not hard to automate it
18:13:45 <sech1> but it will definitely kill botnets
18:14:06 <sech1> "end-user" 1 kh/s bots can't download 256 MB all the time
18:21:21 <tevador> Is it easier to set up a p2p network to download 256 MB every 2 hours, or to simply run a pruned node? I think pooled mining would get a lot closer to hosting a node, which should be the goal.
18:23:25 <sech1> 128 MB/hour is much less than what a node uses
18:24:04 <sech1> even if it's 3-4x more traffic because of torrenting, it's still less than a node traffic
18:25:05 <sech1> we also have self-select, and xmrig even supports it, but pools don't use it
18:26:03 <tevador> optional features like self select are not going to cut it, it must be forced to make lazy miners react
18:28:23 <tevador> I will measure traffic requirements for a synced node, but I don't think it's significantly more than 3 GB/day
18:30:06 <sech1> Sent 1366645440753 bytes (1.24 TB) in 103421693 packets in 2.5 months, average 200.94 kB/s
18:30:15 <sech1> 76d 20h 57m 35s uptime
18:31:34 <tevador> how many out/in peers?
18:33:52 <sech1> 32/32
18:35:12 <tevador> so with just 8 out peers, it should be roughly 2-3 GB/day
18:37:10 <sech1> more like 4 GB/day
18:37:34 <sech1> and much more if you get "lucky" and someone starts syncing from block height 0
18:37:46 <sech1> *one of your peers starts syncing
18:38:03 <sech1> of course you can set bandwidth limits
18:38:22 <tevador> ^ this
18:38:49 <tevador> in any case, running a node would not be significantly different from syncing just the cache
18:39:50 <sech1> It would be fun to see how Monero network scales to 50k nodes (we have 50k miners today)
18:40:26 <sech1> there are currently ~11k nodes: https://monero.fail/map
18:40:39 <UkoeHB> adding large bandwidth costs to mining would probably knock off a lot of miners
18:42:06 <h4sh3d> UkoeHB: I’m still struggling with covid so my review is stuck, no ETA to give but it’s on top of my todo 
18:42:48 <UkoeHB> h4sh3d: thanks for the update, get well!
18:43:09 <tevador> UkoeHB: mostly botnets
18:43:42 <tevador> but perhaps we would get botnets to run a ton of monero nodes :)
18:44:33 <UkoeHB> there are a lot of people stealing electricity who might run into problems if their bandwidth usage suddenly spikes
18:47:55 <tevador> anecdotal
18:51:16 <zkao> UkoeHB: in POS usually 33% attack is enough for majority (1/3 honest vote on fork A, 1/3 byzantine nodes vote A to one side and B to the other side of the network, the remaining 1/3 honest nodes vote on fork B). each honest side think they are with the majority. some recent protocols can do 50% but i believe they need an external random beacon. im 3 years off on that
18:51:19 <zkao> research though
18:51:48 <UkoeHB> Sure, the point is marginal miners will leave if costs increase. This is just a fact that makes '50k nodes' an improbable outcome.
18:52:29 <zkao> a lot of fuzz on the 51% attack stuff, but why is that threshold so magical since u can perform the same attack at much less than 51% hash rate?
18:52:52 <tevador> The current pool situation is not going to fix itself, something must be done. Even if we lose some miners, the result might be a much safer network.
18:53:36 <UkoeHB> I don't disagree - just don't pursue something like that and expect the hash rate to stay the same.
18:54:06 <ComplyLast> safer as in also "less electricity being spent to protect the network"
18:56:49 <ComplyLast> and also potentially pricing out miners that live in places with limited bandwidth, so it's not without it's tradeoffs, and could lead to more centralization not less
18:57:06 <tevador> safer as in "you don't need to trust a single pool operator who controls half of the network"
18:57:38 <ComplyLast> safer as in the cost to attack the network also decreases, so it's all about tradeoffs
18:58:32 <tevador> if profitability is there, other miners will fill the void
18:58:50 <ComplyLast> you're adding more costs nonetheless
18:58:59 <nikg83[m]> ComplyLast: Currently it’s almost no cost to attack with botnets 
18:59:41 <ComplyLast> and that wont change for the most part so long as you can mine with cpus, another tradeoff
18:59:51 <tevador> the "cost" is roughly the cost of running a node, which is arguably quite low
19:00:28 <ComplyLast> <ComplyLast> and that wont change for the most part so long as you can mine with cpus, another tradeoff
19:00:35 <ComplyLast> ofc bar major price increases, etc
19:00:43 <tevador> Still a far cry from hard solutions like the one implemented by wownero
19:04:29 <nikg83[m]> ComplyLast: Making it expensive for botnets is the key, increasing their network usage will raise red flags for them 
19:05:14 <selsta> Cloud botnets won't care about network usage.
19:05:20 <ComplyLast> I'm not convinced that is good for the security of the network
19:06:37 <ComplyLast> actually one could argue botnets help the network deliver a security budget above the value of the coin at any given point and hence good
19:07:12 <selsta> Yes, botnets are bad for profitability but they secure the network.
19:08:31 <tevador> ideally they shouldn't mine at minexmr.com
19:08:35 <rbrunner> Didn't sech1 wonder why on earth botnets seem to mine on public pools? Maybe, thinking outside the box, we should build some new incentive for them to go somewhere else.
19:08:43 <nikg83[m]> selsta: How ? Even they would notice it unless they are too careless
19:08:44 <nikg83[m]> I would propose higher ram requirements but seems some want to mine on android phones with few hundred hash vs botnets 
19:09:27 <ComplyLast> <rbrunner> Didn't sech1 wonder why on earth botnets seem to mine on public pools? Maybe, thinking outside the box, we should build some new incentive for them to go somewhere else.
19:10:22 <ComplyLast> they kinda already have a legal one to do so, but it's indeed surprising they fail to do so. I expect more legal pressure on the entities running pools nonetheless moving forward
19:10:25 <selsta> nikg83[m]: if someone spins up 300000 servers on a cloud provider they will notice, yes, with or without a higher network usage. But it still took them a couple days to shut them down.
19:19:24 <nikg83[m]> <selsta> "nikg83: if someone spins up 3000..." <- That’s true it will take sometime
19:19:24 <nikg83[m]> What do you think about  having higher ram requirements, is ram a scarce resource for legit miners ? 
19:19:24 <nikg83[m]> Also what happened to sha3 Asics which was being discussed while randomx was being deployed 
19:20:11 <nikg83[m]> * > <@selsta:libera.chat> nikg83: if someone spins up 300000 servers on a cloud provider they will notice, yes, with or without a higher network usage. But it still took them a couple days to shut them down.
19:20:11 <nikg83[m]> That’s true it will take sometime
19:20:11 <nikg83[m]> What do you think about  having higher ram requirements, is ram a scarce resource for legit miners (ignore few h/s phone miners) ? 
19:20:11 <nikg83[m]> Also what happened to sha3 Asics which was being discussed while randomx was being deployed 
19:20:28 <tevador> ^ Higher RAM usage is not possible without also increasing the RAM usage of nodes. See the RandomX design notes.
19:20:45 <ComplyLast> sha3 was only an idea if randomx were to ever fail at staving off asics
19:21:01 <selsta> tevador: I think sech1 said it's possible, it only doubles verification time for slow mode.
19:21:29 <tevador> We definitely do not want to make verification any slower!
19:21:56 <sech1> or double cache size with same verification time
19:23:08 <tevador> that also means ~double node RAM usage
19:23:33 <tevador> currently, monerod can run with ~1 GB of RAM
19:24:59 <tevador> Most importantly, RAM requirements don't solve pool centralization problems.
19:26:18 <sethforprivacy> Yes, the much bigger issue is pool centralization over botnets. Botnets are merely a threat to profitability but are actually an excellent asset in securing the network.
19:27:12 <sethforprivacy> The biggest issue with botnets is when they mine on large pools and give pool operators the ability to leverage their hashrate without their consent to attack Monero. Botnet operators are incentivized to keep Monero secure, but are going to take the easiest route available for mining -- i.e. mine on a large public pool like MineXMR.
19:27:33 <nikg83[m]> sethforprivacy: Who was mining with 100sMh/s when minexmr to take it over 51% ? 
19:27:52 <nikg83[m]> * > <@sethforprivacy:matrix.optoutpod.com> Yes, the much bigger issue is pool centralization over botnets. Botnets are merely a threat to profitability but are actually an excellent asset in securing the network.
19:27:52 <nikg83[m]> Who was mining with 100sMh/s on minexmr to take it over 51% ? 
19:28:00 <sethforprivacy> Who knows -- could have been a botnet, and if so, the real issue is pool centralization, not botnets.
19:28:20 <sethforprivacy> If we had botnets but no pool centralization, it's not really problematic. When we ha
19:28:42 <sethforprivacy> s/When/If/, s/ha/had pool centralization but no botnets, it would still be a huge problem./
19:29:13 <sethforprivacy> These are not equal threats to the security of the Monero network.
19:32:06 <sethforprivacy> <tevador> "There is a relatively small..." <- This is a *really* interesting approach... My only hesitation would be that we need to be further along in simplifying non-pooled mining (like p2pool) so that the technical barrier to entry is as low as possible, hopefully almost as low as current pool mining.
19:32:39 <sethforprivacy> A drastic loss in overall hashrate due to a change like this would make attacks by nation states or malicious datacenters much easier, which will become an increasing concern as Monero gets more and more limelight.
19:36:14 <hyc> definitely, increasing the resource burden per miner seems like the only way to go to discourage pool growth
19:37:46 <hyc> although the obvious countermeasure to tevador's suggestion is to use multicast
19:40:01 <sech1> what multicast? UDP? It works only in LAN
19:41:17 <hyc> IPv6 multicast works across routers
19:41:42 <sethforprivacy> If we really want to destroy pools we'll just require they use IPv6 then 😅
19:42:52 <tevador> Multicast is UDP. It only really works with video/audio streams.
19:43:20 <tevador> unusable for reliable P2P data sharing
19:46:46 <hyc> it would work fine for periodic cache broadcasts
19:48:10 <tevador> I'm quite sure that would not work in practice.
19:54:39 <tevador> I opened issue #98 to further discuss this idea
20:00:14 <merope> <sethforprivacy> "Yes, the much bigger issue is..." <- Killing profitability for legitimate miners goes directly against the security of the network. I have yet to do the math on it, but I believe that - hash for hash - botnets have an overall negative effect on network security
20:02:00 <hyc> there's a flip side, tevador: miners could simply start running local nodes, but still send their hashes to a pool
20:02:23 <merope> The main reason being that - since they don't pay for electricity - they can afford to be as inefficient as they like and they still earn the same amount of money, while legitimate miners get pushed out because their dwindling income can't keep up with their operational costs
20:03:51 <sethforprivacy> merope: Agreed, would need to see the math though as I'm not sure they're displacing more "legitimate" hashrate than they're providing, and they're decentralized, hard to stop, and have much lower profit margins than normal miners so they can be quite advantageous.
20:04:03 <hyc> merope: your argument makes no sense. taken to its logical conclusion, if the network was 100% botnets it would be even more secure than now
20:04:25 <hyc> because nobody could afford to intentionally mine
20:04:46 <merope> nobody could afford to intentionally mine profitably
20:04:58 <merope> that does not mean that the network would be invulnerable from attacks
20:05:02 <jberman[m]> Wouldn't it be fairly simple to modify a node to not do any verification and check block headers against the centralized pool?
20:05:18 <hyc> it means the network would have more hashrate than it would if it was only sustained by people paying for electricity
20:05:22 <merope> on the contrary - less people mining overall would mean a weaker target
20:05:44 <merope> hyc: not necessarily
20:06:11 <hyc> yes, necessarily. if 100% of the network was botnets, yes.
20:06:11 <merope> (I think?)
20:09:57 <merope> (WIP) it would definitely mean that the 100% botnet network is using more energy than it would be worth
20:10:30 <merope> trying to construct a counterexample regarding the hashrate (or convince myself that you're right)
20:11:28 <nikg83[m]> merope: Doesn’t meant someone other entity can’t bring a bigger botnet on table to attack the network 
20:11:51 <nikg83[m]> * > <@endor00:matrix.org> (WIP) it would definitely mean that the 100% botnet network is using more energy than it would be worth
20:11:51 <nikg83[m]> Doesn’t meant some other entity can’t bring a bigger botnet on table to attack the network 
20:13:03 <nikg83[m]> * > <@endor00:matrix.org> (WIP) it would definitely mean that the 100% botnet network is using more energy than it would be worth
20:13:03 <nikg83[m]> Doesn’t mean some other entity can’t bring a bigger botnet on table to attack the network 
20:17:03 <dav0h> the meeting already go down?
20:22:01 <jberman[m]> <hyc> "there's a flip side, tevador..." <- I think the counter-argument to this is that it still increases the attractiveness of p2pool. The primary disadvantage of p2pool seems to be the need to run a node, so if the cost to mine with a centralized pool goes up with no effect on the attractiveness of p2pool, then it may necessarily tilt more people toward p2pool
20:24:17 <hyc> unless there's something terribly broken, p2pool is already as attractive as it can get. no pool fees.
20:27:12 <Rucknium[m]> Earlier sech1 wondered why huge miners still mine to pools. Maybe it is because their blocks have a higher chance of being orphaned when there are a few big mining pools? Especially with a 2 minute block time? And p2pool may have the same issue, so the 1% pool fee is lower than the probability of being orphaned.
20:27:36 <jberman[m]> I worded it weird, but further harming the competition from centralized pools is still a form of increasing the attractiveness of p2pool imo
20:28:22 <hyc> perhaps. either way, encouraging/requiring miners to run local nodes sounds like a good thing.
20:28:24 <sech1> p2pool actually has fewer orphan blocks
20:28:47 <sech1> because all p2pool nodes broadcast found blocks
20:28:52 <jberman[m]> hyc: agree
20:29:36 <sech1> p2pool nodes relay shares faster than monerod relays blocks, so if a share has enough diff, it will be broadcasted from everywhere immediately
20:30:36 <sech1> I bet all Monero nodes have at least 1 p2pool node in their peers now
20:30:37 <merope> Rucknium: I think you're overthinking it. Solo mining/p2pool would mean setting up a node, which requires extra work and makes it easier to be spotted (especially with the additional storage requirement, bandwidth usage, and massive number of connections). By comparison, xmrig is just a tiny little executable that can be (relatively) easily embedded in any piece of malware
20:31:32 <sech1> xmrig -> xmrig-proxy on a cheap no-KYC VPS -> p2pool/monerod
20:31:38 <sech1> safe enough even for botnetters
20:32:05 <Rucknium[m]> sech1: How does connection latency play into p2pool? If I'm mining with high latency, won't it be harder to produce and claim a p2pool share (which is found...how often per minute?) than if I am mining to a pool?
20:32:05 <sech1> xmrig-proxy can even be chained
20:32:55 <sech1> Rucknium p2pool has uncle shares, so shares will not be discarded even with high latency
20:33:08 <hyc> Rucknium I think latency is a given. botnets don't have any consistency in their infrastructure
20:33:18 <sech1> but it's still better to have as low latency as possible, or found Monero blocks will have higher chances to be orphaned
20:35:25 <sech1> the only way to make miners run a node is to embed some random piece of data from the blockchain into each hash calculation, and make it depend on the nonce
20:36:16 <sech1> SSD is fast enough to read the data while the hash is running
20:36:31 <sech1> 1-2 ms latency and 10-20k IOPS is not hard
20:38:42 <sech1> it can even be added to the final Blake2b hash, so latency won't matter much (miners could queue Blake2b inputs and process them in background)
20:39:56 <sech1> then the miners would be able one monerod server with fast SSD on their LAN
20:40:02 <Rucknium[m]> I'll say again that I think it would be wise to evaluate this paper and the papers that cite it to see if someone else has come up with a workable solution to the mining pool concentration issue:
20:40:02 <Rucknium[m]> https://dl.acm.org/doi/abs/10.1145/2810103.2813621
20:40:42 <sech1> it's paywalled
20:40:44 <sech1> https://sci-hub.se/https://dl.acm.org/doi/abs/10.1145/2810103.2813621
20:40:48 <sech1> better now
20:40:51 <Rucknium[m]> I don't have time to do it myself though (and I am not really qualified to evaluate lots of the elements of the problem, anyway) :/
20:54:17 <dav0h> Rucknium[m] has anyone given an extensive look at the bot nets used? I've been peaking
20:54:45 <dav0h> its some pretty basic stuff overall but its interesting none the less
20:55:44 <dav0h> A lot of the IP's are also still public to allow for remote injects so like
20:56:38 <dav0h> why not just either ban those ips outright, ban the ones using certain files?
20:57:03 <dav0h> sorry if this has already been brought up previous
21:03:03 <Rucknium[m]> <dav0h> "Rucknium has anyone given an..." <- I don't know. How could an observer know?
21:04:46 <dav0h> Im sure we could find the wallet (s)its being dumped to by just finding a copy of the config file, ban them from there?
21:05:26 <dav0h> im not exactly sure whats achievable on the dev side of xmrig tho. solely just a researcher '
21:07:06 <nikg83[m]> dav0h: They can just keep using different subadress & nobody has access to their config files to know if it’s a botnet or some datacentre mining while their machines are idle 
21:10:33 <dav0h> nikg83[m] threres some that have been found out relatively easily. And theres not a lot of activity as far as the botnets that have been found being updated very often to any capacity. It could at the very least shut down a large amount for enough time to figure things out more reasonably. Also just spit balls
21:12:24 <nikg83[m]> dav0h: It’s upto pools to find and block, we can’t censor any address 
21:12:51 <dav0h> ok so that was my next lines of question
21:13:33 <dav0h> nothing can be done internally to XMRig to maybe correct it?
21:14:29 <dav0h> maybe just adding one little extra command thats specific to that release and if it doesn't have it it shuts off the miner?
21:14:41 <nikg83[m]> dav0h: Even if they change xmrig, it’s open source and can be modified by operators 
21:14:58 <dav0h> hmph
21:15:14 <dav0h> sad pandas
21:16:54 <nikg83[m]> Maybe one day intel/amd will make xmr ASICS and we leave botnets behind 😂
21:18:41 <nioc> As has been discussed here, botnets are not the problem 
21:19:01 <nikg83[m]> nioc: Sorry 🙏🏻 
21:19:49 <nioc> Np, not directed at anyone in particular 
21:32:56 <LyzaL> I can see botnets being negative IF as I suspect botnetters are more likely than legit miners to dump their XMR. So not only do they drive down profitability directly by driving difficulty up, but also indirectly by driving price down
21:40:13 <nioc> Oh the price lol
22:18:18 <nikg83[m]> <nioc> "Oh the price lol" <- Don’t devs get paid in xmr ? 
22:18:28 <nikg83[m]> * > <@nioc:libera.chat> Oh the price lol
22:18:28 <nikg83[m]> Don’t devs (ccs) get paid in xmr ? 
22:28:17 <ComplyLast> yes they do, even though they use euro or dollar as the unit of account when defining rates and then converting to equivalent xmr
22:28:40 <ComplyLast> also XMR inflation is decreasing daily and tail emission is about to kick in
22:29:42 <ComplyLast> also if by legit miner we mean one who invested in the equipment and needs to pay bills there is zero evidence that they would sell less than a botnet operator
22:30:24 <ComplyLast> if anything, in terms of economical incentives, they would have the financial incentive to sell more because they have costs to recoup which a botnet operator mostly doesn't
22:31:13 <hyc> yeah a botnet operator has the luxury of time, can pick and choose when to sell
22:35:39 <nikg83[m]> hyc: Sure they don’t have access to xmrbtc chart 
22:35:39 <nikg83[m]> Anyways it’s getting too offtopic here in mrl