Monero Research Lab Meeting - Wed 27 August 2025, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. Carrot follow-up audit.

4. Discussion: Replace Monero's hash-to-point function with the FCMP++ Upgrade.

5. MRL rooms moderation.

6. Transaction volume scaling parameters after FCMP hard fork.

7. FCMP alpha stressnet planning.

8. CCS proposal: kayabaNerve Finality Layer Book.

9. PoW mining pool centralization. Monero Consensus Status. Bolstering PoW to be Resistant to 51% Attacks, Censorship, Selfish Mining, and Rented Hashpower. Mining protocol changes to combat pool centralization.

10. Any other business

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#1256

[Rucknium]

Logs

< r​ucknium:monero.social > Meeting time! #1261

< r​ucknium:monero.social > 1) Greetings

< a​rticmine:monero.social > Hi

< rbrunner > Hello

< DataHoarder > Rare hi from me

< v​tnerd:monero.social > Hi

< j​berman:monero.social > waves

< r​ucknium:monero.social > 2) Updates. What is everyone working on?

< r​ucknium:monero.social > Ping jeffro256

< j​effro256:monero.social > Howdy

< j​effro256:monero.social > thanks for the ping

< r​ucknium:monero.social > me: Reading papers about selfish mining countermeasures and decentralized consensus protocols. Helping test rolling DNS checkpoints on testnet. Making fixes to moneroconsensus.info and moneronet.info

< v​tnerd:monero.social > me: working on special build for dns checkpoint testing, and looking at carrot+lws stuff

< j​berman:monero.social > me: fixed a couple bugs testing forking from current testnet (in the migration and in scanning), cleaned up the FFI (removed unwraps/asserts, used int error returns, de-duplicated some code with macros, clippy+fmt), implemented consolidated paths in the RPC for getting paths in the tree by global output id, reorganized curve trees db logic into a saner structure in prep for PR(s)

< j​berman:monero.social > to the main monero repo, tested kayaba's latest prove/verify optimizations (good results!!)

< tevador > me: researching selfish mining countermeasures (Hi)

< j​berman:monero.social > Repeating from NWLB: good news for the stressnet: kayabanerve implemented linear prove() times, dropping 128-input tx construction down from 5m30s to ~1m!! Huge

< j​effro256:monero.social > me: initiated communication about Carrot follow-up review by Cypherstack, updated FCMP++ benchmark tool for all the latest FCMP++ changes (github.com/jeffro256/clsag_vs_fcmppp_bench/), working on supporting high input counts in benchmark tool, working on patches in Monero core repo, re-reviewing the de-dup PR by rbrunner7, reviewed several PRs in seraphis-migration, did a write-up<clipped messag

< j​effro256:monero.social > for an upcoming vuln disclosure, helped prepare v0.18.4.2 release. The de-dup PR does a great job at naturally excluding nodes from the known spy node list, which is great! monero-project/monero#9939

< a​rticmine:monero.social > I updated my comments on the FCMP++ weight function. I am also working on a full write-up on Monero s calling generally.

< a​rticmine:monero.social > I am also working on the block signing remix

< k​ayabanerve:matrix.org > monero-oxide migration, optimizations and improvements.

< r​ucknium:monero.social > 3) Carrot follow-up audit.

< j​effro256:monero.social > In communication w/ Cypherstack right now, clearing up scope and such b4 a quote. Is there anything about the scope that people here think should be changed?

< j​effro256:monero.social > Or object generally?

< j​effro256:monero.social > Or any questions?

< j​berman:monero.social > It LGTM

< rbrunner > Same here - as far as I understand such stuff ...

< j​effro256:monero.social > One broad point about the scope we could try to tackle now is adding security arguments for a quantum-resistant migration.

< j​effro256:monero.social > The amount commitments opening should be quantum resistant, the openings for address spend pubkeys I'm less sure about. Going down that path would surely expand the scope significantly. We could also try to tackle that later

< j​effro256:monero.social > Or we might deem it unncessary

< j​berman:monero.social > I would lean toward NACK on that for now since we have more auditing to get through to take fcmp++ to mainnet

< j​berman:monero.social > and Carrot

< j​effro256:monero.social > I would generally agree, but the option is there

< tevador > Are the reasons for the protocol tweaks specified somewhere?

< j​effro256:monero.social > Yes, but it's scattered about in different git commits. I should write down the rationals in one place

< tevador > Yes, I think it should be part of the scope (to verify that the goal of each change is achieved).

< k​ayabanerve:matrix.org > I haven't reviewed this and have no comment other than deferral to jeffro

< r​ucknium:monero.social > Any more discussion of this item?

< j​effro256:monero.social > tevador:

< j​effro256:monero.social > By adding the amount to the derivation of the amount blinding factor, we add ~32 bits of security to Carrot-style openings of the amount commits, which potentially allows quantum-resistant migrations in the future.

< j​effro256:monero.social > By removing the cofactor clear, our X25519 ECDH is A) faster, and B) easier to tweak a standards conformant library to get correct results.

< j​effro256:monero.social > By removing K_s from anchor_sp, for accounts where there are two or more main addresses (i.e. hybrid key hierarchies), you would have to calculate-and-check anchor_sp that many times (which is not secure against collisions), or disable special enotes to yourself.

< j​effro256:monero.social > By removing K^j_v from d_e, once s_sr (the X25519 ECDH exchange in normal enotes) is derived, you no longer need the private view-incoming key or subaddress table to scan normal enotes, which simplifies the scanning code.

< tevador > OK, I think we can move onto the next item.

< j​berman:monero.social > Generally agree with tevador's idea that above rationale makes sense to include in scope

< r​ucknium:monero.social > 4) Discussion: Replace Monero's hash-to-point function with the FCMP++ Upgrade.

< k​ayabanerve:matrix.org > We rely on the hash to point to be a collision resistant hash function to resolve the burning bug. The current HtP isn't a good CRH. We can add a new HtP in ~10 lines. jeffro256: volunteered to update the codebase so all CARROT outputs, already a new type, define their key image generator via a HtP. The FCMP++ upgrade makes it trivial to update the HtP. I've discussed this as a po<clipped message

< tevador > I wrote my opinion on github. I don't think that the change is worth it. The security benefit is questionable.

< k​ayabanerve:matrix.org > tential change for over a year. I just finally did the work to review our existing HtP and confirm it should be replaced.

< k​ayabanerve:matrix.org > tevador has prior advocated against the change due to the marginal increase in security. I'll note that while there's an explicit marginal benefit, the hash function also has implicit bias I'm not sure has ever been formally bounded.

< k​ayabanerve:matrix.org > Even the unbiased version I'm proposing is bounded to 10/sqrt(q), so ~123 bis of security to my understanding. That raises the question of how much worse the current version is.

< j​effro256:monero.social > As to whether the security is worth it, I leave that to people smarter than me. However, if there is a valid argument for the increase in security, I am willing to update all my relevant code to handle that change.

