<suhyeon:matrix.org> Hi, I’m one of the authors (Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. ) — thanks for discussing our work. We computed Qubic’s hashshare using both mainchain and orphan blocks, so that description of the paper is mistakenly incorrect. I’d be happy to discuss the other points further.

<rucknium> @suhyeon:matrix.org: Hello! Do you want to stay for the meeting? It will start in about two hours (17:00 UTC).

<suhyeon:matrix.org> Especially we're interested in missing orphan blocks you pointed out.

<suhyeon:matrix.org> oh can you share the information about the meeting? I have no clue

<rucknium> monero-project/meta #1313

<rucknium> I can add you to the beginning of the meeting agenda if you want.

<suhyeon:matrix.org> okay that will be great then !

<rucknium> Fantastic. Good to meet you!

<suhyeon:matrix.org> Good to meet you too

<sgp_> > <@suhyeon:matrix.org> Hi, I’m one of the authors (Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. ) — thanks for discussing our work. We computed Qubic’s hashshare using both mainchain and orphan blocks, so that description of the paper is mistakenly incorrect. I’d be happy to discuss the other points further.

<sgp_> Welcome! Thanks for joining

<datahoarder> > <@suhyeon:matrix.org> Especially we're interested in missing orphan blocks you pointed out.

<datahoarder> as a heads up, here's also a CSV with all identified "mined" Qubic blocks including orphans up to last week irc.gammaspectra.live/05eb9beefdebb016/blocks-proof.csv, in case of them being orphan the full block header is included, which contain a miner transaction that can be verified with their viewkeys. Most of the dat [... too long, see mrelay.p2pool.observer/e/mem1s9MKSFFLTE4y ]

<suhyeon:matrix.org> We found the reason. At first we attributed Qubic blocks without relying on view keys and used coinbase pattern. Later, we found viewkeys are shared in Qubic's discord channel, we confirmed the identified Qubic blocks but didn't check other blocks not attributed with the pattern. Thanks for sharing the dataset. With yours, our hashshare estimate should be corrected as the below plot (red to blue).

<suhyeon:matrix.org> mrelay.p2pool.observer/m/matrix.org/psnGtaHExKEFXgRjmKpmlFtt.png (image.png)

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

<rucknium> 1. Greetings

<articmine> Hi

<jberman> waves

<vtnerd> Hi

<datahoarder> Hello

hi hivia hi via IRC

<suhyeon:matrix.org> Is this meeting happening here in chat?

yes

<suhyeon:matrix.org> okay good

<boog900> hi

<rucknium> @suhyeon:matrix.org: Yes. MRL meetings are text chat only.

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

<rucknium> me: Using Markov Decision Process (MDP) to analyze selfish mining countermeasures. Accidentally eating all the RAM on the MRL research computing cluster.

<articmine> I updated and uploaded the latest scaling parameters

<articmine> Capping MS to 8 ML

<suhyeon:matrix.org> me: testing randomzied attention test to solve verifier's dilemma in optimistic rollups

<jeffro256> Howdy

<jberman> Implemented changes to tree building using the unbiased hash to point (unbiased hash to point is on the TODO list for beta), addressed all comments on outstanding PR's, we're close to releasing v1.5 for the alpha stressnet. Continuing today with tx relay v2, then may investigate a reported segfault

<jeffro256> Me: working on knowledge proofs integration, reviewing PRs for v1.5 release, and still coordinating with potential auditors for carrot_core

<vtnerd> Me: speced out fcmp++ spending in lws clients. Nothing built, just convos with berman and jeffro confirming plan. Also attempting to rebase the lws carrot patch after jeffros changes to some functions. The tests fail and I havent dug into why yet. A user reported 0conf was broken in carrot but I haven't verified. And otherwis [... too long, see mrelay.p2pool.observer/e/_7yettMKODRFVXpk ]

<datahoarder> Cleaned up all recent additions due to FCMP/Carrot on my codebase to try to make it usable for any potential library users/p2pool. All carrot changes now converge as well. Working on finally making a full event log of Qubic mining events with the archived points of view of their network.

<rucknium> 3. Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. (moneroresearch.info/293)

<rucknium> Welcome, @suhyeon:matrix.org (Suhyeon Lee), co-author of the paper!

<rucknium> How did you find out about this Matrix room by the way?

<suhyeon:matrix.org> Hello Thanks for inviting me and also for discussion

<suhyeon:matrix.org> Oh I found your discussion in X (twitter) and tried to reach out for discussion

<suhyeon:matrix.org> I wanted to mention the description of the hashshare calculation is wrong, not the hashrate calculation itself

<suhyeon:matrix.org> Also, wanted to know missing Qubic blocks from our dataset

<suhyeon:matrix.org> Actually, this work was not systemized, one of side project with me and one undergraduate student (my mentee)

<suhyeon:matrix.org> So dataset was collected after most of selfish mining

<rucknium> @suhyeon:matrix.org: I think @datahoarder:monero.social , true to name, has even more data than that.

