Monero Research Lab Meeting - Wed 26 November 2025, 17:00 UTC

[Rucknium]

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

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. BulletStar (more efficient membership and range proofs).

4. P2Pool consolidation fees after FCMP hard fork. Coinbase Consolidation Tx Type.

5. Transaction volume scaling parameters after FCMP hard fork. Revisit FCMP++ transaction weight function.

6. FCMP alpha stressnet.

7. Post-FCMP scaling concepts.

8. Any other business

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

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#1299

[preland]

If time permits, I’d like to discuss some of the scaling avenues I’ve been looking into at the end of the meeting

[Rucknium]

@preland : Yes. What do you want me to call the agenda item?

[preland]

Something along the lines of "post-FCMP scaling concepts"

[janowitz]

Unfortunately I couldn't attend. Could somebody please post a log? monerologs.net doesn't update any more.

[Rucknium]

@janowitz . https://libera.monerologs.net/monero-research-lab/20251126 is working again. I'll post the log in a minute.

[Rucknium]

Log

< rucknium > Meeting time! #1303

< rucknium > 1. Greetings

< emsczkp:matrix.org > Hi

< gingeropolous > hi

< jberman > waves

< ack-j:matrix.org > Hi

< preland > Hi

< vtnerd > Hi

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

< rucknium > me: Investigating medium- and long-term selfish mining countermeasures again. Looking at FCMP hard fork scaling parameters.

< gingeropolous > me: spinning up my scrap heap for fcmp stressnet testing. Hit a wall with monerosim re: mining shim, going to revert back to less perfect block controller

< emsczkp:matrix.org > wrote the ccs proposal "Bulletstar", renamed in Bulletproofs*

< jberman > me: FCMP++ alpha stressnet I shared a custom build that includes changes slated for v1.5 alpha stressnet to address OOM's, received a couple reports from people using that build I want to continue investigating (new sync issues), planning to put out a new CCS proposal soon

< preland > Continuing i2p bounty work, and personal research into more radical/general scalability paths.

< vtnerd > me: squashing a few things (bugs) in lws, adding a get_info (get_version) endpoint to lws, and working on lwsf lookahead (still a slight mess)

(removed)

(removed)

(removed)

(removed)

(removed)

< plowsof > redacted

< rucknium > (minimum power level to send messages here temporarily raised to 10)