< k​ayabanerve:matrix.org > We can also make more than 10 lines of edits (100 lines?) To become standards compliant, as we almost are compliant with what became the standard, and optimize the resulting function by ~20-40% (but this isn't a performance critical fn after FCMP++). The main benefit is anyone who uses Monero without using the Monero C++ would be able to write a key image generator function <clipped message

< k​ayabanerve:matrix.org > without writing bespoke elliptic curve arithmetic (due to any impl of the standard being relevant).

< k​ayabanerve:matrix.org > If we define the security of our protocol as the security of the weakest component, I wouldn't be surprised if this HtP was technically it.

< tevador > It will be far more than 10 lines of code. Just the fact that RCT and FCMP transactions will coexist for some time will need to be coded for.

< DataHoarder > my opinion, ^ I have been bitten by the bespoke ec math for hash to point specifically, otherwise I was able to make everything else using generic libraries

< j​berman:monero.social > From my view: the benefit seems pretty small, and the change seems pretty small as well. It adds some complexity to manage as tevador notes

< k​ayabanerve:matrix.org > The unbiased hash to point function is ~10 lines tevador

< k​ayabanerve:matrix.org > The call sites will be more, hence why the old RingCT code remains as-is and we use the separation already introduced for CARROT outputs for the new HtP.

< k​ayabanerve:matrix.org > We already have to delineate old outputs from CARROT outputs. cc jeffro256

< j​berman:monero.social > FWIW in tree building we do already have an indicator determined by whether or not an output is Carrot or not (if Carrot, then consensus already made sure the output does not have torsion)

< j​berman:monero.social > So it wouldn't be such a major change to introduce in there

< k​ayabanerve:matrix.org > Even if it is just a few bits or just half a bit, we shouldn't sacrifice them for naught. The moment we realize any cryptography, we realize losses in our security. Our job should always be to minimize those.

< k​ayabanerve:matrix.org > Else, these will add up and add up, and we'll end up with a protocol whose practical bound is lower than desired.

< j​berman:monero.social > On the flip side, if someone wants to write a Monero wallet that can deal with older txs pre-FCMP++, I figure they would still need the old hash to point implemented too

< tevador > Since the biased function is based on Elligator, its security might have been already studied. Could be worth looking into it more.

< k​ayabanerve:matrix.org > It has, and the recommendation for an unbiased version when you need a CRH is from that research.

< k​ayabanerve:matrix.org > Also, the 10 / sqrt(q) bound for calling it twice and summing the result is from an Elligator author.

< tevador > You wrote above: "the hash function also has implicit bias I'm not sure has ever been formally bounded"

< k​ayabanerve:matrix.org > It depends on the exact curve parameters due to the reduction from the order of the field the curve is defined over to the order of the curve.

< k​ayabanerve:matrix.org > You'd need research specific to Curve25519, which may scrape by due to how small the primes are after the leading bit?

< j​effro256:monero.social > FWIW, working with Carrot outputs in the Carrot libs already don't use much of the higher-level key image helper functions that the current code uses, because those are meant for univariate key images and the API would have to be modified

< k​ayabanerve:matrix.org > But that research has been largely forsaken AFAICT because there's other reasons for bias leading people to simply invoke it twice for am unbiased variant, and formalize the bias on that instead

< tevador > It's pretty likely that the bias is exactly 1 bit since it covers half of the curve.

< k​ayabanerve:matrix.org > But you're right, I may have missed a prior formalized bound for single-invocation Elligator over Curve25519

< k​ayabanerve:matrix.org > tevador: I'm pretty sure some resulting points appear more frequently due to the difference in orders.

< tevador > It's possible.

< k​ayabanerve:matrix.org > It's part of the commentary from Hamburg when the IRTF standardized hash to points.

< k​ayabanerve:matrix.org > That's the 'implicit, unformalized' bias I'm gesturing at.

< k​ayabanerve:matrix.org > But again, Curve25519 moduli are favorable and the torsion clear may also be beneficial?

< k​ayabanerve:matrix.org > It's just a such a mess we can either research it or fix it, and it's the perfect time to fix it.

< tevador > I think we should investigate and also model worst case attacks. I think even if you can find a collision in Hp, I don't think it implies you can burn an ouput.

< k​ayabanerve:matrix.org > See jberman, jeffro256 noting we have the perfect spots to deal with this.

< k​ayabanerve:matrix.org > It does because if you have the outgoing view key.

< k​ayabanerve:matrix.org > You can create two outputs with the same discrete logarithm for their key image, and then you solely need a key image generator collision to perform a burn.

< tevador > For RCT it does not imply burning an output. I'm not very familiar with Carrot.

< k​ayabanerve:matrix.org > It's an FCMP++ comment, not a CARROT comment. You're right for RingCT.

< tevador > If FCMP is more vulnerable than RCT, the update can make more sense.

< k​ayabanerve:matrix.org > FCMP++ allows users to publish what were RingCT private spend keys and are now FCMP++ outgoing view keys for newly created wallets.

< k​ayabanerve:matrix.org > The only reason that's safe is because the key image generator is a CRH binding to the outgoing view key and the private spend key.

< k​ayabanerve:matrix.org > See the difficulties Seraphis had with the burning bug, leading Seraphis to define the outgoing view key as a point and a scalar whose ratio formed the linking tag.

< tevador > ^ I don't think this was mentioned in your proposal on github. That's a pretty strong point.

< k​ayabanerve:matrix.org > I did say we require it to be a CRH to stop the burning bug 😅

< k​ayabanerve:matrix.org > But I'm sorry I didn't provide sufficient context/background on that

< j​effro256:monero.social > Although it might be that if people scan CARROT enotes honestly, they can always avoid a burn even if the hash-to-point is not coliision resistant since it would always be the case that x!=x' for some O = x G + y T and O' = x' G + y' T if O!=O'.

< k​ayabanerve:matrix.org > I don't believe so since they only have to be able to scan one of them, not both.

< j​effro256:monero.social > Yes, and the other one is guaranteed to have the same one-time address EC point. Assuming the receiver is scanning honestly (and thus recomputes the one-time address as a function of their spend pubkey), only the receiver should know the discrete logarithm of that point, so the other can't spend it

< k​ayabanerve:matrix.org > IMO, this has sufficient feasibility and acknowledgement to move forward, at least within the scope of this meeting which is 50m in over only a few topics.

< k​ayabanerve:matrix.org > jeffro256: No, they aren't.

< k​ayabanerve:matrix.org > They're guaranteed to have the same key image discrete logarithm and the same key image generator.

< k​ayabanerve:matrix.org > The whole ides is two different one-time addresses can share a key image if the CRH property of the HtP is broken.

< k​ayabanerve:matrix.org > They're allowed to have distinct y values.

< r​ucknium:monero.social > Discussion can continue in the GitHub issue and next meeting. Thanks.

< r​ucknium:monero.social > 5) MRL rooms moderation.

< r​ucknium:monero.social > SyntheticBird: You suggested this item.

< s​yntheticbird:monero.social > Hi

< s​yntheticbird:monero.social > Yes

< k​ayabanerve:matrix.org > Now, is CARROT sufficient to convert the problem from finding a collision to second preimage, which would remain secure? Maybe. Even if, we shouldn't place that bound on CARROT.

< o​frnxmr:monero.social > Too much spam & trolling in lounge, not enough kicks or mutes

< k​ayabanerve:matrix.org > A member here has sent nothing of value, insulted me for days, and arguably even made a threat.