<datahoarder> indeed.

<suhyeon:matrix.org> So there was some mistake and thanks to you we can improve the paper

<suhyeon:matrix.org> Also, for that, I want to mention, at least, appreciation to you guys in paper later. If possible, cowork on the paper will be nice. :)

<datahoarder> Hi @suhyeon:matrix.org. A few notes. I mostly noted that you lacked granular data on Qubic, and mostly ran on on-chain plus tasks from dispatcher (what you call job_notify)

<rucknium> @suhyeon:matrix.org: Do you plan to publish the analysis code and make it open source?

<suhyeon:matrix.org> @datahoarder: Yes we collected such data during only very limited time.

<rucknium> @suhyeon:matrix.org: I would be open to collaboration on the paper :)

<suhyeon:matrix.org> @rucknium: Yes

<datahoarder> I have an archive on all historical tasks from their network, with full block template. Additionally, we also have a record of all solutions of 640M or higher (a block is a high difficulty solution, usually at several G)

<suhyeon:matrix.org> Currently, I'm very busy with my main job. After some hassle, of course, we should publish all the codes.

<datahoarder> That gives us around 6-20 solutions for every task which allows calculating hashrate of Qubic directly from source.

<suhyeon:matrix.org> The reason why we didn't publish the codes is now it's too much with mess

<suhyeon:matrix.org> @datahoarder: Great. How did you collect all the data?

<datahoarder> If you go back to when your paper was posted in this room historically I posted some charts comparing what we saw hashrate wise from them, but that's captured from the live database.

<datahoarder> We connect to their consensus network directly and gather raw packets. These are verified against public keys

<datahoarder> Then we gather tasks from dispatcher, and solutions for each task, provided by computors and signed by them.

<datahoarder> Each solution includes nonce values and PoW hash (for verification)

<suhyeon:matrix.org> okay I'll check this later > <@datahoarder> If you go back to when your paper was posted in this room historically I posted some charts comparing what we saw hashrate wise from them, but that's captured from the live database.

<rucknium> Discussion starts here ^ . @suhyeon:matrix.org , can you try to click on the message? > <@datahoarder> > view–key–based verification can be applied only to blocks that are already definitively included in the main chain; it cannot be used for blocks that are still within an ongoing epoch or for blocks that have already become orphaned.

<suhyeon:matrix.org> What was the major difference in conclusions of your analysis other than hashrate?

<datahoarder> However, this dataset has not been publicly gathered/released at this moment. Nonetheless the hashrate values are mostly similar to the ones reported by Qubic

<suhyeon:matrix.org> @rucknium: Thanks it works

<suhyeon:matrix.org> What I wondered was their selifsh mining strategy in the research

<datahoarder> We also saw similar lack of efficiency on their selfish mining. Initially estimated to -20% losses, later they optimized to -10-8% losses

<datahoarder> The state machine you built is generally very close to what we observed, though they changed it over time.

<rucknium> IMHO, their aim was propaganda. To publicize their cryptocurrency.

<suhyeon:matrix.org> I came across Qubic guys in TOKEN 2049 Singapore

<suhyeon:matrix.org> I asked what they're doing in Qubic

<suhyeon:matrix.org> @rucknium: I agree

<suhyeon:matrix.org> Becuase of that I know Qubic now X)

<suhyeon:matrix.org> They said they're doing optimized selfish mining

<suhyeon:matrix.org> So I wondered they use theoretically optimized selifsh mining based on the Markov chain analysis

<datahoarder> Additionally, there is bias on blocks published by Qubic. Not all of them were intended to be published, some of the bias was caused by sech1 / me :)

<suhyeon:matrix.org> So I checked if they did 'catch up' which means they're behind and try to catch the main chain height. But we didn't find any intended or systemic trials on it.

<datahoarder> in many cases this bias just made them more profitable (it prevented their selfish mining) and your analysis covers later stages, which were not biased this way.

<suhyeon:matrix.org> Rather, we found they made selfish mining less efficient that is analyzed in the paper

<datahoarder> @suhyeon:matrix.org: They do not. The most they do is if they are at "par" after releasing their chain they will stick to it until next block.

<rucknium> @suhyeon:matrix.org: My guess is that they released blocks manually. It was a human judgement decision usually.

<datahoarder> It was automated in later stages. Some of the first long trials were manually released, yes

<suhyeon:matrix.org> Can you explain it more, I didn't understand clearly > <@datahoarder> Additionally, there is bias on blocks published by Qubic. Not all of them were intended to be published, some of the bias was caused by sech1 / me :)

<datahoarder> Basically. We read their nonces and built blocks to send them to the Monero network.

<suhyeon:matrix.org> @rucknium: if it's human decision, wow. Then, how did you guess so?

<datahoarder> This makes them look like they weren't selfish mining for a given period, but they were. This was later prevented by including undisclosed transactions in their blocks.

<rucknium> @datahoarder: @datahoarder:monero.social and sech1 prevented their long private alt-chains from forming by forcing them to be public.