< rucknium > (Ping me in #monero-research-lounge:monero.social if you need your power level raised.)

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

< emsczkp:matrix.org > Here I am, I'm the author of this CCS, thank you for this space

< rucknium > emsczkp:matrix.org: Thanks for joining the meeting.

< articmine > Hi

< rucknium > emsczkp:matrix.org: Would the proposed changes to the FCMP cryptography require a hard fork?

< ack-j:matrix.org > emsczkp:matrix.org: How does bulketproof* compare to your previous work on constant time range proofs?

< ack-j:matrix.org > https://moneroresearch.info/178

< rucknium > Do most of the efficiency gains occur with multi-input txs? How much benefit would single-input txs see?

< emsczkp:matrix.org > rucknium: No, the proposal is an improvement to the zkp proofs mechanisms behind FCMP

< emsczkp:matrix.org > ack-j:matrix.org: this is related to the question of if the Halo's modified IPA is compatible with that of BP in order to do accumulation, and the answer is no ... this research was trying to explore that direction

< ack-j:matrix.org > s/time/size/

< rucknium > So the planned FCMP hard fork could occur, then BulletStar added afterward without a hard fork?

< sgp >_ Thank you for making the proposal

< jberman > i.e. no modifications to the membership proof and range proofs used in FCMP++ txs would be needed, and the folding scheme would simply fold the existing proofs?

< emsczkp:matrix.org > rucknium: there is an asymptotic gain with folding as long as your computations grow, in single-input txs you should not see that

< emsczkp:matrix.org > jberman: We have to operate inside the underlying GBP proof and I would expect some modifications

< rucknium > According to my calculations (2019-2024), 54 percent of txs are single-input: https://gist.github.com/Rucknium/d2c02f51a2d9f103a28caa8f51be7dbf/

< preland > Interesting to see than only around 7% have more than 2

< jberman > as I understand it, a folding scheme would enable accumulating many single-input txs into a single proof. So it's not as though there would be no benefits for single-input txs in aggregate IIUC

< jberman > I think emsczkp:matrix.org was saying that standalone multi-input txs could benefit from a folding scheme too (if you're verifying a single 128-input proof e.g.)

< jberman > is that accurate?

< emsczkp:matrix.org > yes jberman, thank you for clarification. Multiple single-input txs can be aggregated and with folding we may enable an efficient proof batching

< jeffro256 > Howdy. Sorry I'm late. I'm working on organizing an audit for the carrot_core library and trying to pin down a draft for a potential PQ turnstile design

< jberman > basically this would complete this issue: monero-project/research-lab#110

< jberman > emsczkp:matrix.org: although slightly different in that we may not be able to accumualte the existing proofs

< rucknium > How would this work in practice? Users send txs to miners and the miners create an aggregated proof, then post the aggregated proof to the blockchain and throw away the individual proofs?

< jberman > not being able to accumulate the existing FCMP++ proofs is ok imo, this research direction is imo a critical avenue for a more scalable protocol nonetheless

< rucknium > Will this be quantum-resistant?

< jberman > rucknium: IIUC sounds like something like that would be possible. I imagine there would still likely be some archive nodes saving all individual proofs like kayabanerve:matrix.org mentioned in that issue

< jeffro256 > rucknium: You couldn't discard individual proofs w/o a hard fork, but perhaps a new node could skip downloading those individual proofs and just download/verify the aggregate proof

< datahoarder > jberman: pruned txs by default :), full node vs archival node time?

< rucknium > New nodes could do full chain verification without the individual proofs, right? Otherwise, it's not much better than simple pruning like we already have.

< emsczkp:matrix.org > rucknium: no, the folding security will rely on the underlying standard assumptions of GBP. But there are interesting research proposal moving towards PQ safe folding

< rucknium > kayabanerve:matrix.org suggested a moratorium on Monero cryptography research that is not quantum resistant. I don't necessarily share that view, but he did suggest that.

< sgp >_ I tend to prioritize PQ safe as well

< jberman > I think it would be a nice added bonus to consider PQ in this proposal

< jberman > But considering this is an independent researcher aiming to take ownership of this specific research direction in parallel, I don't think it would make a lot of sense to block it

< preland > What would be the implications of shifting to PQ in terms of difficulty/clarity of implementation? I wouldn't want PQ to derail the whole thing

< sgp >_ Yeah I definitely don't want to block it. It is a reasonable enough direction as-is. But practically, PQ safe is more important than efficiency with the existing assumptions, imho

< emsczkp:matrix.org > preland: First you need a PQ safe GBP, then if you want folding is another question. From my knowledge there is only one proposal doing recursive proofs in PQ settings

< rucknium > We need to move on to the next agenda item. Any more quick comments or questions for now? It will come back as an agenda item next week.

< jberman > I'm a strong +1, grateful for the submission emsczkp:matrix.org !

< rucknium > emsczkp:matrix.org: IMHO, it would be good to add to the proposal a description in even simpler language of the likely benefits for Monero.

< emsczkp:matrix.org > ok, thank you

< rucknium > Thank you very much for your work on this, emsczkp:matrix.org

< rucknium > I had to raise your power level, hooftly:matrix.org .

< rucknium > We had spam earlier.

< emsczkp:matrix.org > thank you again, see you next week

< rucknium > 4. P2Pool consolidation fees after FCMP hard fork. Coinbase Consolidation Tx Type (monero-project/research-lab#108).

< hooftly:matrix.org > Ah I figured something happend

< rucknium > Any more discussion on P2Pool coinbase output consolidation for now?

< DataHoarder > No updates from last week. I need to start making a flow diagram to present here.

< rucknium > Thanks.

< rucknium > 5. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-11.pdf). Revisit FCMP++ transaction weight function (seraphis-migration/monero#44).

< DataHoarder > However, it'd depend on 1-in zero fee txs (in-pool) with fallback normal txs (with fees) for no multisig agreement. I think this topic can sit on the sidelines until above flow is ready.

< rucknium > Let me ask if "delayed" fast scaling would be acceptable. Slow scaling parameters in effect for let's say 2 years after the hard fork, then the fast-scaling parameters in effect after that.

< articmine > I am going to cut to the chase here

< rucknium > This would provoide time to make the node code more efficient and some more technological progress in storage and CPUs

< articmine > What I see is that stressnet has uncovered serious vulnerabilities that requires time and resources to fix

< articmine > Many of the devs feel overwhelmed by the task at hand.

< datahoarder > rucknium: akin to ethereum's difficulty bomb, other way around? and worst case - the fast scaling can be soft forked if the code is not ready

< articmine > Fast scaling cannot be soft forked

< jberman > I see where you're headed with this articmine:monero.social , false statements so far

< articmine > What false statements

< jeffro256 > articmine: I think datahoarder:monero.social is saying that with the "delayed" scaling, you can soft fork away the fast scaling before it takes effect

< jberman > articmine: No one feels overwhelmed for starters. We are making progress

< datahoarder > articmine: I mean "limited", not added in. If fast scaling is seen as still bad then, it can be "patched"

< articmine > jberman: I know you are

< articmine > But are the timelines reasonable?

< jberman > What timelines? The prior timeline estimates?

< preland > articmine: To make sure we are all on the same page, what is the current timeline, as I've heard it thrown around a ton, but nothing from core or anyone in the know

< rucknium > IMHO, the poor performance of the node was already revealed during last year's mainnet spam and the first stressnet last year. It is only now that more dev effort has been applied to the problems.

< articmine > My point is that when is being proposed is to throttle scaling in an attempt to mitigate code vulnerabilities

< jeffro256 > It's been a while since (IMO since the divisors kink) we've had a real aligning about timelines

< preland > I think the last estimate I heard was Q1 '26, which seems too early

< jberman > articmine: Ack, heard on this point

< rucknium > How important is it to discuss timelines now?

< jeffro256 > I want to get a code audit for the carrot_core lib ASAP. FCMP++ Rust code already has most of the reviews it needs AFAIK. Then I think the FCMP++ integration code on the daemon side would be worth auditing. That can be done in parallel of carrot_core. We could modify hard fork table then?

< jeffro256 > Then HF activation is 6 months after that release

< sgp >_ jeffro256:monero.social let me know if you want help for the carrot_core audit(s)

< ofrnxmr > dont we hard fork testnet first, potentially stagenet as well to give some time for ecosystem to update

< ofrnxmr > arbitrary, but i dont think it has to be 6 months in advance

< jeffro256 > Yeah, that's fair. Testnet and stagenet don't need a 6month lead time tho

< articmine > I mean if my proposal with a 500000 byte minimum penalty free zone is not enough to address the vulnerability concerns then we have some very serious issues that have nothing to with scaling

< jberman > personally I'd like to complete the alpha stressnet (reach a point where alpha stressnet is running smooth under reasonable conditions), ideally within the next 4 weeks. and then reopen a conversation on target dates

< jeffro256 > That's fair, and can also be done in parallel to integration / crypto audits

< rucknium > Even with node code with zero inefficient "overhead", the proposed FCMP allowed block sizes would stress hardware. With 16MB blocks, which are allowed with quick scaling in articmine:monero.social 's proposal AFAIK, you can get 2466 1in/2out txs into a block, which would require 93 seconds on a single thread to verify. Accord [... too long, see https://mrelay.p2pool.observer/e/v7eH18wKbFd4dkxM ]

< jeffro256 > AFAICT, the remaining changes to be made to the stressnet wouldn't involve much FCMP++/Carrot crypto-specific changes

< rucknium > If an adversary tries to pack blocks, they can slow down verification further by selecting slow tx types.

< ofrnxmr > aside from the dropping connections, i think its running pretty well. Would like to see how mobile wallets fare with the tx volume. Dont want a zcash situation where wallets cant keep up

< jberman > rucknium: that proposal doesn't limit to 16mb blocks

< sgp >_ I'm more concerned with the max block sizes (and permitted growth) than the initial penalty free zone

< jeffro256 > ofrnxmr: Wallets really shouldn't be affected much if you assume daemons are working okay since they deal in pruned transactions, not full transactions

< DataHoarder > also saw last week, that a 128-in FCMP++ input is already larger than the block weight at minimum, which prevents these from being included unless block is grown (I guess if they pay more fees it could be worth it?)

< ofrnxmr > DataHoarder: I think this is due to incorrrecrly reported weight

< articmine > Then use the current scaling parameters with a 500000 byte penalty free zone and see what you get.

< articmine > It is far easier to test the stressnet with the current parameters than with my proposal that delays the scaling by over 2 months

< ofrnxmr > tx reports 132kb, but weight 700kb

< DataHoarder > yeah, then we have "Revisit FCMP++ transaction weight function" as part of this topic :) (which afaik agreement was byte size = weight?)

< jberman > feel free to correct this math articmine:monero.social, but if I'm calculating correctly the latest proposal allows blocks to grow to 611mb within 1 year 1000*(2^(365/100,000/720/2)

< articmine > sgp_: The lot term has va very negative impact on blockchain surveillance

< articmine > Long term

< articmine > I understand that.

< articmine > This is a totally different and very serious issue

< jeffro256 > ofrnxmr: block size is limited by tx weight, not tx byte size. So it would be limited under the current stressnet weight rules, but that is being changed for the next iteration of the stressnet

< articmine > My proposal can destroy blockchain surveillance

< jeffro256 > seraphis-migration/monero#232

< jeffro256 > Under this PR, its weight is approximately equal to its byte size

< ofrnxmr > jeffro256: Right, when i say incorrectly reported weight, i mean that the "weight roughly = to byte size" isnt in yet

< rucknium > jberman: jberman:monero.social: Is it 16MB blocks in the short term (100,000 blocks median)?

< jberman > articmine: 611mb blocks would destroy Monero

< ofrnxmr > jberman: 100.01mb blocks would destroy monero :P

< articmine > How?

< jberman > ofrnxmr: lol

< jberman > articmine: you would need a data center to run a full node

< jeffro256 > articmine: Nodes would not be able to sync / propagate faster than blocks are created. Storage requirements may become infeasible for particpants

< preland > jeffro256: "storage is free"

< preland > yeah, 611mb blocks would be an issue imo

< ofrnxmr > even storage r/w speeds would be crippled by receiving a 600mb block

< sgp >_ I think we should join together and submit a counterproposal. It's fine my initial idea isn't getting traction, but we should have another actual option that's considered good by multiple people instead of talking in circles on this one imho

< articmine > sgp_: I will be blunt. Conflict of interest

< jeffro256 > What is the conflict of interest of discussing new scaling ideas?

< rucknium > sgp_:monero.social: I don't know why you decided to start a blockchain surveillance firm. Baffling decision that will follow you forever.

< ArticMine > https://www.naxo.com/faqs

< preland > rucknium: have to second this lol; fireice_uk keeps giving me grief in the buttcoin discord server because of it xD

< ArticMine > Blockchain survelliance simple does ntot scale

< jberman > I think there is some general agreement short-term / medium-term larger blocks is ok, and general agreement besides articmine:monero.social that consensus allowing blocks in the hundreds of mb's within 1 year is not (ignoring the 100mb serialization limit)

< jberman > packet size limit*

< ArticMine > It is at least apparent conflict of interest as defined by the government of canada

< jberman > unless other people think blocks in the hundreds of mb's is ok?

< boog900 > ArticMine: We cant attract users by promising privacy if we get enough users.

< ArticMine > This is totaly separate from the issue of whethre Monero can handel certain trasnaction rates

< boog900 > Why not just used one of the many other coins and just try get their coin more users

< preland > jberman: I'd say this is a fair summary, though if anyone disagrees they should state it, because as it stands it'll be hard for anyone in the future to look back at this and come to a better conclusion

< ofrnxmr > I havr a 1tb data limit on my vps and my home network

< articmine > We need t make the necessary changes to allow Monero to be used

< rucknium > Is there a workable compromise to have hard fork scaling rules to allow fast scaling, but soft-fork rules has slow scaling? So the soft fork can be lifted or relaxed when it makes sense to do so?

< articmine > If a 100x increase in usage breaks Monero we have some very serious problems

< boog900 > Removing soft fork rules is a HF AFAIK

< articmine > boog900: I have to agree with this

< datahoarder > rucknium: it can be a continuous function (up to some sanity limits) that can be slowed/stopped via soft fork, but that way it's always "improving" faster at a defined rate, not specifically linear

< rucknium > Why would that be true? Miners just agree "after this block, the rules are relaxed"?

< ofrnxmr > rucknium: some miners will reject the blocks

< datahoarder > rucknium: someone could have not upgraded. suddenly, chain split

< ofrnxmr > Some nodes*

< articmine > In Bitcoin they tried this and it failed in 2013

< preland > rucknium: I like this idea on a basic level; the hardfork adds the switch, and soft forks are used to turn it from one to the other, though I agree that it isn't without critique

< boog900 > A soft fork is making rules tighter hard fork is making them looser

< datahoarder > you can always make things stricter, not broader, with softforks.

< articmine > boog900: It can work. We have to be very careful

< articmine > I must say that I am glad my hard line on scaling is exposing some serious problems

< rucknium > IIRC, Bitcoin Unlimited has this idea to let the bitcoin block size be unlimited, but allow miners to agree on a (short-term) limit. And miners would want that since propagation delays would increase their blocks' risk of being orphaned.

< jeffro256 > If we assume that we must hard fork in the future for either A) PQ crypto, or B) recursive ZK proofs, C) out-of-band proving (e.g. sheilded CSV), D) plain old FCMP efficiency improvements, or E) something else, we will have another opportunity in the future to adjust scaling parameters in the scaling-maximization direction kno [... too long, see https://mrelay.p2pool.observer/e/xrfU18wKaVY2X3ZL ]

< jeffro256 > I'm not convinved that increasing scaling parameters is do or not right now when there are popular proposals for much more radical changes in the future

< datahoarder > jeffro256: that ossification/untenable part is maybe why having a future date where it becomes enabled by default (unless something is done) might work to get things moving

< jeffro256 > Yeah, I don't dislike that idea

< boog900 > the difficulty bomb 2

< datahoarder > boog900: "past us build a bomb so we don't procrastinate now"

< jberman > I'm not a proponent of disparate scaling algos / a future bomb

< rucknium > Here is info on the Bitcoin Unlimited Excessive Block Size config parameter: https://medium.com/peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4

< articmine > I mean a soft fork cap on the block size cout be overridden by a 51% of the hashrate

< datahoarder > yeah, maybe difficulty bomb is a bad example, but something reasonable that all agree on ~2 years or whatever is set (and is not catastrophic)

< ofrnxmr > rucknium: I think the fluffy block fix, fixes the broadcast delay

< jeffro256 > articmine: Not really, unless you want 49% of the Monero ecosystem to split

< sgp >_ The problem is that the proposal allows catastrophic things. That's the core problem

< boog900 > yeah I would be ok with a future block size bomb, although I see most likely outcome that it is just delayed and we stick with the more security focused scaling algo

< datahoarder > ofrnxmr: with large tx pools that are segregated (not everyone has all txs) you still end up with large transfer of txs to get blocks accepted

< jberman > (I have to step away in 7 mins unfortunately)

< jeffro256 > In reality, even with a soft fork, you need a supermajority to not cause catastrophic damage to the economy built around your network. You want opposing the soft fork to be so disastrous that no one does it

< ofrnxmr > But what if you're qubic and want to do it for fun?

< articmine > With all due respect the danger of ossification is real

< preland > ofrnxmr: beat me to it lol

< datahoarder > jeffro256: reverse block size scaling? where blocks become smaller until it's catastrophic even without 100x growth

< articmine > Remember what Satoshi said in 2010

< articmine > I mean we can leave the parameters as they are

< boog900 > I think you are the only one that thinks current scaling is anywhere close to safe

< rucknium > boog900: Is this true? Anyone want to say that current scaling is anywhere close to safe?

< preland > rucknium: Define safe in this context

< datahoarder > ofrnxmr: the only reason qubic didn't do it with their tx spamming on the side was they had their own dumb technical limitation to 896 byte block header size, so they could only attach like ~20 txs per block tops

< jeffro256 > I like the current scaling TBF

< boog900 > preland: allows us to react fast enough to someone producing max size blocks to prevent nodes falling out of consensus

< rucknium > preland:monero.social: You can define it as you like. Qualify your statement.

< ofrnxmr > jeffro256: Getting to 40mb in under 48hrs? Without max fees?

< ofrnxmr > I think the current scaling shouldnt allow such growth speeds with just lvl 3 fees. Its almost free

< datahoarder > is it capped to max size blocks? or is it unbounded? if it can reach 100 MB net. limit within one or two weeks, that's catastrophic. Just one or two MRL meetings to talk!

< jeffro256 > boog900: I think that it does do a decent job at it. Yes, you can spam, but you have to stay very very consistent and continually burn XMR to increase block size

< jberman > I intend to make a more detailed comment responding to articmine:monero.social 's latest comment, but here are some things to think about in the mean time:

< boog900 > jeffro256: You just need mining power

< jberman > * The most significant parameter in the proposal/algo is the long term median max growth rate of 2x

< jberman > * This value is what determines how large blocks can grow to over the long term

< ofrnxmr > jeffro256: you dont have to spend very much, and if you control a mining pool, you can earn your losses back by forcing othera to outbid you

< jberman > * Reducing that back to 1.7x and keeping everything else the same, max block size w/in 1 year = 260mb

< rucknium > IMHO, it doesn't make sense to have scaling that would require "manual" intervention. Just set the scaling parameters correctly from the start.

< jberman > * Reducing back to 1.4x and keeping everything else the same, 94mb

< jeffro256 > boog900: Okay fair, but you're still paying an XMR opportunity cost

< boog900 > you can pad blocks with useless data to make them huge, and or you can set txs to 0 fee

< jberman > The current scaling algo in consensus today allows for blocks to grow to 244mb

< datahoarder > ofrnxmr: and IF selfish, can attempt to remove light blocks

< ofrnxmr > I have 200xmr on stressnet and can get blocks to 14mb in 720 blocks and atill have ~200xmr

< articmine > We must not rely on a future hard fork

< boog900 > jeffro256: we have seen an entity recently reduce their XMR reward just for some advertising

< boog900 > what about an entity who wants us dead?

< jeffro256 > jberman: what causes the 244mb cap?

< ofrnxmr > opportunity cost like $1500

< jberman > jeffro256: check this spreadsheet for the calculations: monero-project/research-lab#70 (comment)

< jberman > that shows which params affect the calculation

< preland > ofrnxmr: what if we publically offered like $30 in xmr to an individual who could increase the stressnet blocksize the most

< boog900 > jeffro256: 2 days of mining is 864 XMR

< spackle > Another thing that would have serious impact would be extending the long term median window.

< jeffro256 > boog900: An entity who wanted to cripple Monero would probably go for a 0-tx block strategy IMHO. It's more resource-efficient

< datahoarder > preland: this was being talked about in #monero-research-lounge:monero.social :)

< jberman > spackle: that's true

< boog900 > jeffro256: that would only pause us, nodes falling out of consensus allows double spends

< ofrnxmr > jeffro256: 0tx 51% attack is harder than havinf 51/100 blocks at max size til you pass setialization or packet limits

< jberman > extending the long term median window actually has a very significant impact

< ofrnxmr > At which point the chain is cooked

< jeffro256 > boog900: Fair

< preland > jberman: Probably a dumb question, but how long would it take roundabouts for the size to drop back down to a sane level after reaching the 244 peak

< ofrnxmr > ofrnxmr: And this only takes like 2, maybe 3 days?

< ofrnxmr > preland: Short term = 51 blocks

< boog900 > current mainent would last way less than 2 days

< datahoarder > jberman: Existing miners can pad blocks right now up to that size for "free", fill the rest with legit txs, without getting into penalty zone (point being to always be at the limit of penalty zone), and extend the median free

< preland > ofrnxmr: oh right

< jberman > have to step away, sorry :/

< rucknium > We are almost at 2 hours. IMHO, discussion participants need to see if a compromise is possible and what that compromise would look like. Be creative. If a compromise can't be reached, then that's unfortunate, but sometimes it's like that.

< articmine > I was also called out

< gingeropolous > i think extending the long term median window should be investigated

< gingeropolous > this forces the market, or the attacker, to really justify the blocksize increase

< articmine > A couple of things

< articmine > 1) If the spam is not maintained the short term median resets at 50 blocks.