< s​yntheticbird:monero.social > I have a few complaints regarding the current moderation of the research channel. It comes to no surprise i think that the quality of discussions have degraded in the recent qubic events. What would before be reserved to #monero is now disrupting monero lounge, rarely monero lab. I would like to discuss if there is a possibility to increase moderators in these zones. The discussio<clipped me

< s​yntheticbird:monero.social > ns are not constructive, arguments repetetive and often turns into shilling fight whenever a random or a bot comes in to stir the pot.

< c​aptaincanaryllc:matrix.org > more moderation would be welcome

< s​yntheticbird:monero.social > If the increase in moderator is not justified then I would ask the moderators to be more strict

< r​ucknium:monero.social > Conversations should move according to the procedure: #MRL (heaven) -> #MRL-Lounge (purgatory) -> #Monero-Beef (hell).

< j​effro256:monero.social > I think that CARROT converts the problem of finding the same x to also finding a collision on the hash-to-scalar, but I'll think about it some more. Though I do agree that it's a bit sketchy for CARROT to have that bound

< o​frnxmr:monero.social > I dont even think beef is necessary for a lot of this, not that lounge is purgatory. some of these topics arent "off topic" but are time sinks and distractions

< s​yntheticbird:monero.social > Yeah ngl, interestingband case is kind of annoying. He have a beef with the people with permissioned which either ignore him or maybe do not want to appear like mod abusing. But he has passed the point of being constructive

< tevador > I'm not sure how moderation can work with the relays, at least from the IRC side. But I agree that this room should be more strictly moderated.

< r​ucknium:monero.social > "Stir the pot" and "producing more heat than light" should be avoided in all MRL rooms, observed voluntarily on the part of participants, if possible.

< c​aptaincanaryllc:matrix.org > some pretty lazy attempts at manipulation/subversion happening in lounge on regular basis since qubic

< s​yntheticbird:monero.social > Rucknium: I totally agree and in the fact no moderator intervene when this is obviously the case.

< c​aptaincanaryllc:matrix.org > even to the point of harassing devs just to waste time

< DataHoarder > I have been trying to sync up the new bridge to deploy it soon, probably starting with specific monero rooms first. It can make moderation from Matrix side easier, as each user on IRC will appear distinct

< r​ucknium:monero.social > A scientific tone is appreciated.

< o​frnxmr:monero.social > And worse, long term members (..and mods) are dragged into it and make it worse

< s​yntheticbird:monero.social > It's not just a matter of ban but also telling people to stop the false discussion because its disrupting other to introduce another useful talk

< DataHoarder > Mapping of bans/kicks on each side is a feature that it has, although not widely tested (and relay on irc side would need at least half-op rights)

< o​frnxmr:monero.social > I think lounge should be related to work, and people working

< o​frnxmr:monero.social > Not AMA

< DataHoarder > This is in response of your ask about relays, tevador

< tevador > DataHoarder: thanks

< c​aptaincanaryllc:matrix.org > I think that any kind of hyperbole in that channel seems detrimental

< DataHoarder > monero.social Matrix gods allow, this should finish syncing up today (it's up to the 25th of July now, it has been syncing up from 2024 events)

< r​ucknium:monero.social > DataHoarder has been MVP recently 🎉

< s​yntheticbird:monero.social > DataHoarder, very excited to see the new bridge operational

< r​ucknium:monero.social > (Not minimum viable product, but most valuable player)

< DataHoarder > I was MVP 20+ years ago :)

< o​frnxmr:monero.social > Can i be the lowercase mvp?

< DataHoarder > People find their way in these channels and usually get asked to move elsewhere for specific discussions, but some just ... continue

< s​yntheticbird:monero.social > I think first things we could try get a rough consensus on is whether new moderators are necessary

< DataHoarder > after that, a mute or enforcement could be necessary to prevent channel spam

< r​ucknium:monero.social > Any more to say on this item?

< o​frnxmr:monero.social > diego cc

< s​yntheticbird:monero.social > Rucknium: i think i'm good, the discussion can happen later.

< p​lowsof:matrix.org > isn't Rucknium mod here and in lounge yet?

< c​haser:monero.social > keeping out Qubic sock puppets and concern trolls IMHO is paramount, otherwise valuable discussions and valuable contributors will be turned away from participation. the current admins seem to be MIA. I wouldn't mind having more of them.

< o​frnxmr:monero.social > No

< r​ucknium:monero.social > I'm not mod of any room. I was mod of -beef 😢

< s​yntheticbird:monero.social > Butcherium

< o​frnxmr:monero.social > You are 😆

< r​ucknium:monero.social > I prefer not to have mod powers because mod powers involves you in controvery unnecessarily, but if it's for the collective good, then I can get mod powers.

< r​ucknium:monero.social > The collective good has spoken, it seems.

< p​lowsof:matrix.org > you moderate meetings here, lounge can be handled by banhammer

< o​frnxmr:monero.social > lounge can be handled by ruck

< r​ucknium:monero.social > [Note to IRC side: I am admin now in Matrix MRL room]

< o​frnxmr:monero.social > I'd volunteer, but yknow how that goes

< s​yntheticbird:monero.social > if he wishes so tho

< r​ucknium:monero.social > 6) Transaction volume scaling parameters after FCMP hard fork.

< d​iego:cypherstack.com > Lel

< o​frnxmr:monero.social > articmine updated comment today

< k​ayabanerve:matrix.org > Rucknium: I prefer turkey

< j​berman:monero.social > I'm still not understanding why the disincentive should be so strong for 128-in versus 16x 8-in

< s​yntheticbird:monero.social > chain bloat

< ArticMine > My thought on this is that we can separate the weight that is due to proofs from the rest of the transaction weight and then apply a function so that after the quadratic penalty the fee tracks verification time more closely

< o​frnxmr:monero.social > chain bloat is easier with lower input txs

< o​frnxmr:monero.social > seraphis-migration/monero#44 (comment)

< s​yntheticbird:monero.social > mea culpa i thought the opposite

< o​frnxmr:monero.social > 1 and 2 input txs are the longest verification and highest size

< ArticMine > if one want to maximize spam with mined transaction the smallest weight is optimal

< ArticMine > sinnce this is where the penalty is lowest

< ArticMine > So there is a case to counterbalance this by favoring large transactions

< j​berman:monero.social > I'm not sure I fully follow, Artic are you proposing to update the original proposal with new forumlas?

< o​frnxmr:monero.social > 2c: If fees are set linearly per-input, higher input txs end up paying more per byte than lower input

< ArticMine > If we want the fees to be close to linear with verification time then we will have to apply a weight formula to favor large transactions

< ArticMine > So if this is the wish of the community then yes

< ArticMine > My main concern here is that the transactions be economic to mine

< j​berman:monero.social > linear would mean that it is roughly comparable cost to construct 16x 8-in's compared to 1x 128-in, not to make one more favorable than the other

< ArticMine > Yes

< k​ayabanerve:matrix.org > I think we should set an 8-in/4-out limit and not have large transactions.

< j​berman:monero.social > (although I think there is a stronger argument for 16x 8-in's to cost more)

< ArticMine > This needs a square root weight formula on the proof part of the weight

< k​ayabanerve:matrix.org > Alternatively, a linear weight sounds fine without favoring either side. If anything, I'd call for large TXs to pay notably more than smaller TXs to provide an economic incentive for people to move to small TXs, as we may require in the future.

< ArticMine > My point is we can tune the weight formula to what ever is desired

< DataHoarder > P2Pool coinbase outputs :)

