There is a meeting in this channel in one hour

meeting time: monero-project/meta #665

1. greetings

hello

hi

Hello

hi

Hi

it looks like jdefgh[m] has a proposal about pool mining to discuss monero-project/monero #8181

yo

yes

Yes I think it would be a good time to brainstorm ideas for limiting mining pool centralization.

banning pool mining has been discussed often in the past, it also was deployed on wownero, but it has downsides

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

Yeah, I wonder how that propposal compares to what Wownero has live for a while

Previous discussion here:

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).

EC operations are 4-5% of hash time in Wownero

wow that's a beefy hash then lol

is that like 1-5ms hash time?

1-2 ms, depending on CPU

That's RandomX for you :)

Unless somebody figures out a p2pool implementation that work with nonce-signing, it's a no-go in my opinion

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.

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

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

This is not sustainable for small miners who need to pay their power bills, while big mining farms/botnets would be unaffected

So it would both severely weaken the network and increase hashrate centralization

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

It only punishes small miners.

Destroying the village in order to save it, or how did that saying go?

nonce-signing doesn't work with p2pool. You can't know secret keys of other miners to sign for them

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.

sech1: So did already think that through?

all coinbase tx outputs must be signed with corresponding keys

So no one has looked deeply into the existing research on this? Maybe we should do that.

even if 1 output is not signed, centralized pools can use that output to get block reward

I believe we need to be very careful with any consensus change here

Maybe there is a paper out there that solves the problem that we don't know about.

correct. before the fork, one pool had over 70% of the network hash

Which problem exactly do you mean, Rucknium?

Rucknium: any interesting papers that you've found?

rbrunner: Mining pool centralization.

So not making pools impossible, just keeping them from "centralizing".

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"

the block reward system could be somehow modified to resemble p2pool's logic

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.

Yes, that's the result if you do good work for many years.

there are a few pools that are arguably better than minexmr

So more of a first / early mover advantage?

yes, also many guides are copy/paste from many years ago, they just update the date to 2022

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%.

From 25%

That's the "economical" way to deal with it. Change the incentives for individual miners.

or we can get two 33% pools that together can do 51%

hell, there are some copy-paste guides "updated to 2021" that still talked about mining Cryptonight using an RX480 using minergate

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.

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?

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

rbrunner: let's not feed google with money :D

Just brainstorming :)

Maybe less worse than murdering pool mining

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

Which makes me think: why not include p2pool in xmrig instead?

Does hybrid PoS/PoW mitigate the issue?

Make it the default option, so that people would have to go out of their way to pick a different pool instead

How do we stand with the xmrig dev(s), quite in general? Are they open for proposals?

And it wouldn't require keeping the wallet always open while mining

integrating into xmrig doesn't make sense, you still need Monero node

if you set up Monero node, you can just as well set up p2pool

UkoeHB: PoS is quite a red flag for many people

"do one thing and do it well" (c)

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)

rbrunner: I'm not well versed in the dynamics of PoS, just wondering if anyone knows how well it handles the 51% issue.

If someone gets 51% in PoS, they will always have 51%

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

There are really only three options for consensus: PoW, PoS, federated Byzantine agreement (SCP or similar). All have relative pros/cons.

actually, half of minexmr hashrate comes from HUGE whale miners

I'm talking 100+ MH/s

(The same people who have significant difficulties even running their own node, or need handholding while setting up xmrig)

why they don't mine solo, I have absolutely no idea

Well, yes, there's that too

But botnets like using public pools because there are no traces leading back to them that way

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

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.

I as the CEO of Monero would pour time and energy first into pushing that, before I burry the pools ...

Are we aware of this paper? "Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin Mining Coalitions"

how about increasing the cost of running a mega pool by increasing the hashing blob size?

we can't increase to more than what get_block_template returns

That cost would be proportional basically to the number of miners?

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.

this is 1-5 KB

Changing parameters isn't really going to change much. The affected miners would just keep mining and the distribution would be affected only slightly

So everybody has more communication, not only mega pools

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.

maybe is h4sh3d around to give an update on 7877 review?

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:

Anyone with any experience with WIKINDX or a similar system? Any comments on the matter?

sure, if you get it set up I can help add papers

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

Must have a look how that amazing reduction was achieved ...

would be nice to have a summary of changes in the PR...

reduces the output file sizes drastically so they can fit on animated QR codes

that's the outcome, not the change

Either you are from the inner circle, or you are not :)

this is mooo's work, ive just been testing it on random wallets