<datahoarder> Initially we pushed all instantly, later kept their chains short

<rucknium> It was some intense spy-vs-spy, cloak-and-dagger maneuvering.

<suhyeon:matrix.org> @datahoarder: That's smart. Then, they changed a strategy for that?

<suhyeon:matrix.org> @rucknium: Sounds like game theory

<datahoarder> They added encryption. They added new encryption. They added new new encryption. They blamed pools, disabled task dispatchers, and so on.

<rucknium> A heroic battle in the shadows 😎

<datahoarder> Nothing worked until they added the undisclosed transactions, after it was discussed in an MRL issue :)

<suhyeon:matrix.org> You are cool, guys

<datahoarder> All they did was centralize their network more, anyhow. Their infrastructure back then and now is effectively just a centralized pool with central dispatcher authority that decides what to mine

<datahoarder> The encryption algorithms they use were kept private as well. So anyone verifying solutions is unable to do so anymore.

<suhyeon:matrix.org> I think I can't stay much longer cause it was not a plan today for me. How can we communicate later? Especially @datahoarder:monero.social

<datahoarder> The encryption is kept secret, only to be revealed via discord DMs

<datahoarder> I'm around here and #monero-research-lounge:monero.social

<suhyeon:matrix.org> Okay I'll talk to there later then

<datahoarder> As of last note, besides a specific oddity during a night, the reported hashrates on their API were mostly correct to what the internal stratum was.

<datahoarder> Any other discussion on the paper/Qubic for now if @suhyeon:matrix.org has to leave?

<rucknium> @suhyeon:matrix.org: Thank you very much! It's always great to see more people researching Monero.

<rucknium> @suhyeon:matrix.org: Here is something I wrote about Qubic's disruption: rucknium.me/posts/monero-18-block-reorg

<suhyeon:matrix.org> Oh thank you so much. I'll check this too.

<suhyeon:matrix.org> Thanks for invitation and also thanks for your information.

<suhyeon:matrix.org> Have a good day guys

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

<datahoarder> (if you need input in other topics from me I'll be AFK, ping if needed, doesn't seem like from agenda)

<rucknium> It seems that the new spy nodes have been consistently connected to the network for a week: moneronet.info

<rucknium> Last meeting I suggested that we wait until this meeting to confirm the switch to the new IP address ranges and adopt/publicize the new MRL ban list

<rucknium> The new proposed list is github.com/Boog900/monero-ban-list/blob/update/ban_list.txt

<ravfx:xmr.mx> I confirm it too, when I look at one of my node firewall log, the only thing I can see are the thousands lines that start with "SPIES" on the new range!

<ravfx:xmr.mx> I did keep the old range blocked in case

<rucknium> How can versioning be handled? IIRC, you can add comments to specific lines in the ban list file. IIRC, @jeffro256:monero.social added that feature. Can comments be added on their own line?

<jeffro256> Yes

<jeffro256> Everything on a line on or after a pound character is ignored, then whitespace is stipped, and empty lines ignores

<jeffro256> *ignored

<rucknium> And there is the DNS ban list. One could take a big step and completely replace the DNS ban list with the new MRL ban list (or as many IP addresses on the MRL ban list that fit). It seems that all the nodes on the DNS ban list have disappeared from the network.

<rucknium> Or you could keep most of the DNS ban list unchanged and add the big /24 subnets from the new MRL ban list.

<rucknium> @jeffro256: So maybe a comment could be added to the top of the MRL list: Version 2 or something. And put in-line comments on the old and new /24 ranges, describing what happened.

<rucknium> I just remembered that I wanted to say something at the beginning of the meeting:

<rucknium> Next Wednesday is December 24. Personally, I won't put up an MRL agenda in the meta repo and I won't chair a meeting then. If anyone else wants to, they should feel free.

<boog900> We could, do we care the ban list won't then work on older daemons though?

<rucknium> Good question. Maybe just the comment on the top. That's supported on old nodes, right?

<jeffro256> i dont think so

<rucknium> Here is your PR: monero-project/monero #9558

<rucknium> I thought from the decision that non-inline comments were allowed before, but maybe not.

<rucknium> the description*

<rucknium> Is there another way to properly version the list? Or just live without proper versioning?

<jeffro256> Nope, they weren't a thing at all. The old parsing code reads a line in, then immediately tries to parse it as an net address

<jeffro256> IIRC the net address parsing code skips whitespace, but definitely no comments

<rucknium> Any comments from anyone else about this topic? Anyone opposed to updating the MRL ban list and publicizing it?

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

<preland> I'm taking a final in 6 minutes (sry)

<jberman> I think it's ok that the ban list doesn't work on older daemons

<rucknium> @preland:monero.social: Good luck!

<jeffro256> Me too. If they're not updating their daemon code, they're probably not keep up-to-date with the ban list

<jberman> The recent updates have been important, more people updating is good