< o​frnxmr:monero.social > Why should my wallet bloat the chain by splitting my tx into 16 instead of just sending the damn thing

< k​ayabanerve:matrix.org > ofrnxmr: Transaction uniformity.

< DataHoarder > those tend to be plenty, and small, which with this change would make using p2pool more expensive than a centralized pool due to even higher fees

< k​ayabanerve:matrix.org > And again, this may become a hard requirement in the future. We want people to get prepared now with solutions now.

< k​ayabanerve:matrix.org > I have been told no to 8/4 and I think you all are horrible people who hate privacy and don't understood anything /s

< s​yntheticbird:monero.social > me but unironically

< o​frnxmr:monero.social > Tx uniformity would be a fixed 1 or 2 input tx, not 8 4 2 1

< ArticMine > So i propose we separate the proof parts of the total weight from the rest of the transaction weight, then I can provide options for consideration

< k​ayabanerve:matrix.org > On a legitimate note, if we have an end goal of uniformity, we will decrease from 128 in. I understand we aren't doing so now. We should still nudge people towards less and less inputs per TX.

< k​ayabanerve:matrix.org > 8 in/4 out is a valid uniformity target ofrnxmr

< k​ayabanerve:matrix.org > Dummy inputs/dummy outputs

< j​berman:monero.social > > I intend to break out membership proof size and verify time into 2 additional columns

< j​berman:monero.social > I can do this today

< o​frnxmr:monero.social > my input count on ringct has privacy issues (cospends). What issues for fcmp?

< k​ayabanerve:matrix.org > 4/3 is a minimum established by CARROT.

< o​frnxmr:monero.social > ..afaict, uniformity doesnt add privacy w/o knowledge linking the inputs together

< o​frnxmr:monero.social > And with fcmp, its my understanding that the history of the inputs arent linkable to their origins

< c​haser:monero.social > I (non-sarcastically) agree reducing the number of in/out combinations is a legitimate and viable way toward tx uniformity, and would nudge people toward that even without universal dummies and IVC

< k​ayabanerve:matrix.org > ofrnxmr: More inputs signifies you're an exchange or service provider.

< o​frnxmr:monero.social > no it doesnt

< k​ayabanerve:matrix.org > It's a long-term goal for all TXs to be indistinguishable, which would include fixed input/output count.

< r​ucknium:monero.social > Number of inputs in a FCMP tx probably only gives information to the tx recipient, not an external blockchain observer.

< c​haser:monero.social > ofrnxmr: it still betrays a lower bound on how many enotes you own in that wallet

< k​ayabanerve:matrix.org > With statistical likelihood? Yes. A new user who just joined the network won't have 128 inputs on day one.

< o​frnxmr:monero.social > I can have 128 x 10$ inputs and be spending $1000

< k​ayabanerve:matrix.org > It leaks how many TXs the creator of the TX was involved with.

< ArticMine > A very important point. If we have minimums with 4in then the reference transaction weight will have to be changed

< ArticMine > and very likely the minimum penalty free zone

< k​ayabanerve:matrix.org > So I do want to encourage Monero down that path, but obviously, we can't jump down to the end of 8/4.

< k​ayabanerve:matrix.org > So an economic incentive for fewer inputs may be a good first step.

< o​frnxmr:monero.social > i think this is a non-issue, and disagree that there should be incentive to blocat the chain for pseudo privacy

< o​frnxmr:monero.social > Its not an economic incentive for node runners to store more data for less money

< ArticMine > In other words if the minimum transaction weight is going to be say between 10000 bytes and 20000 bytes then ZM will meed to increase to 2000000 bytes

< k​ayabanerve:matrix.org > Also, we're limiting inputs to 128 with FCMP++, and I'd support limiting to 64 in the future as well.

< k​ayabanerve:matrix.org > Taking steps.

< j​effro256:monero.social > ArticMine: that 4/3 is a minimum bound for a maximum limit rule. Txs can still have 1-3 ins

< tevador > Is dummy input support planned for FCMP? Proposed here: monero-project/research-lab#96 (comment)

< k​ayabanerve:matrix.org > Not planned.

< j​berman:monero.social > not at the moment no

< ArticMine > ... but will they be the same weight as 4in?

< k​ayabanerve:matrix.org > But it'd work and wouldn't be the most difficult, nor the most costly :) You did good tevador

< j​effro256:monero.social > Although I think it's really more like 3/2, but it depends on how you count it

< j​effro256:monero.social > ArticMine: depends on how we end up defining weight. Byte size? No. Should it be the same weight? Almost certainly noyt

< k​ayabanerve:matrix.org > TL;DR IMO, long-term goal of uniformity. TX cost should respect byte size and verification cost, as the Bulletproof clawback does. We can step towards uniformity by additionally penalizing large TXs so that it's cheaper to do small TXs instead.

< o​frnxmr:monero.social > Low input txs***

< k​ayabanerve:matrix.org > We don't have to agree on uniformity as a goal now. We can start just by discussing if weight should be linear to size and time, or just size, or what

< o​frnxmr:monero.social > Those are larger per input, so not "small"

< k​ayabanerve:matrix.org > I can sidetrack us with a penalty on large TXs later

< j​berman:monero.social > Back-tracking a bit, my opinion on weights assuming we maintain the current plan to support up to 128 inputs: I think a formula with linearly increasing weight will probably be simplest and easiest to justify. But will review artic's updates to the proposal, and will break out membership proof size and verification times

< ArticMine > What i do need is typical transaction weights for the bulk of the transactions currently 2in

< ArticMine > if these are replace by 3in or 4in

< tevador > What would be the size of 4/3?

< ArticMine > that is what I need to knnpw

< o​frnxmr:monero.social > This is smooth brained, but again: charging a fixed amount per input ends up more costly per byte for higher input txs, with no obvious penalty to the user

< o​frnxmr:monero.social > kayaba

< j​berman:monero.social > Here is a table with all FCMP++/Carrot tx sizes and verification times, for all input and output combinations: seraphis-migration/monero#44 (comment)

< ArticMine > my understanding is between 10000 and 20000 bytes

< ArticMine > for 4in

< tevador > The table says 10462

< k​ayabanerve:matrix.org > I'd be fine with byte size + fixed amount per input to be respective of verification time. That doesn't encourage making smaller TXs though. Larger TXs are still favored due to their smaller overall byte size.

< ArticMine > 4in are still below 13000 bytes

< j​effro256:monero.social > Byte size for Carrot 4-in is 10240-12216

< k​ayabanerve:matrix.org > But I'd be fine with it. I'm not trying to force in my policies on uniformity today. I've conceded it's a long-term goal at best. I thought an economic penalty may be a decent first step.

< tevador > A (nearly) fixed tx size would remove a lot of the issues with fee scaling.

< ArticMine > So most likely changing TR to 15000 bytes and ZM to 1500000 bytes would work

< ArticMine > it is a very simple change

< ArticMine > on my part

< o​frnxmr:monero.social > Miners get paid more per byte but less per verification time. Users dont see any difference

