before I make this the default on qubic-snooper.p2pool.observer/tree can anyone check any improvements here?

it's SVG, with clickable links :D

plus logos

you can hover on blocks to also see other info, or click on them to get explorer (and p2pool page for p2pool blocks)

DataHoarder: looking good, but both versions of yours show 3495570 as orphaned will Ruck's xmrconsensus doesn't show it orphaned

that was a recent block, I haven't checked further back

check again, nioc

now 3495570 also has the orphan in moneroconsensus :)

yes, just refreshed

(sometimes not all can be pushed to it)

yeah didn't make sense :)

the way to push orphan alt blocks across monero is janky to say the least

sometimes specific peers are dropped

also displays using the data from tips.txt irc.gammaspectra.live/8dcde8c577001ddd/image.png

mempool is quite active, meanwhile qubic is only adding 0-10 txs on their blocks, and most of these txs are their own

others are adding 50-100 txs+

so qubic is missing out on all the txs fees, for recent ones that's like +0.07-0.15 XMR per block

fees have been high lately, might be specifically because qubic is slowing down the network

<mr_x_tcv:matrix.org> > <@chowbungaman:matrix.org> PoW “Maxi” @mechanikalk of @QuaiNetwork on defeating selfish mining attacks in Monero by upgrading its PoW system with “Work Shares”. He is already working on the Pull-Request!! 🤯 Is this the way ??

<mr_x_tcv:matrix.org> This may very well be the best solution for Monero, and would reduce Qubic's reorgs to 1 block deep max. The developers here should really take a serious look at implementing workshares in Monero. Apparently, its implementation would effectively make solo mining profitable with payouts every other day, and further decentralize the network, much like P2Pool.

<rucknium> @mr_x_tcv:matrix.org: If Workshares are the same as Proportional Rewards Splitting (PRS), described in Aumayr et al. (2025) "Optimal Reward Allocation via Proportional Splitting" arxiv.org/abs/2503.10185 , then I don't think it limits re-org depth at all. PRS would increase block verification time to possibly unaccepta [... too long, see mrelay.p2pool.observer/e/sL66nLMKdTBYMGJN ]

<vtnerd> I've had discussions on Twitter with this crowd, and this is the correct paper

<rucknium> I also think that PRS may actually be worse for solo miners because they wont be able to place most of their work shares in a block within the reward window (most of their hashes will be out of date). I think that's how it works. Tell me if I am mistaken. The paper doesn't discuss this solo mining problem.

<vtnerd> They mention that the randomx issue can be mitigated by validating work shares as they come in - the new block arrival just has to lookup in a cache similar to fluffy blocks. However, it definitely makes "full" sync time worse

<rucknium> I was optimistic about PRS on a first read, but tevador suggested that countermeasures that use "more frequent hashpower sampling" should be ruled out because of the block verification slowdown.

<rucknium> in this issue: monero-project/research-lab #144

<rucknium> > After reviewing the available literature about selfish mining, I first want to disqualify all mitigation strategies that rely on more frequent hashrate sampling.

with randomx v2 (the commitment part) you'd have to expose the previous state of all entries, but it would make "quick" verification fast, then can spend some time for the slow path

it's still quite a penalty to hit even for normal blocks, specially on light devices

<vtnerd> @rucknium: every honest miner is incentivized to include the shares because another miner could reorg a block with more cumulative difficulty by including other shares. The situation does make me a little uneasy because the situation is more complex than standard pow

<rucknium> Aumayr et al. (2025) does not directly analyze how many shares would have to be put in each block to make their protocol work. They analyze in pieces: 1) Assume hashpower estimation is done with zero error, then how effective is PRS against selfish mining? 2) How much estimation error do you get at different numbers of workshares per block?

<vtnerd> @rucknium: As stated on Twitter, the prs crowd nearly has me convinced that it's better than tevadors proposal, but no one has a good response to the increased sync time

<rucknium> But they do not analyze how effective PRS is when there is nonzero estimation error, AFAIK.

<vtnerd> "tuning" parameters aren't investigated with prs. Even with tevadors proposal the various parameters are hard to determine imo

<vtnerd> @rucknium: What do you mean by estimation error? Estimating the relative hashpowers?

<rucknium> Right.

<vtnerd> Didn't think about that, the pretty graphs probably assume 100% accuracy, which probably includes a crazy high workshare number, which is a non-starter for longevity of the project

<vtnerd> Guessing that's why they didn't include tuning parameters, the paper is interesting but much less impactful if investigated

<rucknium> Figure 7

<rucknium> IMHO, the paper is unnecessarily difficult to read. Compare with the Publish or Perish paper, which is much easier to read.

<rucknium> They make things very formal, but do not really have much informal explanation of what is happening.

<rucknium> I can decode the game theory formality, but not the computer science formality very well.

<rucknium> And they have enough authors on the paper to edit it well for clarity!

<vtnerd> Yikes the number of samples is way too high imo

<rucknium> Maybe yes, maybe no.

<vtnerd> Quai? Supposedly implements prs, not sure what their sample rate is

<rucknium> We don't know the effect of sampling error on their protocol because they don't directly analyze it. Maybe it would still be effective with low sampling (low number f hash samples per block)

<rucknium> But this could be simulated or even worked out to a closed-form analytical formula.

<rucknium> I might be able to do it, but I won't bother at this point in time because it would definitely be a long-term fix. It requires a hard fork.

<vtnerd> It _seems_ like you'd need a decent sample rate, or solo mining becomes worse as you can't get a share. Or at the very least it's not an improvement for solo mining

<vtnerd> @rucknium: Yes, I wish this was done, as we're left to wonder how to exploit this parameter

<rucknium> I don't know what Twitter is saying, but I don't remember the paper saying anything about PRS being beneficial for solo miners. Maybe that discussion is in papers it cites.

<rucknium> And, IIRC, the paper doesn't say anything about miners being incentivized to include work shares of other pools. I got the impression that miners include just their own hashes that are still in the freshness window. Maybe that's somewhere deep in the computer science jargon or I simply missed it.

<vtnerd> people on Twitter/monerotopia were claiming it helped solo miners and stopped all reorgs. The paper doesn't claim either, and the reorg claim was particularly annoying (I at least refuted that immediately)

<rucknium> I _would_suggest that they read the fine paper, but it's unnecessarily difficult to read as I said, so I can't blame them much.

<vtnerd> My original interpretation of the paper was that you would have an x block window to post your own shares. This wouldn't help solo mining at all.

<vtnerd> The twitter wars implied something different, and I likely did more thinking as to how their magic would work than they did themselves.

<vtnerd> Anyway I think we're mostly in agreement ruck, except for the publish or perish paper (I probably need to reread it)

<vtnerd> I kind of hope prs would work for various reasons, but there is a lot of open questions about it

<vtnerd> And as a followup, if you don't include the highest shares from other people, you may get reorged out, thus it may the case that solo miners benefit. But I don't recall the paper discussing this either (probably need to reread this yet again too)

<rucknium> Sorry, I don't remember: On what point do we disagree about the Publish or Perish paper?

<vtnerd> I need to think it over some more - my understanding is that block weight is determined by whether an uncle block is seen "in time", but each node is going to have a different perspective on that. And I'm not sure what a node during initial sync does - perhaps you ignore weight until your caught up