< ofrnxmr > gingeropolous: How does this do anything to stop the short term 50mb blocks?

< articmine > 2) The rate of growth and decline of the long term median is the same

< articmine > The whole idea behind the long term t was to kill the spam. This is why a ZCash like spam attack I Monero does not work

< articmine > So we limit the growth of the short term median to 16x and the block size also to 16x of the long term median

< articmine > This t what my proposal does

< gingeropolous > and what do those numbers give us in worse case scenario. 100MB blocks in 2 days? 100MB blocks in 1 year?

< articmine > Now that the conflict of interest has been exposed, maybe calmer heads will prevail and we can work on consensus

< rucknium > 6. FCMP alpha stressnet (https://monero.town/post/6763165).

< ofrnxmr > 1.5 hitting some small delays due to nodes dropping all connections

< ofrnxmr > If note, there were also 2 or 3 reports from people on 1.4 also dropping connections, and some "invalid block" logs. So maybe coincidence?

< jeffro256 > Are you running v1.5?

< ofrnxmr > I am

< ofrnxmr > No issues on my end

< DataHoarder > ofrnxmr: if "invalid block" logs are around that specific invalid miner tx, that's an old issue

< ofrnxmr > I dont think it was that one

< gingeropolous > yeah i got a node fully syncd on 1.5

< jeffro256 > Yes, there's still the issues of connections dropping

< jeffro256 > Probably a better long term approach for debugging would be to have the nodes send a reason for dropping beforehand

< rucknium > Opt-in and/or stressnet/testnet only? Could a mainnet adversary find that info useful?

< ofrnxmr > Otherwise, things seem to be pretty smooth. I have some 0 value amounts in wallet (probably result of sweeps) that i think might be slowing down wallet sync.

< ofrnxmr > rucknium: The reasons for dropping connections are usually logged on lvl 2 aiui

< DataHoarder > rucknium: it could be used to detect versions, if behavior changes, or find details about the "internal" state to find propagation

< DataHoarder > if you mean giving the reason to other peers

< jeffro256 > rucknium: Yeah def opt-in only. Since we use TCP connections, sending a message and then verifying it reached the destination requires communication from the other end which is a DoS vector.

< DataHoarder > +1 for it being opt-in, though. that way operators can choose

< ofrnxmr > https://matrix.to/#/!sgiUzbrYPvMAvwQKTG:monero.social/$D1N9WP_TIfgtrYVGN---YXQeobf_ZcFP7asXRiZ9cYA?via=monero.social&via=matrix.org&via=nope.chat datahoarder - different block

< DataHoarder > (also, it should be not be freeform, or it may be abused to display messages on other nodes with high loglevel.)

< DataHoarder > not as bad as this, but similar spesmilo/electrum#4968

< rucknium > Anything more on stressnet?

< rucknium > 7. Post-FCMP scaling concepts.

< preland > (copy paste inbound)

< preland > Thank you. There are two ideas that I have been looking into in terms of scalability. The first is a more ambitious “federation”-style approach to scalability.

< preland > This would have the blockchain and network autonomously split into smaller sub-networks once a certain threshold has been met. The result would be an effectively infinitely scalable network. The main challenges I’ve found would be ensuring that two sub-networks can trivially prove that each other have been following proper p [... too long, see https://mrelay.p2pool.observer/e/yJrq2MwKYlUtNm5R ]

< preland > I’ll continue looking into that, but for now I’m mainly focused on the other idea I’ve been looking into, which is adopting a quorum consensus model similar to how Qubic’s operates (with significant modifications made to its implementation). This would allow for transaction scaling to be increased to an incredib[... more lines follow, see https://mrelay.p2pool.observer/e/yJrq2MwKYlUtNm5R ]

< rucknium > Is the first one similar to sharding?

< preland > Yes

< datahoarder > preland: Note Qubic's model depend on a centralized arbitrator to kick computors out, which they have done a few times and one last week. No specific reason is needed, but they claim to have found collusion

< datahoarder > The comparison with their model is maybe not desired, as it's, mainly centralized across several layers

< preland > datahoarder: Correct; this is one (of many) things that have been switched out

< preland > datahoarder: It's what inspired my initial look into it, which is why I mention it, even if it isn't entirely deserved tbh

< datahoarder > preland: They'll use any mention for marketing :)

< datahoarder > On that topic, they recently changed how all of that works regarding txs, and changed how fast they tick, and changed it back again, and later changed how txs work again.

< ofrnxmr > Isnt the former similar to how pruning currently works

< ofrnxmr > Except, instead of infinite, there are 8 different shards (stripes)

< rucknium > A pruned 1in/2out FCMP tx is about the size of a 1in/2out bitcoin tx, FWIW. Learn to love pruning.

< preland > ofrnxmr: not exactly; each subnetwork would be a distinct network in and of itself, and the networks would be able to interact with each other through some sort of transfering

< preland > the main upside to it wouldn't be in storage per se, but in tps scaling

< rucknium > Or don't. You don't have to love pruning if you don't want to. But it's very useful (and the default when you launch a Monero node from the GUI wallet now).

< datahoarder > if I understand, to "prune" a subnetwork you'd have to aggregate its state in a proof -> to then join the others and "close" aka prune it?

< preland > datahoarder: From what I've seen so far that seems to be the case

< datahoarder > all that would be left of that subnetwork would be that proof, which participants can create new transactions against

< datahoarder > in (again Qubic) case their "pruning" is due to being a balance based system. So they just aggregate current state, delete everything else, and also, delete some inactive (but with active dust) and zero-balance accounts

< rucknium > https://mrelay.p2pool.observer/m/monero.social/FpALSKRIlOlUVUhFgNWuHkRi.ods (carrot_fcmp_pruned_tx_size.ods)

< rucknium > ^ Pruned FCMP tx size table, created by jeffro256:monero.social 🧡

< datahoarder > this is how they claim to be "more private than Monero", too bad anyone can just archive the network :). How does this work for an UTXO based system, without clear spend tied to each UTXO? Using an accumulator (a-la UTREEXO?)

< preland > datahoarder: The equivalent pruning would be using zk rollups

< rucknium > It was posted in the #no-wallet-left-behind:monero.social room: https://matrix.to/#/!PAAeACCTzofUENRcqJ:monero.social/$1QQzyPyFKw0XrNZH3p0t-a4Wgxi4EhstRKq3ir6tJqw?via=monero.social&via=matrix.org&via=tchncs.de

< preland > As you pointed out, the comparison to Qubic is not exactly an apt one admittedly; there are a number of attributes and "quirks" in Qubic that cannot be tolerated whatsoever in Monero, and a number of features that just don't make sense (like UPoW)

< articmine > I have to leave bow

< datahoarder > the lack of decoy indices adds up, it's just a list of key images -> outputs! > A pruned 1in/2out FCMP tx is about the size of a 1in/2out bitcoin tx, FWIW. Learn to love pruning.

< datahoarder > on that topic, would it make sense to have a V3 tx format, that removes the need to serialize inputs with empty vectors of offsets / input type / amount?

< rucknium > If you are curious about how many pruned nodes you have to have to make sure you have all 8 slices/stripes, I have the numbers and formula in Appendix B here: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-optimal-fee-ring-size.pdf

< rucknium > Code: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/code/pruning-slices-collectors-problem.R

< jberman > I think it's possibly unrelated to anything in v1.5. I have complete logs of the issue on my end and a first look looks like an issue that triggers when the pool actually does exceed the max weight > If note, there were also 2 or 3 reports from people on 1.4 also dropping connections, and some "invalid block" logs. So maybe coincidence?

< jberman > I haven't had the chance to dig yet

< datahoarder > the overhead for FCMP++ of "unused" data per input is 1 byte for type, 1 byte for amount, 1 byte for len of offsets. so 19 total, 15% overhead per input. ofc, pruned.

< ofrnxmr > jberman: I pinned a log from 1.4 release with similar issue

< ofrnxmr > jberman: Yeah. The pool was > 600mb , filled with 128 input txs that couldnt be mined

< preland > I am going to continue looking into this further, as I think that this would be an interesting path for Monero to take once FCMP++ has been implemented and related issues have been addresssed. I'll plan on continuing my work and progress in the https://github.com/preland/xmr-republic-docs repository; if there are any issues of [... too long, see https://mrelay.p2pool.observer/e/j4qz2cwKbmU4N01N ]

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

< ofrnxmr > ofrn questions:

< ofrnxmr > 1. Randomx v2 <- are we hoping to ship this with fcmp hf?

< ofrnxmr > 2. Should we increase the default txpool limit by 4x? Also, are we sure eviction works properly? Are txs added back when the txs are re-received from peers?

< ofrnxmr > 3. Is 72hrs a sane expiry for valid txs?

< preland > Thank you

< datahoarder > ofrnxmr: 1. AFAIK the commitment part is done, but not a change in parameters to tweak towards modern hardware

< ofrnxmr > But is this on the todo for fcmp hf? Or not planned? Should it be?

< datahoarder > proposal for v17 monero-project/monero#10038 and monero-project/monero#8827 which is listed under seraphis-migration/monero#53 "RandomX commitments w/double hashing" under "Daemon features"

< datahoarder > that might be nice to see on beta stressnet :)

< plowsof > thanks, i forgot to ask if https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/626 would be funded with the FCMP++ research fund? kayabanerve jberman

< kayabanerve:matrix.org > I find the work emsczkp: is proposing interesting, and the rate reasonable.

< kayabanerve:matrix.org > It is not in scope to the existing fcmp++ research fund, thought that is handed over to the mrl upon resolution iirc.

< ofrnxmr > datahoarder: Thats not v2 thougg

< ofrnxmr > tevador/RandomX#274 datahoarder

< DataHoarder > that's what I mean, "commitment part is done, not change in parameters"

< DataHoarder > about actual v2 parameters, poke sech1 for context :)