<rucknium> Do we know what happens if a ban list with comments is ingested by an old-version node? I can try it if we don't know yet.

<rucknium> The next agenda item (Post-FCMP scaling concepts) was suggested by preland, but they are busy now. Going to next item.

<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).

<jberman> Last week @boog900:monero.social , tevador , and I raised explicit support for max growth of 1.2x the LTM, in addition to the sanity cap

<jberman> @boog900:monero.social mentioned this would allow for 40-47x growth within 1 year, and 2.5x every year after that

<jberman> 40-47x year 1 growth also fits within @ofrnxmr:monero.social's expected growth also shared last week: libera.monerologs.net/monero-research-lab/20251210#c625246

<jberman> I do not think the sanity cap justifies a higher LTM growth rate, because as @boog900:monero.social has argued, the sanity cap eventually will not matter due to its exponential growth

<jberman> Personally I would prefer @boog900:monero.social's proposed params over all proposals, and rank my order of preference:

<jberman> 1. @boog900:monero.social's proposed params, 2) sanity cap, 3) hard cap

<jberman> I am in favor of all 3, but personally mention I'd be ok with excluding the hard cap

<articmine> I have updated this to to cap the MS growth to 8 ML

<jeffro256> Rucknium: a comment line in the ban list should get printed on stdout and skipped

<articmine> I have given my reasons for keeping the growth of ML at 2 under the sanity cap

<rucknium> @jeffro256:monero.social: Would the rest of the ban list lines be interpreted normally and successfully?

<jeffro256> I think so, but I haven't tested

<jberman> @rucknium:monero.social @jeffro256:monero.social @ofrnxmr:monero.social curious if you have thoughts on 2x LTM versus 1.2x LTM

<articmine> We must keep in mind the sanity cap applies

<articmine> So it is the lower of the two

<jberman> > I do not think the sanity cap justifies a higher LTM growth rate, because as @boog900:monero.social has argued, the sanity cap eventually will not matter due to its exponential growth

<jeffro256> @jberman: I think that max long-term growth YoY of 2.5x is enoug, personally

<jeffro256> growth in block size

<jeffro256> Which corresponds to the 1.2x LTM value, right?

<jberman> right

<jeffro256> Then I am also in favor of boog's proposal

<articmine> Yet but this ignores the suppression of Monero for at least the last 5 years

<jberman> non sequitor

<articmine> I know about the lobbying behind the scenes here

<articmine> It is not a non sequitor

<jberman> It is, and your constant witch hunting is hostile to the Monero project

<rucknium> IMHO 1.2x growth on the 100,000-block long-term median (LTM), which allows 2.5x growth annually after exhausting the short-term growth ceiling, would sound good to me. Stressnet is having difficulties processing the (rough) amount of txs that the short-term growth would allow.

<articmine> @rucknium: But you are ignoring the sanity cap

<jberman> > I do not think the sanity cap justifies a higher LTM growth rate, because as has argued, the sanity cap eventually will not matter due to its exponential growthboog900bo

<jberman> 3rd time I've posted this message and you've consitently ignored it every time

<articmine> boog's was without a sanity cap

<jberman> That is not a coherent response to the message

<articmine> What is your rationale

<rucknium> I don't really like exponential growth in the long term, but changing the functional form would require re-analysis of the whole blocksize-fee interaction system.

<rucknium> IMHO, fee analysis of blockchains is nontrivial.

<jberman> Expontential growth in the long term means that it will eventually grow so large that it won't have any impact in limiting growth

<articmine> It is the lower of the two

<jeffro256> IMO I think that there should be a sanity cap just to be safe on either of the proposals, which doesn't necessarily have to be exponential indefinitely

<articmine> I agree with the sanity cap

<rucknium> Asking for rice grains on chessboard squares.

<articmine> What I don't understand is why lock in the harm that has by done

<jberman> It isn't locking in harm that has been done that is a madeup argument that has no basis in reality. It's implementing rational limits that ensure the network remains healthy

<jeffro256> I think that the harm is a sunk cost, we can't unharm reputation / adoption / suppression by allowing big blocks. The harm is at root done at the human level. Yes, perhaps Bitcoin's p-to-p use case is bottlenecked at a technical level, but we're not there: our use case is bottlenecked at the political / adoption level

<articmine> I can't ignore the suppression and how much longer it can go on

<jberman> Good thing 1.2x LTM allows 40-47x growth within 1 year and 2.5x per year every year after that

<articmine> Just look at the historical transaction data for Monero

<articmine> @jberman: It does not if the suppression continues

<jberman> Yes, it does

<articmine> The is no chance to recover

<articmine> Do the math for another decade of suppression

<boog900> You cant predict the future usage of monero

<jberman> By your argument, a 10,000x LTM also would not allow for growth if suppression continues

<articmine> @boog900: Neither can tou

<articmine> You

<boog900> I know my numbers are arbitrary just like yours

<articmine> @jberman: We can go to the ridiculous

<boog900> I feel they allow enough growth while being much safer than what our current algo is and what you propose

