<rucknium> MRL meeting in this room in two hours.

matrix.org downtime seems still ongoing and they are taking the slow path

bsky.app/profile/matrix.org/post/3lxuslbzjuc2t for anyone in matrix.org having issues they can temporarily join IRC :)

<rucknium> Meeting time! monero-project/meta #1263

<rucknium> 1. Greetings

<articmine> Hi

Hello

<vtnerd> hi

<jberman> waves

<boog900> hi

<venture> Hello

<0xfffc> Hi everyone

hi connecting from IRC

<rucknium> We are probably missing people from matrix.org Matrix servers. Logging into the Libera IRC network still works.

<rucknium> 2. Updates. What is everyone working on?

<vtnerd> me: primarily bugs in lws and lwsf. sadly several were reported nearly the same time, and I’ve been going through them

<rucknium> me: Testing rolling DNS checkpoints and created this issue about it: monero-project/monero #10064 . Reading papers about selfish mining. Productionizing transaction spamming code for FCMP alpha stressnet.

me: For fun implemented a DNS + DNSSEC server that can server a single DNS checkpointing domain directly, via nameserver delegation git.gammaspectra.live/P2Pool/monero-highway and holding own keys. Supports Ed25519/ECDSA and other keys

<rucknium> @jeffro256:monero.social: Ping

<jberman> me: sped up popping blocks/reorg handling in the wallet to handle trimming the fcmp++ tree quickly, fixed a bug in the wallet's tree builder path member reference counter, benchmarked tx and membership proof verification using kayaba's latest

<jeffro256> Howdy

<venture> I have been working on a monte carlo simulation of Publish-Or-Perish

<rucknium> 3. gist.github.com/jeffro256/12f4fcc001058dd1f3fd7e81d6476deb.

<jeffro256> me: lots of review, documenting and refining HW wallet support for FCMP++, and refactoring in preparation of a key image generator hash function change proposed by @kayabanerve:monero.social

I have updated the fee calculations in seraphis-migration/monero #44 With an increase in the penalty free zone, ZM from 1000000 bytes to 200000 bytes, an increase in the reference transaction size from 10000 bytes to 20000 bytes and an increase in fees by 4x by elimination the lo fee in the implementation. Then we can have a flat fee structure with fee proportional to weight up to 128 inputs.

<jeffro256> @diego:cypherstack.com: reached out to me with a first draft of the follow up audit, we're discussing it now. Thanks Cypherstack! Not too much to report until after that's done tho

<jeffro256> Haven't heard back in a couple days, I wonder if it might have to do with the Matrix federation security issues

<rucknium> 4. monero-project/research-lab #142.

<rucknium> 4. monero-project/research-lab #142.

<rucknium> Do markdown links not appear properly on IRC side, or is it just the monerologs.net parsing that erases the text?

So far no problems for me with the links of today

<rucknium> Anything to say about hash-to-point now?

In some cases it is lag. I am actually on IRC at the same time

<articmine> See my comment above

<rucknium> I am feeling some lag on the Matrix side. Maybe because martix.org is coming back online?

<rucknium> matrix.org*

<rucknium> 5. github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf. seraphis-migration/monero #44

19:17:08 <br-m> <rucknium> Do markdown links not appear properly on IRC side, or is it just the monerologs.net parsing that erases the text?

there is a markdown parser, but it removes the description as I could not find a proper format for it. Let's discuss alternate formats for that after the meeting

<rucknium> Ok I will post them as regular, separate links for now.

<rucknium> The current agenda item is "Transaction volume scaling parameters after FCMP hard fork. "

As I mentioned before I am recommending both an increase in the minimum penalty free zone and an increase in fee to address these issues.

this is also after reviewing the comments in the last MRL regarding the use of 4 in transactions

<jeffro256> Personally, I think that the penalty free zone shouldn't be increased to much over 2x the max tx size + a coinbase tx size. A 6x increase is pretty aggressive when the average FCMP++ transaction isn't going to be 6x the size of a 16-member CLSAG tx. What's the primary thrust of why it would be increased so much ?

<jberman> My initial read of this latest is that fees are determined entirely by overall tx byte size, and unaffected by tx verif time, or membership proof size/verification (aside from the effect of the memb proof on the overall tx size)

Yes this is correct