< jeffro256 > Personally, I think that the commitment portion is the most important

< jeffro256 > I am neutral to the other virtual machine changes

< spackle > You set the default median and surge factor to limit the size of the short term blocks, and you set the long term median window to keep that limit in place for a known duration. > How does this do anything to stop the short term 50mb blocks?

< spackle > In combination, this establishes that no blocks larger than X MB shall be created in the next Y blocks.

< spackle > Which is the clearest and simplest path to giving the scaling design a safety specification, at least as I see it.

< spackle > Rather, that IS the safety specification that exists which should now be brought into alignment with the realities of the software.

< articmine > spackle: My proposal

< articmine > If you want to stop 50 MB short term blocks

< articmine > How much are t willing to pay for a 50 MB block on mainnet?

< spackle > A steady stream of 50 MB blocks will cripple the network, and should not be produced in the short term at any price IMO.

< articmine > How much do you think it would cost to spam a 50 MB block on mainnet under my proposal at current XMR / USD rates

< articmine > Just one block

< articmine > ... and how long will it take?

< spackle > I am not interested in making the price prohibitive, I am interested in prohibiting the condition entirely.

< articmine > Price in USD or XMR

< articmine > spackle: Then this is the wrong chain for you

< articmine > One needs a chain with a fixed blocksize. That is not the Monero social covenant