<articmine> I have to disagree if the suppression continues

<articmine> For like a decade

<articmine> This is the situation where there is a real difference

<jberman> No algo works if suppression continues indefinitely. When suppression stops, 40-47x within 1 year and 2.5x every year after that is strong allowed growth

<articmine> Which may not be enough

<articmine> Monero climbed 1000x in under 2 months

<articmine> That is in the data I posted

<articmine> Which is being ignored

<jeffro256> If suppression continues for another decade, the limiting factor would be the circular economy infrastructure, not block size. There's a lot of moving parts in an economy that need slow growth and can't be migrated overnight

<boog900> And yet scaling has pretty much never been activated

<articmine> @boog900: Which proves my point

<rucknium> I note that on current stressnet when blocks get around 20MB, there are a lot of orphans and alt chains. Mining pools, if they are alert, may try to limit their own block sizes voluntarily, below the consensus limits, to prevent their blocks from being orphaned.

<boog900> It proves we would have been fine up until now with my scaling algo

<articmine> That the market is dealing with all of these Doomsday scenarios

<rucknium> Alt chains on stressnet, by @datahoarder:monero.social : stressnet.p2pool.observer

<gingeropolous> @rucknium: the mining pools would just peer with each other or create their own rails, like bitcoin has

<articmine> @boog900: ... and with the original algo

<datahoarder> @rucknium: Not visible at the moment even on stressnet.p2pool.observer/fullplot.svg but I could put a fixed height if we want to have an example

<jeffro256> That's not a fair comparison and you know that. A new currency going from 1 user to 1000 users is not the same as going from 1000 users to 1000000 users > <@articmine> Monero climbed 1000x in under 2 months

<rucknium> And then p2pool and solo miners would have a bad time

<boog900> @articmine: Anyone agree with article today?

<boog900> Artic*

<datahoarder> p2pool also has an effective limit in how many txs can be included on the template, but it might go up in the future

<articmine> @jeffro256: It is actually the sharpest that I have seen when compared to Bitcoin etc

<ofrnxmr> @rucknium: And to more effectively orphan other blocks

<ofrnxmr> But these are efficiency gains, not impossible issues

<vtnerd> @articmine: That many users is way more complicated for the infrastructure

<vtnerd> Like the difficulty in engineering ramps up considerably. Every other project just punts and requires tons of ram

<articmine> I am not suggesting 1000x in two months

<jberman> The orphaning issue would be a good one to write up in the stressnet repo. Theoretically I'd assume orphan rates would go up with larger blocks, but I'm sure there are fixes to work through there to mitigate the observed issues

<ofrnxmr> @ofrnxmr: It shouldnt take longer to produce a big block alt chain than a small block one, if the nodes already have the txs. It currently does. I assume its reverifying txs in alt chains or smthn

<articmine> ... but it will take over 6 years to get to 100 MB

<boog900> Your ability to not listen is impressive

<articmine> So is yours

<jberman> @ofrnxmr:monero.social @gingeropolous:monero.social do either of you guys have thoughts on 1.2x LTM vs 2x LTM? Do you follow the argument over that param specifically?

<jberman> and @datahoarder:monero.social

<ofrnxmr> W/ sanity cap. 50x stm and 1.2ltm = 31mb and 78 max in yr. Year one limited to 10mb due yo sanity cap?

<ofrnxmr> w/o sanity cap. 16x stm and 2.0?

<ofrnxmr> Are these whats on the table?

<articmine> @jberman: You are asking people to consider a parameter in isolation out of context

<datahoarder> I have not followed the precise parameters as they have progressed across the past weeks, but note that attacks can be done context-less on scaling methods that just depend on height (and not actual chain state) for abusing RPC or sync

<articmine> Look for example at the 5 months scenario

<ofrnxmr> I think 1.2ltm w/ a 50stm + sanity cap works

<ofrnxmr> But 16stm and 1.2 is a bit low

<gingeropolous> you gotta count me out of this. I don't have the terms / acronyms engrained in my head like I should for this conversation for me to be effective. over the next 3 weeks im gonna try and get myself re-acquainted with this stuff.

<datahoarder> However if we are scaling to those block sizes - the current system is not workable for miners (they will soft cap) unless transactions can pass around easier in the future.

<ofrnxmr> @ofrnxmr: (This is using a 625kb penalty free)

<articmine> @ofrnxmr: I also can agree with that. But not with a 8 stm

<articmine> @ofrnxmr: They want 8 stm and 1.2ltm

<boog900> @ofrnxmr: That is quite aggressive IMO, allowing 100x on the current long term median in the short term

<boog900> My proposal is 8 stm

<articmine> On top of an agreed to less than 1.4 x yearly cap

<ofrnxmr> @boog900: in the short term the max is 10mb .. then 15mb.. then like 20mb..

<articmine> @boog900: Your original proposal did not have a sanity cat

<articmine> cap

<boog900> @articmine: I have stated so much its an optional add on

