<3​21bob321:monero.social> I think you missed gui room

<3​21bob321:monero.social> And events room

<r​ottenwheel:kernal.eu> Don't give him more ideas!

<p​reland:matrix.org> Guys Monero is starting to head towards its genuine market value; another “event” is likely inbound

<3​21bob321:monero.social> Trumps conviction ?

Hashrate took a dump

Lost 37%

sxmr and nano lost 500mh each

<k​arano:poddery.com> Somebody was complaining about nanopool on Twitter earlier

<k​arano:poddery.com> Maybe they have a power outage

<3​21bob321:monero.social> Solar eclipse ?

<p​y.verse:matrix.org> Thats what you get when you touch hookers lol

<p​y.verse:matrix.org> > <@321bob321:monero.social> Trumps conviction ?

<p​y.verse:matrix.org> Thats what you get when you touch the hookers lol

<p​y.verse:matrix.org> > <@321bob321:monero.social> Trumps conviction ?

<p​y.verse:matrix.org> Thats what you get when you play with hookers lol

<w​oodser:monero.social> Fengzie Yang: I replied to your DM, but matrix often has problems where DM isn't working, in case you don't see my replies

We need people to start mining on not-nanopool

<s​yntheticbird:monero.social> Gupax is neat for that. Maybe a reddit post to remind people to use it when they're bored

the 1gh fhat disappeared yesterday (500mh from sxmr and 5ppmh from nano), if it returns and all goes to nanopool, theyll have 1.7/2.9gh

Gupax is nice and simple, but p2pool bloats the chain, especially for small miners

<s​yntheticbird:monero.social> bloats the chain?

<s​yntheticbird:monero.social> with coinbase outputs?

with coinbase consolidations

<s​yntheticbird:monero.social> ah yeah

<s​yntheticbird:monero.social> I get your point but I would honestly prefer a little bloat per block than a 51% attack. What other pool could we recommend at the moment aside of p2pool

Greater than hundreds of times more bloat than a solo block

Thats an uneducated statement, no offence.

it takes > than a whole block to consolidate 1 block reward

And it literally crashes nodes

p2pool is excusable / not that bad if you have like 100kh

crashing ndoes is due to a bug in monerod, not the transaction itself

yeah ^

hopefully fixed soon™

<s​yntheticbird:monero.social> if bloat is a long-term issue the oom issue should be fixed by then

mrl 108/109 fix it, but soontm and fcmp might move the goalpost there as well

<s​yntheticbird:monero.social> yeah, well thx delays

<s​yntheticbird:monero.social> Whats the maximum amount of outputs per coinbase tx?

Not sure if there js a hard max, but mini is doing about 600 atm

~0.0005xmr payments = 1500inputs to consokidate into 1 coinbase (0.6). thats 3 entire blocks

<s​yntheticbird:monero.social> indeed concerning

And 3 blocks worth of fees. Its expensive as hell too

without mrl 108, p2pool shouldnt be used by small miners

Btw. Consolidating 1500 i puts to make 0.6xmr over 3.33 blocks = 0.15xmr in fees (25%)

Inputs*

Without 108, mass adoption of p2pool is bad / terrible for the blockchain.

solo > mining with a centralized pool that uses p2pool (like aterx) > centralized pool (like monerop.com) > p2pool

Even for #2 = mining on a centralized pool that uses p2pool, aterx (250kh) is being paid outputs of 0.02xmr. They dont have to consolidate any more than necessary to payout miners, so not much worse bloat-wise than if they were a completely centralized pool (monerop, 250kh 0.05min payout)

would make solo mining vs p2pool with a couple of 1kh/s help also to counter the risk of 51% attack? Or is it then like pissing in the ocean?

<s​yntheticbird:monero.social> Interesting. I hope a mitigation will be found. In the near-term, we still need to recommend people pools to mine on in order to balance things up. Gupax just happen to have excellent UX. Monero GUI solo would also be something to recommend according to what you said

GUI mines slow compared to xmrig

there are plenty of small pools to choose from

<s​yntheticbird:monero.social> downloading xmrig, setting up config and choosing a pool is already making 90% of people flee

xmrig will generate the config for you

Gupax runs XMRig

Congrats to the 10%

but I wanna be the 1%

So Gupax is just as fast (minus the small overhead for GUI)

Who would have thought making money / mining crypto would require a bit of thonk

sech1: is gupax just for p2pool?

<s​yntheticbird:monero.social> sech1: ofrnxmr brought the concern about on-chain bloat caused by p2pool coinbase rewards.

<s​yntheticbird:monero.social> thus the discussion around UX outside of gupax(p2pool)

Gupax does (succeeds mostly) the uhh.. thing that gui doesnt do for you to give more hashes

<s​yntheticbird:monero.social> nioCat, afaik it is

Gupaxx adds xmrvsbeast raffle to the mix

<r​ottenwheel:kernal.eu> plowsof matrix!

<r​ottenwheel:kernal.eu> Do better!