< spackle > You misunderstand me, nobody is discussing a long term hard limit on block size. I am discussing short term behavior and safety specification.

< spackle > The difference we are discussing is between putting a price tag on breaking the network, and preventing the network from breaking entirely.

< articmine > Then answer my how long question

< spackle > That is for people to come to consensus on, not for me (or you) to dictate.

< articmine > Define short term because

< spackle > I see short term as the length of time it takes to adjust the long term median, currently 50000 blocks.

< articmine > With my proposal the maximum allowable block starting at 1 MB is 16 MB

< articmine > So problem solved

< spackle > If there is agreement that 16 MB is the correct value. I have not yet seen that happen, and I believe we are waiting for further input from the stressnet at this time.

< articmine > Please read my latest proposal

< articmine > There is a lot of FUD and yes even conflict of interest

< spackle > I have read and understand you proposal. Allow me to restate and clarify my position: The safety specification for the scaling design is that 'no blocks larger than X MB shall be created in the next Y blocks.'

< spackle > Get agreement on the maximum size X, get agreement on the length of time Y, and the job is done.

< spackle > *your proposal

< articmine > X = 16 MB Y = 50000

< articmine > Start ing blocks before the 50000 under 1 MB

< spackle > Yes, those are the numbers you have independently chosen by yourself. My understanding is that we are waiting for further stressnet results before agreeing on these values.

