-
m-relay
-
m-relay
<preland:monero.social> 🤡
-
m-relay
<rdorsch:matrix.org> My monerod suddenly starts crashing:
-
m-relay
-
m-relay
<rdorsch:matrix.org> is that a known issue?
-
m-relay
<rdorsch:matrix.org> Worked well before for very many blocks.
-
sech1
Enable huge pages to stop this error
-
m-relay
<jeffro256:monero.social> @sech1: what do you think about adding a weight clawback for miner transactions with a high amount of outputs to prevent the network from penalizing p2pool as much ?
-
sech1
P2Pool payouts are 0 fee already
-
sech1
or do you mean consolidations?
-
m-relay
<strawberry:monero.social> I think he's talking about big consolidation tx fees because p2pool outputs are so small
-
m-relay
<jeffro256:monero.social> yes but block reward is reduced when coinbase weight causes the block weight to go above the penalty free zone
-
m-relay
<jeffro256:monero.social> more output = more weight = more penalty = less block reward
-
m-relay
<strawberry:monero.social> is it possible to receive 2 coinbase outputs in same block by using p2pool?
-
m-relay
<jeffro256:monero.social> not talking about consolidations atm
-
m-relay
<jeffro256:monero.social> yes
-
sech1
p2pool pays 1 output per wallet
-
m-relay
<jeffro256:monero.social> u could just have 2 miner addresses, but only one per wallet
-
sech1
I think it's better to have some compact format for coinbase consolidations
-
sech1
it will save blockchain space as well
-
m-relay
<strawberry:monero.social> so if you get multiple p2pool shares, you get 1 big output from it?
-
sech1
yes
-
m-relay
<strawberry:monero.social> maybe decrease the p2pool window for less consistent but larger outputs
-
m-relay
<jeffro256:monero.social> the more you do that, the closer to solo mining you get in terms of UX, which is the whole reason why p2pool exists IMO
-
m-relay
<strawberry:monero.social> yes its closer to solo mining, but some people are surely willing to make that tradeoff
-
sech1
P2Pool main actually has smaller window right now
-
sech1
PPLNS window = 373 blocks now
-
sech1
It auto adjusts if hashrate gets too big
-
sech1
min payout is 0.00153 XMR
-
sech1
so people can already choose betwen p2pool main and p2pool mini
-
m-relay
<jeffro256:monero.social> Does it adjust based on the mempool size / historical block size as compared to the penalty free zone ?
-
sech1
No, it adjust to mine no more than ~2 Monero blocks per PPLNS window, so that each P2Pool share receives <= 2 payouts on average
-
sech1
Before that it got ridiculous - P2Pool did more than 10 payouts per share
-
m-relay
<strawberry:monero.social> while this would initially be an incentive to use p2pool, can't centralized pools also use it for cheaper payouts?
-
m-relay
<jeffro256:monero.social> Maybe I'm misunderstanding the comment, but why would it limit the number of mined mainnet blocks? So it discards successfully mined blocks ? Surely not
-
m-relay
<jeffro256:monero.social> Do you mean limiting the number of payouts per PPLNS ?
-
m-relay
<jeffro256:monero.social> strawberry: yes
-
m-relay
<strawberry:monero.social> then it benefits all miners at the expense of other users
-
m-relay
<strawberry:monero.social> that being said, pools probably wouldn't go to the effort to implement that? or maybe I'm underestimating them
-
sech1
jeffro256 it limits PPLNS window size to such size that it mines 2 Monero blocks per PPLNS window on average
-
sech1
in other words, total difficulty of shares in PPLNS window = 2x Monero difficulty
-
m-relay
<jeffro256:monero.social> ahhh okay
-
m-relay
<jeffro256:monero.social> thanks for the info
-
m-relay
<horixon:monero.social> i think the miner can set higher difficulty
-
m-relay
<horixon:monero.social> maybe im confusing with centralized pools