14:59:59
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.
15:01:29
rucknium:
@suhyeon:matrix.org: Hello! Do you want to stay for the meeting? It will start in about two hours (17:00 UTC).
15:01:35
suhyeon:matrix.org:
Especially we're interested in missing orphan blocks you pointed out.
15:01:57
suhyeon:matrix.org:
oh can you share the information about the meeting? I have no clue
15:02:16
rucknium:
https://github.com/monero-project/meta/issues/1313
15:02:31
rucknium:
I can add you to the beginning of the meeting agenda if you want.
15:03:03
suhyeon:matrix.org:
okay that will be great then !
15:03:30
rucknium:
Fantastic. Good to meet you!
15:04:05
suhyeon:matrix.org:
Good to meet you too
15:08:05
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.
15:08:05
sgp_:
Welcome! Thanks for joining
15:29:03
datahoarder:
> <@suhyeon:matrix.org> Especially we're interested in missing orphan blocks you pointed out.
15:29:03
datahoarder:
as a heads up, here's also a CSV with all identified "mined" Qubic blocks including orphans up to last week https://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 https://mrelay.p2pool.observer/e/mem1s9MKSFFLTE4y ]
16:59:00
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).
16:59:04
suhyeon:matrix.org:
https://mrelay.p2pool.observer/m/matrix.org/psnGtaHExKEFXgRjmKpmlFtt.png (image.png)
17:00:00
rucknium:
Meeting time! https://github.com/monero-project/meta/issues/1313
17:00:08
rucknium:
1. Greetings
17:00:14
articmine:
Hi
17:00:19
jberman:
waves
17:00:33
vtnerd:
Hi
17:00:39
datahoarder:
Hello
17:01:45
ArticMine:
hi hivia hi via IRC
17:01:46
suhyeon:matrix.org:
Is this meeting happening here in chat?
17:01:59
ArticMine:
yes
17:02:11
suhyeon:matrix.org:
okay good
17:02:12
boog900:
hi
17:02:33
rucknium:
@suhyeon:matrix.org: Yes. MRL meetings are text chat only.
17:03:17
rucknium:
2. Updates. What is everyone working on?
17:04:20
rucknium:
me: Using Markov Decision Process (MDP) to analyze selfish mining countermeasures. Accidentally eating all the RAM on the MRL research computing cluster.
17:05:07
articmine:
I updated and uploaded the latest scaling parameters
17:05:07
articmine:
Capping MS to 8 ML
17:05:29
suhyeon:matrix.org:
me: testing randomzied attention test to solve verifier's dilemma in optimistic rollups
17:05:53
jeffro256:
Howdy
17:05:57
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
17:06:50
jeffro256:
Me: working on knowledge proofs integration, reviewing PRs for v1.5 release, and still coordinating with potential auditors for carrot_core
17:07:32
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 https://mrelay.p2pool.observer/e/_7yettMKODRFVXpk ]
17:09:44
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.
17:10:33
rucknium:
3. Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. (https://moneroresearch.info/293)
17:11:03
rucknium:
Welcome, @suhyeon:matrix.org (Suhyeon Lee), co-author of the paper!
17:11:19
rucknium:
How did you find out about this Matrix room by the way?
17:11:30
suhyeon:matrix.org:
Hello Thanks for inviting me and also for discussion
17:11:47
suhyeon:matrix.org:
Oh I found your discussion in X (twitter) and tried to reach out for discussion
17:12:23
suhyeon:matrix.org:
I wanted to mention the description of the hashshare calculation is wrong, not the hashrate calculation itself
17:12:34
suhyeon:matrix.org:
Also, wanted to know missing Qubic blocks from our dataset
17:13:01
suhyeon:matrix.org:
Actually, this work was not systemized, one of side project with me and one undergraduate student (my mentee)
17:13:11
suhyeon:matrix.org:
So dataset was collected after most of selfish mining
17:13:17
rucknium:
@suhyeon:matrix.org: I think @datahoarder:monero.social , true to name, has even more data than that.
17:13:22
datahoarder:
indeed.
17:13:29
suhyeon:matrix.org:
So there was some mistake and thanks to you we can improve the paper
17:14:04
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. :)
17:14:14
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)
17:14:32
rucknium:
@suhyeon:matrix.org: Do you plan to publish the analysis code and make it open source?
17:14:55
suhyeon:matrix.org:
@datahoarder: Yes we collected such data during only very limited time.
17:15:11
rucknium:
@suhyeon:matrix.org: I would be open to collaboration on the paper :)
17:15:12
suhyeon:matrix.org:
@rucknium: Yes
17:15:24
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)
17:15:39
suhyeon:matrix.org:
Currently, I'm very busy with my main job. After some hassle, of course, we should publish all the codes.
17:15:51
datahoarder:
That gives us around 6-20 solutions for every task which allows calculating hashrate of Qubic directly from source.
17:15:58
suhyeon:matrix.org:
The reason why we didn't publish the codes is now it's too much with mess
17:16:42
suhyeon:matrix.org:
@datahoarder: Great. How did you collect all the data?
17:16:45
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.
17:17:07
datahoarder:
We connect to their consensus network directly and gather raw packets. These are verified against public keys
17:17:34
datahoarder:
Then we gather tasks from dispatcher, and solutions for each task, provided by computors and signed by them.
17:17:46
datahoarder:
Each solution includes nonce values and PoW hash (for verification)
17:17:50
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.
17:18:12
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.
17:18:21
suhyeon:matrix.org:
What was the major difference in conclusions of your analysis other than hashrate?
17:18:27
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
17:18:37
suhyeon:matrix.org:
@rucknium: Thanks it works
17:18:54
suhyeon:matrix.org:
What I wondered was their selifsh mining strategy in the research
17:19:17
datahoarder:
We also saw similar lack of efficiency on their selfish mining. Initially estimated to -20% losses, later they optimized to -10-8% losses
17:19:39
datahoarder:
The state machine you built is generally very close to what we observed, though they changed it over time.
17:19:52
rucknium:
IMHO, their aim was propaganda. To publicize their cryptocurrency.
17:19:52
suhyeon:matrix.org:
I came across Qubic guys in TOKEN 2049 Singapore
17:20:05
suhyeon:matrix.org:
I asked what they're doing in Qubic
17:20:12
suhyeon:matrix.org:
@rucknium: I agree
17:20:22
suhyeon:matrix.org:
Becuase of that I know Qubic now X)
17:20:38
suhyeon:matrix.org:
They said they're doing optimized selfish mining
17:20:56
suhyeon:matrix.org:
So I wondered they use theoretically optimized selifsh mining based on the Markov chain analysis
17:20:56
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 :)
17:21:41
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.
17:21:43
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.
17:21:55
suhyeon:matrix.org:
Rather, we found they made selfish mining less efficient that is analyzed in the paper
17:22:10
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.
17:22:13
rucknium:
@suhyeon:matrix.org: My guess is that they released blocks manually. It was a human judgement decision usually.
17:22:44
datahoarder:
It was automated in later stages. Some of the first long trials were manually released, yes
17:22:53
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 :)
17:23:14
datahoarder:
Basically. We read their nonces and built blocks to send them to the Monero network.
17:23:19
suhyeon:matrix.org:
@rucknium: if it's human decision, wow. Then, how did you guess so?
17:24:02
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.
17:25:21
rucknium:
@datahoarder: @datahoarder:monero.social and sech1 prevented their long private alt-chains from forming by forcing them to be public.
17:25:51
datahoarder:
Initially we pushed all instantly, later kept their chains short
17:25:52
rucknium:
It was some intense spy-vs-spy, cloak-and-dagger maneuvering.
17:25:54
suhyeon:matrix.org:
@datahoarder: That's smart. Then, they changed a strategy for that?
17:26:23
suhyeon:matrix.org:
@rucknium: Sounds like game theory
17:26:25
datahoarder:
They added encryption. They added new encryption. They added new new encryption. They blamed pools, disabled task dispatchers, and so on.
17:26:40
rucknium:
A heroic battle in the shadows 😎
17:26:44
datahoarder:
Nothing worked until they added the undisclosed transactions, after it was discussed in an MRL issue :)
17:26:54
suhyeon:matrix.org:
You are cool, guys
17:27:40
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
17:28:43
datahoarder:
The encryption algorithms they use were kept private as well. So anyone verifying solutions is unable to do so anymore.
17:28:47
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
17:28:55
datahoarder:
The encryption is kept secret, only to be revealed via discord DMs
17:29:09
datahoarder:
I'm around here and #monero-research-lounge:monero.social
17:29:48
suhyeon:matrix.org:
Okay I'll talk to there later then
17:30:01
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.
17:31:17
datahoarder:
Any other discussion on the paper/Qubic for now if @suhyeon:matrix.org has to leave?
17:31:23
rucknium:
@suhyeon:matrix.org: Thank you very much! It's always great to see more people researching Monero.
17:31:44
rucknium:
@suhyeon:matrix.org: Here is something I wrote about Qubic's disruption: https://rucknium.me/posts/monero-18-block-reorg/
17:32:15
suhyeon:matrix.org:
Oh thank you so much. I'll check this too.
17:32:30
suhyeon:matrix.org:
Thanks for invitation and also thanks for your information.
17:32:33
suhyeon:matrix.org:
Have a good day guys
17:33:40
rucknium:
4. Spy nodes (https://github.com/monero-project/meta/issues/1124).
17:34:02
datahoarder:
(if you need input in other topics from me I'll be AFK, ping if needed, doesn't seem like from agenda)
17:34:53
rucknium:
It seems that the new spy nodes have been consistently connected to the network for a week: https://moneronet.info/
17:36:04
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
17:37:30
rucknium:
The new proposed list is https://github.com/Boog900/monero-ban-list/blob/update/ban_list.txt
17:37:47
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!
17:37:47
ravfx:xmr.mx:
I did keep the old range blocked in case
17:38:28
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?
17:39:05
jeffro256:
Yes
17:39:49
jeffro256:
Everything on a line on or after a pound character is ignored, then whitespace is stipped, and empty lines ignores
17:39:52
jeffro256:
*ignored
17:40:27
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.
17:41:07
rucknium:
Or you could keep most of the DNS ban list unchanged and add the big /24 subnets from the new MRL ban list.
17:43:11
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.
17:43:41
rucknium:
I just remembered that I wanted to say something at the beginning of the meeting:
17:44:37
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.
17:44:41
boog900:
We could, do we care the ban list won't then work on older daemons though?
17:45:10
rucknium:
Good question. Maybe just the comment on the top. That's supported on old nodes, right?
17:47:30
jeffro256:
i dont think so
17:49:53
rucknium:
Here is your PR: https://github.com/monero-project/monero/pull/9558
17:50:17
rucknium:
I thought from the decision that non-inline comments were allowed before, but maybe not.
17:50:27
rucknium:
the description*
17:51:23
rucknium:
Is there another way to properly version the list? Or just live without proper versioning?
17:52:01
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
17:52:43
jeffro256:
IIRC the net address parsing code skips whitespace, but definitely no comments
17:53:09
rucknium:
Any comments from anyone else about this topic? Anyone opposed to updating the MRL ban list and publicizing it?
17:53:47
rucknium:
Is @preland:monero.social here?
17:54:15
preland:
I'm taking a final in 6 minutes (sry)
17:54:19
jberman:
I think it's ok that the ban list doesn't work on older daemons
17:54:37
rucknium:
@preland:monero.social: Good luck!
17:55:00
jeffro256:
Me too. If they're not updating their daemon code, they're probably not keep up-to-date with the ban list
17:55:06
jberman:
The recent updates have been important, more people updating is good
17:56:04
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.
17:57:56
rucknium:
The next agenda item (Post-FCMP scaling concepts) was suggested by preland, but they are busy now. Going to next item.
17:58:12
rucknium:
6. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-01.pdf). Revisit FCMP++ transaction weight function (https://github.com/seraphis-migration/monero/issues/44).
17:58:23
ArticMine:
https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-03.pdf
17:58:40
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
17:58:47
jberman:
@boog900:monero.social mentioned this would allow for 40-47x growth within 1 year, and 2.5x every year after that
17:58:50
jberman:
40-47x year 1 growth also fits within @ofrnxmr:monero.social's expected growth also shared last week: https://libera.monerologs.net/monero-research-lab/20251210#c625246
17:58:58
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
17:59:09
jberman:
Personally I would prefer @boog900:monero.social's proposed params over all proposals, and rank my order of preference:
17:59:18
jberman:
1. @boog900:monero.social's proposed params, 2) sanity cap, 3) hard cap
17:59:36
jberman:
I am in favor of all 3, but personally mention I'd be ok with excluding the hard cap
17:59:40
articmine:
I have updated this to to cap the MS growth to 8 ML
18:00:11
jeffro256:
Rucknium: a comment line in the ban list should get printed on stdout and skipped
18:00:36
articmine:
I have given my reasons for keeping the growth of ML at 2 under the sanity cap
18:02:09
rucknium:
@jeffro256:monero.social: Would the rest of the ban list lines be interpreted normally and successfully?
18:02:20
jeffro256:
I think so, but I haven't tested
18:02:33
jberman:
@rucknium:monero.social @jeffro256:monero.social @ofrnxmr:monero.social curious if you have thoughts on 2x LTM versus 1.2x LTM
18:03:32
articmine:
We must keep in mind the sanity cap applies
18:03:53
articmine:
So it is the lower of the two
18:04:41
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
18:05:23
jeffro256:
@jberman: I think that max long-term growth YoY of 2.5x is enoug, personally
18:05:37
jeffro256:
growth in block size
18:06:03
jeffro256:
Which corresponds to the 1.2x LTM value, right?
18:06:10
jberman:
right
18:06:47
jeffro256:
Then I am also in favor of boog's proposal
18:07:07
articmine:
Yet but this ignores the suppression of Monero for at least the last 5 years
18:07:33
jberman:
non sequitor
18:08:04
articmine:
I know about the lobbying behind the scenes here
18:08:24
articmine:
It is not a non sequitor
18:08:43
jberman:
It is, and your constant witch hunting is hostile to the Monero project
18:08:54
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.
18:09:38
articmine:
@rucknium: But you are ignoring the sanity cap
18:10:00
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
18:10:12
jberman:
3rd time I've posted this message and you've consitently ignored it every time
18:10:28
articmine:
boog's was without a sanity cap
18:10:52
jberman:
That is not a coherent response to the message
18:11:12
articmine:
What is your rationale
18:11:19
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.
18:11:34
rucknium:
IMHO, fee analysis of blockchains is nontrivial.
18:12:02
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
18:12:03
articmine:
It is the lower of the two
18:12:32
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
18:13:14
articmine:
I agree with the sanity cap
18:13:28
rucknium:
Asking for rice grains on chessboard squares.
18:13:44
articmine:
What I don't understand is why lock in the harm that has by done
18:15:43
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
18:15:48
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
18:16:07
ArticMine:
https://bitinfocharts.com/comparison/monero-transactions.html#log&alltime
18:16:38
articmine:
I can't ignore the suppression and how much longer it can go on
18:17:05
jberman:
Good thing 1.2x LTM allows 40-47x growth within 1 year and 2.5x per year every year after that
18:17:07
articmine:
Just look at the historical transaction data for Monero
18:17:51
articmine:
@jberman: It does not if the suppression continues
18:18:17
jberman:
Yes, it does
18:18:50
articmine:
The is no chance to recover
18:19:45
articmine:
Do the math for another decade of suppression
18:20:22
boog900:
You cant predict the future usage of monero
18:20:25
jberman:
By your argument, a 10,000x LTM also would not allow for growth if suppression continues
18:20:45
articmine:
@boog900: Neither can tou
18:20:59
articmine:
You
18:21:21
boog900:
I know my numbers are arbitrary just like yours
18:21:54
articmine:
@jberman: We can go to the ridiculous
18:22:12
boog900:
I feel they allow enough growth while being much safer than what our current algo is and what you propose
18:22:57
articmine:
I have to disagree if the suppression continues
18:23:28
articmine:
For like a decade
18:23:52
articmine:
This is the situation where there is a real difference
18:24:11
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
18:24:31
articmine:
Which may not be enough
18:25:08
articmine:
Monero climbed 1000x in under 2 months
18:25:21
articmine:
That is in the data I posted
18:25:37
articmine:
Which is being ignored
18:25:37
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
18:25:48
boog900:
And yet scaling has pretty much never been activated
18:26:08
articmine:
@boog900: Which proves my point
18:26:44
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.
18:26:57
boog900:
It proves we would have been fine up until now with my scaling algo
18:27:00
articmine:
That the market is dealing with all of these Doomsday scenarios
18:27:05
rucknium:
Alt chains on stressnet, by @datahoarder:monero.social : https://stressnet.p2pool.observer/
18:27:23
gingeropolous:
@rucknium: the mining pools would just peer with each other or create their own rails, like bitcoin has
18:27:51
articmine:
@boog900: ... and with the original algo
18:27:53
datahoarder:
@rucknium: Not visible at the moment even on https://stressnet.p2pool.observer/fullplot.svg but I could put a fixed height if we want to have an example
18:27:59
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
18:28:00
rucknium:
And then p2pool and solo miners would have a bad time
18:28:29
boog900:
@articmine: Anyone agree with article today?
18:28:39
boog900:
Artic*
18:28:52
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
18:29:02
articmine:
@jeffro256: It is actually the sharpest that I have seen when compared to Bitcoin etc
18:30:09
ofrnxmr:
@rucknium: And to more effectively orphan other blocks
18:31:01
ofrnxmr:
But these are efficiency gains, not impossible issues
18:31:13
vtnerd:
@articmine: That many users is way more complicated for the infrastructure
18:31:53
vtnerd:
Like the difficulty in engineering ramps up considerably. Every other project just punts and requires tons of ram
18:31:54
articmine:
I am not suggesting 1000x in two months
18:32:20
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
18:32:30
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
18:33:06
articmine:
... but it will take over 6 years to get to 100 MB
18:33:58
boog900:
Your ability to not listen is impressive
18:35:12
articmine:
So is yours
18:35:42
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?
18:35:52
jberman:
and @datahoarder:monero.social
18:36:32
ofrnxmr:
W/ sanity cap. 50x stm and 1.2ltm = 31mb and 78 max in yr. Year one limited to 10mb due yo sanity cap?
18:36:32
ofrnxmr:
w/o sanity cap. 16x stm and 2.0?
18:36:44
ofrnxmr:
Are these whats on the table?
18:36:56
articmine:
@jberman: You are asking people to consider a parameter in isolation out of context
18:37:16
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
18:37:26
articmine:
Look for example at the 5 months scenario
18:37:36
ofrnxmr:
I think 1.2ltm w/ a 50stm + sanity cap works
18:37:50
ofrnxmr:
But 16stm and 1.2 is a bit low
18:37:56
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.
18:38:06
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.
18:38:12
ofrnxmr:
@ofrnxmr: (This is using a 625kb penalty free)
18:38:34
articmine:
@ofrnxmr: I also can agree with that. But not with a 8 stm
18:39:14
articmine:
@ofrnxmr: They want 8 stm and 1.2ltm
18:39:30
boog900:
@ofrnxmr: That is quite aggressive IMO, allowing 100x on the current long term median in the short term
18:39:45
boog900:
My proposal is 8 stm
18:40:10
articmine:
On top of an agreed to less than 1.4 x yearly cap
18:40:34
ofrnxmr:
@boog900: in the short term the max is 10mb .. then 15mb.. then like 20mb..
18:40:50
articmine:
@boog900: Your original proposal did not have a sanity cat
18:41:14
articmine:
cap
18:41:20
boog900:
@articmine: I have stated so much its an optional add on
18:41:36
boog900:
Its still not in my proposal as a must
18:41:53
articmine:
It was way more aggressive than Bitcoin Cash
18:42:00
ofrnxmr:
W/o a sanity cap, id use more restrictive values
18:43:06
articmine:
My point is that with a sanity cap we can use 8stm 2ltm
18:43:32
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.
18:43:47
boog900:
Literally in my proposal from the start
18:44:07
boog900:
Politician level of honesty
18:44:20
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
18:44:45
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
18:44:48
jberman:
that's accurate, right @boog900:monero.social ?
18:45:29
articmine:
@boog900: ... and I am not forgettting the next item on the agenda the Bitcoin style hard caps that my proposal make redundant
18:45:50
boog900:
@ofrnxmr: The sanity cap assumes exponential growth of our capacity, let's not pretend that will perfectly track our actual capacity growth
18:46:02
boog900:
@jberman: Yes
18:46:33
boog900:
@articmine: Politician levels of point dodging
18:46:59
ofrnxmr:
@boog900: so 50stm w 625kb penaltyfree = 62mb max?
18:47:05
articmine:
A 32 MB hard cap is on the agenda
18:47:22
boog900:
@ofrnxmr: Yes
18:47:41
ofrnxmr:
@boog900: ok so 25stm
18:49:14
articmine:
We are talking at this point 8 stm and 2 ltm
18:49:21
articmine:
With a sanity cap
18:49:24
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.
18:49:37
ofrnxmr:
25stm + 1.2ltm + sanity cap
18:49:37
ofrnxmr:
W/o sanity cap id be on the side of restricting further, but i dont think im in that camp
18:49:45
articmine:
But this is not enough for the small blockers
18:50:20
boog900:
I just don't think the sanity cap should come into discussion for the underlying algo
18:50:35
boog900:
Like it should just be an add on for both
18:50:46
boog900:
Shouldn't be relying on it for security
18:51:00
jberman:
I generally agree with boog there
18:51:03
articmine:
@boog900: It is critical for the discussion
18:51:13
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
18:51:29
articmine:
Who thinks the sanity cap is not relevant here?
18:51:38
boog900:
@articmine: Yes because otherwise your proposal is stupid.
18:52:11
boog900:
It depends on it for its security
18:52:16
articmine:
@boog900: By the same argument so is yours
18:52:18
jberman:
I re-raise the point that I'm in favor of boog's proposed params without a sanity cap
18:52:41
boog900:
@ofrnxmr: That's exactly what I am trying to prevent by not having an ever moving sanity cap.
18:53:01
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
18:53:28
articmine:
@ofrnxmr: That is my t
18:53:40
articmine:
point
18:54:00
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.
18:54:03
ofrnxmr:
With fcmp, it doesnt take very many txs to fill a 10mb block
18:54:21
boog900:
Its about safe growth, nodes need time to prepare
18:54:34
boog900:
Both software and hardware
18:54:47
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)
18:54:59
jberman:
so there's no proposal on the table that would have a cap on block size at 10mb in 4 years
18:55:30
rucknium:
7. Proposal: Limit blocks to 32 MB, regardless of context (https://github.com/monero-project/research-lab/issues/154).
18:56:01
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
18:58:20
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?
18:58:41
jberman:
what proposal makes you think there would be max 10mb blocks in 4 years?
18:58:58
ofrnxmr:
@jberman: i must not understand the math here
18:59:22
rucknium:
@vtnerd:monero.social has stepped forward to save the kingdom: https://github.com/monero-project/research-lab/issues/154#issuecomment-3651723232
18:59:57
rucknium:
i.e. to engineer a solution to the 100MB packet limit.
19:00:00
jberman:
@ofrnxmr: which math were you misunderstanding?
19:00:15
jberman:
or assuming
19:00:17
ofrnxmr:
@jberman: i understand it as
19:00:18
ofrnxmr:
penalty free = 625kb, 8x = 5000kb, *2 = 10000kb
19:00:36
vtnerd:
@rucknium:monero.social: oh no! Yeah itll be an interesting engineering feat
19:01:25
jberman:
Got it, the proposal's short term limit, that the LTM still allows to be raised with consistent high usage
19:03:03
articmine:
Yes this is not necessary with the sanity median
19:03:10
articmine:
So NO
19:04:01
articmine:
To the 32 MB or 90 MB Bitcoin style limit
19:04:15
ofrnxmr:
@jberman: So were talking about 25mb in first year w/o prior volume?
19:04:29
articmine:
For clarity my ABSTAIN is no longer the case
19:05:03
articmine:
Sanity cap
19:05:35
articmine:
Makes these hard limits un necessary
19:05:39
jberman:
@ofrnxmr: yes
19:05:58
ofrnxmr:
Last hard for q4 2022. So about 3.5yrs since last hard fork.
19:05:59
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
19:06:11
articmine:
Not with my proposal
19:06:17
ofrnxmr:
And i assume we'll have to hard fork to fix relay /p2p
19:07:02
articmine:
@ofrnxmr: Yes
19:07:11
rucknium:
Weren't fluffy blocks introduced between hard forks?
19:07:14
jberman:
@boog900:monero.social thoughts on raising the STM, and potentially reducing the LTM a bit further? that would accomodate the "holiday shopping" influx
19:07:24
ofrnxmr:
@jberman: Yeah.. i'd probably go with artics 16x + 1.2 + sanity
19:07:53
ofrnxmr:
@rucknium: As optional iirc, not sure how that worked
19:07:54
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.
19:08:16
boog900:
@ofrnxmr: That's literally my proposal fwiw.
19:08:43
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
19:08:55
boog900:
@jberman: Ehh the stm is the thing I think is too high, I wouldn't mind raising it a little
19:09:20
ofrnxmr:
So the fixes could be deployed w/o hard fork, but wouldnt prevent neteork fracture unless mandatory update
19:09:25
articmine:
@boog900: To clarify 16 x on MS , 1.2x on ML plus sanity ?
19:09:34
jberman:
@boog900: @ofrnxmr:monero.social by artic's 16x, you're saying you'd be ok with allowing 32x in short term?
19:09:36
boog900:
Just because an update it technically a HF it doesn't mean we have to actually officially HF
19:09:52
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.
19:10:00
ofrnxmr:
@jberman: Yeah
19:10:49
ofrnxmr:
@rucknium: This is also an issue with tzrelayv2, since it still have to deal with old nodes using old relay
19:10:53
boog900:
Artics original 16x was with a modified algorithm that only allowed 16x max growth
19:10:58
articmine:
Who If we cap MS then the blocksize is allowed to go to 2x MS
19:11:14
boog900:
His new one is 8 x for stm which allows 16x max growth
19:11:25
articmine:
Unless of t sanity caps the blocksize
19:11:40
boog900:
So I thought for either one my one is pretty much that. I didn't realize you wanted 32 x max growth
19:12:21
boog900:
I don't see the need ngl
19:12:52
boog900:
Bitcoin cash has much less aggressive algo and they showed it could handle the combined usage of btc ETH ltc and bch iirc
19:13:22
ofrnxmr:
@boog900: Their txs are also 20x lower in size, so isnt their tx throughput much greater
19:13:59
ofrnxmr:
smaller*
19:14:25
boog900:
Its still multiplies based on previous size though, but yes.
19:15:03
kayabanerve:matrix.org:
I still support a 90 MB hard cap until the P2P, RPC protocols are upgraded.
19:16:46
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
19:17:12
rucknium:
I propose that scaling discussion be skipped at the December 31 MRL meeting.
19:18:10
boog900:
I think we can declare consensus, with the people supporting my proposal last meeting and this meeting.
19:18:43
articmine:
@rucknium: I will not be able to attend that meeting since I am flying back to Canada from Europe that day
19:18:49
ofrnxmr:
So in conclusion: what is artics proposal and boogs proposal.
19:18:53
boog900:
@articmine: Yes so max size with both is than same as my proposal
19:20:19
articmine:
@ofrnxmr: My latest is 8x on MS 16x on the block weight 2 x on ML plus sanity cap
19:20:45
boog900:
https://github.com/seraphis-migration/monero/issues/44#issuecomment-3617687600
19:20:54
boog900:
The last bit of that comment is my proposal
19:21:30
articmine:
Just plug give us the critical numbers
19:22:35
ArticMine:
https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-12-03.pdf
19:22:49
boog900:
@articmine: 8 MS, 1.2 ML, optional sanity
19:23:23
articmine:
What about the block weight!
19:23:35
articmine:
8 Or 16?
19:24:11
boog900:
I didn't change the algorithm to try and get faster growth.
19:24:15
boog900:
So 16x
19:24:57
articmine:
So we are both in agreement on MS and the block weight
19:25:29
boog900:
Yes, the part of my proposal that had the most contention today, we agree on.
19:26:05
articmine:
This come then down to 2x on ML with mandatory sanity vs 1.2x on ML with optional sanity?
19:26:36
jberman:
I'm in favor of @boog900:monero.social's proposal regardless of the sanity cap
19:26:39
articmine:
Let us be clear on what is on the table
19:27:15
boog900:
1.2 has had overwhelming support
19:27:34
jberman:
I would reluctantly be ok with 2x'ing the MS (to allow for 32x growth) and keeping 1.2 ML
19:27:49
jberman:
And I am in favor of the sanity cap regardless
19:28:09
ofrnxmr:
Alright so sounds like we're close
19:28:28
articmine:
I have to oppose 1.2 on ML with sanity
19:28:48
boog900:
You would be OK without sanity?
19:30:53
articmine:
No because the proposed hard caps at 90 MB and 32 MB
19:30:53
articmine:
I have to insist on sanity
19:31:44
jberman:
I would be ok with boog's proposed without a sanity cap and without a hard cap
19:32:14
jberman:
2-3 years of consistently maxxed out usage to trip the 100mb limit
19:32:38
articmine:
@jberman: I can support that
19:33:01
boog900:
Sounds good to me.
19:33:18
jberman:
2-3 years seems manageable, albeit it is a marginally uncomfortable position to be in for something to need to potentially be "managed"
19:33:50
boog900:
better than the current situation at least
19:34:16
jberman:
@boog900: yep
19:35:43
articmine:
So there we have it
19:35:44
articmine:
8x on MS 16x on block weight 1.2 on ML no sanity no hard caps
19:36:11
articmine:
Do we have consensus?
19:36:31
jberman:
+1
19:36:35
boog900:
I agree to that.
19:36:43
ofrnxmr:
deal
19:37:00
rucknium:
+1
19:37:18
rucknium:
More people want to chime in?
19:37:30
ofrnxmr:
@rucknium: twitter's never going to let us live this down
19:38:28
jeffro256:
+
19:39:01
ofrnxmr:
This will incidentally fix (hide) the xmrig issue for large templates (since there wont be any blocks with 2800txs in them)
19:39:05
rucknium:
Twitter is a constant reminder that the medium is the message.
19:39:09
spackle:
+1
19:39:13
ofrnxmr:
(for a while anyway)
19:41:03
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"
19:41:43
articmine:
I will proceed to update the document accordingly
19:42:08
rucknium:
@articmine:monero.social: Thank you
19:43:01
rucknium:
8. FCMP alpha stressnet (https://monero.town/post/6763165).
19:44:05
jeffro256:
v1.5 is coming out soon, be on the lookout for that
19:44:11
ofrnxmr:
Not many fcmp issues being encountered. Mostly monerod issues
19:44:59
jberman:
anything new? AFAIK, main items now are the "not relayed" state, segfault, and higher orphan rates?
19:52:12
rucknium:
We can end the meeting here. Thanks everyone.
19:52:31
ofrnxmr:
Cheers
19:52:56
jeffro256:
Thanks everyone
19:53:46
ofrnxmr:
@jberman: Not relayed = absent on current spam so maybe can ignore that for now
19:55:22
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
19:56:17
jberman:
I'm guessing node B probably doesn't have all the block's txs and has to do rounds to get them all
19:56:40
jberman:
but maybe there are some lingering connection issues to still deal with / correct
19:57:22
jberman:
in any case ya it shouldn't take 5-10s to do all those rounds. logs will help explain that one
19:57:50
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.
19:58:49
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
19:59:48
ofrnxmr:
Both of the pools are pretty similar, i assume they have most of the same txs, especially for the first block mined
20:00:25
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
20:00:44
ofrnxmr:
And there are (afaik) no 128in txs
20:00:51
ofrnxmr:
Not from me, anyway
20:01:04
ofrnxmr:
All of mine are 1 or 2 in, and 2 or 16 out
20:01:15
rucknium:
When the txpool hits the limit, does it refuse new txs or kick out old ones?
20:02:06
jberman:
if a tx pays a fee higher than any alreayd in the pool, it'll replace the lowest paying tx(s)
20:02:32
jberman:
otherwise it won't accept the new ones
20:02:51
rucknium:
That could cause problems here because my spammer is paying low fees and @ofrnxmr:monero.social is paying high fees.
20:03:47
jberman:
@jberman: fwiw there is a TODO to address this here: https://github.com/monero-project/monero/blob/48ad374b0d6d6e045128729534dc2508e6999afe/src/cryptonote_core/blockchain.cpp#L4236-L4240
20:04:38
jberman:
@rucknium: v1.5 will also include improvements to the node's behavior when this is happening
20:05:43
jberman:
and v1.4 is actually broken when that's happening
20:06:22
jberman:
https://github.com/seraphis-migration/monero/issues/244#issuecomment-3609352393
20:37:40
articmine:
Thanks
20:38:26
articmine:
I have added the updated scaling documents as discussed
20:39:36
articmine:
https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025Final.pdf
20:58:33
boog900:
@articmine: why change the definition of Ms?
21:27:13
articmine:
The bound to ML was performed on MN before
21:28:41
articmine:
On the next step
21:30:33
articmine:
So technically MS was not bound to ML . It was the actual penalty median MN
21:31:34
articmine:
It is simpler and in line with what was discussed but functionally equivalent
21:33:00
articmine:
I believe that this was changed at the last fork, but I may be wrong
21:38:05
articmine:
Yes it was defined in two steps before. So yes we should have been arguing over MN rather than MB
21:38:56
articmine:
MS*
21:48:16
articmine:
Since we argued over MS then changing the definition of MS to follow everyone's understanding of what MS means makes sense
21:50:07
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.
22:09:08
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?
22:11:57
articmine:
That actually makes more sense to me.
22:14:05
boog900:
yeah I agree
22:15:04
articmine:
Then I will make the changes in document to avoid any confusion
22:16:58
articmine:
The other median should be straight forward. Just change 1.7 to 1.2
22:17:26
articmine:
ML