ok seems like we are done; thanks for attending everyone

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.

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.

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)

^That would be problematic because each block could potentially require a new cache to be constructed, making PoW verification much slower.

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.

Hmmm, right

pools will use torrents to distribute new cache

it's not hard to automate it

but it will definitely kill botnets

"end-user" 1 kh/s bots can't download 256 MB all the time

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.

128 MB/hour is much less than what a node uses

even if it's 3-4x more traffic because of torrenting, it's still less than a node traffic

we also have self-select, and xmrig even supports it, but pools don't use it

optional features like self select are not going to cut it, it must be forced to make lazy miners react

I will measure traffic requirements for a synced node, but I don't think it's significantly more than 3 GB/day

Sent 1366645440753 bytes (1.24 TB) in 103421693 packets in 2.5 months, average 200.94 kB/s

76d 20h 57m 35s uptime

how many out/in peers?

32/32

so with just 8 out peers, it should be roughly 2-3 GB/day

more like 4 GB/day

and much more if you get "lucky" and someone starts syncing from block height 0

*one of your peers starts syncing

of course you can set bandwidth limits

^ this

in any case, running a node would not be significantly different from syncing just the cache

It would be fun to see how Monero network scales to 50k nodes (we have 50k miners today)

there are currently ~11k nodes: monero.fail/map

adding large bandwidth costs to mining would probably knock off a lot of miners

UkoeHB: I’m still struggling with covid so my review is stuck, no ETA to give but it’s on top of my todo

h4sh3d: thanks for the update, get well!

UkoeHB: mostly botnets

but perhaps we would get botnets to run a ton of monero nodes :)

there are a lot of people stealing electricity who might run into problems if their bandwidth usage suddenly spikes

anecdotal

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

research though

Sure, the point is marginal miners will leave if costs increase. This is just a fact that makes '50k nodes' an improbable outcome.

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?

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.

I don't disagree - just don't pursue something like that and expect the hash rate to stay the same.

safer as in also "less electricity being spent to protect the network"

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

safer as in "you don't need to trust a single pool operator who controls half of the network"

safer as in the cost to attack the network also decreases, so it's all about tradeoffs

if profitability is there, other miners will fill the void

you're adding more costs nonetheless

ComplyLast: Currently it’s almost no cost to attack with botnets

and that wont change for the most part so long as you can mine with cpus, another tradeoff

the "cost" is roughly the cost of running a node, which is arguably quite low

<ComplyLast> and that wont change for the most part so long as you can mine with cpus, another tradeoff

ofc bar major price increases, etc

Still a far cry from hard solutions like the one implemented by wownero

ComplyLast: Making it expensive for botnets is the key, increasing their network usage will raise red flags for them

Cloud botnets won't care about network usage.

I'm not convinced that is good for the security of the network

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

Yes, botnets are bad for profitability but they secure the network.

ideally they shouldn't mine at minexmr.com

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.

selsta: How ? Even they would notice it unless they are too careless

I would propose higher ram requirements but seems some want to mine on android phones with few hundred hash vs botnets

<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.

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

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.

<selsta> "nikg83: if someone spins up 3000..." <- That’s true it will take sometime

What do you think about having higher ram requirements, is ram a scarce resource for legit miners ?

Also what happened to sha3 Asics which was being discussed while randomx was being deployed

* > <@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.

That’s true it will take sometime

What do you think about having higher ram requirements, is ram a scarce resource for legit miners (ignore few h/s phone miners) ?

Also what happened to sha3 Asics which was being discussed while randomx was being deployed

^ Higher RAM usage is not possible without also increasing the RAM usage of nodes. See the RandomX design notes.

sha3 was only an idea if randomx were to ever fail at staving off asics

tevador: I think sech1 said it's possible, it only doubles verification time for slow mode.

We definitely do not want to make verification any slower!

or double cache size with same verification time

that also means ~double node RAM usage

currently, monerod can run with ~1 GB of RAM

Most importantly, RAM requirements don't solve pool centralization problems.

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.

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.

sethforprivacy: Who was mining with 100sMh/s when minexmr to take it over 51% ?

* > <@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.

Who was mining with 100sMh/s on minexmr to take it over 51% ?

Who knows -- could have been a botnet, and if so, the real issue is pool centralization, not botnets.

If we had botnets but no pool centralization, it's not really problematic. When we ha

s/When/If/, s/ha/had pool centralization but no botnets, it would still be a huge problem./

These are not equal threats to the security of the Monero network.

<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.

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.

definitely, increasing the resource burden per miner seems like the only way to go to discourage pool growth

