gingeropolous ccs proposal to beef up / maintain infra for MRL reddit.com/r/Monero/comments/un0wqi…ccs_request_more_storage_for_monero

<plowsof[m]> "gingeropolous ccs proposal to..." <- for Rucknium to be precise

not really. man i wish matrix had an ignore button. ah well

it does

click on the account, there's a red ignore button at the end

oh, just realized that gingeropolous left :/

nice. thanks

meeting 2.5hr

meeting time: monero-project/meta #702

1. greetings

hello

hello

Hi

Hi

Hi

hello

2. updates, what is everyone working on?

Hi

Been doing a lot of work on BCH projects, including prototyping various data structures.

Me: I’ve been feature engineering for my magic grant, I have a neural network built that is achieving roughly the same accuracies as the other models.

I have basically done everything else, that was blocking me from continuing the Decoy reimplementation, including the time consuming monthly report.

After this, I made the next step and confirmed (so far visually), that my Python interpretation of the gamma distribution's parameters is the same as the original Monero's. See here:

Ruck: if nothing stops me, I should have it done until the end of the next week.

me: Continuing work on Seraphis (will write unit tests for my input selection solver today, next step is enote scanning workflows). Also pushing multisig PR 8149 forward (finally done with all the rebases). The existing multisig implementation is completely busted, so it's important to fix as many bugs as possible with the next HF. However, as ooo123ooo123[m] rightly points out, we need more reviews for increased

confidence that all the bugs/protocol inadequacies have been resolved (if there are any takers, please help with that, the protocol is too large for any one person to identify every possible weakness).

Looks great! Just a typo: Those are the PDFs rather than the CDFs