<boog900> Its still not in my proposal as a must

<articmine> It was way more aggressive than Bitcoin Cash

<ofrnxmr> W/o a sanity cap, id use more restrictive values

<articmine> My point is that with a sanity cap we can use 8stm 2ltm

<boog900> > Optionally we can add the moving sanity cap, however I do not think it is necessary, with an algorithm that moves at an appropriate rate.

<boog900> Literally in my proposal from the start

<boog900> Politician level of honesty

<jberman> One thing to clarify about STM. Common to all proposals on the table, there is a separate 2x on top of the STM. I believe that's why boog says 50stm allows 100x on the current LTM in the short term

<ofrnxmr> @boog900: yeah, i disagree with this, because this just caps scaling with the assumption that the network wont improve until it has to, where with sanity cap improving it should be a first class citizen

<jberman> that's accurate, right @boog900:monero.social ?

<articmine> @boog900: ... and I am not forgettting the next item on the agenda the Bitcoin style hard caps that my proposal make redundant

<boog900> @ofrnxmr: The sanity cap assumes exponential growth of our capacity, let's not pretend that will perfectly track our actual capacity growth

<boog900> @jberman: Yes

<boog900> @articmine: Politician levels of point dodging

<ofrnxmr> @boog900: so 50stm w 625kb penaltyfree = 62mb max?

<articmine> A 32 MB hard cap is on the agenda

<boog900> @ofrnxmr: Yes

<ofrnxmr> @boog900: ok so 25stm

<articmine> We are talking at this point 8 stm and 2 ltm

<articmine> With a sanity cap

<boog900> @ofrnxmr: IMO even 8 is too high. With an adjusted long term median of 5 MB, 50x would allow 250 MB blocks in the short term.

<ofrnxmr> 25stm + 1.2ltm + sanity cap

<ofrnxmr> W/o sanity cap id be on the side of restricting further, but i dont think im in that camp

<articmine> But this is not enough for the small blockers

<boog900> I just don't think the sanity cap should come into discussion for the underlying algo

<boog900> Like it should just be an add on for both

<boog900> Shouldn't be relying on it for security

<jberman> I generally agree with boog there

<articmine> @boog900: It is critical for the discussion

<ofrnxmr> I don't want to have this argument every 3-4 years. we can use semi-fast growth scaling and adjust the sanity cap at thr next hard fork if we fuck up and havent made progress

<articmine> Who thinks the sanity cap is not relevant here?

<boog900> @articmine: Yes because otherwise your proposal is stupid.

<boog900> It depends on it for its security

<articmine> @boog900: By the same argument so is yours

<jberman> I re-raise the point that I'm in favor of boog's proposed params without a sanity cap

<boog900> @ofrnxmr: That's exactly what I am trying to prevent by not having an ever moving sanity cap.

<ofrnxmr> I wouldnt be in favor of 10mb blocks being the max 5 years from now, just because 4 years from now volume was low

<articmine> @ofrnxmr: That is my t

<articmine> point

<boog900> @ofrnxmr: It wouldn't be the max, blocks can grow. Yes there could be some congestion, but that's the case with anything but infinite block size.

<ofrnxmr> With fcmp, it doesnt take very many txs to fill a 10mb block

<boog900> Its about safe growth, nodes need time to prepare

<boog900> Both software and hardware

<jberman> 8x STM, 1.2x LTM allows for 40-47x growth short term. Even with the sanity cap (which I wanted to avoid rasing here), 4 years from now it will have grown 10mb * 1.4^n (n is years from when sanity cap is in place)

<jberman> so there's no proposal on the table that would have a cap on block size at 10mb in 4 years

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

<articmine> Just a note. I am traveling back to Canada on Dec 31st so I will not be able to attend a meeting on December 31st

<jberman> did I misunderstand something? @ofrnxmr:monero.social why did you say you're against 10mb blocks in 4 years just becaues volume now is low?

<jberman> what proposal makes you think there would be max 10mb blocks in 4 years?

<ofrnxmr> @jberman: i must not understand the math here

<rucknium> @vtnerd:monero.social has stepped forward to save the kingdom: monero-project/research-lab #154#issuecomment-3651723232

<rucknium> i.e. to engineer a solution to the 100MB packet limit.

<jberman> @ofrnxmr: which math were you misunderstanding?

<jberman> or assuming

<ofrnxmr> @jberman: i understand it as

<ofrnxmr> penalty free = 625kb, 8x = 5000kb, *2 = 10000kb

<vtnerd> @rucknium:monero.social: oh no! Yeah itll be an interesting engineering feat

<jberman> Got it, the proposal's short term limit, that the LTM still allows to be raised with consistent high usage

<articmine> Yes this is not necessary with the sanity median

<articmine> So NO

<articmine> To the 32 MB or 90 MB Bitcoin style limit

<ofrnxmr> @jberman: So were talking about 25mb in first year w/o prior volume?

<articmine> For clarity my ABSTAIN is no longer the case

<articmine> Sanity cap