A larger penalty free zone means a malicious miner can spam the blockchain more.

<jeffro256> ^^^

Yes but there is also an increase in fees

Fees don't affect the miner.

<jeffro256> not if colluding with a miner

A penalty free zone 2x the max tx fee was tried in 2017 and it did not work

The fees are just too high

<jeffro256> Only for max size txs, though, right?

<jeffro256> Assuming other traffic

in 2017 it was all txs

We had a 2in 2 out tx at 135000 bytes and a penalty free zone of 60000 bytes

<jeffro256> 2017 was before bulletproofs. I feel like the change to bulletproofs (a huge drop in transaction size) lowered the fees more than the increase in the minimum penalty-free zone

<jeffro256> But I'm just spitballing

Even after the increase to 300000 bytes fee were still very hihg

It was only by not reducing the penalty free zone after bulletprrof that we go reasonable fees

<jeffro256> I'm a bit biased because I'm also of the opinion that the fees should be higher than they currently are

If the tx volume is sufficient, the penalty free zone will adjust. A smaller minimum value is more spam resistant.

I am actually proposing both a fee increase and an increase in the penalty free zone

The current fee structure is very well received by the users. A massive increase in fees is something I cannot support

<jeffro256> > Even after the increase to 300000 bytes fee were still very hihg

<jeffro256> > So you agree that increasing the penalty-free zone didn't do much to lower small-tx fees?

It did not go far enough in 2017

<jeffro256> So if you also want to raise fees, then why are we raising the penalty free zone?

We needed a penalty free zone in the 1000000 - 200000 bytes back then

to 2000000 bytes

We need both

raise fees and the penalty free zone

<boog900> why do we need it

What would be the verification time for a 2MB block?

<rucknium> @ofrnxmr:monero.social: Insight about that ^ with FCMP private testnet experiments?

~12.5x that of a 128 input tx

we have to be realistic here

<jeffro256> If all 1-in,2-out, then 2MB*(1 tx / 6261 B)*(30 ms / tx) ~ 9600 ms of CPU time

One we can use parallel processing to the block, unlike single large txs