re-reviewed 8076 (rbrunner's PR to reduce trips to the daemon on wallet refresh), dug deeper into the Dandelion++ impl while doing so, and have been working through patching some daemon connectivity/reliability issues I noticed in the process (txs get stuck after failing to relay on 1st try, and connections are dropping leading to sporadic failed submits/warnings in the logs). Getting to the bottom of these specific connectivity

issues I believe will give me momentum into reviewing perfect-daemon's 7760 that deals with similar issues

jberman: Great. Thank you. I have heard from many people that `monerod` has reliability issues.

Yeah, 7760 is waiting for a long time already, would be sad to waste it because nobody reviews

3. discussion, any questions/comments/things to talk about?

Tbh I'm hoping some of 7760 can be knocked out with smaller bite-sized patches like vtnerd pointed out in his review of that PR; that PR is fairly large and difficult to reason through

Would anyone mind if I opened a PR for the research-lab GitHub repo to update the README a little? For example, addition MoneroResearch.info , link to list of open research questions, explanation of where to find meeting announcements, etc.

Also, there is a PR waiting to be merged to add previous meeting logs.

go for it

jberman[m]: the problem is it fixes a number of interconnected bugs, so one large rewrite was the easiest way to go for it

Is 7999 still being looked at for the fork? monero-project/monero #7999

for this fork? no

Bulletproofs++ will be included into this fork

BP++?

only 1 +, not 2

there is also ++ now but that isn't implemented yet

at least there is a paper for it

the BP++ paper said it was slower than BP+ (in their tests), so it's usefulness remains to be seen

maybe batching can amortize those costs

<Rucknium[m]> "Looks great! Just a typo..." <- Fixed. Thanks.

Do people have thoughts about gingeropolous 's CCS proposal for more storage on the research computing server? repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/317

In the short term, the storage increase is important for analyzing user behavior on other blockchains.

Rucknium[m]: Would it be useful for BCH work too ?

We are not using it for BCH-focused projects. However, as discussed in a recent meeting, I will be analyzing some key medium-of-exchange cryptocurrencies, including BTC, BCH, LTC, DOGE, and maybe DASH.

Not much to say I guess - improving the tools for the job is always a plus imo

<UkoeHB> "the BP++ paper said it was..." <- "This code is not competitive with implementations in C or Rust or that use highly performant libraries for the elliptic curve operations." That's reference implementation without any optimizations

yes, hence 'remains to be seen'

<Rucknium[m]> "In the short term, the storage..." <- Exactly this is what ArticMine suggested me to do with my future fee vs blocksize analysis. This will help proving Monero's superiority.

EC op count should give a fairly good indication.

Since Monero will adapt to the situation better. We know it.

So yeah. I'm for the gingeropolous 's CCS Proposal.

BP++ is also a very new paper, so it would be good to let it marinate (and maybe do some poc and perf testing if we can find someone able and motivated to implement it).

Anything else anyone wants to say? Otherwise we can close the meeting early

On mining pool concentration, I want to point out that my suggestion to try to have minexmr.com implement a dynamic pool operator fee got lots of upvotes on Reddit. Which doesn't mean too much, but suggests that the community would be OK with the idea: reddit.com/r/Monero/comments/uk8pab/comment/i7o6bt6

Of course the key hurdle is whether minexmr.com itself is OK with the idea

Good luck. I wrote a patch to do that automatically years ago, nobody cared.

and how many of the upvotes are from minexmr miners?

<UkoeHB> "BP++ is also a very new paper..." <- The hardest part is to check it's security. Implementation is easy

We will likely continue to deal with this problem. According to my very preliminary model, minexmr's share of blocks found increases when the fiat/XMR exchange rate declines. It may be that miners who use minexmr are less sensitive to depreciation of XMR.

Such a dynamic pool fee would work if miners were picking pools "dynamically", but I think it would just be "free money" for the pool operator as-is

yeah if most miners are "set it and forget it"

ooo123ooo123[m]: well if you want to implement a proof-of-concept, I can spin up some perf tests

We know that there is a large botnet concentration on Minexmr, so they are definitely "less sensitive to depreciation"

yes, minexmr is probably the default pool in many botnet guides

merope: How did you check that ? Is it public knowledge ?

And even if mining configuration were not "set it and forget it", we still have the issue of withdrawal minimums. Many small miners start mining on Minexmr, get told to switch, but stick around because they can't withdraw their payouts yet

People are very attached to those 1-2 dollars worth of xmr they took weeks to mine

<Rucknium[m]> "On mining pool concentration..." <- Pool will not commit suicide this way, so it will not help at all. And if pool decides to commit suicide then another pool will pop up and replace it

Frankly if pools will not change behavior to reducing concentration, then a protocol change may be in order, in line with tevador's MRL issue #98. I think we have been hoping that p2pool changes things, especially now that it is integrated with the GUI wallet. But if things don't change, what do we do?

tevadors boolberry-like thing might work

I don't think that others pools can just grab market share so easily. minexmr's hashrate share is the product of years of inertia.

though if the majority of that hr is botnets, they'll just hide behind a proxy

but i guess at some level it will still add costs to the pool, which will drive the fee up, which would hopefully get ppl to migrate to different pools

One thing that could help is (1) xmrig auto uses the pool with lowest hash rate in a set of pools it knows about and (2) a common api for pools to "exchange" pending balances, similar to how banks do settlements.

It'd rely on pools being onest, but the current system already does.

Also relies on someone to do the code...

(this is to counter the "people are very attached..." point)

Might rely too much on cooperation though.

yeah.

Though if you don't cooperate, you get bumped off xmrig's list ? Might be enough of an incentive.

right now there's relatively little cost of being a big pool

Does xmrig have a builtin list atm ? If not, it'd also add a centralization aspect.

there's no built in list in xmrig

Actually, nvm, this adds nothig on top of p2pool does it. Ignore what I said.

It would rely on trusting both pools - but given that you were using one pool and are now switching to the other, it implies that you are trusting them already to hold your balance

but there is a list at xmrig.com/wizard#pools

The main issue I see with the balance transfer is the setup and the tx fees every time someone wants to switch

this seems very top down

sech1 perhaps add a warning next to minexmr's name? Or remove minexmr from that list?

That way, if somebody really wants to mine there, they'll have to add it manually

that would be censorship

Might be enough to deter a clueless newbie

clueless newbie don't use this page

they usually watch some youtube video or google "how to mine monero"

I've pointed countless newbies to the wizard (don't know how many have actually used it though)

and find a guide that tells them to use minexmr

and most noobs (i was once a noob) want to see a payout to see that its real

so they go for the one that'll give them a payout the soonest

And it would not be censorship - they still *can* mine there, they'll just have to add it as a "custom pool" instead of going off the preconfigured list

if the noob sticks around they may change pools. but i imagine it would mainly be for a lower fee