although the obvious countermeasure to tevador's suggestion is to use multicast

what multicast? UDP? It works only in LAN

IPv6 multicast works across routers

If we really want to destroy pools we'll just require they use IPv6 then 😅

Multicast is UDP. It only really works with video/audio streams.

unusable for reliable P2P data sharing

it would work fine for periodic cache broadcasts

I'm quite sure that would not work in practice.

I opened issue #98 to further discuss this idea

<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

there's a flip side, tevador: miners could simply start running local nodes, but still send their hashes to a pool

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

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.

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

because nobody could afford to intentionally mine

nobody could afford to intentionally mine profitably

that does not mean that the network would be invulnerable from attacks

Wouldn't it be fairly simple to modify a node to not do any verification and check block headers against the centralized pool?

it means the network would have more hashrate than it would if it was only sustained by people paying for electricity

on the contrary - less people mining overall would mean a weaker target

hyc: not necessarily

yes, necessarily. if 100% of the network was botnets, yes.

(I think?)

(WIP) it would definitely mean that the 100% botnet network is using more energy than it would be worth

trying to construct a counterexample regarding the hashrate (or convince myself that you're right)

merope: Doesn’t meant someone other entity can’t bring a bigger botnet on table to attack the network

* > <@endor00:matrix.org> (WIP) it would definitely mean that the 100% botnet network is using more energy than it would be worth

Doesn’t meant some other entity can’t bring a bigger botnet on table to attack the network

* > <@endor00:matrix.org> (WIP) it would definitely mean that the 100% botnet network is using more energy than it would be worth

Doesn’t mean some other entity can’t bring a bigger botnet on table to attack the network

the meeting already go down?

<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

unless there's something terribly broken, p2pool is already as attractive as it can get. no pool fees.

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.

I worded it weird, but further harming the competition from centralized pools is still a form of increasing the attractiveness of p2pool imo

perhaps. either way, encouraging/requiring miners to run local nodes sounds like a good thing.

p2pool actually has fewer orphan blocks

because all p2pool nodes broadcast found blocks

hyc: agree

p2pool nodes relay shares faster than monerod relays blocks, so if a share has enough diff, it will be broadcasted from everywhere immediately

I bet all Monero nodes have at least 1 p2pool node in their peers now

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

xmrig -> xmrig-proxy on a cheap no-KYC VPS -> p2pool/monerod

safe enough even for botnetters

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?

xmrig-proxy can even be chained

Rucknium p2pool has uncle shares, so shares will not be discarded even with high latency

Rucknium I think latency is a given. botnets don't have any consistency in their infrastructure

but it's still better to have as low latency as possible, or found Monero blocks will have higher chances to be orphaned

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

SSD is fast enough to read the data while the hash is running

1-2 ms latency and 10-20k IOPS is not hard

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)

then the miners would be able one monerod server with fast SSD on their LAN

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:

it's paywalled

better now

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) :/

Rucknium[m] has anyone given an extensive look at the bot nets used? I've been peaking

its some pretty basic stuff overall but its interesting none the less

A lot of the IP's are also still public to allow for remote injects so like

why not just either ban those ips outright, ban the ones using certain files?

sorry if this has already been brought up previous

<dav0h> "Rucknium has anyone given an..." <- I don't know. How could an observer know?

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?

im not exactly sure whats achievable on the dev side of xmrig tho. solely just a researcher '

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

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

dav0h: It’s upto pools to find and block, we can’t censor any address

ok so that was my next lines of question

nothing can be done internally to XMRig to maybe correct it?

maybe just adding one little extra command thats specific to that release and if it doesn't have it it shuts off the miner?

dav0h: Even if they change xmrig, it’s open source and can be modified by operators

hmph

sad pandas

Maybe one day intel/amd will make xmr ASICS and we leave botnets behind 😂

As has been discussed here, botnets are not the problem

nioc: Sorry 🙏🏻

Np, not directed at anyone in particular

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

Oh the price lol

<nioc> "Oh the price lol" <- Don’t devs get paid in xmr ?

* > <@nioc:libera.chat> Oh the price lol

Don’t devs (ccs) get paid in xmr ?

yes they do, even though they use euro or dollar as the unit of account when defining rates and then converting to equivalent xmr

also XMR inflation is decreasing daily and tail emission is about to kick in

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

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

yeah a botnet operator has the luxury of time, can pick and choose when to sell

hyc: Sure they don’t have access to xmrbtc chart

Anyways it’s getting too offtopic here in mrl