<articmine> Makes these hard limits un necessary

<jberman> @ofrnxmr: yes

<ofrnxmr> Last hard for q4 2022. So about 3.5yrs since last hard fork.

<ofrnxmr> I assume the next hard fork (after fcmp) will be less than 4yrs after. With sanity cap, we wont hit 90mb before we hard fork again

<articmine> Not with my proposal

<ofrnxmr> And i assume we'll have to hard fork to fix relay /p2p

<articmine> @ofrnxmr: Yes

<rucknium> Weren't fluffy blocks introduced between hard forks?

<jberman> @boog900:monero.social thoughts on raising the STM, and potentially reducing the LTM a bit further? that would accomodate the "holiday shopping" influx

<ofrnxmr> @jberman: Yeah.. i'd probably go with artics 16x + 1.2 + sanity

<ofrnxmr> @rucknium: As optional iirc, not sure how that worked

<rucknium> IIRC, there is a Levin flag for Fluffy blocks support. That wouldn't be needed if fluffy blocks were introduced at a hard fork.

<boog900> @ofrnxmr: That's literally my proposal fwiw.

<ofrnxmr> @rucknium: But the issue here isnt adding new feature, thats easy, its that old nodes would break if they dont adopt it and blocks go over 90mb

<boog900> @jberman: Ehh the stm is the thing I think is too high, I wouldn't mind raising it a little

<ofrnxmr> So the fixes could be deployed w/o hard fork, but wouldnt prevent neteork fracture unless mandatory update

<articmine> @boog900: To clarify 16 x on MS , 1.2x on ML plus sanity ?

<jberman> @boog900: @ofrnxmr:monero.social by artic's 16x, you're saying you'd be ok with allowing 32x in short term?

<boog900> Just because an update it technically a HF it doesn't mean we have to actually officially HF

<rucknium> And I guess if you have a lot of old nodes on the network, it would consume resources of the new nodes since they would relay txs the old way.

<ofrnxmr> @jberman: Yeah

<ofrnxmr> @rucknium: This is also an issue with tzrelayv2, since it still have to deal with old nodes using old relay

<boog900> Artics original 16x was with a modified algorithm that only allowed 16x max growth

<articmine> Who If we cap MS then the blocksize is allowed to go to 2x MS

<boog900> His new one is 8 x for stm which allows 16x max growth

<articmine> Unless of t sanity caps the blocksize

<boog900> So I thought for either one my one is pretty much that. I didn't realize you wanted 32 x max growth

<boog900> I don't see the need ngl

<boog900> Bitcoin cash has much less aggressive algo and they showed it could handle the combined usage of btc ETH ltc and bch iirc

<ofrnxmr> @boog900: Their txs are also 20x lower in size, so isnt their tx throughput much greater

<ofrnxmr> smaller*

<boog900> Its still multiplies based on previous size though, but yes.

<kayabanerve:matrix.org> I still support a 90 MB hard cap until the P2P, RPC protocols are upgraded.

<articmine> That is correct. 16x on both MS and block weight > <@boog900> Artics original 16x was with a modified algorithm that only allowed 16x max growth

<rucknium> I propose that scaling discussion be skipped at the December 31 MRL meeting.

<boog900> I think we can declare consensus, with the people supporting my proposal last meeting and this meeting.

<articmine> @rucknium: I will not be able to attend that meeting since I am flying back to Canada from Europe that day

<ofrnxmr> So in conclusion: what is artics proposal and boogs proposal.

<boog900> @articmine: Yes so max size with both is than same as my proposal

<articmine> @ofrnxmr: My latest is 8x on MS 16x on the block weight 2 x on ML plus sanity cap

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

<boog900> The last bit of that comment is my proposal

<articmine> Just plug give us the critical numbers

<boog900> @articmine: 8 MS, 1.2 ML, optional sanity

<articmine> What about the block weight!

<articmine> 8 Or 16?

<boog900> I didn't change the algorithm to try and get faster growth.

<boog900> So 16x

<articmine> So we are both in agreement on MS and the block weight

<boog900> Yes, the part of my proposal that had the most contention today, we agree on.

<articmine> This come then down to 2x on ML with mandatory sanity vs 1.2x on ML with optional sanity?

<jberman> I'm in favor of @boog900:monero.social's proposal regardless of the sanity cap

<articmine> Let us be clear on what is on the table

<boog900> 1.2 has had overwhelming support

<jberman> I would reluctantly be ok with 2x'ing the MS (to allow for 32x growth) and keeping 1.2 ML

<jberman> And I am in favor of the sanity cap regardless

<ofrnxmr> Alright so sounds like we're close

<articmine> I have to oppose 1.2 on ML with sanity

<boog900> You would be OK without sanity?

<articmine> No because the proposed hard caps at 90 MB and 32 MB

<articmine> I have to insist on sanity

<jberman> I would be ok with boog's proposed without a sanity cap and without a hard cap

<jberman> 2-3 years of consistently maxxed out usage to trip the 100mb limit