< articmine > I originally had 32 for X and later modified it to 16

< spackle > Again, values you chose yourself without input from testing.

< spackle > Last I heard jberman said he needed to review the 16x cap in totality with the proposal

< spackle > I will wait for others to speak up, I am sure conversation will continue.

< articmine > 16 had input from testing

< articmine > As for the 1.7 growth rate for ML it was chosen at the last fork by an individual who has a conflict of interest

< spackle > I don't think so, it was thrown out by one person as a more reasonable option than 32. I did not see hard empirical reasons or consensus backing it.

< articmine > My original proposal at the time was 2

< spackle > I am happy to be proven wrong, and if you would like to list the reasoning or people who had consensus on that value I think that would be helpful.

< spackle > If that is the case, then I would like to see that discussed thoroughly at the next meeting.

< articmine > At the time I worked on issue 70 with Koe. We came to consensus. The fee structure was based upon 2. It was at the last moment that the change was made

< articmine > One can read all of this on issue 70

< articmine > The fee structure is still based upon 2

< spackle > Was any practical testing of the daemon considered in your discussions with Koe?

< articmine > I am talking like 5 years ago

< spackle > What I have seen from the stressnet would indicate that was not the case.

< articmine > spackle: I agree

< spackle > Indeed, so the scaling was set without empirical feedback. Now is the time for that to happen.