< j​effro256:monero.social > Is ZM the penalty free minimum ? I don't know how I feel about increasing that...

< ArticMine > Miners get paid per byte of weight

< ArticMine > Yes XM is the penalty free minimum

< ArticMine > ZM

< ArticMine > My question is: do we have consensus for 4in as a standard

< ArticMine > If so i can implement the scaling changes

< o​frnxmr:monero.social > No

< j​effro256:monero.social > Miners ostensibly don't care about transaction verification time unless it affects the speed of their block propagation. Ideally, each transaction in their mined block is already in honest nodes' mempools already

< j​effro256:monero.social > I don't think 4-in should be a standard IMO, IIRC <1% of current Monero txs are 4-in

< k​ayabanerve:matrix.org > jberman has asked I submit the optimized Field25519 impact which impacts verification time via a patch (not waiting for upstream to merge) and to get numbers accurate to the final target. I'll try to do so shortly after this.

< k​ayabanerve:matrix.org > TL;DR Numbers are still variable and may change by ~20% by tomorrow on this point alone.

< k​ayabanerve:matrix.org > jeffro256: 3 isn't a power of 2, and we can't do 2 in unless in < out :C

< j​effro256:monero.social > fair point

< ArticMine > So if I understand correcty 4in is the minimu?

< k​ayabanerve:matrix.org > A 3-in is effectively entirely as costly as 4-in, on proof size and verification time. It saves the 32 bytes in the key image store, and ~1kb for the signatures + the commitments we can't assume are zero (but still pay the verification cost on).

< k​ayabanerve:matrix.org > Long-term goal: less input TXs.

< k​ayabanerve:matrix.org > IMO, for now: TX weight linearly respective to size and time, potentially penalizing larger TXs in a way encouraging smaller TXs instead.

< k​ayabanerve:matrix.org > Instead of forcing people to write better code, we can have them save money if they write better code.

< o​frnxmr:monero.social > at the cost of my ssd storage .. and bandwidth

< j​effro256:monero.social > ArticMine: 4 is the minimum value we should set the maximum limit rule to, not the minimum input count. In other words, we should never add a rule which limits the input count to less than 4. But txs with <4 ins can exist

< j​effro256:monero.social > And will exist, probably continuing to be the majority of txs like it is today

< o​frnxmr:monero.social > As a miner, i earn more if i store less data = logic is backwords

< o​frnxmr:monero.social > Backwards*

< j​effro256:monero.social > In other other words, 4-in transactions need to be able to exist

< ArticMine > I understand that tx with less than 4 can exist but they will have the same or similar weight as 4 in. If so then I must change the scaling paramenters

< o​frnxmr:monero.social > Penalizing large in with higher fees means miners are incentivized to prefer large in txs

< j​effro256:monero.social > No they should not have a similar weight as a 4-in IMO

< j​berman:monero.social > I think easiest to justify / achieve consensus on would be: linear increasing weights, clamping to higher powers of 2 to incentivize powers of 2

< k​ayabanerve:matrix.org > (Though Monero TXs are so cheap right now that may not matter 😅)

< k​ayabanerve:matrix.org > ofrnxmr: that requires users make large input TXs for miners to have that option, and users won't be incentivized to.

< j​effro256:monero.social > I agree with jberman. Now the question is: linear with respect to the input count itself, or linear with respect to the proof size of that many inputs?

< k​ayabanerve:matrix.org > I don't think miners are a relevant part of the puzzle here.

< k​ayabanerve:matrix.org > If there's a congested mempool, the existing fee market handles all.

< o​frnxmr:monero.social > not if i make my own block templates ..

< r​ucknium:monero.social > IMHO, it could be a good idea to pin tx fee levels to network hashpower. Hashpower follows the purchasing power of 1 XMR closely. Or, closely enough.

< ArticMine > What matter is the weight of the bulk of the transactions currently 2in or less? So are the proposed FCMP++ 2in weights going to hold

< o​frnxmr:monero.social > thats pinning to usd

< k​ayabanerve:matrix.org > I would say linear to TX size and linear to inputs. Two separate terms in the equation jeffro256

< k​ayabanerve:matrix.org > Model space and time

< r​ucknium:monero.social > That could end all the discussions of "what if XMR purchasing power increases suddenly" for good.

< k​ayabanerve:matrix.org > ofrnxmr: Even with your own block template, you can't make higher paying TXs appear out of thin air.

< r​ucknium:monero.social > It's pinning to purchasing power of a CPU.

< j​effro256:monero.social > kayabanerve: Not necessarily. What we want to avoid is people adding transactions into the mempool which miners aren't incentivized to mine so they stick around. This can happen when the penalty free zone is saturated

< a​rticmine:monero.social > Correct

< r​ucknium:monero.social > and/or a kilowatt hour of electricity.

< o​frnxmr:monero.social > Yes you can. Mine empty blocks until ppl raise their fees

< r​ucknium:monero.social > You need a mining cartel to do that

< r​ucknium:monero.social > Let's continue the agenda

< ArticMine > We need to use node relay to block not economic transactions

< r​ucknium:monero.social > See "Monopoly without a monopolist" paper

< k​ayabanerve:matrix.org > ofrnxmr: that attack always exists

< r​ucknium:monero.social > 7) FCMP alpha stressnet planning.

< o​frnxmr:monero.social > i think would be nice to have kayabas tx creation speedups in for stressnet

< ArticMine > I have to attend another meeting

< j​berman:monero.social > re: alpha stressnet, just 1 more blocker PR needed

< o​frnxmr:monero.social > ty artic

< r​ucknium:monero.social > ofrnxmr: Did you try much with the Monero Research Computing Cluster?

< j​berman:monero.social > I don't think it needs to be a blocker, we can merge it in after launch/people can run it if they want even without a merge

< o​frnxmr:monero.social > No, i synced up a couple nodes but havent started spamming from there yet

< r​ucknium:monero.social > A very "tidy" setup would be to have a docker container or something with a node, a monero-wllet-rpc, the spam script, and a unique wlalet in each.

< j​effro256:monero.social > I took a deeper dive into 0xfffc 's 9494 PR, and I'm satisified with it. I'm currently reviewing PR #81 in seraphis-migration. I think we could start planning a launch date

< k​ayabanerve:matrix.org > The Monero FCMP++ branch has a PR from me moving from j-bermam/fcmp-plus-plus (a fork of kayabaNerve/fcmp-plus-plus) to monero-oxide/monero-oxide#fcmp++ which now hosts the FCMP++ libraries.

< r​ucknium:monero.social > Junior in MRC has plenty of storage for lots of stressnet nodes, but Senior doesn't. Maybe some storage could be moved there.

< j​berman:monero.social > I would propose launch date 7 days after merging #81

< o​frnxmr:monero.social > Except w/o docker

< j​effro256:monero.social > This could be done, but IDK if deterministic builds for GUIX and Rust are ready yet, so users would have to just trust a single person

< k​ayabanerve:matrix.org > The monero-oxide/monero-oxide#fcmp++ code has most of the optimizations I've made recently. I also proposed a faster verifier, but it's on a branch and will not be included as it'd need to be audited (or at least heavily reviewed) to be merged.

< r​ucknium:monero.social > I don't like docker either. Any way to do dockerless docker? :P