P2Pool reduced the bloat more than a year ago. Main P2Pool pays in bigger chunks (depending on pool hashrate)

Can't the same be applied to mini chain ? last mined block (3160897) have ~590 outputs in coinbase tx.

<r​ottenwheel:kernal.eu> plowsof @plowsof:matrix.org mate.

<r​ottenwheel:kernal.eu> 😂

Mini chain also has it. It will reduce outputs if it gets higher hashrate

Oh cool, so in a long-term scenario, can we recommend p2pool mini ? Or will it not be enough to avoid bloat

The bloat is overrated

Consolidations take around ~530 bytes per input

P2Pool mini generates around ~2200 payouts per day, or only 1.1 MB/day in consolidations

P2Pool main finds many more blocks, but it pays in larger chunks, so it generates even a bit fewer payouts (~2000/day)

Reassuring to hear, I crave for 2MB per day in exchange to 51% resiliency

maybe a stupid question but if an input is 530 bytes in average. How is p2pool.io/explorer/tx/de943ab20371b…32d610983aa9af110c84debe7687ef8dc88 only 22 kB? Compression? or did I missed smth?

<b​awdyanarchist:matrix.org> Listening to a spaces rn where they're talking about "silent payments" ... which is merely stealth addresses, cutely named, normies thinking now they've got Privacy!

<b​awdyanarchist:matrix.org> They were now just talking about "how to make a transaction not look unique or stand out from other transactions"

<x​mrfamily:matrix.org> I just found out about silent payments. I have zero interest, but thought was interesting how vik and sethforprivacy making it seem revolutionary

SyntheticBird it's 22 kb is because it's coinbase output (39 bytes per output). But it later becomes an input in the consolidation tx, and then it's 530 bytes

sech1 make sense. thx

Revuo Monero Issue 197: May 23 - 30, 2024. revuo-xmr.com/issue-197.html

Sech, thats just playing with words.. if the pool _difficulty_ increases, people find less shares. Main's payout window pays a 500kh miner outputs of 0.001

Thats 600 outputs for 1 coinbase

Sorry, 0.002, 300 outputs for 500kh.

Saying "its only 2200 payouts" is ignoring that its still 300x more chain space AND that it literally takes up an entire block for s 300kh miner to consolidate 1 coinbase

Mrl 108 fixes the issue. And it IS an issue. Mass adoption of p2pool is not a non-isssue. 300/1 is not a non-issue. 1500/1 is not a non-issue. There are Only 720 blocks per day. you csnt have 1 person using >1 blocks just to spend spend 1 coinbase

Its not a p2pool issue, but it is an issue exposed by p2pool.

<r​ottenwheel:kernal.eu> Yeah, wtf sech1?

Where my math is wrong?

Main payout is 0.00174 right now, not 0.001

i changed my statement ans rounded up to 0.002

300 outputs for 500 kh, yes. But p2pool will need to find 300 blocks for that, and it will take a few days

it's still 1 MB/day from p2pool main and 1 MB/day from p2pool mini

p2pool main only finds ~70 blocks/day

Mass adoption will increase p2pool hashrate, then it will automatically increase the minimal payout

"you csnt have 1 person using >1 blocks just to spend spend 1 coinbase" <- dynamic block size algorithm says hello

<a​nhdres:matrix.org> public version of Monero Garden finally live at monero.garden

<a​nhdres:matrix.org> my comment in the original CCS page: repo.getmonero.org/monero-project/c…als/-/merge_requests/346#note_24804

monero-project/research-lab #108 would of course be nice to save on fees when consolidating inputs

108 saves massively on blockspace

Im not sure if/how 108 would work with fcmp, if at all, but 108 would save us a lot of trouble

"dynamic block size algorithm says hello" << not a solution to taking up hundreds of times more storage space vs solo, and tens of times more than pool. Pools have larger minimum payouts vs p2pool (ie 0.05xmr vs 0.0004-0.002 currently), but still split the coinbase into smaller sizes vs solo (ie 0.05 vs 0.6)

Instead of 3 tx/block (450 outputs), with 108 you could consolidate ~7000 p2pool outputs per block or ~2500/tx

only takes 2160 tx consolidations to take up 24hrs of blockspace and force users to pay higher fees. 432xmr produced/day, Thats 324k outputs * 0.002

=648xmr in p2pool outputs to own a full day of blockspace. You dont want mass adoption or the majority of blocks will be consolidations or will cause blocks to expand inorganically. Mrl108 fixes this under the current ring signature model

monero.garden Hm

"648xmr in p2pool outputs to own a full day of blockspace" p2pool can't mine that much even in theory because the whole network mines 432 xmr/day. Don't twist the number

*numbers

Dynamic block size IS the solution

I'm for MRL108, but for a different reason

not what i expected it to look like: "Overall, it's design should mimic children picture books" looks like a monerodocs thing. quartz.jzhao.xyz

<a​nhdres:matrix.org> we'll keep moving apart from the standard design and towards a different aesthetic. It was never intended to look (or read) as a 5yo picture book, the layout maybe, but the intended age is more like 10-12