< spackle > Right now we are waiting on feedback, as I understand things.

< articmine > I am actually shocked as to has been revealed in the Stressnet

< articmine > I also don't know when the fatal bugs were introduced

< articmine > What I do know is that the scaling was way more aggressive in 2014

< articmine > No Long term median

< articmine > Just the short term median

< spackle > Also way more disconnected from reality.

< articmine > The long term median was introduced in 2919

< articmine > 2019

< articmine > Like I said I am glad we exposed the conflict of interest so we can work on this in a sensible way

< articmine > We got a lot acct in the last meeting

< articmine > accomplished

< articmine > We have to get to the bottom of the bugs, t risk assist with them, how long they will take to fix, what resources are needed etc

< articmine > We have to get to the bottom of the bugs, the risk associated with them, how long they will take to fix, what resources are needed etc.

< articmine > Sorry I hate phones and their useless AI

< articmine > Then we can connect with reality

< articmine > We also given the seriousness of the situation need to make sure that the feedback is not influenced by conflicts of interest

< spackle > My opinion is that consensus is reached when informed persons can affirmatively state:

< spackle > 1.) YES, the network can handle a steady stream of blocks that are size X.

< spackle > 2.) YES, we can respond, and adapt the network, to handle what may arise in the future over time Y.

< spackle > Others have discussed longer term values, such as what the block size may become in a year. I leave it to them to make their case.