< k​ayabanerve:matrix.org > It's 15-20% faster for 128-input TXs though.

< k​ayabanerve:matrix.org > (8% for 64, and rather negligible after)

< r​ucknium:monero.social > Last time on stressnet the spamming monero-wallet-rpc instances could not stay connected to nodes easily. So I did one node per rpc instance IIRC.

< k​ayabanerve:matrix.org > monero-oxide/monero-oxide#fcmp++ does target Rust 1.69 for the relevant libraries, as we need for cross-compilation and Guix. cc tobtoht

< o​frnxmr:monero.social > Thats due to the 100mb txpool

< o​frnxmr:monero.social > Restricted-rpc works

< k​ayabanerve:matrix.org > I'll also try to submit the patch for the Field25519 arithmetic tonight for jberman's benches, but I see no reason we can't also include it in stressnet.

< r​ucknium:monero.social > jberman 's proposal "I would propose launch date 7 days after merging #81" sounds fine to me.

< j​effro256:monero.social > I plan to hop back on reviewing #81 when I'm done with reviewing the peer dedup PR

< r​ucknium:monero.social > jeffro256: I removed the spy nodes agenda item for this meeting. Should it be put back in, or can it be skipped today?

< r​ucknium:monero.social > I noticed your new comments on the peer subnet deduplication PR

< o​frnxmr:monero.social > Just the one thinf about dns blocklist

< r​ucknium:monero.social > Any more discussion on alpha stressnet planning?

< o​frnxmr:monero.social > Consensus to update blocklist to remove a couple old ones and add active subnet(s)?

< j​berman:monero.social > "Any more discussion on alpha stressnet planning?" -> nothing from me

< r​ucknium:monero.social > ofrnxmr: This one? #1242

< o​frnxmr:monero.social > Yeah

< j​effro256:monero.social > It can be skipped IMO

< r​ucknium:monero.social > Maybe more thumbs can be upped on #1242

< r​ucknium:monero.social > 8) CCS proposal: kayabaNerve Finality Layer Book.

< r​ucknium:monero.social > What are the advantages and disadvantages of a finality layer compared to rolling N-block (e.g. 10) checkpoints, where nodes refuse to re-org to a new alt-chain deeper than N blocks?

< k​ayabanerve:matrix.org > The fact one can have formally-proven safety in an asynchronous model and one immediately fails even in the synchronous model?

< a​tomfried:matrix.org > I still dont realy know a good, decetnralized, fair and secure way of selecting the validators.

< k​ayabanerve:matrix.org > If Qubic achieves a 10-block reorg, which IIRC they've demonstrated multiple 9-block reorgs, suggesting they could, it'd immediately netsplit off all new nodes.

< k​ayabanerve:matrix.org > (any nodes not online at the time of reorg)

< r​ucknium:monero.social > Are you aware of any scholarship on N-block rolling checkpoints?

< r​ucknium:monero.social > An easy fix is to have deterministic tiebreaking at N block re-orgs.

< r​ucknium:monero.social > Deterministic tiebreaking has been studied in many papers.

< k​ayabanerve:matrix.org > Until the 'didn't reorg' group achieved a chain with more work, if they ever did, but then the nodes which followed Qubic's chain won't reorganize back.

< r​ucknium:monero.social > (Instead of first-seen rules)

< o​frnxmr:monero.social > theyd have to maintain the longest chain, else the offline nodes will eventually be reorged onto the "honest" chain

< k​ayabanerve:matrix.org > We're at a point where we have to replace 10 with 20, if we were to discuss not reorganizing past N IMO.

< k​ayabanerve:matrix.org > (cc Rucknium for actual statistics on this)

< k​ayabanerve:matrix.org > And all of this, IMO, implies PoW has been shown to be insufficient for the Monero network as it stands.

< k​ayabanerve:matrix.org > While there are proposed improvements, I'm not convinced they do any better than marginal.

< b​oog900:monero.social > to get back to the real chain they would need to do a reorg bigger than 10 blocks, right?

< r​ucknium:monero.social > Are you referring to my analysis here? monero-project/research-lab#102 (comment)

< k​ayabanerve:matrix.org > A proper finality layer would also presumably remove the 10-block lock.

< tevador > A deterministic tie break won't fix chain splits. The attacker will instead publish an 11-block reorg + 1 block on top of the honest chain simultaneously.

< b​oog900:monero.social > oh the offline nodes

< k​ayabanerve:matrix.org > ofrnxmr: No because they won't reorg off Qubic's due to the same max reorg rule.

< o​frnxmr:monero.social > Depends on how long the lead was maintained

< k​ayabanerve:matrix.org > Rucknium: Probably. The question would be since Qubic exists, with the attacks they've demonstrated, what reorg is now sufficiently improbable?

< k​ayabanerve:matrix.org > And is there one with their proximity to 51%, even if it's just occasionally ~30-40% over a 8 hour period?

< r​ucknium:monero.social > tevador: So attack the honest chain and attacking chain simultaneously? Yes, I suppose that could work in the attacker's favor to cause a netsplit.

< k​ayabanerve:matrix.org > Do we wish to move to a (8 * 60 / 2)-block lock, recommended confirmations, and max reorg depth?

< tevador > Anything with a max reorg depth is not PoW anymore.

< b​awdyanarchist:matrix.org > kayabanerve: How much of a factor do you think, is the inclusion of time as an independent variable in consensus, a major factor in a finality layer? Dont most PoS systems use time slots?

< o​frnxmr:monero.social > isnt the main reason 10+ block reorgs are an issue, due to invalidating decoys

< k​ayabanerve:matrix.org > A proper finality layer solves this. A finality layer can replace the 10-block lock. The risk of a finality layer is the finality layer stalling, performing censorship, though that'd enable a social slash, or equivocating. I believe all of those can be made less problematic than PoW today.

< r​ucknium:monero.social > According to what I'm reading by Roughgarden, the less synchronous you become, the more permissioned the validation must be.

< c​haser:monero.social > tevador: indeed

< k​ayabanerve:matrix.org > much less

< DataHoarder > 21:00:11 <k​ayabanerve:matrix.org> If Qubic achieves a 10-block reorg, which IIRC they've demonstrated multiple 9-block reorgs, suggesting they could, it'd immediately netsplit off all new nodes.

< DataHoarder > They have been able to get +14 ahead

< k​ayabanerve:matrix.org > And the amount of discussions DNS checkpoints have gotten, which would be centralized, solely justify my position IMO.

< DataHoarder > they released when monero got 9 deep

< o​frnxmr:monero.social > tevador we already (effectively) have a max reorg depth of a few thousand blocks

< k​ayabanerve:matrix.org > BawdyAnarchist: My proposal is asynchronous BFT which doesn't have bounds on time.

< g​onbat.zano:zano.org > > they've demonstrated multiple 9-block reorgs

< g​onbat.zano:zano.org > kayabanerve They also had the capacity to do 16 blocks and decided not to, according to DataHoarder's research

< tevador > ofrnxmr: technicality

< r​ucknium:monero.social > kayabanerve: What do you want to accomplish with this agenda item? General countermeasures to a malicious mining pool is next.

< k​ayabanerve:matrix.org > Can I have my CCS merged and can the community agree PoW isn't a fundamental tenant of Monero, security and decentralization is? 😅