The earliest payout is from pools with the lowest withdrawal minimum

we are at the end of the hour, thanks for attending everyone

The earliest payout is based on that minimum, the pool hash rate, and luck.

earliest pending balance shows that it is working

are there any downsides to monero-project/research-lab #98 that aren't apparent?

every miner would have to run a node

not as i understand it. the pool would have to deliver a chunk of data every n blocks to a miner

not realistic for a big pool

isn't that the point?

they could use some CDN though

gingeropolous: It's can be mitigated with patch for xmrig and modification from pool side which will deliver hash of whatever is added for hashing

useless

thats more $$, which increase the fee %

Mitigated is the wrong word. It's additional traffic for pool miners

having own node locally will be more efficient

I think the main concern about reducing or eliminating the viability of pools is a dramatic reduction is hashrate, which would harm blockchain security.

Rucknium[m]: Are you just copy/pasting answers of others ?

this wouldn't necessarily reduce or eliminate the viability of pools though. it would just encourage distribution

I don't know how much a pool operator would need to pay for CDN, but I don't think it will cost them more than they already pay for servers

sech1: It's easy to write dumb daemon that will maintain only 10GB of blockchain state that is needed for mining

Are you implying someone should never have an opinion another shared ?

It's unclear. Maybe you are being an asshole. Or both, you never know.

Can you explain which (or a third possibility I did not think of) ?

it's easy to modify the proposal to require all blockchain data, not just 10 GB

sech1: Data can be requested asynchronously from other nodes, no problem

Oh wait, I forgot, I already asked to explain something, and you did not bother.

So I know now.

I'll still wait for a third asshole time before /ignore, due to the first message about an interesting paper.

(might have been a mistake)

ooo123ooo123[m] it's still 256 MB of data download every 64 blocks, traffic usage will be the same as just running the local node

right, but for a pool operators, now they have the cost of delivering 256 MB of data * (number of miners)

sech1: 33KB/s isn't a problem for miner

sech1: Would the pool necessarily be the one sending out the chain data? Pool miners could just operate as normal listener nodes on the network to get chain data, then talk to the pool for the mining part (while I was typing, ooo123 made this point). Rather than significantly reducing pool dominance it might just reduce overall hashrate (reducing the cost of 51%).

<Rucknium[m]> "I think the main concern about..." <- Note that the proposal in issue 98 would make centralized pools harder to run, but it would not eliminate pools entirely

33 KB/s is a problem for botnet miners which are the majority on minexmr

So, with a proper implementation, it could potentially shift the balance further towards p2pool

33 KB/s per each botnet worker is a lot

many are on poor connections

sech1: Real botnet machines has enough free HDD space for mining

s/has/have/

But it would make the botnet even easier to spot

This direction is just making mining node heaver for everyone without achieving the goal

gingeropolous: Due to that, wouldn't the proposal incentivize pools to ban low-hashrate miners? If it is a cost per miner rather than cost per hash.

"Hmmm, my cpu usage is often 100%, ram usage 2GB higher than normal, and now I have lost 10GB of disk space and my connection is always pegged"

but isn't mining way more resource intensive that running a node?

than*

just on the CPU

it is, but on in disc space

merope: Botnet victims are smart enough to not notice it

If pools expect all their miners to download blockchain data from the network, wouldn't this really clog up public nodes (assuming pool miners are optimized so they don't mirror the chain).

?

Rucknium[m]: In that case, those miners would still have to move to another pool (which they would not have done otherwise). They are low hashrate, but still better than nothing

Not necessarily in cost if the mining is done during the heating season in a building heated with electricity

^

gah, ment ^ for merope

If one replaces electric resistance heating with mining there is NO additional electricity cost

<moneromooo> "Are you implying someone..." <- People with their own opinion usually can defend it. That wasn't the case there

Besides, botnets often [citation needed] rely on swarms of low-hashrate workers - so such a ban policy on the pool side would force botnets to use proxies or spread their hashrate elsewhere

ooo123ooo123 this topic has come up before, and the notion that killing pools would reduce network security is correct and has been discussed before