<articmine> @jberman: I can support that

<boog900> Sounds good to me.

<jberman> 2-3 years seems manageable, albeit it is a marginally uncomfortable position to be in for something to need to potentially be "managed"

<boog900> better than the current situation at least

<jberman> @boog900: yep

<articmine> So there we have it

<articmine> 8x on MS 16x on block weight 1.2 on ML no sanity no hard caps

<articmine> Do we have consensus?

<jberman> +1

<boog900> I agree to that.

<ofrnxmr> deal

<rucknium> +1

<rucknium> More people want to chime in?

<ofrnxmr> @rucknium: twitter's never going to let us live this down

<jeffro256> +

<ofrnxmr> This will incidentally fix (hide) the xmrig issue for large templates (since there wont be any blocks with 2800txs in them)

<rucknium> Twitter is a constant reminder that the medium is the message.

<spackle> +1

<ofrnxmr> (for a while anyway)

<rucknium> It looks like there is consensus at this meeting for "8x on MS 16x on block weight 1.2 on ML no sanity no hard caps"

<articmine> I will proceed to update the document accordingly

<rucknium> @articmine:monero.social: Thank you

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

<jeffro256> v1.5 is coming out soon, be on the lookout for that

<ofrnxmr> Not many fcmp issues being encountered. Mostly monerod issues

<jberman> anything new? AFAIK, main items now are the "not relayed" state, segfault, and higher orphan rates?

<rucknium> We can end the meeting here. Thanks everyone.

<ofrnxmr> Cheers

<jeffro256> Thanks everyone

<ofrnxmr> @jberman: Not relayed = absent on current spam so maybe can ignore that for now

<ofrnxmr> Higher orphan rates also seem to be related to very slow notifications of new blocks when blocks are big. When i mine a block on node A (add-priority-node=nodeb) nodeb doesnt see that theres a new block for sometimes 5-10 seconds

<jberman> I'm guessing node B probably doesn't have all the block's txs and has to do rounds to get them all

<jberman> but maybe there are some lingering connection issues to still deal with / correct

<jberman> in any case ya it shouldn't take 5-10s to do all those rounds. logs will help explain that one

<rucknium> Maybe could have something to do with the 600MB default txpool size. "Actual" txpool is size is 1GB. Next stressnet, default txpool size should probably be raised.

<jberman> yes, if missing txs, it'll still verify any new ones which can take ~5s b/c of 128-in's. and then it does a round to get its missing ones which can take another ~5s to verify again

<ofrnxmr> Both of the pools are pretty similar, i assume they have most of the same txs, especially for the first block mined

<ofrnxmr> I add like 100mb to the pool of high fee txs before mining, so the first block should have the oldest of those in it

<ofrnxmr> And there are (afaik) no 128in txs

<ofrnxmr> Not from me, anyway

<ofrnxmr> All of mine are 1 or 2 in, and 2 or 16 out

<rucknium> When the txpool hits the limit, does it refuse new txs or kick out old ones?

<jberman> if a tx pays a fee higher than any alreayd in the pool, it'll replace the lowest paying tx(s)

<jberman> otherwise it won't accept the new ones

<rucknium> That could cause problems here because my spammer is paying low fees and @ofrnxmr:monero.social is paying high fees.

<jberman> @jberman: fwiw there is a TODO to address this here: github.com/monero-project/monero/bl…ote_core/blockchain.cpp#L4236-L4240

<jberman> @rucknium: v1.5 will also include improvements to the node's behavior when this is happening

<jberman> and v1.4 is actually broken when that's happening

<jberman> seraphis-migration/monero #244#issuecomment-3609352393

<articmine> Thanks

<articmine> I have added the updated scaling documents as discussed

<articmine> github.com/ArticMine/Monero-Documen…b/master/MoneroScaling2025Final.pdf

<boog900> @articmine: why change the definition of Ms?

<articmine> The bound to ML was performed on MN before

<articmine> On the next step

<articmine> So technically MS was not bound to ML . It was the actual penalty median MN

<articmine> It is simpler and in line with what was discussed but functionally equivalent

<articmine> I believe that this was changed at the last fork, but I may be wrong

<articmine> Yes it was defined in two steps before. So yes we should have been arguing over MN rather than MB

<articmine> MS*

<articmine> Since we argued over MS then changing the definition of MS to follow everyone's understanding of what MS means makes sense

<boog900> in the code we get the median of the last 100 blocks weight for Ms, but for Mn we then do min(max(Ml, Ms), 50 * Ml). From the doc it would seem Ms should be a median of max(Mb, Ml) for the Ml at block Mb.

<articmine> So the simplest way then is to change 50 to 8 in the code and then change the definitions of both MS and MN to reflect the code?

<articmine> That actually makes more sense to me.

<boog900> yeah I agree

<articmine> Then I will make the changes in document to avoid any confusion

<articmine> The other median should be straight forward. Just change 1.7 to 1.2

<articmine> ML