< o​frnxmr:monero.social > Pow is a fundamental tenant of monero IMO

< r​ucknium:monero.social > Can we not use comma splices? :P

< c​haser:monero.social > kayabanerve: "A proper finality layer solves this..." comment: the finality layer would offer a strong economic incentive against it being stalled/being coopted/censorious. it's not a high-probability event. equivocations (slashing stake for provable misbehavior) can be quasi-automated within the consensus rules.

< tevador > 1) CCS merged - maybe, 2) There will likely be stiff opposition to PoS.

< r​ucknium:monero.social > At least consensus on no-comma-splices.

< k​ayabanerve:matrix.org > We can't say "we declare pos" and move to a finality layer over night. I want the idea to be fairly treated. I believe there's more than sufficient justification to move forward with research and a proposal.

< tevador > I think there is a case for the CCS to be merged. If people donate the required amount, the research should be done.

< k​ayabanerve:matrix.org > chaser It solves it within its bounds. The only solution a max reorg depth is is within the bound 'no miner can attempt more than a 10 block reorg'.

< k​ayabanerve:matrix.org > That's such a disastrous bound, which has already failed, any solution premised on it is a failure.

< k​ayabanerve:matrix.org > But you're right a finality layer is only a solution to a bounded problem (n = 3f + 1).

< r​ucknium:monero.social > Finality layer doesn't solve short-chain selfish mining, does it? And it doesn't solve empty block attacks, but you hinted it might. Or how would it?

< k​ayabanerve:matrix.org > Sorry. In a fully synchronous network, you can assume no nodes are offline and all nodes receive the honest blockchain before any alt is published.

< r​ucknium:monero.social > Is that an amendment to your statement about N-block rolling checkpoints?

< k​ayabanerve:matrix.org > It can if it finalizes the honest chain before the selfishly mined chain is publish, preventing re-org'ing to itm

< k​ayabanerve:matrix.org > It doesn't solve a miner producinga empty blocks.

< c​haser:monero.social > kayabanerve: to clarify, I added the comment because I think the majority of the opposition to the finality layer is rooted in people not having an understanding of proof-of-stake consensus mechanics and nomenclature

< k​ayabanerve:matrix.org > A sufficiently low latency finality layer, on an optimal network, would mean 1% of hash power earns 1% of blocks (again, in an ideal world).

< tevador > Depending on the speed of finalization, selfish mining might still be possible.

< r​ucknium:monero.social > Then you need it explain it. Lots of terms have not been explained. I mean, I would prefer if terms were explained.

< r​ucknium:monero.social > Or offer a reference, which kayabanerve declined to provide when I requested :P

< k​ayabanerve:matrix.org > Rucknium: Yes. A N-block rolling checkpoint works if you have no offline nodes and propagation is instant.

< k​ayabanerve:matrix.org > Who here has 100% uptime on their node?

< k​ayabanerve:matrix.org > Does everyone?

< s​yntheticbird:monero.social > I do

< s​yntheticbird:monero.social > I have triple digit uptime it's not a myth guy

< k​ayabanerve:matrix.org > Sorry, what reference did I decline to provide?

< p​rivacyx:monero.social > I 100% uptime

< k​ayabanerve:matrix.org > Are you talking about the reference of my proposed book? I believe I offered to provide that as soon as my CCS is merged and I actually do the work :p

< r​ucknium:monero.social > You can check empirical update in the last month of many nodes here: https://xmr.ditatompel.com/remote-nodes

< b​oog900:monero.social > the propagation being instant is the bigger problem than uptime

< k​ayabanerve:matrix.org > I agree there's confusion and a lack of understanding. That's why my CCS exists.

< c​haser:monero.social > Rucknium: a finality layer could serve as a foundation for force-inclusion of transactions in blocks, which would actually prevent empty-block attacks.

< b​oog900:monero.social > I can live with offline nodes potentially following the bad chain although its not something I like

< k​ayabanerve:matrix.org > Also because I'm tired of explaining things in lounge for the umpteenth time.

< b​oog900:monero.social > I can't live with nodes online being split be a reorg right at the boundary

< b​oog900:monero.social > by*

< r​ucknium:monero.social > I think a high-hashpower attacker can even get around the force-inclusion of txs by broadcasting high-fee txs and mining them itself.

< k​ayabanerve:matrix.org > Hence why a comment I left is in order to prevent censorship, we have to burn TX fees (at least partially) 😅

< c​haser:monero.social > Rucknium: also, a finality layer, where a block is finalized, I believe treats any length of reorgs the same, short or long.

< k​ayabanerve:matrix.org > This is something I've already noted.

< o​frnxmr:monero.social > wouldnt this just be offset by the block reward

< c​haser:monero.social > Rucknium, kayabanerve: that's true.

< o​frnxmr:monero.social > We already "burn" some block reward

< k​ayabanerve:matrix.org > According to ArticMine, the penalty already is an effective burn.

< r​ucknium:monero.social > Aha, here is what I was referring to: https://libera.monerologs.net/monero-research-lounge/20250813#c557210

< r​ucknium:monero.social > > kayabanerve: Any recommended introductory texts on blockchain finality layers?

< r​ucknium:monero.social > More comments on this item?

< c​haser:monero.social > burning more of the fees in exchange for making empty-block attacks less feasible sounds like a good trade.

< r​ucknium:monero.social > AFAIK, fee burning would reduce the security budget, so there is a tradeoff.

< b​oog900:monero.social > I'm not sure I agree, you can still fill blocks up quite high without hitting the penalty. With FCMP it will go up even more.

< b​oog900:monero.social > just increase fees to cover the drop in proportion going to the miner?

< r​ucknium:monero.social > boog900: Do you have some elasticity estimates 👀

< b​oog900:monero.social > I think fees could probably do with increasing anyway

< r​ucknium:monero.social > The elasticity of tx volume with respect to tx fee

< r​ucknium:monero.social > 9) PoW mining pool centralization. Monero Consensus Status. Bolstering PoW to be Resistant to 51% Attacks, Censorship, Selfish Mining, and Rented Hashpower. Mining protocol changes to combat pool centralization.

< tevador > Raising tx fees is the best way to disincentivize empty blocks.

< tevador > My contribution to this agenda item: monero-project/research-lab#144

< r​ucknium:monero.social > We have a new. Right. New issue from tevador on Publish or Perish

< tevador > Based on my research, this would be the most efficient PoW-only solution.

< r​ucknium:monero.social > A later paper by the same authors suggested PoP wasn't very good.

< r​ucknium:monero.social > One of the papers you cite, "Laying Down the Common Metrics"

< tevador > My referenced paper [6] measured the performance of PoP and it performed the best out of all soft forking solutions.

< r​ucknium:monero.social > The profitablility threshold for a selfish miner, according to that later paper, is .25

< r​ucknium:monero.social > Table II

< r​ucknium:monero.social > Zhang & Preneel (2019) "Lay down the common metrics: Evaluating proof-of-work consensus protocols’ security." https://doi.org/10.1109/SP.2019.00086

< tevador > Profitability threshold is only part of the story.

< r​ucknium:monero.social > I looked closely at proportional reward splitting. It does a lot better than the others, but requires a hard fork and faster PoW verification, as you note.

