rucknium reviewed shared attack code (LLM-heavy, grid-search on stubborn mining; OK but not amazing) and argued more exhaustive analysis (MDP or RL-MDP) is needed before endorsement; monerosim is useful but cannot cover all scenarios. tevador updated SoP last week (gingeropolous independently found a fixed issue) and will freeze specs unless a major issue appears. Biggest potential issue is temporary network splits from subjective fork choice (limited compared to PoP). gingeropolous plans more monerosim runs + LLM attacks. Clarifications: colliding minor_version shares → first-seen enters pool (other can be timestamped); fork choice only on new block or new chain (not every share, to avoid thrashing). monerosim optimizations make it runnable on consumer hardware. rucknium: I looked a little into the code that the researcher here shared with me:

GitHub

Share or Perish (selfish mining mitigation) · Issue #146 · monero-project/research-lab

Share or Perish The previously proposed Publish or Perish [1] (PoP) has some shortcomings. With the default parameter k=3, it cannot prevent deeper...

rucknium: It was nice of them to share the code. IMHO, the code is OK, but not amazing. rucknium: It looks like there was heavy LLM usage. tevador: I made some updates to SoP in the last week. gingeropolous: thanks for the report, it seems you independently discovered the issue I fixed yesterday. rucknium: They try to attack the protocol with stubborn mining and sort of do a grid search of possible parameters that could give the adversary an advantage. rucknium: IMHO, it would be premature to endorse SoP without a more exhaustive analysis, like putting it into an MDP (Markov Decision Process). rucknium: I think that if you leave stones unturned, a nasty strategy could be lurking under one of them. rucknium: And that's the same weakness with gingeropolous 's experiments. AFAIK, there is no way for monerosim to simulate enough scenarios to try to cover everything. rucknium: But monerosim is useful for catching other issues, like the block minor version. gingeropolous: oh i will drive the bots to find all the stones tevador: Agreed. People can release their LLMs on it. I'll freeze the specs for now unless a major issue is discovered. rucknium: The selfish mining strategy against Nakamoto consensus was developed first. Stubborn mining was a small improvement. Then, MDP was deployed against the problem and a little more profit was squeeze out of Nakamoto consensus for the adversary., rucknium: gingeropolous: What's your plan for that? selsta: tevador: jeffro256: this is the LLM proposal, hopefully it's not too sloppy

Snippet | IRCCloud

tevador: I think the biggest potential issue of SoP is that the network temporarily splits due to the subjective fork choice rule. The attacker can induce this by release a block at the boundary of being late. But this is a trade off. But unlike PoP, the split is quite limited (1 block + 32 workshares) rucknium: IMHO, what's needed is to put SoP into an MDP framework and count the states. If there are too many states to fully solve, then you could try a modified MDP with reinforcement learning. Modified MDP with reinforcement learning has been used recently for more complex selfish mining countermeasures that have too many states to feasibly solve in traditional MDP. gingeropolous: current plan is to run the sims with the new spec, and then direct the llm to attack it. But yeah a more formal approach would be welcomed. i could probably plug in that paragraph and it would get to work rucknium: Sounds good. rucknium: More on this issue? gingeropolous: yeah 2 questions gingeropolous: it was in the note. When two miners find a pool share for the same slot (same minor_version), does each count, or one per slot? We'll count one, first seen. gingeropolous: Should a share arriving re-run the fork choice, or only a block? monerod only re-runs it on blocks, so that's what we'll do first, and we'll measure how often a share would have changed the outcome. jeffro256: selsta: This has several issues, I can DM later tevador: If two shares have colliding minor_version, only the first one seen enters the workshare pool. gingeropolous: awesome thanks tevador: But the other one is can also be counted as "seen" with a timestamp for the lateness check. tevador: For the fork choice, my intention was to run it only when a new block or a new chain is received. tevador: I think recalculating with every share has the potential for nodes to switch between 2 chains too often. tevador: We can see if this can have some unforeseen effects, like nodes stubbornly sticking to one chain and refusing to switch. gingeropolous: yeah. endless sims! I also encourage folks to run monerosim on your own. recent optimizations bring scale to general consumer hardware... you don't need a 1tb ram monster for most stuff

#monero-research-lab

View quoted note →