15:00:14
rucknium:
MRL meeting in this room in two hours.
17:00:08
rucknium:
Meeting time! https://github.com/monero-project/meta/issues/1310
17:00:12
rucknium:
1. Greetings
17:00:28
tevador:
Hi
17:00:30
articmine:
Hi
17:00:32
datahoarder:
Hello world.
17:00:34
boog900:
hi
17:00:42
jeffro256:
Howdy
17:00:55
emsczkp:matrix.org:
Hello
17:01:05
jberman:
waves
17:01:14
vtnerd:
Hi
17:01:16
ArticMine:
Hi from IRC
17:02:34
ammortel:
Hello
17:02:38
rucknium:
2. Updates. What is everyone working on?
17:03:30
tevador:
Revisiting PQ encryption (#151).
17:03:33
ArticMine:
I have reviewing the various scaling proposals
17:03:57
datahoarder:
Implemented Carrot PQ derivation changes and PQ Turnstile test on my libraries, and tested convergence. Stressnet testing, launched https://stressnet.p2pool.observer/ (for as long as stressnet monerod survives). Analyzing long term Qubic log artifacts, it's ~800 GiB of compressed event logs.
17:04:01
rucknium:
me: Working on analysing selfish mining with Markov Decision Process (MDP). Getting stressnet more stressed. Updated https://moneroresearch.info to the latest version of WIKINDX, with some help from @plowsof:matrix.org .
17:04:49
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
17:04:55
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
17:07:08
vtnerd:
Me: working on boost::beast transition in lwsf for websocket support. Otherwise bug fixes in lws+lwsf infrastructure
17:07:49
rucknium:
3. Bulletproofs* (more efficient membership and range proofs) (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626).
17:08:07
rucknium:
This CCS proposal has now moved to Funding Required.
17:08:29
emsczkp:matrix.org:
Hi, I’m the proposer of the Bulletproofs* research. Thank you all.
17:08:29
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:
17:08:29
emsczkp:matrix.org:
https://ccs.getmonero.org/proposals/emsczkp-research-folding-gbp.html
17:09:02
rucknium:
More discussion of Bulletproofs*?
17:09:50
tevador:
jeffro256: where can I find the PQ changes to carrot?
17:10:23
datahoarder:
tevador: https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243
17:10:23
datahoarder:
https://github.com/jeffro256/carrot/pull/6
17:10:33
jeffro256:
https://github.com/jeffro256/carrot/pull/6
17:10:42
datahoarder:
https://github.com/seraphis-migration/monero/pull/250 for C++ code port
17:10:43
jeffro256:
jinx
17:10:50
jeffro256:
Thanks, DataHoarder
17:10:52
tevador:
Thanks
17:11:47
rucknium:
4. Spy nodes (https://github.com/monero-project/meta/issues/1124).
17:12:28
rucknium:
I noticed yesterday that the spy nodes on the LionLink Autonomous System Number (ASN) had disappeared from my scanner: https://moneronet.info/
17:13:31
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.
17:13:43
rucknium:
But @boog900:monero.social may have more info
17:14:35
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 https://mrelay.p2pool.observer/e/mfeFltEKTm9ZR1hL ]
17:15:13
boog900:
I think they have just switched to these IP ranges:
17:15:13
boog900:
```
17:15:13
boog900:
45.13.179.0/24
17:15:13
boog900:
82.26.133.0/24[... more lines follow, see https://mrelay.p2pool.observer/e/yZ2IltEKRlcxaTdF ]
17:15:20
jeffro256:
It destroys spend privacy for the migrated enotes, but should leave the history of the rest of the wallet hidden
17:15:42
boog900:
@boog900: This is more IPs than they had before as well btw
17:16:03
jeffro256:
But they showed up with the spy fingerprint on the new range?
17:16:05
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."
17:16:37
boog900:
@jeffro256: Yep
17:18:06
boog900:
Those ranges are on a different ASN that got registered a few weeks after I found the spy nodes last year
17:18:38
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?
17:18:45
rucknium:
IMHO, it's strange that the DigitalOcean & Hetzner spy nodes fixed their spy fingerprint, but these "new" nodes coming online today did not.
17:19:15
rucknium:
Two entities using the same software. One entity fixed their software.
17:19:23
rucknium:
One hypothesis ^
17:20:10
jeffro256:
You think perhaps someone is selling this spy node software commercially?
17:20:34
rucknium:
Maybe monitor the situation for a week and then update the official MRL ban list with the new IP ranges and announce it.
17:20:51
ArticMine:
They are as part of BS
17:21:07
jeffro256:
Maybe they had an automatic deploy script, but forgot to update the deploy script
17:21:20
rucknium:
@jeffro256:monero.social: I don't know how plausible it is, but it's a possibility that came to my mind.
17:22:36
ArticMine:
BS does not have to work, to make money. The illusion of surveillance is enough
17:23:20
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.
17:23:20
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.
17:23:54
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.
17:24:08
boog900:
They can't really keep them hidden anyway, 2000 nodes going offline then 2000 nodes going online is pretty obvious
17:24:20
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.
17:25:01
rucknium:
@boog900:monero.social: It's obvious when it's being monitored daily 😇
17:25:11
selsta:
can someone make a fresh list for the DNS ban list that fits into DNS?
17:26:27
boog900:
https://github.com/Boog900/monero-ban-list/pull/10
17:26:35
rucknium:
selsta: I suggested it here a while ago, but now the ranges should be changed to reflect the new spy ranges: https://github.com/monero-project/meta/issues/1242
17:26:44
boog900:
@boog900: That's the update to my list
17:27:40
jeffro256:
Maybe we invest in a compact binary format for specifying the DNS ban list?
17:28:00
datahoarder:
Binary ranges ought to work :)
17:28:44
datahoarder:
Or require TCP for dns which should already be a thing with the long existing dns checkpoints
17:29:38
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.
17:29:44
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.
17:29:52
selsta:
ok, once https://github.com/Boog900/monero-ban-list/pull/10 is merged I'll ask mooo to update the DNS list, at least as many as fit
17:30:31
selsta:
if they switch back we can update it again
17:30:39
jeffro256:
@rucknium: So you're saying add it to the FCMP++ hard fork.......
17:31:13
datahoarder:
There's automatic range merging plus a binary format for this would help sizes. What are the current sizes and intended target?
17:31:16
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.
17:32:59
rucknium:
Subnet deduplication PR by @rbrunner7:monero.social , reviewed by @jeffro256:monero.social , @vtnerd:monero.social , and myself: https://github.com/monero-project/monero/pull/9939
17:33:08
rucknium:
More on spy nodes at this time?
17:33:59
rucknium:
5. New papers: Lee, S., & Kim, H. (2025). Inside Qubic's Selfish Mining Campaign on Monero: Evidence, Tactics, and Limits. (https://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. (https://moneroresearch.info/292)
17:34:22
rucknium:
There are two new papers about Monero. I read both of them.
17:35:05
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.
17:35:54
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.
17:36:12
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
17:36:41
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.
17:36:50
rucknium:
@datahoarder:monero.social: Do you agree that's what they did?
17:37:41
rucknium:
They still have data on the orphaned blocks that propagated through the network, but they don't use it to compute "effective hashpower"
17:37:45
rucknium:
AFAIK
17:37:46
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
17:38:08
datahoarder:
The current task includes all possible Qubic block templates, so they can find orphans as well that never get published
17:38:58
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.
17:38:58
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.
17:39:22
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.
17:39:52
datahoarder:
I did get a different understanding of that section, I'll re-read.
17:39:53
jeffro256:
That is a pretty big mistake for a researcher to make when selfish mining is the main topic of the paper IMO.
17:40:55
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
17:41:34
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.
17:41:44
rucknium:
^ That's the passage I'm interpreting
17:42:10
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)
17:42:46
datahoarder:
@rucknium: Aha! They later touch on it if I remember correctly, that they may have underestimated hashrate
17:42:58
jeffro256:
Eek, yeah if you take their word in that passage Rucknium quoted, then they messed up that calculation.
17:43:01
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.
17:43:35
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
17:44:21
rucknium:
I note that they use the original Eyal & Sirer (2013) theoretical selfish mining behavior.
17:44:35
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 https://mrelay.p2pool.observer/e/2t7zltEKNFhZUl9F ]
17:44:47
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
17:44:52
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.
17:45:28
rucknium:
@datahoarder:monero.social: Do you have something to say about @jeffro256:monero.social 's guess?
17:46:15
datahoarder:
@jeffro256: They did, specially around the threshold levels
17:46:58
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
17:47:00
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
17:47:21
datahoarder:
Aha. Most of those are 1-2 deep only
17:47:41
datahoarder:
I am parsing the event logs so I'll have more info on this later
17:47:54
rucknium:
@jeffro256:monero.social: They plot Qubic's orphaned blocks in Fig. 1 on page 3.
17:48:21
jeffro256:
@datahoarder: Are these dump from Qubic mining pool or from your node?
17:48:56
datahoarder:
It's a dump of the equivalent of their inner stratum tasks and solutions - with 600M difficulty granularity
17:49:22
datahoarder:
Events logged to the millisecond across several networks PoV and across Monero nodes
17:50:01
datahoarder:
(And other data, Tari blocks, task server they had, it's ~800 GiB of compressed event logs)
17:50:56
ravfx:xmr.mx:
I noticed the spy nodes stopped to try to connect to my node on the 6 of this month.
17:50:56
ravfx:xmr.mx:
Adding the new IPs everywhere.
17:51:08
ravfx:xmr.mx:
https://mrelay.p2pool.observer/m/xmr.mx/uXaEUNvsxSEQSiBksYMvRZHy.png (clipboard.png)
17:51:55
rucknium:
What I'm trying to do now is 1) Fit tevador's "Share or Perish" (https://github.com/monero-project/research-lab/issues/146) suggestion into MDP and 2) Develop an alternative MDP objective that maximizes disruption instead of maximizes the adversary's revenue.
17:52:07
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.
17:52:24
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
17:53:52
rucknium:
I will probably make my Monerotopia Conference talk in February about Qubic and selfish/disruptive mining. Possibly with some collaboration.
17:53:55
datahoarder:
@rucknium: Indeed. There's entities extracting maximum value and entities extracting maximum damage or marketing
17:55:51
datahoarder:
What about the other paper if there isn't more on Qubic?
17:56:08
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. (https://moneroresearch.info/292)
17:57:08
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.
17:57:44
rucknium:
In 2017, Monero didn't even require a fixed ring size, so they could use ring size as a predictor.
17:58:24
rucknium:
IMHO, training ML on RingCT Monero txs is a dead end because you cannot get a valid training set.
17:58:28
ArticMine:
There was a minimum ring size
17:59:25
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.
18:00:11
rucknium:
Yes, minimum ring size in 2017, but AFAIK, users could select higher than the minimum if desired.
18:01:21
ArticMine:
Yes they could. I used a much higher ring size in 2018 to extract the Monero Original safely.
18:01:38
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?
18:02:26
ArticMine:
The minimu as I recall was 5
18:03:09
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 😎
18:03:13
rucknium:
The other 8 are
18:03:20
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. (https://moneroresearch.info/266)
18:03:26
rucknium:
Yang, X., Xu, L., & Zhu, L. (2025). De-anonymizing Monero: A Maximum Weighted Matching-Based Approach. IEEE Transactions on Information Forensics and Security. (https://moneroresearch.info/260)
18:03:31
ArticMine:
I used like 255 to ensure common rinngs on both chains greater than 5 for the Monero Original extration
18:03:40
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. (https://moneroresearch.info/290)
18:03:40
jeffro256:
According to the README, there was already of minimum of 3 by 2016, which got increased to 5 in 2017.
18:03:43
rucknium:
Kopyciok, Y., Victor, F., & Schmid, S. (2025). Moneros Decentralized P2P Exchanges: Functionality, Adoption, and Privacy Risks. (https://moneroresearch.info/270)
18:03:49
rucknium:
Kopyciok, Y., Schmid, S., & Victor, F. (2025). Friend or Foe? Identifying Anomalous Peers in Moneros P2P Network. (https://moneroresearch.info/280)
18:03:55
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. (https://moneroresearch.info/248)
18:04:03
ArticMine:
25*
18:04:05
rucknium:
Gao, Y., Zhang, Y., Piškorec, M., & Tessone, C. J. (2025). Monero Peer-to-peer Network Topology Analysis. (https://moneroresearch.info/278)
18:04:11
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. (https://moneroresearch.info/267)
18:04:44
rucknium:
More discussion on these papers?
18:05:29
ravfx:xmr.mx:
They also moved the tor/i2p spy nodes too
18:05:48
jeffro256:
Does the BulletCT paper count? ;)
18:06:04
rucknium:
@ravfx:xmr.mx: These were the spy nodes spying on the i2p and tor networks in general, right?
18:07:38
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. https://moneroresearch.info/285
18:08:14
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).
18:09:10
ArticMine:
I have spent some time reviewing the various proposals. In particular @boog900
18:10:42
ArticMine:
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%.
18:10:50
ravfx:xmr.mx:
@rucknium: yeah, but they have a big collection of them at LIONLINK
18:10:57
ravfx:xmr.mx:
had*
18:12:50
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
18:13:25
boog900:
I think my proposal is too aggressive if anything, but it is an improvement over what we have currently.
18:13:34
ArticMine:
Then we hate the issue of too high an annual growth rate.
18:13:59
rucknium:
@boog900:monero.social: Can you post the link?
18:14:10
ArticMine:
My take is that my proposal with the Nielsen's Law caop is the way to go
18:14:31
boog900:
https://github.com/seraphis-migration/monero/issues/44#issuecomment-3617687600
18:14:35
ArticMine:
We are capping the annula growth rate to below 1.389 x
18:14:55
ArticMine:
There is also no need for fixed caps
18:15:26
ArticMine:
and we have a predictable max block weight with time.
18:15:44
ArticMine:
Like ~7 years to reach 100 MB for example
18:16:28
boog900:
1024x max growth in a year is completely unnecessary
18:16:59
boog900:
47x is too but it is much better
18:17:16
ArticMine:
There is no max growth of 1000x in a year
18:17:21
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
18:17:44
boog900:
ArticMine: 16x in short term 2x every ltm adjustment
18:18:09
ArticMine:
I ran a bitcoin node in 2017 - 2018. Over 2 TB of data in a month
18:18:31
ArticMine:
Bitcoin stly fee markes can be easily spammed
18:18:46
ArticMine:
that was over a 50 Mbits DSL line
18:19:20
ArticMine:
@boog900 You have the cap at 1.390 ..
18:19:26
ArticMine:
That is the key change
18:19:30
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
18:19:42
boog900:
I SAID MAX GROWTH.
18:19:54
ArticMine:
I know max growth
18:20:01
ArticMine:
is way faster
18:20:18
ArticMine:
but are people prepard to accept this with no caop?
18:20:29
ArticMine:
Or conntroversial fied limits?
18:20:30
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
18:21:26
ArticMine:
If that is the case then the market is taking care of things
18:21:46
ArticMine:
This is not a case to argue against the underlaying scaling
18:22:02
boog900:
why do we need to plan for no growth for 14 years then gigabyte blocks in 1 year?
18:22:04
ArticMine:
And I mean ovr a decade of more
18:22:30
boog900:
ArticMine: it is as otherwise we are just relying on the sanity cap to keep us secure
18:22:36
ArticMine:
We are not planning for no growth for 17 years
18:22:46
boog900:
another bandaid solution, just like the ones that got monerod in the state it is
18:22:53
ArticMine:
we can have 1000 tpd in 14 years
18:23:02
ArticMine:
tps
18:23:15
boog900:
we do not need 1024x in a single year
18:23:16
ArticMine:
This is far from no growth
18:23:49
jberman:
I think @boog900:monero.social raises good arguments against exponential cap, in favor of more reasonable allowed max growth params
18:23:52
boog900:
we can have a gradual increase if you believe we wont have all the growth in 1 year
18:24:40
sgp_:
Even if we allow, say, 2x growth per year max, that will still catch up to the sanity cap over time
18:24:50
ArticMine:
We have an under 1.4x per cap How many time do I have to repeat this?
18:25:06
boog900:
brooooo
18:25:08
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.
18:25:33
ArticMine:
That is what it is
18:25:45
jeffro256:
It's not like the block size is allowed to immediately jump up to sanity cap
18:25:52
boog900:
my proposal has that as optional @jeffro256:monero.social, I don't think it is needed with it though
18:25:58
ArticMine:
Both are integrated into my proposal
18:26:05
boog900:
the underlying scaling is slow enough without it IMO
18:27:01
jeffro256:
So why does it hurt, in your eyes? Just extra unnecessary complexity?
18:27:02
ArticMine:
2.5x is greater compunded than 1.4x
18:27:13
boog900:
@jeffro256: yes
18:27:25
boog900:
ArticMine: 2.5x is literally maxing out scaling
18:27:43
boog900:
1.4x is always increasing, no matter what
18:27:44
ArticMine:
It is actually too high over time
18:27:52
boog900:
I agree
18:28:03
boog900:
^ > <@boog900> I think my proposal is too aggressive if anything, but it is an improvement over what we have currently.
18:28:09
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
18:28:11
ArticMine:
Then what is the problem with under 1.4x?
18:28:16
boog900:
we can lower it?
18:28:39
boog900:
ArticMine: BECAUSE IT INCREASES NO MATTER WHAT
18:28:50
ArticMine:
We have a cap ML can stay at 2x and allow or the necessary felxibilty
18:29:02
boog900:
you have a shit scaling algo with a sanity ontop that makes it kinda ok for some years/.
18:29:09
ArticMine:
It is a sanity cap
18:29:15
boog900:
why not just have a good scaling algo
18:29:28
ArticMine:
It is not possible to do both
18:29:50
boog900:
it really is
18:29:52
ArticMine:
You eithe lock up the short term or allow massive grwoth in the long term
18:29:56
boog900:
why do we need 1024x max growth in a year
18:30:22
ArticMine:
16*32 =512 please
18:30:47
boog900:
that is under a year 1024x is a little over a year
18:31:04
boog900:
I said this in my comment
18:31:24
ArticMine:
With a 1.4 cap Please
18:31:32
ArticMine:
1.4x
18:31:34
boog900:
oh my days
18:31:37
boog900:
can we just vote?
18:32:07
gingeropolous:
i think all the proposals would need to be up somewhere with things clearly laid out before a vote
18:32:20
kayabanerve:matrix.org:
Should we literally just have a vote on 1.4x YoY or 1.4x prior year?
18:32:23
ArticMine:
Yes 2.5x per year vs under 1.4x per year
18:32:28
gingeropolous:
everythings buried in comments and threads blah blah blah
18:32:37
kayabanerve:matrix.org:
Should we first agree to defer to a vote after consensus this isn't going anywhere?
18:32:46
rucknium:
What would the voting process be and what would it accomplish?
18:32:50
boog900:
I really don't like how you are framing this ArticMine
18:33:03
boog900:
really disingenuous
18:33:08
ArticMine:
the maximum growth
18:33:16
gingeropolous:
i think our terminology is also mixed
18:34:09
ArticMine:
What is wrong with thatSo we vote between my proposal and @boog900s?
18:34:54
articmine:
@rucknium: I would like to know myself?
18:35:12
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?
18:35:37
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
18:36:08
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
18:36:33
ArticMine:
I have my ptoposal on github for everyone to review
18:36:39
boog900:
@jberman: a ltm multiplier of 1.2 with 5 adjustments
18:36:48
ArticMine:
This is getting pointless
18:37:14
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
18:37:15
jbabb:cypherstack.com:
the point is to patch the big bang block bug/attack
18:37:39
articmine:
An under 1.4x per year maximum cap
18:38:03
articmine:
Even this is not enough
18:38:05
boog900:
I don't see everyone coming to consensus on a single algo, a vote is just to decide the scaling algo by majority.
18:39:33
articmine:
There are 2 Lagos on the table
18:39:44
articmine:
algos
18:39:45
boog900:
@sgp_: isn't this pretty much my proposal?
18:41:17
sgp_:
Yeah I think the thinking largely aligns
18:41:30
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
18:42:23
boog900:
@articmine: I really hate how you are just closing your ears to all arguments
18:42:27
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 https://mrelay.p2pool.observer/e/kNnHmNEKcHFoRTY5 ]
18:42:39
articmine:
@boog900: I am t
18:42:52
boog900:
like on the one hand you say mine is more aggressive on the other you say we want a more restrictive algo?
18:42:57
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
18:43:26
sgp_:
which is what boog suggested
18:43:27
gingeropolous:
lets seperate dynamic caps and non-dynamic caps. dynamic here is referring to chain usage. not just blockheight
18:44:20
sgp_:
growing 2.5x in any given year is plenty generous imo
18:45:17
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.
18:45:20
articmine:
@sgp_: Yes they can. This allows the harm done by the BS companies to Monero to be baked into the consensus protocol
18:46:06
articmine:
So if the suppression continues we can't recover
18:46:07
articmine:
We come back to the conflict of interest
18:46:17
gingeropolous:
is the main contention over the non-dynamic caps?
18:46:20
boog900:
oh my days
18:47:22
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
18:47:32
articmine:
The main contention is allowing catch up after suppression
18:48:17
articmine:
So if Monero is suppressed for say a decade we can't recover
18:48:38
sgp_:
Any annual growth over 1.4 is recovering towards the sanity cap
18:49:05
boog900:
if we needed 10000x, your 1000x would also not allow us to recover.
18:49:24
articmine:
The sanity cap grows during the suppression period
18:49:24
boog900:
what makes 1000x special?
18:49:44
articmine:
It is not
18:49:47
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 https://mrelay.p2pool.observer/e/2LzimNEKbTFZaDl5 ]
18:50:45
boog900:
@jeffro256:monero.social: do you think my values are good, ignoring the sanity cap for now?
18:50:55
articmine:
The sanity cap is not a band aid
18:51:00
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
18:51:13
gingeropolous:
ok, so sanity cap = 1.4x thing, the neilson law thing. The hard cap is the 90MB proposed thing.
18:51:36
articmine:
@jeffro256: No the state suppression is overturned by the courts
18:51:52
articmine:
Then Monero needs to recover
18:52:04
articmine:
That is the issue
18:52:15
boog900:
FWIW you can calculate a maximum block size without an explicit sanity limit
18:52:42
boog900:
so you can get the max size of a block at a specific height
18:53:12
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
18:53:28
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.
18:53:47
boog900:
@boog900: the closer you starting block the lower that number will be too.
18:54:11
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?
18:54:14
jeffro256:
Ignoring sanity limit ofc
18:54:23
articmine:
@gingeropolous: Yes but if you drastically reduce the underlying scaling , then we cannot recover from state suppression
18:54:57
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
18:55:04
articmine:
Bitcoin today is a disaster as peer to peer cash
18:55:07
jbabb:cypherstack.com:
@jeffro256: increasing trust and/or usability. enabling swaps would be a workaround
18:55:07
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
18:55:47
articmine:
It is heavily price
18:55:53
articmine:
Priced
18:56:04
boog900:
@boog900: Artic is 512x to 1024x in the first year then 32 to 64x in the years after.
18:56:24
articmine:
It has NOT happened in 11 years
18:56:49
articmine:
With more aggressive scaling and NO sanity cap
18:57:53
articmine:
We are not ZCash which was spammed to 300x in blocksize
18:57:54
jberman:
@boog900:monero.social: what if you brought the params down further such that yearly growth is capped at 1.4x via dynamic scaling?
18:58:15
articmine:
@jberman: It will not work at a
18:58:29
articmine:
AKL
18:58:32
gingeropolous:
well that'd be even worse for the suppression hypothesis @jberman:monero.social
18:59:14
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.
18:59:37
boog900:
I would prefer that to be lower, if that could get consensus.
18:59:52
elongated:matrix.org:
@articmine: Not yet
18:59:57
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
19:00:25
boog900:
@jeffro256: 1.2 ^ 5
19:00:37
articmine:
1.2^5
19:01:02
jeffro256:
@jberman: You didn't ask me lol, but that's much too conservative for my taste
19:02:22
jeffro256:
@articmine: Isn't LTM 100K blocks, which would mean 1.2 ^ ~2.6?
19:03:09
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 https://mrelay.p2pool.observer/e/mLWOmdEKRDRZRURf ]
19:03:14
tevador:
It's 100K blocks, so it can grow every 50K blocks.
19:03:14
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.
19:03:54
articmine:
@kayabanerve:matrix.org: Really
19:03:56
boog900:
wait no I said that wrong my bad
19:04:41
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 (?)
19:04:52
boog900:
both proposals have 16x in the short term.
19:05:02
rucknium:
@articmine:monero.social: /s means that @kayabanerve:matrix.org meant the comment sarcastically.
19:05:05
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
19:05:06
kayabanerve:matrix.org:
No one suggesting scaling usage 40% per year should be considered suppressive.
19:05:34
articmine:
Yours has very stiff pricing with no scaling growth
19:05:34
tevador:
People on matrix: please try to keep your messages <500 characters. It's very hard to read the conversation on IRC otherwise.
19:06:01
ofrnxmr:
@kayabanerve:matrix.org: 40% from 300kb-650kb, i would definitely consider suppressive
19:06:15
articmine:
@kayabanerve:matrix.org: I agree
19:06:20
kayabanerve:matrix.org:
Sorry, I meant to send my messages in immediate succession but my internet had a hiccup
19:06:59
kayabanerve:matrix.org:
My following messages obviously elaborate on the "/s" originally included but lacking comprehension
19:07:34
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.
19:07:35
kayabanerve:matrix.org:
I meant to point out the absurdity, not leave it hanging for three minutes 😅
19:08:07
kayabanerve:matrix.org:
Doesn't that simply suggest we need a larger base, as these proposals already include?
19:09:25
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
19:10:27
boog900:
what do we think the best path to consensus is?
19:10:49
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)
19:10:50
rucknium:
@jeffro256:monero.social: Isn't this the tyranny of exponential growth and a reason to not have exponential growth indefinitely?
19:10:58
kayabanerve:matrix.org:
I'd advocate complete proposals, potentially independent or not, and voting
19:11:02
rucknium:
I will again point to the logistic growth curve.
19:11:21
kayabanerve:matrix.org:
My proposal was for an independent knob. I don't see why 1.4x usage can't be an independent knob.
19:11:28
jeffro256:
Artic, what do you think of Boog900's proposal as-is?
19:11:29
rucknium:
Which is classically the theoretical curve of adoption of a new technology.
19:11:31
gingeropolous:
and the proposals should have graphs. graphs!
19:11:59
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
19:12:12
rucknium:
Ah, but Arrow's Paradox ;)
19:12:21
kayabanerve:matrix.org:
Hence my proposal for independently voting on static capacity and a sanity cap
19:12:27
ofrnxmr:
Anyway, my vote is
19:12:27
ofrnxmr:
* 40% YoY (regardless of volume). Baseline of 10mb
19:12:27
ofrnxmr:
* something like 50x max growth (based on volume) in 1yr (not 1000x, not 1.5x)
19:12:27
ofrnxmr:
* 90mb default max miner template (not hard cap)
19:12:42
tevador:
16x STM, 1.2x LTM and ZM = 625 000 + sanity cap starting at 10 MB seems reasonable to me.
19:12:55
kayabanerve:matrix.org:
@rucknium:monero.social: we can also acknowledge impossibility and give up, so true
19:12:56
boog900:
the voting has started it seems :p
19:13:08
rucknium:
I mean, Arrow's Impossibility Theorem.
19:13:14
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.
19:13:51
rucknium:
@jeffro256:monero.social: I agree that is a limitation. But you could relax the ceiling with linear growth at that point or something.
19:14:06
tevador:
The 40% YoY growth could be limited to ~20 years, which is enough to reach VISA-level throughput.
19:14:06
kayabanerve:matrix.org:
I would like to end the McCarthyism though
19:15:04
gingeropolous:
2x STM, 50x LTM and ZM = 300 000 . These are the current params, right?
19:15:08
ofrnxmr:
tevador: Depends on size of future txs. So i dont think its really necessary to cap atm.
19:16:13
boog900:
@gingeropolous: 50 STM, 1.7 LTM
19:16:51
gingeropolous:
ok. got it
19:17:10
tevador:
Well, if PQ transactions are 1 MB, then yes, we have a problem. But that's for another time.
19:17:54
kayabanerve:matrix.org:
The network isn't ossified and we can adjust the formulas for PQ TXs with the PQ fork
19:18:02
jberman:
tevador: I'm ok with this as well
19:18:18
boog900:
tevador: is this 16x as is artic's 16x or my 16x (so 8)?
19:18:23
articmine:
@jeffro256: That was my point regarding @boog900 proposal
19:18:24
articmine:
One can lower the limit over say 1000 TPS
19:18:25
articmine:
But now we need maximum flexibility and the possibility of growth below the cap
19:18:27
articmine:
So we should keep the 2x on ML at least until we reach 1000 TPS
19:19:48
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 https://mrelay.p2pool.observer/e/ib3QmdEKV3VOSzk3 ]
19:20:01
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
19:20:17
boog900:
it is basically a more aggressive algorithm for the same max size.
19:20:18
tevador:
boog900: I'm talking about the maximum legal block size limit, so I think it's yours.
19:20:30
boog900:
nice 👍️
19:20:46
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?
19:20:51
tevador:
625 000 * 16 = 10 MB sanity cap
19:21:20
gingeropolous:
or we make the short term more flexible by allowing 4x the median 100 blocks instead of 2x
19:22:02
gingeropolous:
and that would keep fees lower during these expansions
19:22:06
ofrnxmr:
@gingeropolous: i think its already too reactive at 100 blocks, but i digress
19:22:08
tevador:
I think doubling every 100 minutes is plenty fast.
19:22:19
ofrnxmr:
+1
19:22:38
gingeropolous:
aye
19:22:42
rucknium:
I also assume that Monero transactions are directly related to the real economy (https://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.
19:23:36
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
19:23:42
kayabanerve:matrix.org:
@jeffro256:monero.social: intergalactic p2p communication >:(
19:23:56
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
19:24:17
articmine:
A tight base with 2x on ML is better
19:24:58
gingeropolous:
well i don't have these abbreviations memorized so im out
19:25:28
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.
19:25:44
rucknium:
p2pool has its own method, but that can be managed too.
19:26:05
tevador:
Yes, a limit can be soft forked later if needed.
19:26:05
ofrnxmr:
@rucknium: imo this is more sane than adding a 90mb hard cap
19:26:23
ofrnxmr:
Just add a 90mb default max template
19:27:08
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
19:27:20
tevador:
The problem is that AFAIK you need just 1 block over 100 MB to kill the network.
19:27:24
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.
19:28:21
ofrnxmr:
tevador: no, the 1 block wouldnt transmit
19:28:37
ofrnxmr:
The miner would get forked off
19:28:58
boog900:
not if it is fluffy
19:29:07
rucknium:
PirateChain miners causing netsplits because of excessive block verification time: https://web.archive.org/web/20230803171107/https://old.reddit.com/user/SignificantRoof5656/comments/15h9reh/pirate_chains_045_spam_attack_2_months_later/
19:29:09
articmine:
And safer
19:29:14
jeffro256:
Or it would only partially transmit, depending on network conditions. This would give miners making too-big blocks a severe disadvantage.
19:29:27
ofrnxmr:
@boog900: in which case the network would survive, but bootstrapping wouldnt
19:29:37
boog900:
@ofrnxmr: the network would split
19:29:44
boog900:
or well could split
19:30:11
boog900:
2 or more different chains which allows double spending on each one.
19:30:12
tevador:
ofrnxmr: That might not be true if we sync headers first at some point.
19:30:47
jberman:
@ofrnxmr: I'd call this more like "chicken running around with its head cut off"
19:31:22
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
19:32:17
rucknium:
We can hit the next agenda item since it's being discussed already
19:32:23
rucknium:
7. Proposal: Limit blocks to 32 MB, regardless of context (https://github.com/monero-project/research-lab/issues/154).
19:33:15
kayabanerve:matrix.org:
It can be broadcast bit not synced or scanned, or so
19:33:26
ofrnxmr:
Repeating "Just add a 90mb default max template"
19:33:31
kayabanerve:matrix.org:
Unless the sync process also separates TXs out
19:33:44
jeffro256:
NACK to 32MB non-dynamic limit, sorry Kayaba
19:33:44
ofrnxmr:
@kayabanerve:matrix.org: @ tip, it does
19:34:22
kayabanerve:matrix.org:
@rucknium:monero.social: that's now 90 MB per prior meeting,
19:34:34
kayabanerve:matrix.org:
@jeffro256:monero.social: ^
19:35:27
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
19:35:28
rucknium:
By the way, the new network scan data is in. 1,850 "new" spy nodes on the SCNL-0001-1 ASN: https://moneronet.info/
19:35:56
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.
19:35:59
boog900:
so close to half our network!
19:36:23
boog900:
its weird all those good nodes in their spy block
19:36:26
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
19:36:40
jeffro256:
NACK to 90MB non-dynamic limit ;)
19:36:49
jeffro256:
@boog900: Double crossers?
19:37:49
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
19:37:50
kayabanerve:matrix.org:
:p
19:38:38
boog900:
very funny SCNL-0001-1 was registered weeks after I found the spies last year
19:38:50
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)
19:38:55
boog900:
have to register a new one now!
19:39:02
ammortel:
It would be more elegant not to limit anything but to improve what causes the limitation's need. If that is possible
19:39:04
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: https://github.com/spackle-xmr/monero/pull/12
19:39:26
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
19:39:57
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
19:40:33
rucknium:
This is literally true for the current mainnet circumstances I described.
19:40:39
boog900:
tbf it is the same, its just the fix is harder
19:40:43
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
19:40:46
jberman:
the node breaks first fwiw, wallets download pruned tx data
19:40:57
kayabanerve:matrix.org:
This also is reachable by an adversary today
19:40:58
rucknium:
Those of us in the stressnet trenches last year know :)
19:41:26
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.
19:41:38
kayabanerve:matrix.org:
Which will screw with indexers and maybe _some_ wallets.
19:41:41
ofrnxmr:
@rucknium: Fwiw, fcmp seems to handle 50mb batches ok
19:42:12
jberman:
@kayabanerve:matrix.org: ok fair enough, the RPC wallet2 uses to sync should be ok fwiw*
19:42:43
datahoarder:
@ofrnxmr: I added proper calculation of byte size vs weight to stressnet block explorer, to see how that differs
19:43:24
rucknium:
@datahoarder:monero.social: I'm getting Bad Gateway now. But thanks for that
19:43:32
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_.
19:43:41
ofrnxmr:
@datahoarder: I think sync_info shows byte size
19:43:42
datahoarder:
@rucknium: Just fixed it, node crashed, OOM
19:43:57
datahoarder:
https://stressnet.p2pool.observer/block/f661443cc27163de55b32c939418fbddb0f93e4f7d6575221387051456356021
19:44:00
kayabanerve:matrix.org:
We can remove the limit with the functioning. tevador's table explained the theory of outcomes on this.
19:44:07
jberman:
is that an OOM running the latest v1.5 pre-release as well?
19:44:18
datahoarder:
@ofrnxmr: you can check this on any historical block (or tx)
19:44:20
kayabanerve:matrix.org:
So @jeffro256:monero.social: , want to elaborate why you don't support a limit just under the existing hard limits?
19:44:36
datahoarder:
@jberman: yep, with the patches. but I was using computer for other things now
19:44:40
kayabanerve:matrix.org:
I can't force you to agree but yes, I'd like to maintain consensus on this
19:44:48
kayabanerve:matrix.org:
We did have loose consensus last meeting
19:45:04
datahoarder:
We can talk about oom later keep going. Just wanted to bring up the size vs weight
19:46:54
tevador:
Fixing the 100MB limit is technically a hard fork in any case.
19:47:40
kayabanerve:matrix.org:
Eh. Nodes who were online at the threshold may continue indefinitely due to split syncing if blocks and TXs.
19:48:04
kayabanerve:matrix.org:
It's this horrific Schrödinger's cat of liveness, functioning, and hard forks
19:48:13
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 https://mrelay.p2pool.observer/e/m8O4mtEKX1ZRMy1x ]
19:48:26
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
19:49:02
tevador:
Nodes who don't upgrade may fork off, that' the definition of a hard fork.
19:49:27
kayabanerve:matrix.org:
Isn't that advocating 100 GB as the hard limit @jeffro256:monero.social: ?
19:49:35
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
19:49:37
kayabanerve:matrix.org:
1000x when the network breaks?
19:49:49
rucknium:
tevador: Was this fix a hard fork? https://github.com/spackle-xmr/monero/pull/12
19:50:00
kayabanerve:matrix.org:
tevador Fair
19:50:46
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.
19:51:16
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: ?
19:51:38
tevador:
Yes, increasing the limits seems like a HF to me if non upgraded nodes won't sync the larger blocks.
19:52:05
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
19:52:30
rucknium:
Then add one to the Monero hard fork count, I suppose.
19:52:37
kayabanerve:matrix.org:
We should get rid of the gun entirely with a proper sync protocol but should at least remove the round
19:52:49
datahoarder:
@rucknium: https://www.reddit.com/r/Monero/comments/1mvmg44/a_list_of_all_of_moneros_consensus_changes/
19:53:43
kayabanerve:matrix.org:
Didn't @jeffro256 HF the merkle tree three months ago?
19:53:45
tevador:
Under my sanity cap, 100 GB blocks are not possible until about 2052.
19:53:49
kayabanerve:matrix.org:
Or was that not merged yet?
19:54:31
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
19:54:34
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
19:55:22
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.
19:55:48
kayabanerve:matrix.org:
That's why I'm proposing canonicalizing current limits. To remove this bullshit.
19:56:10
tevador:
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.
19:56:28
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.
19:56:53
datahoarder:
tevador: I suggested it explicitly only being enabled for a specific hardfork, not further ones
19:57:39
kayabanerve:matrix.org:
I suggested it be enabled until removed in favor of fixed p2p, RPC, wallet sync protocols.
19:58:12
kayabanerve:matrix.org:
They both declare an intended term. One forces the issue and one acknowledges the issue.
19:58:31
tevador:
datahoarder: What if we need an emergency HF in the future before the issue is fixed?
19:58:41
rucknium:
We are about to hit three hours of meeting. Stressnet is next.
19:58:46
articmine:
Then we are back to the Bitcoin scenario. Put in a sunset block for the cap
19:59:00
datahoarder:
tevador: then you explicitly need to update that parameter. which documents this being pushed
19:59:07
rucknium:
Please start to wrap up the discussion for now.
19:59:14
datahoarder:
it's more of fuzzy feelings, as next hardfork could just push it
19:59:30
kayabanerve:matrix.org:
Yes, I'd like to not overload future HFs when this is obviously a priority
19:59:38
tevador:
articmine: The sunset block is meaningless if nodes start crashing at the limit.
19:59:43
kayabanerve:matrix.org:
Stressing about it doesn't actually solve it
19:59:54
kayabanerve:matrix.org:
If you want to stress, you can solve it
20:00:21
articmine:
My point is how long is it going to take to fix this
20:00:36
tevador:
https://github.com/monero-project/research-lab/issues/154#issuecomment-3620881639
20:00:46
articmine:
How many years?
20:00:47
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
20:00:53
kayabanerve:matrix.org:
@articmine:monero.social: PRs welcome
20:01:24
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?
20:02:07
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.
20:02:24
tevador:
If anyone has a problem with the 90MB limit, please post your arguments in #154.
20:02:30
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)
20:02:52
boog900:
tx relay v2 is a similar change to the p2p network, and that has taken a while.
20:02:59
rucknium:
tevador: Good. Discussion can continue on GitHub of course.
20:03:21
rucknium:
8. FCMP alpha stressnet (https://monero.town/post/6763165).
20:04:02
rucknium:
This week we increased the spam volume. 40GB was added in the last week and the unpruned node database is now over 100GB.
20:04:36
rucknium:
https://mrelay.p2pool.observer/m/monero.social/NKqjHnLSyYCuhpLrPGsMnrUN.png (stressnet_block_weight_2025_12_10.png)
20:05:02
datahoarder:
As mentioned. Deployed stressnet block explorer https://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.
20:05:04
rucknium:
^ That's the last week of stressnet block weights from https://stressnetnode1.moneronet.info/
20:06:17
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.
20:06:19
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.
20:07:14
rucknium:
IMHO, there is node instability at the 18MB block limit. A lot of orphaned blocks and foolish behavior by monerod.
20:07:36
ofrnxmr:
@rucknium: I think thats due to txpool
20:07:52
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
20:08:08
ofrnxmr:
I notice a lot of inconsistent txpools,which leads to new blocks being broadcast with alot of unknown txa
20:08:26
datahoarder:
@jberman: of note, I make heavy use of RPC for the explorer
20:08:54
ofrnxmr:
example: @rucknium:monero.social your explorer showed 600mb, but my nodes showed like 50mb, 200mb, and 400mb
20:09:34
jberman:
sounds like the nodes with <600mb are having issues
20:09:45
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.
20:09:57
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.
20:10:49
jberman:
(I agree with boog fwiw, my hunch is a new sync protocol is going to end up a more involved change)
20:11:09
jeffro256:
@boog900: Hence why I'm so ready to getting header-only sync in Monero, especially DoS-resistent header-only sync with PoW commitments
20:11:13
jberman:
(I guess boog didn't say that, but tha'ts myu hunch)
20:11:34
ofrnxmr:
@jberman: Similar problems for lower pool sizes, like spam node will have 10k txs, but explorer has only seen 5k of them
20:11:35
datahoarder:
@jeffro256: pow commitments on beta stressnet would be so nice to have :)
20:12:36
ofrnxmr:
Also a major issue is that eventually you get a lot of "not relayed" and "failing" txs. No idea why
20:13:20
jeffro256:
@datahoarder: @datahoarder:monero.social: you may be interested in https://github.com/monero-project/monero/pull/10038
20:13:45
datahoarder:
I already have the code in, even on my go-RandomX (which also supports V2!)
20:14:00
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
20:14:08
datahoarder:
I was looking at that but the TODO was a bit empty
20:15:02
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.
20:15:04
jberman:
@ofrnxmr:monero.social: and these issues are definitively not issues helped/sovled by 252 and 254, ya?
20:15:31
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
20:15:45
jeffro256:
#252 is huge
20:16:02
ofrnxmr:
@jberman: Right
20:16:17
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
20:16:32
datahoarder:
but one would assume then the transactions make their way over time later
20:19:45
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
20:21:19
rucknium:
Anything more on stressnet?
20:21:39
ofrnxmr:
@jberman: rucknium asked about double spends, and noted that he had a lot of failing txs
20:21:58
ofrnxmr:
I hadnt noticed failing before, but already had an issue open about not relayed
20:22:14
ofrnxmr:
The other day, i noticed 1000+ failing, and ~800 not relayed
20:22:34
rucknium:
Nodes thought some of my wallets were trying to double spend. rescan_spent solved it.
20:22:50
ofrnxmr:
@ofrnxmr: checked because (wallets were giving double spend errors)
20:23:00
rucknium:
It wasn't a few outputs. AFAIK, it was almost all of the outputs that those wallets were trying to spend
20:23:40
ofrnxmr:
The node didnt go over capacity on the pool - its set to 50gb max
20:23:44
rucknium:
I don't know if I have the time allocation to troubleshoot every issue I hit.
20:23:59
rucknium:
I mean, submit a useful bug report and help investigate
20:24:35
rucknium:
I just do some percussive maintenance and move on.
20:25:10
jberman:
ack on this issue, I essentially have a status report on it here: https://github.com/seraphis-migration/monero/issues/185#issuecomment-3609916734 > <@rucknium> Nodes thought some of my wallets were trying to double spend. rescan_spent solved it.
20:25:12
rucknium:
Keeping the spamming going, alone, takes time. I think I had about 80 wallets spamming this week.
20:25:38
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
20:26:28
jberman:
@rucknium: you generally don't have to help investigate. just a quick summary of the issue and log level 2 is enough
20:26:29
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.
20:27:27
ofrnxmr:
@rucknium: The "not relayed" txs should probably be an easy fix
20:27:36
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.
20:27:54
ofrnxmr:
If you relay_tx txid, they relay. So its just monerod failing to do its job
20:27:55
jberman:
@rucknium: that's fine
20:28:26
ofrnxmr:
@ofrnxmr: The failing state though, i dont know what would cause that
20:29:47
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)
20:30:22
jberman:
(it could be the latter causing issues, I'm not sure)
20:32:11
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
20:32:38
rucknium:
@jberman:monero.social: Thank you!
20:33:22
rucknium:
9. Post-FCMP scaling concepts.
20:33:26
rucknium:
Is @preland:monero.social here?
20:33:49
rucknium:
Maybe I should put this item earlier in the agenda.
20:33:52
rucknium:
next time
20:35:15
rucknium:
We can end the meeting here. Thank you.