< b​awdyanarchist:matrix.org > Rucknium: Relative performance depended alot on assumed γ value (percent of honest HP mining on the attacker's chain). PoP outperformed NC up to 0.4

< tevador > See Fig. 2, PoP performs well. Outperformed only by NC with gamma = 0, which is unrealistic.

< r​ucknium:monero.social > You mean when gamma is zero, Nakamoto Consensus outperforms PoP up to 0.4, right?

< tevador > ^ Correct.

< tevador > But gamma is never zero.

< r​ucknium:monero.social > Well, I have a paper that says selfish mining can be defeated up to selfish mining hashpower = 0.5

< r​ucknium:monero.social > Not sure how reliable this paper is

< r​ucknium:monero.social > Ghoreishi & Meybodi (2024) "New intelligent defense systems to reduce the risks of Selfish Mining and Double-Spending attacks using Learning Automata" https://arxiv.org/abs/2307.00529

< r​ucknium:monero.social > Also doesn't require a hard fork. Only change in miner strategy.

< r​ucknium:monero.social > Let me post my short thoughts:

< r​ucknium:monero.social > Ghoreishi & Meybodi (2024) "New intelligent defense systems to reduce the risks of Selfish Mining and Double-Spending attacks using Learning Automata" https://arxiv.org/abs/2307.00529 seems to suggest an automatic way for honest miners to build on honest blocks when a selfish miner is active. It says that it can completely eliminate the selfish miner's profit advantage when the se<clipped message

< r​ucknium:monero.social > lfish miner has less than 50% of hashpower (this claim makes me skeptical). Part of the procedure uses block time stamps, which we assume are actually spoofable, within some limits. I don't know how well their system works without honest time stamps. They cite a paper from 2014 about non-spoofable block time stamps, but I haven't looked at that paper.

< tevador > I'll read it, but I'm skeptical.

< tevador > I read that 2014 paper.

< r​ucknium:monero.social > The non-spoofable timestamp paper is.. Right [4] One Weird Trick to Stop Selfish Miners: Fresh Bitcoins, A Solution for the Honest Miner. https://eprint.iacr.org/2014/007

< tevador > It's very very impractical.

< tevador > It needs a trusted authority which generates unspoofable timestamps.

< tevador > PoP, on the other hand, only needs to measure the relative arrival of competing blocks, so it has zero requiremnts on clock synchronization or timestamp accuracy.

< r​ucknium:monero.social > I'll read the PoP paper.

< b​awdyanarchist:matrix.org > I'm working on a nodejs simulation to compare various honest/selfish strategies. Can add an arbitrary number of pools, set their strategies and HP, and also attempts to simulate probablistic network latency with tunable input constants.

< tevador > ^ cool, I need to simulate some proposals

< tevador > It would be nice to double check the numbers from the PoP paper.

< b​awdyanarchist:matrix.org > I think I'm about 80% of the way to an alpha release. Hoping to post a first rev before next week.

< r​ucknium:monero.social > BawdyAnarchist: Try to look at the Markov Decision Process (MDP) methodology of "Lay down the common metrics" and Aumayr et al. (2025) "Optimal Reward Allocation via Proportional Splitting" https://arxiv.org/abs/2503.10185

< r​ucknium:monero.social > It seems like MDP can require lots of CPU and RAM, but MRL has that if needed.

< r​ucknium:monero.social > In addition to the papers already mentioned I read (half of) Lewis-Pye & Roughgarden (2024) "Permissionless Consensus" https://arxiv.org/abs/2304.14701

< r​ucknium:monero.social > Mostly these are impossibility results at a high level. I am also getting some terms precisely defined.

< r​ucknium:monero.social > tevador: Is a higher rate of hashpower sampling completely infeasible? I wonder how much CPU time will be spent on a typical block's FCMP verification compared to one RandomX PoW

< r​ucknium:monero.social > Aumayr et al. (2025) "Optimal Reward Allocation via Proportional Splitting" is supposed to get the profitability threshold to 0.38, but it does require more PoW hashes per block.

< r​ucknium:monero.social > BawdyAnarchist: AFAIK, the papers with MDP methodology did not publish their code. Maybe try to email the authors. Maybe there is off-the-shelf code for MDP that can be adopted to the scenarios.

< b​awdyanarchist:matrix.org > I'll see what I can find.

< r​ucknium:monero.social > More comments on this agenda item?

< tevador > My proposal has a block time of 60 s, so it already doubles the PoW cost.

< r​ucknium:monero.social > The second one, "Hard-forking proposal"

< tevador > Yes.

< r​ucknium:monero.social > We can end the meeting here. Thanks everyone.

< tevador > PoW is more sensitive to performance than tx verificaion. For example, SPV-style wallets only verify PoW.

< tevador > So I don't think PoW cost of >1 second per block would be great. That would become 10 seconds on a raspberry pi.

< a​ck-j:matrix.org > I have a concern with the proposed finality layer or POS switch largely surrounding coin distribution. Monero’s emission curve was extremely aggressive and IMHO a blemish on the protocol as it favored the few early adopters too greatly. This combined with early mining software being sabotaged to reduce efficiency leads one to wonder what the distribution of coins actually looks

< a​ck-j:matrix.org > like. There’s nothing we can do about that now but switching to POS knowing this seems insane to me. I currently support tevadors proposals to stay with POW, increase fees and research creative solutions to selfish mining.

< a​ck-j:matrix.org > I support kayabanerve CCS proposal but I’d like these concerns addressed in the book.

< moneromooo > FWIW it is an apparently common misconception. The bad miner only caused an skewed distribution vs hash rate for the first few weeks (assuming the CN people mined it). No extra monero was generated. So AFAIK the high bound on this is very small by now.

< moneromooo > So using it to claim PoS would be insane is ill informed at best. There are other much more persuasive arguments to be made.

< nioc > and 11 years since that happened, plenty of time for them to sell

< nioc > sorry, didn't realize the channel I was in

< a​ck-j:matrix.org > Thanks moo, good to know. I wasn’t around back then and have only heard stories.

< a​ck-j:matrix.org > My first point still stands

< r​ucknium:monero.social > The distribution of the coins being completely unknown is a security worry, IMHO. AFAIK, the only thing that can really be known is that X coins haven't been spent since RingCT was introduced ( jeffro256 produced the numbers on that IIRC) and any of the few public valid reserve proofs that exist. Even public view keys aren't very reliable because they don't show outbound spends.

< r​ucknium:monero.social > A transparent blockchain would give hints about who owns certain piles of coins.

< j​effro256:monero.social > ~9% of funds in pre-RingCT outputs have not yet been spent

< o​frnxmr:monero.social > So like 70% of the supply? :P

< j​effro256:monero.social > The remaining enotes have been spent, but that doesn't necessarily mean that they've changed hands. They could have just been churned into RingCT enotes owned by the same people

< o​frnxmr:monero.social > Do you know how many xmr = 9% of pre-ringct?

< r​ucknium:monero.social > For a point of comparison (BTC and BCH spent outputs 2017 - 2022), see my analysis: https://rucknium.me/posts/pre-fork-btc-bch-spending/

< d​gently:catgirl.cloud > People that wanted increased privacy did indeed send to themselves