<jeffro256> (in response to tevador's question)

<boog900> IMO 1 MB blocks is already too big

<boog900> which was the original proposal

I have said for a long time that we are going to need parallel processing to address verification time

<jberman> you can parallel process at every level theoretically, even within verifying a single 128-in tx. but finding the sweet spot of where to apply the parallel verif to maximize CPU utilization is another q

<jeffro256> @jeffro256: Also that 9.6s figure for 2MB of FCMP++ transactions didn't include BP+ range proof verification. It is a small, but certainly noticeable part of the verification time

<jberman> right now the implementation batch verifies all FCMP++ proofs synchronously

<jberman> so verification time of a large block should be somewhat faster than time to verify each proof in the block individually, ignoring parallelism at any level

are you excluding any palatalization implementations at the OS level?

<jeffro256> This is true, I am not considering batching. That's if verifying independently

<jeffro256> But we already do multi-threaded verification in monerod

<jberman> fcmp++ verification is currently batched, and not multi-threaded

On a CPU with say 64 threads this cam make a major difference

<jberman> yes

<rucknium> I will limit this agenda item to 30 minutes of discussion. That means ending at 17:52

<jberman> I think it could be easily updated to batch in groups of some max size, and do parallel batch verification within each block

<ofrnxmr> Jeffro,that must be 9600ms if firsttime seeing the txs?

<jeffro256> @ofrnxmr:monero.social: yes for full verification

<ofrnxmr> Ok, because if i aready have the txs, a 15mb block takes about 5 seconds

<jeffro256> During block propagation, assuming the tx is already in the pool, the FCMP would have already been verified, so it won't take that long when verifying an incoming block

<ofrnxmr> 5 seconds from notified to "synced". So not all verification time, some of that is bandwidth

I don't think I would support going above 600 KB with the minimum penalty free zone. That's still ~80 tx per block. Min tx fee for 8000 byte tx would be ~0.0001, about $0.03.

If my calculations are correct.

<articmine> I cannot support anything below 1000000

<articmine> bytes

I don't find a fee of $0.03 to be excessive. Might even be too low IMO.

<rucknium> Let's continue the agenda:

<rucknium> 6. FCMP alpha stressnet planning seraphis-migration/monero #53#issuecomment-3053493262

<rucknium> There has been movement in seraphis-migration/monero #81 , the last thing to be merged before alpha stressnet

<jberman> In PR 81, I modified some of wallet2's reorg handling logic to:

<jberman> -- always request blocks starting from 1 higher from current known tip

<jberman> -- if reorg detected, then request 3 blocks back

<jberman> -- if reorg still detected, then request 100 blocks back (100 is the default max reorg depth)

<jberman> @jeffro256:monero.social highlighted how this incurs extra cost for daemons to handle reorgs (e.g. in a 10 block reorg, wallets will end up requesting 100 blocks back from tip to handle the reorg)

<jberman> I'm planning to revert back to behavior that does not incur extra cost to handle such a reorg, hopefully will complete that today

<jeffro256> I honestly don't think that 81 should be a blocker personally

<jberman> ofrn reported various refresh issues similar to issue #45 that the PR solved for him

<jeffro256> Okay fair

<jeffro256> Which part of the PR actually fixeD the reorg issue ?

<jeffro256> it was an issue with reorgs right ?

<jberman> yep, the reason I widened the PR's scope to remove init hash download was because that part touches on similar areas that would need changing. So I figured better to kill 2 birds with 1 stone and not need to make more changes separately

<ofrnxmr> @jeffro256: There were numerous isues

<ofrnxmr> One of them was that the wallet was broken if you had a non-0 restore height

<ofrnxmr> I dm'd you another one a moment ago and will send another in a few mins

<rucknium> IMHO, with stressnet, keeping wallets working without manual fixes will be important.

<rucknium> Starting with my scripts that I used to spam last year's stressnet, I have written "easy-to-use" functions that can create an arbitrary number of wallets and monero-wallet-rpc instances. Wallets need to be generated programatically because 1in/2out tx creation times seem to go from 0.1 seconds to 5 seconds with current FCMP [... too long, see mrelay.p2pool.observer/e/-auB0rEKcmJKZXYx ]

<rucknium> On last year's stressnet, I had 3-4 wallets spamming at a time IIRC. I could manually fix them when they encountered problems, but dozens of wallets would be harder.

<ofrnxmr> Lots of wallets or slow blocktimes

<ofrnxmr> I'm testing 15 subaccounts right now - i think subaccounts might be broken

<rucknium> @ofrnxmr: On FCMP?

<ofrnxmr> Yeab

<rucknium> My spamming functions don't work without accounts.

<rucknium> I was promised accounts work 😢

<rucknium> Did you limit subaddress lookahead? I don't know if that could help anything.

<jeffro256> They should work AFAIK and are planned to worl but plz lmk if they don't

<ofrnxmr> check dm

<rucknium> More discussion of stressnet planning can happen in #monero-stressnet:monero.social ( ##monero-stressnet on IRC I think).

<rucknium> I am wondering if the spamming code should be published or not. That discussion can happen at another time or asynchronously.

<rucknium> Any other major things about FCMP alpha stressnet to discuss?

<jberman> nothing from me

<rucknium> 7. Mining pool centralization: Temporary rolling DNS checkpoints monero-project/monero #10064 and Publish or Perish monero-project/research-lab #144

<rucknium> Do we talk to talk about DNS checkpoints and PoP together, or separately and in which order?

<ofrnxmr> bug found: when checkpointed chain reverts a reorg, the shared-ring-db gets borked

<rucknium> Does that happen with every re-org, or just ones involving checkpointing?

<ofrnxmr> just checkpointing

DNS checkpoints can work by themselves, so I think it can be discussed separately. They can prevent deep reorgs that are bad for UX. But they can't stop selfish mining and might even help the selfish miner in some cases.

<rucknium> Note that the network connectivity of the Qubic adversary is quite poor. They are losing almost every block propagation race. DataHoarder: is that correct?

Only if it's a race. usually it's not a race and they are ahead

<ofrnxmr> I think they are losing because they have to broadcast their txs with the blocks

They take an extra penalty for unknown txs having to get verified

<rucknium> But maybe they could improve their network connectivity in the future.

Plus sometimes their blocks or changes are delayed 8-20 seconds

<ofrnxmr> If they were doing just empty blocks, would be faster

What might help would be to connect the checkpointing node directly to a few large honest pool nodes.

<rucknium> DNS checkpoints help the selfish miner if they can push their blocks to honest miners faster/earlier.

<rucknium> AFAIK

p2pool is testing a few changes to broadcast non-p2pool blocks across its network

which submits to monerod directly

It's enough if they push their blocks faster to the checkpointing node.

so that makes all blocks spread across faster, alt or not

<rucknium> tevador: Right. maintaining connectivity and a common view of the network's block is important.

<venture> Regarding PoP, basic monte carlo sim is set up (honest miner case, with fork-resolution-policy, the soft fork proposal, no vesting / reward-splitting). The selfish-miner is implemented as well but lacks "proficiency" in my model. it performs not well / based on a simple heuristic currently.

I am testing a "connector" network where they share view of multiple monerod nodes, local or remote, and share available information across (for checkpointing purposes). It needs more work to show as a proof of concept, but has more uses besides checkpointing (good for pools to broadcast blocks to each other quick and other information)

<venture> i noticed (probably obvious) that the fork probability (even in the honest case only), depends on the window and the block frequency. so D=5s on 1 min blocks (more forks) than on 2 min blocks. up to 3.5%

couldn't qubic just join p2pool?

<rucknium> I wrote some thoughts about the heart of selfish mining last meeting, but didn't post because they were related to changing the hashpower sampling rate. tevador has some good points against increasing the sampling rate. But I think it's useful to think about common network view:

<bawdyanarchist:matrix.org> Speaking of Monte Carlo, I released my first rev of a Monero sim. Still a WIP, but normal honest miner behavior appears to be working, the structure is solid, and it's at a point that adding new strategies is fully pluggable.

<bawdyanarchist:matrix.org> github.com/BawdyAnarchist/Monero-Simulator

Guest28: in regards to what? No need to even join p2pool, it's just to speed up block transmission across the network. any monerod from a user using p2pool will have its blocks also broadcasted

<rucknium> In "Lay Down the Common Metrics: Evaluating Proof-of-Work Consensus Protocols' Security", the authors have a section "What Goes Wrong: Information Asymmetry" that gets to the heart of the matter. I think it explains why an attacker with minority hashpower can gain an advantage over honest miners (and honest merchants). A minor [... too long, see mrelay.p2pool.observer/e/s5C70rEKOXlsQzRM ]

<rucknium> I have developed my own analogy.

<rucknium> It's a gambling analogy, of course.

<rucknium> In blackjack, "the house always wins" because the ruleset creates biased odds...or does it? en.wikipedia.org/wiki/Card_counting can help a blackjack player get an advantage over the casino. If, by chance, the cards remaining in the dealing deck are high-numbered cards, then the player is temporarily at an advantage. In [... too long, see mrelay.p2pool.observer/e/wOa80rEKM0FsNEVB ]

<rucknium> A selfish miner acts in the same way. It knows the blocks produced by itself and the honest miners. When it is ahead of the honest miners because of randomly being luckier than its hashrate would normally allow, it "bets big" by withholding blocks. I think this analogy can help us understand why minority-hashpower selfish miners can get an advantage and maybe how they could be defeated.

<rucknium> Aumayr et al. (2025) "Optimal Reward Allocation via Proportional Splitting" arxiv.org/abs/2503.10185 is like re-shuffling the deck often, which decreases the card-counter's edge. But that costs RandomX hash verification time. Too much, probably. And it would require a hard fork.

<bawdyanarchist:matrix.org> @rucknium:monero.social: The "Optimal Reward Allocation" team said that they followed closely the MDP implementation from "Laying Down the Common Metrics" (cited the same MATLAB source you found.

<bawdyanarchist:matrix.org> > In our case, we only adapted the "reward splitting" MDP to follow our reward sharing variant ("proportional reward splitting" - PRS), so it is mostly the same as this repo's implementation.

<bawdyanarchist:matrix.org> github.com/commonprefix/proportional-reward-splitting-MDP

in those same analogues, a checkpoint would be a "deck change" @rucknium where any new information from old deck is useless unless it was already abused?

<rucknium> @bawdyanarchist:matrix.org: Awesome. Thank you!

The DNS checkpointing issue didn't receive many comments. So I guess we can go ahead with it? Are any changes in monerod needed? It can stay opt-in since it's a soft fork.

<rucknium> DataHoarder: I think it would be similar. Here are other card counting countermeasures: en.wikipedia.org/wiki/Card_counting#Countermeasures

"20:13:19 <br-m> <ofrnxmr> bug found: when checkpointed chain reverts a reorg, the shared-ring-db gets borked"

^ that'd need addressing

<vtnerd> the thing about opt-in is the solo miners joining the selfish-mining, etc

also, alt blocks even close to a tip do not get shared across peers unless they are longer, or forced flushed

<rucknium> @vtnerd:monero.social has done some "procedure smoothing" coding on monerod.

if we want the network to switch, at least, some of these should get broadcasted across the network and not just kept locally

If the majority of the network hashrate opts in, everyone will eventually end up on the checkpointed chain.

<rucknium> DataHoarder has been thinking of ways to get alt blocks propagated more reliably.

<vtnerd> there’s also whether we have one source publishing checkpoints or multiple (as they could disagree and cause some headaches)

the problem is for the majority of the network to even get those blocks in the first place, if it's a race

<ofrnxmr> Tevador - need changes to frequency of checking and reduction of bantime. Patches for that are ready

we can "manage" for public nodes. additionally RPC has some issues with old blocks (which Qubic encountered and blamed pools instead!)

<vtnerd> tevadoryour correct, its just that having people on the “wrong chain” temporarily hurts my head a bit

<vtnerd> I guess its no different than a reorg though

I have some of my own local WiP patches for me to address this, but some proper solution might be nice. Can talk a bit after discussion

<rucknium> I think @kayabanerve:matrix.org 's idea for an RPC method to checkpoint blocks is a good idea for the checkpointing nodes. You want them to stand on a block without the round-trip latency of querying DNS.

^ local temporary checkpoint that doesn't survive restarts?

<venture> mrelay.p2pool.observer/m/monero.social/FvzPJgCrjLhCvYkHEvibiqMv.svg (test_run2.svg)

call it, block pinning?

<venture> is this received on IRC side

<venture> ?

yes, nice svg

<vtnerd> my other thought with banning is whether we create a semi-permanent netsplit, the banning side would need to keeping retrying those nodes for a bit

<rucknium> Some group of nodes tell a checkpointing script that they all (or a {super} majority) have some block and wish to "finalize" it. Then the checkpointing script sends a finalize command to all those nodes and updates the TXT DNS record.

<venture> it's the simulation. with view for each miner (lane) .. including their branches (which they would have to maintain up to k , with the soft fork proposal)

<vtnerd> Im not sure if the current retry algorithm is sufficient for that potential netsplit case

I guess the fact that the checkpointed chain won't be relayed if qubic's chain is longer might be an issue.

<venture> the last lane is the selfish one

@rucknium I had that "finalize" step on majority on my test tool but didn't involve getting these back to monerod somehow, I should incorporate that in my simulations

indeed tevador. There are workarounds *now* but a .patch release that allows broadcasts would help a lot

even just a couple of nodes doing so would unclog most of the network if we want these altchains

<bawdyanarchist:matrix.org> @venture:monero.social: Did you publish your code yet for it? Can you share the link?

we can reach public nodes directly, but not hidden or outbound only nodes

<rucknium> My basic checkpointing script on testnet just assume that the single checkpointing node will get the DNS checkpoint instruction soon after it's posted, but there are gaps there with DNS caching and having 4 domains.

I think it would be quite safe to relay alt block up to a certain depth even if the chain is shorter.

<venture> @bawdyanarchist:matrix.org: i will. but no, it's not yet on github

an alternative would be querying a local DNS server that the checkpointing script runs, @rucknium, that has the most recent fetched value faster

<rucknium> I wonder what the reason for not relaying alt blocks that clear the difficulty threshold is? If they clear difficulty, DDoS risk is low.

tevador: something like max desired reorg depth, or, up to last randomx epoch, those were my two "sane" min/max bounds for that distance

Exactly, the DoS risk is nonexistent if the PoW is checked first.

<rucknium> By the way, on testnet we were able to produce empirical evidence that a 10-block re-org can invalidate txs: libera.monerologs.net/monero-research-lounge/20250903#c579433-c579443

I'm looking at nodes out there with open rpc and over time checking their /get_alt_blocks_hashes output too, fetching the full blocks, then relaying these blocks around

<rucknium> I'm not 100% sure if the 7 invalidated txs were actually mined in a block or were just waiting in txpool. (If in txpool, they would have been included in the next block).

Thanks for that, Rucknium! Nice to have it documented

The fact that transactions get stuck in the mempool for a week is much worse than just invalidating.

<boog900> DataHoarder: Ah I saw someone sent my node a deep alt block and was a bit confused :D

<rucknium> @ofrnxmr:monero.social was able to spend those outputs later because he cleared his node's txpool. I think another node mined it, not his. But @ofrnxmr:monero.social can confirm

to make it more obvious, the transactions with the key image stay in mempool so other new transactions can't replace this invalid one

just in case the old chain comes back

<rucknium> And clear some things in the wlalet cache I think.

<rucknium> Ordinary users would find it difficulty to clear everything.

@boog900: it might not have been me, snatching some of qubic lost chains is tricky so these are the ones I'm focused in finding

and it'd stay in other node mempools

so it'd block transmission or broadcasts, or mining

<rucknium> In a scenario where the community and other agents are reluctant to enable DNS checkpoints, a grim trigger strategy can be followed en.wikipedia.org/wiki/Grim_trigger

<rucknium> Set up infrastructure for DNS checkpoints, but don't post checkpointed blocks to the DNS records unless Qubic re-orgs more than 9 blocks (or they facilitate a short-chain double-spend tx). If they do, issue checkpointed blocks indefinitely.

<rucknium> Rolling DNS checkpoints reduces Monero's decentralization, so it isn't idea for the Monero protocol, either.

<rucknium> I don't see much opposition to it at the moment.

it's understood it's a bandaid until measures can be implemented in the longer term

<rucknium> The Core Team would need to agree since they manage the DNS records. You need most big mining pools to agree and enable checkpoint enforcing (and probably a new monerod release with procedure smoothing).

<rucknium> It's in the mining pools' interest to enable checkpointing enforcement if they are mostly all in it together.

the cadence changes and improvements can be done ahead of time, as they also smooth over any future need of it even if it's not for qubic

(broadcasts, reorg ring db fix, check intervals, etc.) before agreeing to issuing them or not

that way it's ready, instead of lagging for all that to be available. monero users can sometimes delay updates quite a bit

<rucknium> If there are not objections here, then timeline, tasks, and personnel should be decided.

<rucknium> i.e. who does what, and when.

<rucknium> DataHoarder has good understanding of the DNS issues involved. And the block propagation issues. He could lead on that. @vtnerd:monero.social could help with additional smoothing changes to monerod.

Tracking issues can be openened first.

<rucknium> The Core Team would need to reach a consensus on this. @articmine:monero.social could lead on that if desired.

<rucknium> Mining pools need to be contacted and their internal decision processes need to be worked through, and their decision communicated.

i will bring it up with the core team

<rucknium> ArticMine: Thank you!

<rucknium> From previous experience, hashvault, moneroocean, supportxmr, and nanopool seemed quick to implement changes to their mining procedures when contacted: rucknium.me/posts/monero-transactions-60-seconds-faster

I have a list of issues that we encountered while monitoring and operating monerod in a different capacity, and data to back the reasoning behind these fixes. as long as scope is limited @rucknium I can take care of that part

<rucknium> DataHoarder: Fantastic. Thank you!

<rucknium> Try to pass improvements to @ofrnxmr:monero.social and myself, which are performing checkpointing experiments on testnet.

hashvault, moneroocean, supportxmr, and nanopool are together >50%, enough for a soft fork.

<rucknium> Who will craft the message and contact mining pools? Last time, at least @ofrnxmr:monero.social and @ack-j:matrix.org helped contact mining pools.

<ofrnxmr> Plowsof also helped

<ofrnxmr> "ofrnxmr was able to spend those outputs later because he cleared his node's txpool. I think another node mined it, not his. But ofrnxmr can confirm" correct

<rucknium> By last time, I mean the block template updating config fix: rucknium.me/posts/monero-transactions-60-seconds-faster

<rucknium> selsta would be the person to coordinate a new point release of monerod. He has said he is standing by to assist on that.

<rucknium> What else would need to be done?

address MoneroPulse page if it's decided to change so people are informed on their opt-in decision if wanted

<rucknium> If anyone thinks of something else that can be done and/or wants to take on a task, say it later in this room and/or on the GitHub issue: monero-project/monero #10064

<rucknium> DataHoarder: Good idea. That could be folded in with crafting a blog post on getmonero.org and broadcasting info to Core'e email list so that the message is consistent.

<venture> i wanted to ask, do we have numbers on orphan rate pre qubic? that way the propagation time can be inferred from the poisson distribution

<rucknium> @rucknium: I may take on these communication tasks if no one else wants to.

@venture we have historical p2pool logs and what miners were mining when they found their shares, every 10 seconds. sometimes you see half the miners mining on an orphan block. unknown if we have other longer term data besides monero nodes keeping alternate blocks pre-qubic

<rucknium> @venture:monero.social: Did you see my info about empirical block propagation times in issue 10064?

<rucknium> There is also an analysis of logs in a research-lab issue by @chaser:monero.social IIRC

<venture> ah nice. will check it out. no, wasn't aware of 10064

<rucknium> Next: Publish or Perish: monero-project/research-lab #144

<venture> ah shit. Thought was already on the agenda. my svg related. but work in progress :)

<rucknium> I have been considering the methodology of these papers.

<rucknium> Most of these papers use Markov Decision Process (MDP) to decide the adversary's optimal behavior.

<rucknium> But there are two limitations to MDP. They can only model stationary processes. MDP is a subset of Stochastic Dynamic Programming (SDP), which can also model non-stationary processes.

<venture> my guess is they implement a miner from scratch (without PoW), and have a gloval eventqueue that calls on_mine based on poisson distribution and thinning by shares.

<venture> That queue gets emptied at each t and calls on_deliver

<rucknium> MDP also can only model a single agent's decision. The honest miners are basically on autopilot and inert.

<venture> and once that was set-up, they did the policy MDP..

<rucknium> A process is stationary if its statistical/probability processes do not depend on time.

<venture> @rucknium: yes, autopilot, ie always broadcasts on_mine

<rucknium> Mining is a Poisson process, which is memoryless. So far, so good. But difficulty adjustment is not memoryless. And a selfish minor alters difficulty adjustment.

<venture> yeah.. diff adjustment is often not considered in these papers. only the one with selfish-mining re-examined

<rucknium> Grunspan & Pérez-Marco (2019) "On profitability of selfish mining" arxiv.org/abs/1805.08281 give a critique of modeling selfish mining in a MDP framework in this ^ basis.

<rucknium> on this basis*

<rucknium> I don't know how much this critique matters in the current scenario.

<rucknium> Related, I winder if the objective function in the PoP's MDP could be easily modified from relative revenue to "propaganda value", or something, since Qubic seems to care a lot about that.

<venture> unfortunately they didn't publish their solved MDP I thinik

<rucknium> On the single-player limitation to MDP, I have only seem two-player modeling in Aumayr et al. (2025) "Optimal Reward Allocation via Proportional Splitting" arxiv.org/abs/2503.10185

<rucknium> They say their protocol has a Nash equilibrium for some parameter values. Maybe other papers do game theory modeling. I haven't read them all in this area.

<rucknium> Aumayr et al. (2025) also does MDP as a complement to their game theory modeling.

<rucknium> @venture:monero.social: Here was the orphan analysis by @chaser:monero.social monero-project/research-lab #102#issuecomment-1577827259

<rucknium> Did Negy, Rizun, & Sirer (2020) "Selfish mining re-examined" use MDP?

<rucknium> My big-picture impression of PoP is that it bites most fiercely in its k parameter. The other changes seem to have the biggest effect for tie/races/near-ties. For a very strong adversary, k rules.

<venture> @rucknium: around 15 reorgs per month, that's insanely low, good propagation. man qubic seems well connected in sniping in between with their blocks

<rucknium> k is a mirror image of the rule in Bitcoin Cash (for example) that won't re-org to a chain when the re-org is more than n blocks deep. The k rule is that a node will not re-org to a chain that is less than k deep. k = infinity means that both the N and k rules are in effect, basically. That is what I understand.

<bawdyanarchist:matrix.org> ls

<bawdyanarchist:matrix.org> *sorry. stray keypres

<rucknium> It is possible that Negy, Rizun, & Sirer (2020) "Selfish mining re-examined" doesn't use MDP because they agree with the critique of Grunspan & Pérez-Marco (2019) , but say they don't go far enough.

<antilt:we2.ee> > In case of two competing chains of equal weight, the PoP paper calls for a random selection to be made, but I would suggest to use a deterministic tie breaking rule (e.g. with hashing).

<antilt:we2.ee> @tevador: how would that work ?

rucknium: with k=∞ you can still reorg, just not to a selfish chain that will have a weight of zero

<venture> i think diff adjustment is not elastic enough in monero for a selfish-miner.. def. worth looking into, but "static" is also valuable and should help short-term selfish-mine mitigation

antilt: I've been thinking about this and it seems that the random selection they propose has a reason. The attacker can't know in advance if they will win a race.

With deterministic selection, you plug in both chains into a hash function and that will tell you which chain to select. The attacker can do this check before deciding to publish its chain.

<venture> yeah. that's a downside. but uniform splits the hashrate in half

<venture> but even with deterministic selection, he can't the uncle in...

<venture> can't *get

<rucknium> "About 80 percent of blocks arrived at all five Monero nodes within a one-second interval." rucknium.me/posts/monero-pool-transaction-delay

<rucknium> In early 2023

<rucknium> The magic of fluffy blocks

<rucknium> Stochastic dynamic programming could relax the stationarity assumption. In theory I could try that since Stochastic dynamic programming is used in economics a lot, but I don't know how difficult it would be in this case.

With deterministic selection, the attacker will only release a block if it wins the selection. So a probability of 1.0 to win. With random selection, the chance is (1.0+α)/2, which is < 1.0.

<venture> probability of 1 omits the cases where he lost hashrate effort and never broadcasts (that's not visible, but still there)

<antilt:we2.ee> tevador with k=3 this case would happen quite often. How do checkpoints fit in here?

If he loses the selection, he mines a secret block N+2 with the honest uncle.

<rucknium> Doesn't the attacker have to waste more hashpower to get a winning block wit deterministic selection? Throw a whole block away if it is losing?

<venture> tevador: i need to get my head around this memoryless thing. he would start over at this point.. but maybe that has no downside..

He wouldn't throw it away, he'd continue mining N+2, so his chain will have an equal weight if N+2 is released in time using the honest N+1 uncle. So the overall chance of winning is 75% for the 2 attempts.

<venture> i hope i can share some simulation numbers soon, with the 2 variants, uniform, deterministic

<venture> but what about changing the second rule, to only go for the heighest weight, if it is >= 2

^ Then you would have longer honest chain splits.

All this will probably need to be simulated first.

<rucknium> We can end the meeting here. Feel free to continue discussing. Thanks everyone.

antilt: the idea was to use k=∞ with checkpoints.

k=3 makes more sense without checkpoints

<articmine> I will respond to the fee and minimum penalty free issue in the GitHub issue

<articmine> tevador: ping

<antilt:we2.ee> thx. an attacker would <<51% and a custom strategy iiuc

<antilt:we2.ee> *would need

Rucknium next p2pool release will fast propagate all Monero blocks, so we can expect <1 second propagation times once enough p2pool miners update. My tests show propagation delay <3 ms per one hop, compared to Monero's 400+ ms

relevant code SChernykh/p2pool 50634e5 :)

I touched on it lightly sech1 as well :)

so if pools want faster propagation, all they have to do is run *a* p2pool instance, no need to mine on it, connected to one of their monerod

p2pool should receive blocks via ZMQ and broadcast to other peers who don't have it, which in turn if these have other p2pool (like mini/nano) they would also broadcast it to most participants

p2pool will also submit_block to that monerod with new incoming blocks

<rucknium> sech1: Great :)

<rucknium> According to my network construction simulations, all reachable nodes should get a message within 4 hops: monero-project/monero #9939#discussion_r2285992169

so it's a two-way bridge for faster blocks

<rucknium> Add reachable nodes and you would get a max of 5 total since all unreachable nodes must have an outbound connection to a reachable node (unreachable nodes cannot connect to each other).

Yeah, most important is that major Monero pools start running p2pool nodes connected to their block producing nodes, via zmq

But even without it, this change will speed up the network

I expect pools' effective hashrate to get >1% free boost :) Just because everyone will get new blocks faster

<venture> put my current simulator online here github.com/venture-life/mining-simulator