<a​nhdres:matrix.org> and above of course

<a​nhdres:matrix.org> with the illustrations on it it'll look way more book-like

anhdres you scared me for a moment there, we need to read your comment first repo.getmonero.org/monero-project/c…als/-/merge_requests/346#note_24804

"p2pool can't mine that much even in theory because the whole network mines 432 xmr/day. Don't twist the number" << of course not. If it mined 432/day it would use 66% of blockspace if people consolidated regularly. I said "the majority of blocks will be consolidations" 66% is a majority

And thats assuming people always consolidate max size transactions. Less than max size tx scales even worse

And dynamic blocks are not the solutions. "a different reason" = fees? Fees and blockspace are linear afaik. 7000inputs for 100kb vs 150 is a massive difference

2/3 of a block when you have 500kh doesnt scale. You need to increase blockspace to 500kb to account for 2 transactions! Lol!

Dynanic blocks dont solve bloat, they make bloating easier and cheaper. P2pool can be used to attack the network and im sure you know that

108 and 109 do nothing against people who want to actively attack the network with tx that mimic p2pool (mordinals or split > reconsolidation), but they prevent p2pool from accidentally doing it

Im not telling people don't use p2pool, im sayinf without mrl108 p2pool a 5kh miners on mini has to pay terribly expensive fees (25%) and creates 3+ blocks worth bloat to spend 0.6xmr

P2Pool produces ~2000-2200 inputs/day, and it doesn't change with adoption. It was a problem in the original release, but now it reduces PPLNS window size to reduce the number of outputs per block

More hashrate -> more difficulty -> larger min. payout

and if someone spins up a p2pool small and a p2pool micro, because they want rewards more often?

It is tuned in such a way that each found share is paid out in no more than 2 Monero blocks on average

Mini and main are the o

and the number of shares per day is fixed in p2pool

2k inputs/day for each p2pool instance

right.

Bloat is not a problem at this scale

key point "at this scale"

it's 1 MB/day, maybe 1.2 MB/day

Even with 10 p2pool chains, it's 10-12 MB/day

Nothing

3.6 GB/year

You can buy 1 TB ssd for cheap now

key point "at this scale" <- p2pool PPLNS window algorithm is designed to limit number of outputs per day to 2-2.2k, no matter how many miners are there. Now another question is how many concurrent p2pool chains are running, but I doubt there will be many in the future

Greed tells me that once difficulty gets too high that people will want their payouts. If all blocks were mined by 1 p2pool, the outputs would be 0.196xmr minimum. "how long does it take to mine that much" = 1/3rd as long as solo mining, and incredibly difficult to find a p2pool share

And if there are 5 p2pool chains with 80%, 15%, 5%, 3% and 2% of the network hashrate, every miner can find a pool that matches their hashrate

So really there's no need for more than 5 chains

5-6 MB/day is the max bloat with current transaction sizes

or maybe 40,40,15,5,3,2 - that makes it 6 chains

actually p2pool-mini is 0.5% now, so maybe a few more chains will be needed. It's an interesting math task to find the optimal distribution of pool hashrates to satisfy all miners

<s​yntheticbird:monero.social> cc Rucknium ?

My gut feeling says something like Fibonacci sequence will be the best 1, 1, 2, 3, 5, 8, 13, 21, 34, ...

<s​yntheticbird:monero.social> lmfao

<s​yntheticbird:monero.social> Golden ratio strikes again

<3​21bob321:monero.social> Golden shower*

<r​ucknium:monero.social> SyntheticBird: IMHO MRL #108 "Coinbase Consolidation Tx Type" would be a good idea for the next hard fork. If we still have rings in the next hard fork, it helps privacy for most users and reduces blockchain size and cost to P2Pool miners. If the next hard fork is FCMP, then we don't really get privacy benefits, but we still get the blockchain size and P2Pool cost benefits.

<r​ucknium:monero.social> If the next hard fork increases fee per byte and/or tx size a lot (through FCMP or a large ring size increase), then MRL #108 would be important to keep P2Pool competitive with centralized mining pools. I do some calculations in github.com/Rucknium/misc-research/b…ck-marble-optimal-fee-ring-size.pdf page 11, lines 240-284.

<s​yntheticbird:monero.social> > With the ring size 60 and 70 nanoneros per byte scenario considered above, about 57 percent of the value of that output would be consumed by the cost to spent the output in a transaction’s output.

<s​yntheticbird:monero.social> Ouch!

In this case P2Pool would have to hard fork too to increase the minimum payout to 0.003 XMR or even more.

If MRL108 is not implemented

0.003 XMR is more than 24 hours of mining at 10 kh/s, so payouts will be rare for low hashrate mining

*miners

It's better to implement a compact coinbase consolidation tx type to keep min payouts low

<n​ononynous:monero.social> The control port of tor is really useful and should be used in binaries

<n​ononynous:monero.social> It helps isolating transaction circuits or switching circuits when refreshing a wallet and for monerod it could autosetup the --anonymous-inboung + --proxy arg