I did not see any request to defend it. But an opinion is not necessarily based on facts and logic. It could be based on feelings (though in the current case, I agree it probably doesn't have a place).

In the feelings case, there is no real defense since introspection about one's feelings is pretty much impossible.

(to a fairly large extent anyway)

M5M400 didn't respond to my cost estimate request in pools.

It "would be nice (TM)" to see a detailed study on the impact of that proposal on mining requirements, as a function of how much of the chain you need to lookup and how often

(I agree with what merope just said btw, I used to think pools should be taken down a notch, I now think it'd be more loss than gain, though that is of course a guess, absent the actual attempt)

merope: Discussion doesn't prove anything. Why ?

IIRC wownero did switch from "pools ok" to "trying to disincentivize pools", and hash rate went down IIRC. anyone knows whther true, and whether it has recovered (or maybe hash / price ratio) ?

Wownero is consitently ~2x more profitable to mine

so I can say hashrate reduced by 50%

2x more... than monero ?

ooo123ooo123 If you'd read the previous discussion, you'd know. Otherwise, by your logic we'd have to redemonstrate the entirety of mathematics every say that 2+2=4. Stop polluting the channel if you have nothing to contribute

yes, than monero

Was is sinilar to monero before ?

yes

Thanks.

thank to MoneroOcean and other switching pools

wownero is still randomx, right? just enforced solo mining

merope: Any short summary why ?

its a randomx variant.. some of the parameters changed, but its essentially the same (CPU centric)

Oh right, 1MB cache was it?

it's randomx with 1 MB scratchpad, so more favorable for Intel CPUs

Rx/wow

A bit lighter with higher hashrates

ooo123ooo123: The log of the previous discussion is here: libera.monerologs.net/monero-research-lab/20220216

I wonder if we could look at extra_nonce of the wownero blocks before and after solo_mining and try to compare hashrate distribution from that

afaik, the wownero solo-only prevents p2pool from working.

Sorry, tx_extra length

Though I doubt there would be an exact correspondence between tx_extra lengths and individual miners

i think if that weren't true, solo-only would be more ... attractive..?

Yeah, if p2pool were still possible with solo-only it would be the perfect solution

Very unlikely. Pools have a special length (the zone117x based ones at least have a 4 byte chunk (5 with length I think) extra data which non pool will not usually have.

i wonder if we could do that thing that other networks have done where they split up the PoW. Here, instead of splitting between different PoW, we split between solo blocks and pool blocks

Some pools watermark their blocks for... asshole reasons. Though since pools usually list their blocks, it doesn't really matter in practice.

(and that watermark is data in extra too, which means specific length typically)

Well, some pools, at least one pool.

it'd be interesting, because a solo miner could contribute to both blocks

but a pool could only contribute to one

though that could be more convoluted than its worth

contributing to both blocks = computing two separate hashes

so their effort would just be split between the two sides, and you'd be back to square one

naw, those protocols do something like every even block is X, and odd block is Y

so with tevador's proposal, pool traffic would be 85 GB/month/miner

1000 miners = 85 TB/month, or $500 to pay for a CDN

and its currently ....

CDN from OVH, for example

moneromooo: wownero hashrate when they went solo

so yes, this proposal just adds traffic toa list of miners' problems

not so much changes for pools

blargh

w[m]: missing sentence fragment ?

and this proposal will probably wipe out small pools due to increased costs

only big pools will remain

so the effect might be quite the opposite of the desired

.hrm

sech1, do you believe in 1000x-3000x multiplier for p2pool payouts frequency relatively to solo mining too ?

I don't "believe". It can be calculated

network diff / p2pool diff = multiplier

currently it's 2185x for p2pool-mini

assuming that each share give 1 payout

which is not true in general case

so real multiplier will be smaller

unfortunately, i don't think we can expect the same result as the bitcoin mining network. due to the lower barrier of entry, we'll have an eternal september kinda thing, so participants won't come to the realization that they need to spread the hash

sech1: how do p2pool payouts compare to the fee cost of spending a single input?

though some bigger miners will find multiple shares per payout too, so... would the average still be 1?

i think bitcoin pulled it off because the participants are more professional level

if you combine many inputs, the fee will be < 1% of the amount

What's about multiplier for "equal amount payout frequency" ? e.g. time to get the same amount with available hashrate from solo or p2pool mining ?

it will be worse after July fork though

sech1: What's the real multiplier then ?

never consolidate, just hodl till the dust buys a house.

The real (long term average) multiplier depends on your hash rate, so there is not one single one.

real multiplier depends on pool luck and individual miner luck

sech1: I mean specifically the differential fee from incrementing the number of inputs (this math is important for input selection).

ooo123ooo123 the *average* time to get the same amount will always the same, because it only depends on your hashrate vs network hashrate. What changes is the variance. Solo mining is the maximum variance (all-or-nothing, and it can take years on low hashrate to find a block), pool mining is lower variance the bigger the pool.

I can only estimate average numbers (see above)

UkoeHB adding 1 input adds ~520 bytes to the transaction weight

so it's quite cheap

(and of the p2pool hash rate too)

sech1: average real numbers

is ?

the amount of XMR mined? It's the same over long enough time

520 sounds like a lot. Are you sure ?

ooo123ooo123 why don't you try calculating them yourself, and then we can compare notes?

he can only criticize

<sech1> 1000 miners = 85 TB/month, or $500 to pay for a CDN >>> wait wait. With this estimate, minexmr would have a $6k / month CDN cost

what the current min fee per byte, and what is the current p2pool payout?

moneromooo that's from my experiments (100 KB transaction = 194 inputs)

A ring... 16 outs, 32 bytes maybe. Amount, 6 bytes. Key image, 32 bytes. Various lengths, a handful of bytes.

gingeropolous that's peanuts for them

They currently get $12k / month in fees

Amount probalby 1 byte even nowadays.

moneromooo: seems right, seraphis is around 700-900 bytes per input I think

Hmm. I wonder what I'm forgetting then.

merope: I've already said it's <= 12x

Oh. Signatures :D

I'm trying to understand how you're calculating

UkoeHB Minimum payout = Monero block reward/2160, ~0.0003 XMR

yes, those bulletproofs take a lot of tx space

BPs are for outs.

oh. anyway, it's 515-520 bytes per input from what I can see when I sweep p2pool payouts

Yes, I'd just discounted sigs, my mistake.

merope: ok, and what is the min fee per byte?

4000 piconero

Lowest fee I'm seeing right now is 0.000004257869 per byte

will be when we hit the tail emission

So a single payout will be able to pay for its own spend

yes

otherwise I wouldn't make 2160 the default

Though the usual pattern is for miners to aggregate all payouts with a sweep

I wanted to make it bigger, but the fee calculation didn't add up

yes, sweeping many inputs is ~3x more efficient

July fork will increase fees almost 5x, this will be sensitive for p2pool miners

is that payout ~150x the fee? ok

the very smallest fee*

after the fork, sweeping minimum p2pool payouts (<0.0003 XMR each) will cost 4-5% of the amount

so mining on p2pool-mini and getting more than 0.0003 XMR per payout will be more important

but it won't matter "in the future" (c) when median block size increases a lot :D

and we'll have small fees again

I also thought about adding "0-fee" transaction broadcasting between p2pool nodes. They can still mine 0-fee transactions from their own miners

mmmmm yes

but this will make such transactions stand out, so I'm not sure

i mean, consolidating that dust makes it stand out

true

it's already easy to spot

let alone having your xmr address shared amongst the p2pool members with your ip, so ...

an observer who saves all p2pool blocks knows all inputs and if he/she sees a tx with > 100 inputs, each of inputs has a p2pool payout to the same address in its rings, then it's obvious

im still trying to get through my head how taking $6k out of minexmr's $12k monthly inflows wouldn't do much

they would just increase the fee to 1.5% and get 18k/month

and smaller pools would just go out of business

while the fat one dries, the thin one dies

yeah i guess 1.5 isn't that far from 1.0, and supportxmr 0.6% compared to minexmr 1.1% indicates that its all hogwash anyway

Maybe what's needed is people to make flashy youtube or tiktok videos showing one click p2pool setup.

:)

Unironically yes

clearly we need asics

so we can have mining farms that know how to distribute hashrate

The main hurdle is the "one click setup" part

Would it count as one click if you have to install python and wxwidgets first...

we have zero click setup aka botnets

one click, disable antivirus, sync the blockchain....

well, conclusion is tiktok

ooo123ooo123[m]: This PR monero-project/monero #8149 has stabilized after a bunch of rebases, cleanup, and some review comments (sorry for the messy commit history). Do you want to review the changes?

.merges