<g​ingeropolous:monero.social> Rucknium: / DataHoarder - it might not be entirely categorical, but it would be cool if your visualization indicated which blocks were empty. Or num tx / block. I mean, not necessary obvi. im currently just going between your site and xmrchain to identify empty blocks

<r​ucknium:monero.social> Yes, I've thought about that. I don't really want to add another row of printed info, but maybe I can figure out how to "shade" the boxes to indicate emptiness visually.

<r​ucknium:monero.social> Looks like I can make them a different shape. Maybe circle for empty?

<r​ucknium:monero.social> I can make them into pie charts too 👀

You can query monerod for that

Get the block header

<r​ucknium:monero.social> Right. I already have that data

<r​ucknium:monero.social> gingeropolous: Done

<r​ucknium:monero.social> Thanks for the suggestion.

<c​ountbleck:matrix.org> Looks like Qubic's doing better now? Orphan rate looks higher than before (now above 1%)

They're just trying to orphan blocks more often

They have the same hashrate as before, it's not growing

<c​ountbleck:matrix.org> So they could've been doing this, but just didn't

moneroconsensus.info last orphaned block was almost 70 blocks ago, so they are not very successful now

bad luck, I guess

for them

<k​ill-switch:matrix.org> If they are doing an ISM properly, they should stop orphaning coinciding with the upward difficulty adjustment and switch to honest mining for the next epoch as I under stand it

<k​ill-switch:matrix.org> > The goal of phase one is to knock out the honest miners’ blocks and set up the attacker to profit in the epoch directly following the attack.

<k​ill-switch:matrix.org> If they are doing an ISM properly, they should stop orphaning coinciding with the upward difficulty adjustment and switch to honest mining for the next epoch as I understand it

<k​ill-switch:matrix.org> > The goal of phase one is to knock out the honest miners’ blocks and set up the attacker to profit in the epoch directly following the attack.

<r​ucknium:monero.social> kill/switch: Monero's difficulty adjustment algorithm doesn't have epochs. It's a continuous, smooth adjustment.

<k​ill-switch:matrix.org> yeah the paper uses terminology that isn't 1:1 with Monero's sliding DAA, but they cover that later on in more detail

<k​ill-switch:matrix.org> basically though, they should be creating and riding "waves" in the difficulty that they create with orphaning

<r​ucknium:monero.social> The Selfish Mining Re-examined one? Yes, they model Monero directly.

<k​ill-switch:matrix.org> yeah

<k​ill-switch:matrix.org> in phase one, the orphaning technique increases average block time, and in phase two honesty phase, it comes back down

<r​ucknium:monero.social> I'm not sure they have the requisite hashpower to profitably follow the selfish mining strategy.

<k​ill-switch:matrix.org> yeah it's not profitable, per the paper, until its > ~30%

<k​ill-switch:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/pDtihNrLpNHPaPFyCaPlWpfA

<r​ucknium:monero.social> AFAIK, Qubic has gamma = 0. That's what I understood from a quick look at the paper.

<k​ill-switch:matrix.org> gamma is the proportion of honest miners that mine on top of their submitted fork(s) if I understood it right

<k​ill-switch:matrix.org> or I guess miners == miner's effective hash rate. I did not get that part fully

<k​ill-switch:matrix.org> y = 0 if they are unlucky, and y=1 if they are perfectly lucky

<k​ill-switch:matrix.org> but, since this technique estimation is based on I think hash rate (alpha) being greater than 30%, they should be profitable even if they are at a bit under 30% total block count, due to the phase one orphaning losses affecting them as well, just at a slightly lower percentage vs. honest miners

<k​ill-switch:matrix.org> at any rate, the lesson is you need >70% honest miners for PoW I suppose

@rucknium:monero.social: maybe add "n % blocks in last x blocks were unknown and had no transactions"?

Qubic seems to be claiming all unknown is theirs, while most is, that's probably a nicer heuristic

<v​tnerd:monero.social> the “attack”, when successful, only gets you more revenue compared to expected. the remainder of the argument suggests that everyone jumps to this pool for the higher revenue. its a different argument than the pure 51% attack

Whats their current hashrate % of pool at?

<k​ill-switch:matrix.org> yeah, as they claim more %, they get more and more weight in the block rewards, until they are taking almost all of it at nearing 50%, which serves to disincentivize honest mining from the reward incentives perspective

<r​ucknium:monero.social> DataHorader: I am working on a separate plot with that type of info. It will be available in fixed 6, 12, and 24 hour intervals, not rolling. e.g. 12:00 UTC to 18:00 UTC. This is a more statistically rigorous view of relative hashpower since you don't get the multiple hypothesis testing problem with a rolling, trailing count.

<r​ucknium:monero.social> I hope that makes sense.

<k​ill-switch:matrix.org> the side effect there is of course its a centralized entity that now is the defacto sole operator of a juicy crypto network, and a easy target for FinCen enforcement, and they can't claim otherwise if they get to that magic number and centralize the network. CFB might not be bragging about USA visa trips to conferences then...

<r​ucknium:monero.social> I won't be testing hypotheses at this point, but it may be easy for Qubic to appear lucky on a rolling, trailing count, but not on fixed intervals.

well, since they know already: x.com/c___f___b/status/1954220272996778084

"Monero team" is just DataHoarder and me :D

<r​ucknium:monero.social> You two are very clever 😁

<o​frnxmr:monero.social> offtopic: When checking print_pool_stats, it shows bytes as (example) 722611

<o​frnxmr:monero.social> When checking print_pool_sh if shows bob size 114182 and weight 722611

<o​frnxmr:monero.social> is there an eli5 on the differences?

<r​ucknium:monero.social> Is bob a typo?

<o​frnxmr:monero.social> Blob*

<o​frnxmr:monero.social> Yea, typo

<r​ucknium:monero.social> I don't know about blob, but weight != size because of the bulletproofs clawback. See Zero to Monero.

<o​frnxmr:monero.social> Ok, print_pool_stats shows pool size based on weight

<o​frnxmr:monero.social> Maybe it should be using blob size 🤷‍♂️

<b​asses:matrix.org> xcancel.com/c___f___b/status/1954220272996778084#m