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

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

<rucknium> 1. Greetings

Hi

<articmine> Hi

<datahoarder> Hello world.

<boog900> hi

<jeffro256> Howdy

<emsczkp:matrix.org> Hello

<jberman> waves

<vtnerd> Hi

Hi from IRC

<ammortel> Hello

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

Revisiting PQ encryption (#151).

I have reviewing the various scaling proposals

<datahoarder> Implemented Carrot PQ derivation changes and PQ Turnstile test on my libraries, and tested convergence. Stressnet testing, launched stressnet.p2pool.observer (for as long as stressnet monerod survives). Analyzing long term Qubic log artifacts, it's ~800 GiB of compressed event logs.

<rucknium> me: Working on analysing selfish mining with Markov Decision Process (MDP). Getting stressnet more stressed. Updated moneroresearch.info to the latest version of WIKINDX, with some help from @plowsof:matrix.org .

<jeffro256> Me: Added PQ changes to spec, working on knowledge proof integration into wallet2, communicating with potential code auditors for carrot_core, reviewed some seraphis-migration PRs

<jberman> Identified and patched issues causing broken and unreliable sync when the pool exceeds the max weight allowed, currently investigating unexpectedly slow multithreaded FCMP++ verification

<vtnerd> Me: working on boost::beast transition in lwsf for websocket support. Otherwise bug fixes in lws+lwsf infrastructure

<rucknium> 3. Bulletproofs* (more efficient membership and range proofs) (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626).

<rucknium> This CCS proposal has now moved to Funding Required.

<emsczkp:matrix.org> Hi, I’m the proposer of the Bulletproofs* research. Thank you all.

<emsczkp:matrix.org> No additional comments beyond the previous meeting. I just wanted to let the community know that this proposal has been merged. I’m truly happy about this and I look forward to seeing it funded:

<emsczkp:matrix.org> ccs.getmonero.org/proposals/emsczkp-research-folding-gbp.html

<rucknium> More discussion of Bulletproofs*?

jeffro256: where can I find the PQ changes to carrot?

<datahoarder> tevador: gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243

<datahoarder> jeffro256/carrot #6

<jeffro256> jeffro256/carrot #6

<datahoarder> seraphis-migration/monero #250 for C++ code port

<jeffro256> jinx

<jeffro256> Thanks, DataHoarder

Thanks

<rucknium> 4. Spy nodes (monero-project/meta #1124).

<rucknium> I noticed yesterday that the spy nodes on the LionLink Autonomous System Number (ASN) had disappeared from my scanner: moneronet.info

<rucknium> I think that the spy node on DigitalOcean and Hetzner are still there. About a month ago they started "hiding" themselves by not responding with the spy node fingerprint.

<rucknium> But @boog900:monero.social may have more info

<jeffro256> tevador: Changes in #6 may (needs reviewing) allow a PQ switch-style migration which securely 1) opens amounts to existing amount commitments, and 2) opens key images to existing output pubkeys. The signer should be able to make a Schorr signature against their prove-spend key, univariate over the T generator, which is A) hi [... too long, see mrelay.p2pool.observer/e/mfeFltEKTm9ZR1hL ]

<boog900> I think they have just switched to these IP ranges:

<boog900> ```

<boog900> 45.13.179.0/24

<boog900> 82.26.133.0/24[... more lines follow, see mrelay.p2pool.observer/e/yZ2IltEKRlcxaTdF ]

<jeffro256> It destroys spend privacy for the migrated enotes, but should leave the history of the rest of the wallet hidden

<boog900> @boog900: This is more IPs than they had before as well btw

<jeffro256> But they showed up with the spy fingerprint on the new range?

<rucknium> By "just switched" we mean "switched in the last 24 hours and the scanner should display the info when it updates the data for today."

<boog900> @jeffro256: Yep

<boog900> Those ranges are on a different ASN that got registered a few weeks after I found the spy nodes last year

<jeffro256> hmmm, does anyone have any hypothesis why they would have shown up non-fingerprinting on the old range, but fingerprinting on the new range?

<rucknium> IMHO, it's strange that the DigitalOcean & Hetzner spy nodes fixed their spy fingerprint, but these "new" nodes coming online today did not.

<rucknium> Two entities using the same software. One entity fixed their software.

<rucknium> One hypothesis ^

<jeffro256> You think perhaps someone is selling this spy node software commercially?

<rucknium> Maybe monitor the situation for a week and then update the official MRL ban list with the new IP ranges and announce it.

They are as part of BS

<jeffro256> Maybe they had an automatic deploy script, but forgot to update the deploy script

<rucknium> @jeffro256:monero.social: I don't know how plausible it is, but it's a possibility that came to my mind.

BS does not have to work, to make money. The illusion of surveillance is enough

<boog900> The 2 proxies always behaved a bit differently, I suggested that they might just be trying to stop us from finding their other nodes.

<boog900> If they keep the big subnets as obvious proxies, then they might have thought we are less likely to look for difference in behavior and find their other nodes.

<rucknium> By the way, the second chart on moneronet.info, "Estimated number of honest nodes with ban lists enabled", increased the number of nodes with "DNS ban list enabled", but those are probably false positives.

<boog900> They can't really keep them hidden anyway, 2000 nodes going offline then 2000 nodes going online is pretty obvious

<rucknium> Since no nodes on the DNS ban list are on the network anymore, all nodes don't have them in their peer lists anymore. The data in the chart is an inference, not direct measurement, based on whether nodes share banlisted peers when they perform a Levin handshake.

<rucknium> @boog900:monero.social: It's obvious when it's being monitored daily 😇

can someone make a fresh list for the DNS ban list that fits into DNS?

<boog900> Boog900/monero-ban-list #10

<rucknium> selsta: I suggested it here a while ago, but now the ranges should be changed to reflect the new spy ranges: monero-project/meta #1242

<boog900> @boog900: That's the update to my list

<jeffro256> Maybe we invest in a compact binary format for specifying the DNS ban list?

<datahoarder> Binary ranges ought to work :)

<datahoarder> Or require TCP for dns which should already be a thing with the long existing dns checkpoints

<jeffro256> @rucknium: We could drop the old spy node ranges, which should free up a lot of space, but it would be a sneaky trick if they switched back. I guess it's faster to update a DNS record than to re-acquire a block of IPs for hosting.

<rucknium> More honest nodes are using the DNS ban list than the MRL ban list. 55 percent versus 8 percent. Changing the DNS ban list could have a big effect.

ok, once Boog900/monero-ban-list #10 is merged I'll ask mooo to update the DNS list, at least as many as fit

if they switch back we can update it again

<jeffro256> @rucknium: So you're saying add it to the FCMP++ hard fork.......

<datahoarder> There's automatic range merging plus a binary format for this would help sizes. What are the current sizes and intended target?

<rucknium> Anyway, node operators should continue to be encouraged to update to the latest version of monerod, which has the subnet deduplication countermeasure against this type of adversary.

<rucknium> Subnet deduplication PR by @rbrunner7:monero.social , reviewed by @jeffro256:monero.social , @vtnerd:monero.social , and myself: monero-project/monero #9939

<rucknium> More on spy nodes at this time?

<rucknium> 5. New papers: Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. (moneroresearch.info/293) & Venturi, A., Jerico-Yoldi, I., Zola, F., & Orduna, R. (2025). ART: A Graph-based Framework for Investigating Illicit Activity in Monero via Address-Ring-Transaction Structures. (moneroresearch.info/292)

<rucknium> There are two new papers about Monero. I read both of them.

<rucknium> I liked the Qubic paper. I don't agree with every methodological decision, but they did a good job in a short period of time IMHO.

<rucknium> It concludes that Qubic did not achieve a 51% attack and Qubic's block-orphaning strategy was usually less profitable than if they had just mined honestly.

<datahoarder> They used on-chain data plus tasks form Qubic. They lacked a lot of data but still aggregated them consistent to what we also found with larger set of data and internal hashrates

<rucknium> In Section III(A), they seem to say that they assume Qubic's hashpower share is the share of main-chain blocks that they mine. This seems incorrect because it ignores orphaned blocks of honest miners and Qubic and blocks that Qubic never broadcasted to the network.

<rucknium> @datahoarder:monero.social: Do you agree that's what they did?

<rucknium> They still have data on the orphaned blocks that propagated through the network, but they don't use it to compute "effective hashpower"

<rucknium> AFAIK

<datahoarder> They did gather a limited selection of orphan blocks. They describe how they gathered the data, one by querying Monero nodes for blocks and historical orphans, and second by polling one of Qubic RPC that gives the current task

<datahoarder> The current task includes all possible Qubic block templates, so they can find orphans as well that never get published

<jeffro256> > <@rucknium> In Section III(A), they seem to say that they assume Qubic's hashpower share is the share of main-chain blocks that they mine. This seems incorrect because it ignores orphaned blocks of honest miners and Qubic and blocks that Qubic never broadcasted to the network.

<jeffro256> If true, then this is the exact same misunderstanding of PoW that the Qubic founder leveraged to claim a "51%" attack, which they later retracted. As you probably know, you don't just need more than 51% of the blocks, you need 51% of the active hashpower, which is not the same thing.

<datahoarder> But indeed, they didn't do a similar comparison of hashrates when taking into account missing data. That's the flaw I see, they lacked large sets of data for orphans or actual hashrates.

<datahoarder> I did get a different understanding of that section, I'll re-read.

<jeffro256> That is a pretty big mistake for a researcher to make when selfish mining is the main topic of the paper IMO.

<datahoarder> Yeah, that would be a major criticism as well. That's a root base that they use for assumptions later on so if that's flawed, the simulations may be too

<rucknium> > Figure 1 shows Qubic’s mining power share in the Monero network, computed as the ratio of Qubic-attributed blocks to all main-chain blocks over weekly, daily, and hour windows. Since direct telemetry of the pool’s physical hashrate is unavailable, we rely on this ‘effective hashrate’ realized on-chain as the primary metric (α) for our selfish mining models.

<rucknium> ^ That's the passage I'm interpreting

<datahoarder> Their estimates found a lower efficiency than observed in the real world. This may be due to that flawed assumption (our quick checks using more complete data of orphans on both sides showed -20 to -12% efficiency loss)

<datahoarder> @rucknium: Aha! They later touch on it if I remember correctly, that they may have underestimated hashrate

<jeffro256> Eek, yeah if you take their word in that passage Rucknium quoted, then they messed up that calculation.

<rucknium> Or maybe "Qubic-attributed" blocks also means Qubic's orphaned blocks. But then it doesn't make sense to not include the honest miners' orphaned blocks.

<datahoarder> That's why they have a whole section on the observed values not matching simulations. The actual state machine for the simulation is pretty accurate to observed behavior otherwise

<rucknium> I note that they use the original Eyal & Sirer (2013) theoretical selfish mining behavior.

<rucknium> Later papers showed that the selfish mining behavior proposed by Eyal & Sirer (2013) was not optimal. Selfish miners could get a little more revenue by following a more complex decision rule. You find the decision rule by setting up Markov Decision Process (MDP) analysis. In MDP, you define the objective (i.e. maximize self mi [... too long, see mrelay.p2pool.observer/e/2t7zltEKNFhZUl9F ]

<jeffro256> I wonder if Qubic had many of their blocks orphaned in practice. If I had to guess, it's probably not big enough to be important

<rucknium> The Eyal & Sirer (2013) strategy instructs the selfish miner to broadcast its block if its chain is one block ahead of the honest chain. But often Qubic would broadcast when it was two blocks ahead. The two-blocks-ahead strategy is less profitable, but less risky if Qubic's block propagation is slow.

<rucknium> @datahoarder:monero.social: Do you have something to say about @jeffro256:monero.social 's guess?

<datahoarder> @jeffro256: They did, specially around the threshold levels

<datahoarder> I have the dumps I published every week until they stopped selfish but they had quite many in the list that can be proven

<jeffro256> @jeffro256: TBC, by orphaned, I mean Qubic's blocks which made it on the main chain of most other nodes, but then were beat out. I'm not talking about blocks in side chains which Qubic decided to abandon before they were longer than main

<datahoarder> Aha. Most of those are 1-2 deep only

<datahoarder> I am parsing the event logs so I'll have more info on this later

<rucknium> @jeffro256:monero.social: They plot Qubic's orphaned blocks in Fig. 1 on page 3.

<jeffro256> @datahoarder: Are these dump from Qubic mining pool or from your node?

<datahoarder> It's a dump of the equivalent of their inner stratum tasks and solutions - with 600M difficulty granularity

<datahoarder> Events logged to the millisecond across several networks PoV and across Monero nodes

<datahoarder> (And other data, Tari blocks, task server they had, it's ~800 GiB of compressed event logs)

<ravfx:xmr.mx> I noticed the spy nodes stopped to try to connect to my node on the 6 of this month.

<ravfx:xmr.mx> Adding the new IPs everywhere.

<ravfx:xmr.mx> mrelay.p2pool.observer/m/xmr.mx/uXaEUNvsxSEQSiBksYMvRZHy.png (clipboard.png)

<rucknium> What I'm trying to do now is 1) Fit tevador's "Share or Perish" (monero-project/research-lab #146) suggestion into MDP and 2) Develop an alternative MDP objective that maximizes disruption instead of maximizes the adversary's revenue.

<rucknium> Qubic wasn't trying to maximize revenue. They were interested in the propaganda value of disruption, IMHO. So we want to know how the proposed countermeasures would inhibit disruptive mining instead of just selfish mining.

<datahoarder> If you want specific pre-parsed data around Qubic I have an aggregate list, though not posted publicly (it's incomplete, pending parsing of full logs which I can't do live, we are still gathering data). If you want this incomplete list, DM me

<rucknium> I will probably make my Monerotopia Conference talk in February about Qubic and selfish/disruptive mining. Possibly with some collaboration.

<datahoarder> @rucknium: Indeed. There's entities extracting maximum value and entities extracting maximum damage or marketing

<datahoarder> What about the other paper if there isn't more on Qubic?

<rucknium> The other paper is Venturi, A., Jerico-Yoldi, I., Zola, F., & Orduna, R. (2025). ART: A Graph-based Framework for Investigating Illicit Activity in Monero via Address-Ring-Transaction Structures. (moneroresearch.info/292)

<rucknium> I didn't really like this paper. It fit a machine learning model on 19 transactions from 2017 and tried to validate detection of behavioral traits in txs.

<rucknium> In 2017, Monero didn't even require a fixed ring size, so they could use ring size as a predictor.

<rucknium> IMHO, training ML on RingCT Monero txs is a dead end because you cannot get a valid training set.

There was a minimum ring size

<rucknium> Even if you have info from centralized exchanges, those txs are obviously a biased sample that would not reflect general user behavior outside of interaction with a centralized exchange.

<rucknium> Yes, minimum ring size in 2017, but AFAIK, users could select higher than the minimum if desired.

Yes they could. I used a much higher ring size in 2018 to extract the Monero Original safely.

<jeffro256> A minimum of two ring members causes decoy elimination cascading attacks. Was that the limit enforced in 2017, or was that already known by then and the minimum greater than 2?

The minimu as I recall was 5

<rucknium> These two papers brings the count to 10 of Monero papers written by non-MRL affiliated researchers in 2025. Nice to have the auxiliary platoon of external researchers 😎

<rucknium> The other 8 are

<rucknium> Thakore, V., & Vijayakumaran, S. (2025). MProve-Nova: A Privacy-Preserving Proof of Reserves Protocol for Monero. Proceedings on Privacy Enhancing Technologies, 2025(2), 582–606. (moneroresearch.info/266)

<rucknium> Yang, X., Xu, L., & Zhu, L. (2025). De-anonymizing Monero: A Maximum Weighted Matching-Based Approach. IEEE Transactions on Information Forensics and Security. (moneroresearch.info/260)

I used like 255 to ensure common rinngs on both chains greater than 5 for the Monero Original extration

<rucknium> Lee, J., Choi, G., Han, J., & Park, J. (2025). Advanced Monero wallet forensics: Demystifying off-chain artifacts to trace privacy-preserving cryptocurrency transactions. Forensic Science International: Digital Investigation, 54, 301988. (moneroresearch.info/290)

<jeffro256> According to the README, there was already of minimum of 3 by 2016, which got increased to 5 in 2017.

<rucknium> Kopyciok, Y., Victor, F., & Schmid, S. (2025). Moneros Decentralized P2P Exchanges: Functionality, Adoption, and Privacy Risks. (moneroresearch.info/270)

<rucknium> Kopyciok, Y., Schmid, S., & Victor, F. (2025). Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. (moneroresearch.info/280)

<rucknium> Shi, R., Peng, Z., Lan, L., Ge, Y., Liu, P., & Wang, Q., et al. 2025, February 24–28, Eclipse Attacks on Monero’s Peer-to-Peer Network. Unpublished paper presented at Network and Distributed System Security (NDSS) Symposium 2025. (moneroresearch.info/248)

25*

<rucknium> Gao, Y., Zhang, Y., Piškorec, M., & Tessone, C. J. (2025). Monero Peer-to-peer Network Topology Analysis. (moneroresearch.info/278)

<rucknium> Gao, Y., Piškorec, M., Zhang, Y., Vallarano, N., & Tessone, C. J. (2025). Charting the Uncharted: The Landscape of Monero Peer-to-Peer Network. (moneroresearch.info/267)

<rucknium> More discussion on these papers?

<ravfx:xmr.mx> They also moved the tor/i2p spy nodes too

<jeffro256> Does the BulletCT paper count? ;)

<rucknium> @ravfx:xmr.mx: These were the spy nodes spying on the i2p and tor networks in general, right?

<rucknium> Then, 11 😀 Wang, N., Wang, Q., Liu, D., Esgin, M. F., & Abuadbba, A. (2025). BulletCT: Towards More Scalable Ring Confidential Transactions With Transparent Setup. moneroresearch.info/285

<rucknium> 6. Transaction volume scaling parameters after FCMP hard fork (github.com/ArticMine/Monero-Documen…/master/MoneroScaling2025-12-01.pdf). Revisit FCMP++ transaction weight function (seraphis-migration/monero #44).

I have spent some time reviewing the various proposals. In particular @boog900

the laater would make a good choice for a mature chain over 1000 transactions per second. If one tries to modify it then the maximum annual growth rate grows over 2.5%.

<ravfx:xmr.mx> @rucknium: yeah, but they have a big collection of them at LIONLINK

<ravfx:xmr.mx> had*

This issue is that we need the ability of ML to change in order to accommodate the variability in transaction rates that has been identified in the past both in Monero and other chains including over 100x in Bitcoin and Litecoin

<boog900> I think my proposal is too aggressive if anything, but it is an improvement over what we have currently.

Then we hate the issue of too high an annual growth rate.

<rucknium> @boog900:monero.social: Can you post the link?

My take is that my proposal with the Nielsen's Law caop is the way to go

<boog900> seraphis-migration/monero #44#issuecomment-3617687600

We are capping the annula growth rate to below 1.389 x

There is also no need for fixed caps

and we have a predictable max block weight with time.

Like ~7 years to reach 100 MB for example

<boog900> 1024x max growth in a year is completely unnecessary

<boog900> 47x is too but it is much better

There is no max growth of 1000x in a year

<sgp_> Personally I'd consider a 100x capacity change in the short term to be unimportant. Without it, worst case fees go up in the short term. I don't consider this a failure. I don't see short term higher fees as a devastating failure of the goal of p2p cash

<boog900> ArticMine: 16x in short term 2x every ltm adjustment

I ran a bitcoin node in 2017 - 2018. Over 2 TB of data in a month

Bitcoin stly fee markes can be easily spammed

that was over a 50 Mbits DSL line

@boog900 You have the cap at 1.390 ..

That is the key change

<boog900> @articmine:monero.social: has said mine is good for a mature network, I believe my proposal also allows us to reach a mature level (according to artic) in a reasonable amount of time

<boog900> I SAID MAX GROWTH.

I know max growth

is way faster

but are people prepard to accept this with no caop?

Or conntroversial fied limits?

<boog900> Max growth in a single year makes the sanity cap meaningless as eventually it grows enough to not restrict a years worth of growth

If that is the case then the market is taking care of things

This is not a case to argue against the underlaying scaling

<boog900> why do we need to plan for no growth for 14 years then gigabyte blocks in 1 year?

And I mean ovr a decade of more

<boog900> ArticMine: it is as otherwise we are just relying on the sanity cap to keep us secure

We are not planning for no growth for 17 years

<boog900> another bandaid solution, just like the ones that got monerod in the state it is

we can have 1000 tpd in 14 years

tps

<boog900> we do not need 1024x in a single year

This is far from no growth

<jberman> I think @boog900:monero.social raises good arguments against exponential cap, in favor of more reasonable allowed max growth params

<boog900> we can have a gradual increase if you believe we wont have all the growth in 1 year

<sgp_> Even if we allow, say, 2x growth per year max, that will still catch up to the sanity cap over time

We have an under 1.4x per cap How many time do I have to repeat this?

<boog900> brooooo

<jeffro256> Why not both? I thought that the exponential cap was an additional sanity check on the long term medium, which itself is limited by the historical block sizes.

That is what it is

<jeffro256> It's not like the block size is allowed to immediately jump up to sanity cap

<boog900> my proposal has that as optional @jeffro256:monero.social, I don't think it is needed with it though

Both are integrated into my proposal

<boog900> the underlying scaling is slow enough without it IMO

<jeffro256> So why does it hurt, in your eyes? Just extra unnecessary complexity?

2.5x is greater compunded than 1.4x

<boog900> @jeffro256: yes

<boog900> ArticMine: 2.5x is literally maxing out scaling

<boog900> 1.4x is always increasing, no matter what

It is actually too high over time

<boog900> I agree

<boog900> ^ > <@boog900> I think my proposal is too aggressive if anything, but it is an improvement over what we have currently.

<jeffro256> TBF, if implementeting the sanity cap as a function of the block height, it could be extremely helpful as a quick stateless pre-check

Then what is the problem with under 1.4x?

<boog900> we can lower it?

<boog900> ArticMine: BECAUSE IT INCREASES NO MATTER WHAT

We have a cap ML can stay at 2x and allow or the necessary felxibilty

<boog900> you have a shit scaling algo with a sanity ontop that makes it kinda ok for some years/.

It is a sanity cap

<boog900> why not just have a good scaling algo

It is not possible to do both

<boog900> it really is

You eithe lock up the short term or allow massive grwoth in the long term

<boog900> why do we need 1024x max growth in a year

16*32 =512 please

<boog900> that is under a year 1024x is a little over a year

<boog900> I said this in my comment

With a 1.4 cap Please

1.4x

<boog900> oh my days

<boog900> can we just vote?

<gingeropolous> i think all the proposals would need to be up somewhere with things clearly laid out before a vote

<kayabanerve:matrix.org> Should we literally just have a vote on 1.4x YoY or 1.4x prior year?

Yes 2.5x per year vs under 1.4x per year

<gingeropolous> everythings buried in comments and threads blah blah blah

<kayabanerve:matrix.org> Should we first agree to defer to a vote after consensus this isn't going anywhere?

<rucknium> What would the voting process be and what would it accomplish?

<boog900> I really don't like how you are framing this ArticMine

<boog900> really disingenuous

the maximum growth

<gingeropolous> i think our terminology is also mixed

What is wrong with thatSo we vote between my proposal and @boog900s?

<articmine> @rucknium: I would like to know myself?

<jberman> I generally agree with ginger, it's a bit hard to follow and I'm decently well versed in the scaling algo params. Where did 2.5x come from?

<jeffro256> Even so, 512x is too much. Assuming that only 10000 people use Monero now, a 512x growth rate means that every man, woman, and child on the planet would be migrated Monero in ~2.2 years. > <ArticMine> 16*32 =512 please

<sgp_> This conversation is so silly. Why can't we do something like 1.4x sanity cap which is ever increasing, but instead of allowing >100x growth in any single year based on demand, why not limit that to 2x or so max per any single year. Not 512x-ish

I have my ptoposal on github for everyone to review

<boog900> @jberman: a ltm multiplier of 1.2 with 5 adjustments

This is getting pointless

<sgp_> Which goes to my point that the "feature" of >100x growth per year to accommodate demand should be an explicit non-goal > <ArticMine> This issue is that we need the ability of ML to change in order to accommodate the variability in transaction rates that has been identified in the past both in Monero and other chains including over 100x in Bitcoin and Litecoin

<jbabb:cypherstack.com> the point is to patch the big bang block bug/attack

<articmine> An under 1.4x per year maximum cap

<articmine> Even this is not enough

<boog900> I don't see everyone coming to consensus on a single algo, a vote is just to decide the scaling algo by majority.

<articmine> There are 2 Lagos on the table

<articmine> algos

<boog900> @sgp_: isn't this pretty much my proposal?

<sgp_> Yeah I think the thinking largely aligns

<jeffro256> I agree that 1.4x per year probably isn't enough if we actually expect the real long term median block size to hit this sanity cap. 1.4x growth per year means that it would take 4 decades to reach global adoption assuming 10,000 users now. > <@articmine> An under 1.4x per year maximum cap

<boog900> @articmine: I really hate how you are just closing your ears to all arguments

<gingeropolous> right. Lets perhaps start with terms. I think we generally agree that theres a short term median, and blocks can grow 2x the median. Then there's a long term median, and blocks currently can grow to 50x the LTM. What is that 50x factor called? These are the dynamic caps. Then we have possibly 2 additional caps coming into play [... too long, see mrelay.p2pool.observer/e/kNnHmNEKcHFoRTY5 ]

<articmine> @boog900: I am t

<boog900> like on the one hand you say mine is more aggressive on the other you say we want a more restrictive algo?

<sgp_> arguing "2.5x vs 1.4" is not accurate. One increases only with demand, the other increases regardless of it. They can be combined together

<sgp_> which is what boog suggested

<gingeropolous> lets seperate dynamic caps and non-dynamic caps. dynamic here is referring to chain usage. not just blockheight

<sgp_> growing 2.5x in any given year is plenty generous imo

<boog900> @gingeropolous: the short term multipler is what I have been calling that 50x number, basically it means the median can rise 50x in the short term (before an adjustment of the long term median). This means we can have blocks 100x the size of the current long term median before any adjustments as blocks can be 2x the median.

<articmine> @sgp_: Yes they can. This allows the harm done by the BS companies to Monero to be baked into the consensus protocol

<articmine> So if the suppression continues we can't recover

<articmine> We come back to the conflict of interest

<gingeropolous> is the main contention over the non-dynamic caps?

<boog900> oh my days

<sgp_> the fundamental thinking difference is that Artic considers high fees in the short term (if demand grows faster than block space increases) to cause the permanent failure of Monero's p2p usage. But it's simply not possible to always guarantee low fees even with aggressive scaling space afforded

<articmine> The main contention is allowing catch up after suppression

<articmine> So if Monero is suppressed for say a decade we can't recover

<sgp_> Any annual growth over 1.4 is recovering towards the sanity cap

<boog900> if we needed 10000x, your 1000x would also not allow us to recover.

<articmine> The sanity cap grows during the suppression period

<boog900> what makes 1000x special?

<articmine> It is not

<jeffro256> IMO, if implemented non-dynamic caps (e.g. the 1.4x sanity limit) should be very liberal (i.e. non-limiting) with today's conditions. They should only kick in when we predict that the hardware/bandwidth requirements would cause severe decentralization issues. The dynamic caps should be the real bottlenecks under current and [... too long, see mrelay.p2pool.observer/e/2LzimNEKbTFZaDl5 ]

<boog900> @jeffro256:monero.social: do you think my values are good, ignoring the sanity cap for now?

<articmine> The sanity cap is not a band aid

<jeffro256> In my opinion, hoping that state/BS-organized suppression would heal itself if we allow more transactions on the chain is wishful thinking. > <@articmine> So if Monero is suppressed for say a decade we can't recover

<gingeropolous> ok, so sanity cap = 1.4x thing, the neilson law thing. The hard cap is the 90MB proposed thing.

<articmine> @jeffro256: No the state suppression is overturned by the courts

<articmine> Then Monero needs to recover

<articmine> That is the issue

<boog900> FWIW you can calculate a maximum block size without an explicit sanity limit

<boog900> so you can get the max size of a block at a specific height

<gingeropolous> so if the sanity cap starts at 10MB, that gives us 660k tx/day for year 1, which is about where bitcoin stands, today

<jeffro256> @jeffro256: You can't heal price suppression except by increasing trust in your product / mission. As long as transactions are not prohibitively expensive for day-to-day use (which I don't think they would be with a 2x dynamic short-term limit), then I think allowing spam would harm trust more than the friction due to said on-chain fees.

<boog900> @boog900: the closer you starting block the lower that number will be too.

<jeffro256> Yours has max dynamic growth of 2.5x? > <@boog900> @jeffro256:monero.social: do you think my values are good, ignoring the sanity cap for now?

<jeffro256> Ignoring sanity limit ofc

<articmine> @gingeropolous: Yes but if you drastically reduce the underlying scaling , then we cannot recover from state suppression

<boog900> @jeffro256: so in the short term it allows 16x then after that every ltm adjustment is 1.2x. So in the first year 40 to 47x every year after that 2.5x

<articmine> Bitcoin today is a disaster as peer to peer cash

<jbabb:cypherstack.com> @jeffro256: increasing trust and/or usability. enabling swaps would be a workaround

<gingeropolous> the dynamic stuff? thats very liberal no matter how we cut it. the multiplier being 50x or 16x, it'll hit the sanity cap quickly

<articmine> It is heavily price

<articmine> Priced

<boog900> @boog900: Artic is 512x to 1024x in the first year then 32 to 64x in the years after.

<articmine> It has NOT happened in 11 years

<articmine> With more aggressive scaling and NO sanity cap

<articmine> We are not ZCash which was spammed to 300x in blocksize

<jberman> @boog900:monero.social: what if you brought the params down further such that yearly growth is capped at 1.4x via dynamic scaling?

<articmine> @jberman: It will not work at a

<articmine> AKL

<gingeropolous> well that'd be even worse for the suppression hypothesis @jberman:monero.social

<boog900> @jberman: I would prefer it to be 2x, I think it is safe enough. What I don't like is the 16x in the short term.

<boog900> I would prefer that to be lower, if that could get consensus.

<elongated:matrix.org> @articmine: Not yet

<jeffro256> How is 2.5x max growth acquired from a 1.2x LTM increase, assuming STM is maxed out? Maybe I'll just have to do the math lol > <@boog900> so in the short term it allows 16x then after that every ltm adjustment is 1.2x. So in the first year 40 to 47x every year after that 2.5x

<boog900> @jeffro256: 1.2 ^ 5

<articmine> 1.2^5

<jeffro256> @jberman: You didn't ask me lol, but that's much too conservative for my taste

<jeffro256> @articmine: Isn't LTM 100K blocks, which would mean 1.2 ^ ~2.6?

<kayabanerve:matrix.org> I think the abundance hypothesis is put forth by agitators in an attempt to split the community and degrade the network's performance, meaning we should strike a reasonable balance (what's being labelled the 'suppression hypothesis', despite still allowing for 40% growth of use YoY) in order to ensure network quality, stabilit [... too long, see mrelay.p2pool.observer/e/mLWOmdEKRDRZRURf ]

It's 100K blocks, so it can grow every 50K blocks.

<boog900> @boog900: if we have an adjusted ltm at 10 MB, so adoption brings us to 10 MB for a few years, then 16x means we could have 160 MB before a ltm adjustment, 1024x means 10 GB.

<articmine> @kayabanerve:matrix.org: Really

<boog900> wait no I said that wrong my bad

<gingeropolous> so the hypothetical scenario is that The Law somehow abolishes blockchain surveillance companies, and then within a matter of days there are millions of txs per day on the monero blockchain (?)

<boog900> both proposals have 16x in the short term.

<rucknium> @articmine:monero.social: /s means that @kayabanerve:matrix.org meant the comment sarcastically.

<kayabanerve:matrix.org> I know that isn't actually a helpful comment, but I feel obliged to point out how absurd some of this discussion had been and still is

<kayabanerve:matrix.org> No one suggesting scaling usage 40% per year should be considered suppressive.

<articmine> Yours has very stiff pricing with no scaling growth

People on matrix: please try to keep your messages <500 characters. It's very hard to read the conversation on IRC otherwise.

<ofrnxmr> @kayabanerve:matrix.org: 40% from 300kb-650kb, i would definitely consider suppressive

<articmine> @kayabanerve:matrix.org: I agree

<kayabanerve:matrix.org> Sorry, I meant to send my messages in immediate succession but my internet had a hiccup

<kayabanerve:matrix.org> My following messages obviously elaborate on the "/s" originally included but lacking comprehension

<jeffro256> I think 40% can be too conservative at today's size, but on the other hand, at a VISA level size, it would be absurd to think that we could expand 40% in one year.

<kayabanerve:matrix.org> I meant to point out the absurdity, not leave it hanging for three minutes 😅

<kayabanerve:matrix.org> Doesn't that simply suggest we need a larger base, as these proposals already include?

<kayabanerve:matrix.org> My primary comment was solely 40% of the year's usage, even if not 40% of the prior year's +40%, shouldn't be considered suppressive

<boog900> what do we think the best path to consensus is?

<sgp_> @jeffro256: As long as we don't start with Visa's allowance, Monero will always trail it in adjusted performance terms (assuming tech keeps getting better)

<rucknium> @jeffro256:monero.social: Isn't this the tyranny of exponential growth and a reason to not have exponential growth indefinitely?

<kayabanerve:matrix.org> I'd advocate complete proposals, potentially independent or not, and voting

<rucknium> I will again point to the logistic growth curve.

<kayabanerve:matrix.org> My proposal was for an independent knob. I don't see why 1.4x usage can't be an independent knob.

<jeffro256> Artic, what do you think of Boog900's proposal as-is?

<rucknium> Which is classically the theoretical curve of adoption of a new technology.

<gingeropolous> and the proposals should have graphs. graphs!

<kayabanerve:matrix.org> I agree independent proposals mashed together can be suboptimal, but we need at least clear, complete proposals, and the issue with proposals as large as AM's is the specific nitpicking

<rucknium> Ah, but Arrow's Paradox ;)

<kayabanerve:matrix.org> Hence my proposal for independently voting on static capacity and a sanity cap

<ofrnxmr> Anyway, my vote is

<ofrnxmr> * 40% YoY (regardless of volume). Baseline of 10mb

<ofrnxmr> * something like 50x max growth (based on volume) in 1yr (not 1000x, not 1.5x)

<ofrnxmr> * 90mb default max miner template (not hard cap)

16x STM, 1.2x LTM and ZM = 625 000 + sanity cap starting at 10 MB seems reasonable to me.

<kayabanerve:matrix.org> @rucknium:monero.social: we can also acknowledge impossibility and give up, so true

<boog900> the voting has started it seems :p

<rucknium> I mean, Arrow's Impossibility Theorem.

<jeffro256> @rucknium: I do like a good logistical curve. The one issue I see with this is that we have to determine an absolute top of the curve which encodes when "complete" adoption is hit.

<rucknium> @jeffro256:monero.social: I agree that is a limitation. But you could relax the ceiling with linear growth at that point or something.

The 40% YoY growth could be limited to ~20 years, which is enough to reach VISA-level throughput.

<kayabanerve:matrix.org> I would like to end the McCarthyism though

<gingeropolous> 2x STM, 50x LTM and ZM = 300 000 . These are the current params, right?

<ofrnxmr> tevador: Depends on size of future txs. So i dont think its really necessary to cap atm.

<boog900> @gingeropolous: 50 STM, 1.7 LTM

<gingeropolous> ok. got it

Well, if PQ transactions are 1 MB, then yes, we have a problem. But that's for another time.

<kayabanerve:matrix.org> The network isn't ossified and we can adjust the formulas for PQ TXs with the PQ fork

<jberman> tevador: I'm ok with this as well

<boog900> tevador: is this 16x as is artic's 16x or my 16x (so 8)?

<articmine> @jeffro256: That was my point regarding @boog900 proposal

<articmine> One can lower the limit over say 1000 TPS

<articmine> But now we need maximum flexibility and the possibility of growth below the cap

<articmine> So we should keep the 2x on ML at least until we reach 1000 TPS

<jeffro256> @rucknium:monero.social: That's not a bad idea. Will we be ossified by the point humanity achieves intergalatic space travel? Will cryptocurrencies be needed at that point? Probably by the time that humanity leaves Earth, if such a time comes, hopefully there is enough rough consensus on Earth to fork to support non-trivial l [... too long, see mrelay.p2pool.observer/e/ib3QmdEKV3VOSzk3 ]

<boog900> @boog900: artic changed the scaling algorithm so a 8x stm before which allowed 16x max size blocks in the short term now it is the same so a 16x stm allows 16x max size

<boog900> it is basically a more aggressive algorithm for the same max size.

boog900: I'm talking about the maximum legal block size limit, so I think it's yours.

<boog900> nice 👍️

<articmine> A larger base opens the door to spam > <@kayabanerve:matrix.org> Doesn't that simply suggest we need a larger base, as these proposals already include?

625 000 * 16 = 10 MB sanity cap

<gingeropolous> or we make the short term more flexible by allowing 4x the median 100 blocks instead of 2x

<gingeropolous> and that would keep fees lower during these expansions

<ofrnxmr> @gingeropolous: i think its already too reactive at 100 blocks, but i digress

I think doubling every 100 minutes is plenty fast.

<ofrnxmr> +1

<gingeropolous> aye

<rucknium> I also assume that Monero transactions are directly related to the real economy (en.wikipedia.org/wiki/Real_economy) instead of the financial economy. Therefore, the number of txs per person is limited since people have limited time in a day and limited demand for txs. And the number of people on the planet is leveling off.

<jberman> Also fwiw, I generally agree a fixed cap probably is not required at conensus with sane params in the scaling algo and especially not with the 1.4x sanity cap starting at 10mb > <@ofrnxmr> Anyway, my vote is

<kayabanerve:matrix.org> @jeffro256:monero.social: intergalactic p2p communication >:(

<jberman> Once blocks start creeping up, if the node isn't re-architected in time / prepared, then there should be ample time to put a cap in place if the network would die without .. especially with the sanity cap

<articmine> A tight base with 2x on ML is better

<gingeropolous> well i don't have these abbreviations memorized so im out

<rucknium> You could put a lower cap on the block templates that the monerod RPC generates. That doesn't stop a malicious miner nor miners who change the code and re-compile, but it could stop miners from mindlessly leading each other off a cliff like lemmings.

<rucknium> p2pool has its own method, but that can be managed too.

Yes, a limit can be soft forked later if needed.

<ofrnxmr> @rucknium: imo this is more sane than adding a 90mb hard cap

<ofrnxmr> Just add a 90mb default max template

<ofrnxmr> Like btc op codes, can just change the param later (even using a runtime flag) instead of having to fork to allow the larger blocks

The problem is that AFAIK you need just 1 block over 100 MB to kill the network.

<rucknium> IMHO, many miners would lead each other off a cliff irrationally. It happened to PirateChain. And Monero mining pools used to have deplayed block template updating that cost them fee revenue.

<ofrnxmr> tevador: no, the 1 block wouldnt transmit

<ofrnxmr> The miner would get forked off

<boog900> not if it is fluffy

<rucknium> PirateChain miners causing netsplits because of excessive block verification time: web.archive.org/web/20230803171107/…ains_045_spam_attack_2_months_later

<articmine> And safer

<jeffro256> Or it would only partially transmit, depending on network conditions. This would give miners making too-big blocks a severe disadvantage.

<ofrnxmr> @boog900: in which case the network would survive, but bootstrapping wouldnt

<boog900> @ofrnxmr: the network would split

<boog900> or well could split

<boog900> 2 or more different chains which allows double spending on each one.

ofrnxmr: That might not be true if we sync headers first at some point.

<jberman> @ofrnxmr: I'd call this more like "chicken running around with its head cut off"

<ofrnxmr> Anyway, id avoid hard cap and do template max defaults. Gives us 6yrs to fix the situation properly and doesnt require a hf to deploy

<rucknium> We can hit the next agenda item since it's being discussed already

<rucknium> 7. Proposal: Limit blocks to 32 MB, regardless of context (monero-project/research-lab #154).

<kayabanerve:matrix.org> It can be broadcast bit not synced or scanned, or so

<ofrnxmr> Repeating "Just add a 90mb default max template"

<kayabanerve:matrix.org> Unless the sync process also separates TXs out

<jeffro256> NACK to 32MB non-dynamic limit, sorry Kayaba

<ofrnxmr> @kayabanerve:matrix.org: @ tip, it does

<kayabanerve:matrix.org> @rucknium:monero.social: that's now 90 MB per prior meeting,

<kayabanerve:matrix.org> @jeffro256:monero.social: ^

<kayabanerve:matrix.org> @ofrnxmr:monero.social: it needs to be at all times, not conditionally, hence the proposal on a 90 MB static limit until syncing and scanning are fixed

<rucknium> By the way, the new network scan data is in. 1,850 "new" spy nodes on the SCNL-0001-1 ASN: moneronet.info

<kayabanerve:matrix.org> I'll withdraw my proposal if someone fixes both before the next HF. Else, 90 MB static limit with the HF is my advocacy.

<boog900> so close to half our network!

<boog900> its weird all those good nodes in their spy block

<ofrnxmr> @kayabanerve:matrix.org: A hard limit will require a hf to remove. A soft limit allows miners to produce whatever they want, and just a point release to change

<jeffro256> NACK to 90MB non-dynamic limit ;)

<jeffro256> @boog900: Double crossers?

<kayabanerve:matrix.org> I think @jeffro256:monero.social: is compromised by chain analysis and wants to destabilize the network, proposal to remove from all Monero activity /s /s /s

<kayabanerve:matrix.org> :p

<boog900> very funny SCNL-0001-1 was registered weeks after I found the spies last year

<kayabanerve:matrix.org> If this isn't fixed by the HF, I don't see why we wouldn't plug the hole in this way with the next HF. I don't believe the protocol has ossified and I don't like this guillotine over our heads, with a fraying rope, even if the rope still has a year now (and will have six years under upcoming proposals)

<boog900> have to register a new one now!

<ammortel> It would be more elegant not to limit anything but to improve what causes the limitation's need. If that is possible

<rucknium> I don't know how the 90MB limit is different from the limit that mainnet nodes running 2023 software would have if there were 20 consecutive blocks of 1.5MB or larger. Fixing that limit wasn't the same as a hard fork, either: spackle-xmr/monero #12

<kayabanerve:matrix.org> We should have any solution ASAP IMO, and this one which _should_ never trigger and will be ready, when the necessary reworks won't be, is best IMO

<kayabanerve:matrix.org> @rucknium:monero.social: The issue literally is some blocks can be sent that can't be naturally synced or indexed or scanned by wallets

<rucknium> This is literally true for the current mainnet circumstances I described.

<boog900> tbf it is the same, its just the fix is harder

<kayabanerve:matrix.org> Instead of having these weird edge cases needing ad-hoc patches which are fine because they simply haven't been triggered yet, my proposal is to solidify safe, deterministic rules to ensure the network functions

<jberman> the node breaks first fwiw, wallets download pruned tx data

<kayabanerve:matrix.org> This also is reachable by an adversary today

<rucknium> Those of us in the stressnet trenches last year know :)

<kayabanerve:matrix.org> @jberman:monero.social: Yes and no. Yes, the pruned TXs will take longer to break, but the RPC still has some methods break at that point.

<kayabanerve:matrix.org> Which will screw with indexers and maybe _some_ wallets.

<ofrnxmr> @rucknium: Fwiw, fcmp seems to handle 50mb batches ok

<jberman> @kayabanerve:matrix.org: ok fair enough, the RPC wallet2 uses to sync should be ok fwiw*

<datahoarder> @ofrnxmr: I added proper calculation of byte size vs weight to stressnet block explorer, to see how that differs

<rucknium> @datahoarder:monero.social: I'm getting Bad Gateway now. But thanks for that

<kayabanerve:matrix.org> Either we hit this and the network breaks in weird and sporadic ways, or we hit this and have artificially lower capacity than the network would have _if it functioned properly at such scale_.

<ofrnxmr> @datahoarder: I think sync_info shows byte size

<datahoarder> @rucknium: Just fixed it, node crashed, OOM

<datahoarder> stressnet.p2pool.observer/block/f66…bddb0f93e4f7d6575221387051456356021

<kayabanerve:matrix.org> We can remove the limit with the functioning. tevador's table explained the theory of outcomes on this.

<jberman> is that an OOM running the latest v1.5 pre-release as well?

<datahoarder> @ofrnxmr: you can check this on any historical block (or tx)

<kayabanerve:matrix.org> So @jeffro256:monero.social: , want to elaborate why you don't support a limit just under the existing hard limits?

<datahoarder> @jberman: yep, with the patches. but I was using computer for other things now

<kayabanerve:matrix.org> I can't force you to agree but yes, I'd like to maintain consensus on this

<kayabanerve:matrix.org> We did have loose consensus last meeting

<datahoarder> We can talk about oom later keep going. Just wanted to bring up the size vs weight

Fixing the 100MB limit is technically a hard fork in any case.

<kayabanerve:matrix.org> Eh. Nodes who were online at the threshold may continue indefinitely due to split syncing if blocks and TXs.

<kayabanerve:matrix.org> It's this horrific Schrödinger's cat of liveness, functioning, and hard forks

<jeffro256> I would be fine with a 32MB limit on the serialized cryptonote::block itself, not the block weight. The current serialized size of cryptonote::block isn't currently limited. After the FCMP++ HF, it will be limited to one million transactions, plus a miner transaction with 10K outputs, but I think that we could do better th [... too long, see mrelay.p2pool.observer/e/m8O4mtEKX1ZRMy1x ]

<kayabanerve:matrix.org> It works enough it isn't dead, but it is broken and it's no longer verifiable as it can't be synced

Nodes who don't upgrade may fork off, that' the definition of a hard fork.

<kayabanerve:matrix.org> Isn't that advocating 100 GB as the hard limit @jeffro256:monero.social: ?

<jberman> I agree with tevador. It would be a point release in name only. if older nodes cannot sync, it's a fork from those nodes

<kayabanerve:matrix.org> 1000x when the network breaks?

<rucknium> tevador: Was this fix a hard fork? spackle-xmr/monero #12

<kayabanerve:matrix.org> tevador Fair

<kayabanerve:matrix.org> @rucknium:monero.social: Probably, see how Bitcoin increased the amount of database references allowed when verifying a block and how that was a HF.

<jeffro256> Yes, I believe so. The limit would be a small, but useful protection against DoS attacks for block deserialization which we don't currently have. > <@kayabanerve:matrix.org> Isn't that advocating 100 GB as the hard limit @jeffro256:monero.social: ?

Yes, increasing the limits seems like a HF to me if non upgraded nodes won't sync the larger blocks.

<kayabanerve:matrix.org> I'm not trying to say things are bad and should be bad. I'm saying things are bad and we should acknowledge that instead of having a loaded gun sitting around

<rucknium> Then add one to the Monero hard fork count, I suppose.

<kayabanerve:matrix.org> We should get rid of the gun entirely with a proper sync protocol but should at least remove the round

<datahoarder> @rucknium: reddit.com/r/Monero/comments/1mvmg4…of_all_of_moneros_consensus_changes

<kayabanerve:matrix.org> Didn't @jeffro256 HF the merkle tree three months ago?

Under my sanity cap, 100 GB blocks are not possible until about 2052.

<kayabanerve:matrix.org> Or was that not merged yet?

<jberman> Going off reddit, it seems that many in the community would prefer the guillotine over Monero that it should break if the sync protocol isn't updated, although it's been portrayed to the community as just a "fix" by @articmine:monero.social

<kayabanerve:matrix.org> There's this weird off by one for 250 GB blocks jeffro256 submitted a patch for a few months ago, which would've be/would technically cause a net split

<kayabanerve:matrix.org> The amount of broken things sitting around is prone to a bunch of net splits and any fixes, even reasonable, can be argued hard forks.

<kayabanerve:matrix.org> That's why I'm proposing canonicalizing current limits. To remove this bullshit.

I think it's reasonable to add the 90MB hard cap for now in a way that we can't forget to remove it when a future HF fixes the underlying problem.

<kayabanerve:matrix.org> Yes, the limit is bad, but right now it's hodge podged and broken. At least I'll just be bad but functional with an explicit setting.

<datahoarder> tevador: I suggested it explicitly only being enabled for a specific hardfork, not further ones

<kayabanerve:matrix.org> I suggested it be enabled until removed in favor of fixed p2p, RPC, wallet sync protocols.

<kayabanerve:matrix.org> They both declare an intended term. One forces the issue and one acknowledges the issue.

datahoarder: What if we need an emergency HF in the future before the issue is fixed?

<rucknium> We are about to hit three hours of meeting. Stressnet is next.

<articmine> Then we are back to the Bitcoin scenario. Put in a sunset block for the cap

<datahoarder> tevador: then you explicitly need to update that parameter. which documents this being pushed

<rucknium> Please start to wrap up the discussion for now.

<datahoarder> it's more of fuzzy feelings, as next hardfork could just push it

<kayabanerve:matrix.org> Yes, I'd like to not overload future HFs when this is obviously a priority

articmine: The sunset block is meaningless if nodes start crashing at the limit.

<kayabanerve:matrix.org> Stressing about it doesn't actually solve it

<kayabanerve:matrix.org> If you want to stress, you can solve it

<articmine> My point is how long is it going to take to fix this

<articmine> How many years?

<kayabanerve:matrix.org> As is 90 MB + 10 MB a year or so. Unless the issue is fixed, allowing it to be removed, it isn't meaningful

<kayabanerve:matrix.org> @articmine:monero.social: PRs welcome

<rucknium> Does someone want to take the initiative to recruit more senior-level developers or is the project going to continue to overwork its mainstays?

<kayabanerve:matrix.org> It's obviously important. I'd estimate within two years, as someone who observes p2p/wallet development but doesn't participate. If you want to ensure it's done, you have to ensure that yourself. No discussion nor stress will magically translate to actual work about it.

If anyone has a problem with the 90MB limit, please post your arguments in #154.

<kayabanerve:matrix.org> (Not to say we can't discuss coordination of work, ofc, cc @rucknium:monero.social: who brought up bringing in more devs)

<boog900> tx relay v2 is a similar change to the p2p network, and that has taken a while.

<rucknium> tevador: Good. Discussion can continue on GitHub of course.

<rucknium> 8. FCMP alpha stressnet (monero.town/post/6763165).

<rucknium> This week we increased the spam volume. 40GB was added in the last week and the unpruned node database is now over 100GB.

<rucknium> mrelay.p2pool.observer/m/monero.social/NKqjHnLSyYCuhpLrPGsMnrUN.png (stressnet_block_weight_2025_12_10.png)

<datahoarder> As mentioned. Deployed stressnet block explorer stressnet.p2pool.observer on clearnet. can view blocks or transactions. in a future stressnet, we could share viewkeys to identify miners/transactions. Hope it's useful, monerod willing.

<rucknium> ^ That's the last week of stressnet block weights from stressnetnode1.moneronet.info

<rucknium> I think the short-term scaling limit has been reached, at about 18MB blocks when fees are not maxed. Up to 30MB blocks when fees are near maximum.

<jeffro256> @boog900: To be fair, the tx relay v2 issue is much more complicated since different relay strategies affect network-level privacy and bandwidth requirements. Whereas fixing the 100MB block sync issue effectively boils down to splitting up the same message in the same order over multiple packets.

<rucknium> IMHO, there is node instability at the 18MB block limit. A lot of orphaned blocks and foolish behavior by monerod.

<ofrnxmr> @rucknium: I think thats due to txpool

<jberman> On network health: FCMP++-related OOM's have seemed relatively in check with the pre-release v1.5 (although @Datahoarder's latest OOM is worth a look). Right now I'm focused on an interesting FCMP++ verification regression with that build, and I do want to investigate that fully before v1.5

<ofrnxmr> I notice a lot of inconsistent txpools,which leads to new blocks being broadcast with alot of unknown txa

<datahoarder> @jberman: of note, I make heavy use of RPC for the explorer

<ofrnxmr> example: @rucknium:monero.social your explorer showed 600mb, but my nodes showed like 50mb, 200mb, and 400mb

<jberman> sounds like the nodes with <600mb are having issues

<boog900> @jeffro256: Ehh tbf I thought tx relay v2 would be a pretty easy change before we started actually working on it. I think preventing any DoS while changing the whole sync and relay protocol is going to be complicated or at least take a while to review.

<rucknium> Keeping spam tx volume consistently high is hard wen nodes are acting foolishly. So I won't keep trying there. I think good info was obtained in the last week.

<jberman> (I agree with boog fwiw, my hunch is a new sync protocol is going to end up a more involved change)

<jeffro256> @boog900: Hence why I'm so ready to getting header-only sync in Monero, especially DoS-resistent header-only sync with PoW commitments

<jberman> (I guess boog didn't say that, but tha'ts myu hunch)

<ofrnxmr> @jberman: Similar problems for lower pool sizes, like spam node will have 10k txs, but explorer has only seen 5k of them

<datahoarder> @jeffro256: pow commitments on beta stressnet would be so nice to have :)

<ofrnxmr> Also a major issue is that eventually you get a lot of "not relayed" and "failing" txs. No idea why

<jeffro256> @datahoarder: @datahoarder:monero.social: you may be interested in monero-project/monero #10038

<datahoarder> I already have the code in, even on my go-RandomX (which also supports V2!)

<ofrnxmr> The tldr is that the txpool itself has issues. Fixing that should fix a lot of the alt chains, reorgs, and nodes falling behind as a result

<datahoarder> I was looking at that but the TODO was a bit empty

<rucknium> And nodes shouldn't check if they need to increase the LMDB size every time they receive a tx in the txpool, if that is actually what's happening.

<jberman> @ofrnxmr:monero.social: and these issues are definitively not issues helped/sovled by 252 and 254, ya?

<datahoarder> @ofrnxmr: I noticed orphan blocks dumping txs on txpool, but txpool doesn't grow, so node keeps orphan block ... but without txs to switch or broadcast it if it becomes the legit one

<jeffro256> #252 is huge

<ofrnxmr> @jberman: Right

<datahoarder> which might explain the issues with orphans once txpool grows - one orphan causes a temporary split due to inability to switch back even if other grows a bit more

<datahoarder> but one would assume then the transactions make their way over time later

<jberman> ok, it's sounding like you guys are running into new issues where you're seeing in the logs what's happening / noticing interesting patterns. if you could write up issues for these circumstances (or add to existing ones) and include those logs, it would be helpful so we can keep track of them

<rucknium> Anything more on stressnet?

<ofrnxmr> @jberman: rucknium asked about double spends, and noted that he had a lot of failing txs

<ofrnxmr> I hadnt noticed failing before, but already had an issue open about not relayed

<ofrnxmr> The other day, i noticed 1000+ failing, and ~800 not relayed

<rucknium> Nodes thought some of my wallets were trying to double spend. rescan_spent solved it.

<ofrnxmr> @ofrnxmr: checked because (wallets were giving double spend errors)

<rucknium> It wasn't a few outputs. AFAIK, it was almost all of the outputs that those wallets were trying to spend

<ofrnxmr> The node didnt go over capacity on the pool - its set to 50gb max

<rucknium> I don't know if I have the time allocation to troubleshoot every issue I hit.

<rucknium> I mean, submit a useful bug report and help investigate

<rucknium> I just do some percussive maintenance and move on.

<jberman> ack on this issue, I essentially have a status report on it here: seraphis-migration/monero #185#issuecomment-3609916734 > <@rucknium> Nodes thought some of my wallets were trying to double spend. rescan_spent solved it.

<rucknium> Keeping the spamming going, alone, takes time. I think I had about 80 wallets spamming this week.

<jberman> ack, would probably be good to add to that issue about not relayed this new failing state > <@ofrnxmr> I hadnt noticed failing before, but already had an issue open about not relayed

<jberman> @rucknium: you generally don't have to help investigate. just a quick summary of the issue and log level 2 is enough

<rucknium> And I don't know if the issues I hit are meaningful or if it's just because I'm sending txs at a rate that no user would reasonably send them.

<ofrnxmr> @rucknium: The "not relayed" txs should probably be an easy fix

<rucknium> @jberman:monero.social: I can push logs to a viewable directory in the MRL research computing cluster. Extracting them and bringing to GitHub is annoying.

<ofrnxmr> If you relay_tx txid, they relay. So its just monerod failing to do its job

<jberman> @rucknium: that's fine

<ofrnxmr> @ofrnxmr: The failing state though, i dont know what would cause that

<jberman> tbh I think we'll probably want tx relay v2 in place before really digging on that one (and revert pool complement checking that I added to stressnet to reduce bandwidth)

<jberman> (it could be the latter causing issues, I'm not sure)

<jberman> A general update on stressnet: will just keep hammering issues as they come in, and work toward getting tx relay v2 in. Unfortunately the influx of issues (both from the integration itself and from existing quirks) is large, so it's taking time to work through it

<rucknium> @jberman:monero.social: Thank you!

<rucknium> 9. Post-FCMP scaling concepts.

<rucknium> Is @preland:monero.social here?

<rucknium> Maybe I should put this item earlier in the agenda.

<rucknium> next time

<rucknium> We can end the meeting here. Thank you.