<ofrnxmr> Doge, zcash, any other pow coin, they dont actually care about pool dominance

<ofrnxmr> isnt like 70% of Btc hashrate all the same pool operator behind the curtain

<ofrnxmr> If qubic, or fed.gov became a dominant pool, none of these miners would care. They already mine on compliant pools and censor txs

<ofrnxmr> Attacking monero only makes noise, because 1) our txs can be invalidated 2) we care about pool dominance

<ofrnxmr> This attack wouldnt work on zcash, because they dont give a shit that 75% of hashrate is on 1 pool

22:50:37 <br-m> <privacyx> It appears the laregest monero pools like supportxmr and nanoppool have teamed up to fight against Qubit selfish mining by selfish mining

no, you can see that yourself with logs

I found it funny on their self-made FUD so also added stratum tracking for other pools on the tips.txt

They also seem to misunderstand timestamps are entirely miner set and within p2pool it wasn't uncommon to see people with clocks more than six hours apart (future/past)

I think we now limit this to like 30m or so as it was making effectively invalid blocks at that point

You need to explicitly keep track of when blocks and alt chains arrive on your node(s) and for that you need higher monero verbosity. nioc explanation of it being sluggish in broadcasting is correct

Qubic also has a very delayed switch time that causes their blocks to naturally orphan more

<kerenken:matrix.org> How is p2pool orphanic qubic?

qubic is either not finding enough blocks to be able to make a longer altchain in time or it's hit by their own made severe transmission delay

Orphaning is not free - you need longer chains (or well

more work)

irc.gammaspectra.live/447f79a58a62cb47/IMG_6877.jpeg

In this cases qubic was one block ahead, but then Monero found two in a row before qubic could broadcast a longer chain

If you follow tips.txt it mentions when either side needs more blocks to orphan the other

<barthman132:matrix.org> Aaajww291: It takes months for him to actually make that change. The fact that our pools are orphaning his blocks now probably isn’t helping him, but because the barrier of entry to attack monero is low. It probably won’t matter anyway

<privacyx> Not sure if this has been suggested or discussed but would instead of purely “longest chain wins,” nodes could incorporate propagation speed into tie-breaking decisions.

<privacyx> Or heaviest chain wins ( eg. total difficulty)

<privacyx> I was reading this paper about defense systems to prevent or reduce risk of selfish mining & double spend attacks

<privacyx> arxiv.org/pdf/2307.00529

That ones "a dud" sadly

tevador and Rucknium left comments about it in the prev meeting

<privacyx> Oh I missed it thanks