< articmine > spackle: I agree

< articmine > spackle: This is where the cost of spam becomes paramount

< spackle > Then indeed we are in agreement, including that X=16MB and Y=50000 blocks are not yet settled values. I have yet to see anyone affirm those statements with those values.

< articmine > One important aspect of testnet is that the current. short term aggressive scaling should be used with the FCMP++ sizes and verification times.

< articmine > Otherwise it will take months if not years to spam up the testnet, with my proposal

< articmine > This is by design. I deliberately designed it to frustrate and increase the cost of spam

[janowitz]

Thank you, @Rucknium

Unfortunately I was not able to attend the meeting, and I am aware my comment is not being considered here, but maybe someone will read this. I am one of the few being fully with ArticMine.

According to my router stats, last month I roughly received 4TB of data and sent 1TB. So receiving would be around 150 GB a day, so accordingly a block with 200 MB every 2 minutes. Nielsens's law shows bandwidth is growing by 50% per year and should be roughly x50 the bandwidth of 10 years ago. The average user is streaming 4k content with up to ~50 Mbit/s and downloading a 1 GB block would take 8 seconds on a 1 Gbit/s connection under perfect circumstances.

Storage prices are as low as never before, and SSD is about 1/30 of the cost 10 years ago, most probably becoming even cheaper than traditional HDDs in the next few years https://ourworldindata.org/grapher/historical-cost-of-computer-memory-and-storage
Maybe Monero should add more than 8 "slices" for pruning nodes like 32 or 64 and allow users to choose how much they want to hold, including zero making a pruning node not a source for initial sync any more. I think the network is resilient enough at this point to do this.

The only concern I'd have is the verification, which should remain feasible to accomplish on average hardware. I don't think we should necessarily look at Raspi or low-end VPS even if we might lose some nodes. So I'd argue an average CPU with maybe 20 threads should be able to keep up syncing at any time. For mining, most rely on pools anyway, which most probably have way better hardware, and with fluffy blocks, they have only little overhead to download after a block is created.

We shouldn't make the same mistakes as Bitcoin, when it had its momentum in adoption from large merchants like Microsoft starting to accept Bitcoin in their stores in 2014, but the blockchain became clogged, and Bitcoin has been removed again from all those. Nowadays blocks don't even get full because people have been mostly driven to custodial solutions, which can't be our goal. According to public statistics from merchants like Shopinbit or Coincards, literally nobody uses LN, and Monero is becoming dominant wherever it is accepted. Discouraging growing organic usage would be fatal for Monero.

Bitcoin became successful anyway, however not as a medium of exchange but as a projected store of value (which I doubt but doesn't matter here). Monero doesn't have this opportunity, since after delisting and more and more strict regulations, we can't rely on institutional investors or ETFs to pump the price short term. We need organic adoption, and like articmine stated, we should be prepared to scale by x100 at any time.

[MoneroArbo]

So I'd argue an average CPU with maybe 20 threads should be able to keep up syncing at any time.

I don't think that's average. According to Valve the most common CPU has 6 cores / 12 threads. The percent of people with 20 threads or more is about 27%. 15% of users have 8 threads and almost 29% have 12 threads.

These numbers are probably actually higher than average since it's a survey of people who use their PC for gaming.

I've been testing FCMP on an older laptop (10th gen i5) with 8 threads (4 cores) and 10 MB blocks already can take 10-20 seconds per block to verify. A single 128 input transaction verifies in about 12 seconds.

edit: I do agree with you generally but for me the target would actually be "below average CPU" because I know a bunch of people don't have access to good hardware, or Internet for that matter, but Monero is important for them too. If the goal is peer to peer cash, accessibility is key.

[janowitz]

I don't think that's average. According to Valve the most common CPU has 6 cores / 12 threads. The percent of people with 20 threads or more is about 27%. 15% of users have 8 threads and almost 29% have 12 threads.

Thank you for this link, interesting data!

I've been testing FCMP on an older laptop (10th gen i5) with 8 threads (4 cores) and 10 MB blocks already can take 10-20 seconds per block to verify. A single 128 input transaction verifies in about 12 seconds.

Okay, large input tx might become a problem at some point, since there could be ~65 tx with 150 kB size each in a 10 MB block. With 8 threads it would take around 100 seconds to verify those according to your figures on this hardware. But looking at verification times with more and more inputs, it's pretty linear with the amount of inputs, however not with tx size and maybe weight should increase with every additional input not to discount malicious actors for creating tx with max amount of inputs. But it seems this has been reverted back to byte size.

I will join stressnet, too to test a bit for myself asap.