<l​eonarth_:matrix.org> Selfish mining / block withholding

<l​eonarth_:matrix.org> My understanding of how this attack vector works:

<l​eonarth_:matrix.org> - PoolX mines block 3000: doesn't broadcast it to the network

<l​eonarth_:matrix.org> - PoolX starts mining block 3001 while other pools are still doing useless work on block 3000

<l​eonarth_:matrix.org> - PoolY mines block 3000 and broadcasts it

<l​eonarth_:matrix.org> - PoolX mines block 3001 and immediately broadcasts both 3000,3001 blocks to the network creating a longer chain

<l​eonarth_:matrix.org> - PoolY block becomes orphaned as PoolX is ahead

<l​eonarth_:matrix.org> - PoolX gets reward from 2 blocks

<l​eonarth_:matrix.org> Countermeasures: we could design pattern recognition for this type of behavior and discard PoolX broadcast, e.g.: if the block broadcast time of block 3000 and block 3001 are too close then PoolX is mining too fast.

<l​eonarth_:matrix.org> Meaning PoolX is either:

<l​eonarth_:matrix.org> - mining too fast: achieved over 51% of network hashrate

<a​nilwang:matrix.org> A naive observation. Monero generally work and the main problem is the reorgs attack. Reorgs should be infrequent, especially from one node so not only have this rule: discard nodes that have reforged in the last 10 blocks... Give someone else a chance to mine the block. That should turn a 100 node attack into a 10 node attack. Add another condition, reject a node if it has had m<clipped message>

<a​nilwang:matrix.org> ore than 2 reorgs in the last 50 blocks. Would this not encourage committing blocks as early as possible to avoid the reorgs penalty.

<l​eonarth_:matrix.org> how would you code that in the consensus?

<p​reland:monero.social> The issue that was raised when I suggested similar was that this 1. Could splinter the network if two nodes disagree on something being an orphan, and 2. If it was implemented, it would still be affected by Sybil