<reject-all:matrix.org> In regards to this BS stuff, Is monero moving towards nodes only on data centers and high-end infrastructure?

<elongated:matrix.org> @reject-all:matrix.org: If it’s heavily spammed yes

<reject-all:matrix.org> If users are unable to run a node (without access to data centers, high-end equipment) does this threaten the decentralization (and therefore the censorship resistance) of Monero?

<ofrnxmr:xmr.mx> @reject-all:matrix.org: Obviously

<ofrnxmr:xmr.mx> Or (less rude) by definition, yes.

<reject-all:matrix.org> So you would say it's a requirement for the 'common' user with consumer hardware and typical bandwidth limitations to be capable of running a full node, and if otherwise Monero won't be a decentralized/permissionless?

<reject-all:matrix.org> Is this sufficiently being taken into account with regards to BS/scaling?

<reject-all:matrix.org> @ofrnxmr:xmr.mx

<ofrnxmr:xmr.mx> i wouldnt say a requirement, but a preference

<ofrnxmr:xmr.mx> Currently monero is running quite well on stressnet with 10+ mb blocks, including a couple old, hdd, quad core systems and a single core 2gb ram vm

<ofrnxmr:xmr.mx> As far as bandwidth, no. I don't think monero aims to support limited bandwidth, though we are working to reduce bandwidth by upwards of 70% from current

<ircmouse:matrix.org> New Monero research paper just dropped! "Inside Qubic’s Selfish Mining Campaign on

<ircmouse:matrix.org> Monero: Evidence, Tactics, and Limits"

<ircmouse:matrix.org> Link: arxiv.org/pdf/2512.01437 (arxiv.org/pdf/2512.01437)

<ircmouse:matrix.org> Credit to @ack-j:matrix.org for pointing it out in the MRL channel. Didn't see it posted here so wanted to share.

<datahoarder> ^ I commented about this paper in MRL channel. TL;DR, they had limited/not granular data, estimated similar numbers as we did empirically from granular data

<elongated:matrix.org> @ofrnxmr:xmr.mx: How much storage does these “old” systems need to have ? To be future proof for 3-4yrs

<reject-all:matrix.org> @ofrnxmr:xmr.mx: Interesting, I'll try and get setup with stressnet on my PC.

<reject-all:matrix.org> But I do find something a bit unclear:

<reject-all:matrix.org> Users able to run full nodes without data centers/high-end equipment is by definition decentralization/censorship resistance.[... more lines follow, see mrelay.p2pool.observer/e/5fvFs88KeDRoR29V ]

<ofrnxmr> Dependa what you define as "common user" and "consumer hardware" and "typical bandwidth"

<datahoarder> @reject-all:matrix.org: there's a future with aggregated proofs that would allow a mixed version of pruned/full/archival. One where it downloads pruned txs, but each block has an aggregated proof that fully verifies the transactions. Archival nodes would keep the per-transaction full proofs, but they aren't needed for these lighter full verification nodes.

<datahoarder> Storage and bandwidth requirements for these would be vastly lower

<ofrnxmr> tevador's proposal seems to intend to keep up with "consumer hardware" advancements

<ofrnxmr> For full/archival nodes

<ofrnxmr:xmr.mx> @elongated:matrix.org: future proof with 10mb blocks = 3tb for year 1 :)

<elongated:matrix.org> @ofrnxmr:xmr.mx: Isn’t the consensus 100mb limit ?

<elongated:matrix.org> Just assuming some agency has its life mission to spam xmr 😅

<elongated:matrix.org> 30tb/yr ? With 100mb limit

making it highly centralized due to storage/compute/bandwidth costs -> then strike the central locations :)

<ofrnxmr:xmr.mx> @elongated:matrix.org: 100mb is the packet size limit, wont be hit for 6yrs under tevador's or articmines proposals

<ofrnxmr:xmr.mx> Yeah, ppl yelling fud about 90mb limit dont realize that 90mb is 65gb per day

in chain data* the limit can strike due to other factors

<elongated:matrix.org> @ofrnxmr:xmr.mx: Thx to artic fans

<ofrnxmr:xmr.mx> i dont even think artic fans, just ppl who are claiming that im "breaking a promise" "for no reason"

<ofrnxmr:xmr.mx> Pointing to getmonero's retarded faq as proof that monero blocks are currently "unlimited"

People don't realize we use size_t and not arbitrary precision integers for packed and block sizes

can't even go past uint64_t block sizes!

<ofrnxmr:xmr.mx> getmonero.org/get-started/faq/#anchor-block-limit

<ofrnxmr:xmr.mx> > No, Monero does not have a hard block size limit. Instead, the block size can increase or decrease over time based on demand. It is capped at a certain growth rate to prevent outrageous growth (scalability).

<elongated:matrix.org> @ofrnxmr:xmr.mx: Needs to be fixed

technically there is a cap even if we send packets less bad

if block header itself reaches packet limit :)

100 MiB block headers would be ... interesting

just about 3 million tx hashes

<ofrnxmr:xmr.mx> WHY ARE YOU BREAKING MONERO'S PROMISE! DATAHOARDER IS A FED WHO IS TRYING TO HIJACK MONERO

1 exabyte (2^63) block size :)

<ofrnxmr:xmr.mx> has anyone looked to see if zano has the packet limit?

damn, you can no longer address the storage of the world in a single uint64

<rbrunner7> After reading this, and the Twitter thread it links to, I fear we could be near a total breakdown of any sensible discussion about block sizes. Out go technical arguments and sound logical reasoning, and emotions totally rule the day: old.reddit.com/r/Monero/comments/1p…ill_be_the_only_contender_for_sound

<rbrunner7> (There is currently a very detailed response to my comment from ArticMine caught in some filter, waiting for release.)

> This is all really strange considering that the current average block size is 100 kB and it's not possible to up it up to anything really big in a fast manner.

stressnet disagrees

<rbrunner7> Say, how much would it cost to produce a valid 50 MB block, mine it, and bring the network down with it? Can't be more than a few thousand dollars, I would guess? If I was rich I would be tempted to do that as an attempt to bring people to their senses.

yeah the temporary part (like, not even has to make it to the hardfork if fixed before) has been totally lost to the wind

if it's a miner, rbrunner7, effectively "free"

even better if they do 51%

they can pad their own blocks with txs to grow the median for free

<rbrunner7> Ah, yes, of course, because you get your expenses back :)

without majority hashrate you still need to spam, but you can get some better efficiency if you are already a mining pool

pad what you can and spam the rest

<rbrunner7> Maybe we can win over M5M400?

<elongated:matrix.org> @ofrnxmr:xmr.mx: They are safe with 0.01 zano tx fees

funnily qubic was padding their blocks with withheld txs

<ofrnxmr:xmr.mx> zano = 100mb (same code as monero) github.com/hyle-team/zano/blob/mast…%2Finclude%2Fnet%2Flevin_base.h#L90

<ofrnxmr:xmr.mx> And 50mb p2p github.com/hyle-team/zano/blob/mast…rency_core%2Fcurrency_config.h#L141

... but the max number of txs they could mine was, 20.

<rbrunner7> No, seriously, I think there are people right now that can only return to their senses quickly by hitting them on the head with a hammer.

so literally qubic had set a hardcoded limit into how many transactions could be included

zano 50mb limit!!!!

actually, we also do have 50mb packet size

and 100mb for levin

<rbrunner7> Yeah, but anyway not a contender for "sound money", so ...

MAX_RPC_CONTENT_LENGTH = 1048576 // 1 MB

DEFAULT_RPC_SOFT_LIMIT_SIZE 25 * 1024 * 1024 // 25 MiB

<ofrnxmr:xmr.mx> github.com/monero-project/monero/bl…ster/src%2Fcryptonote_config.h#L141

<ofrnxmr:xmr.mx> monero has that same 50mb line

so maybe we are worse than we thought :)

in a worse place than*

<rbrunner7> Don't think you can get away with "unlimited logical block size, with a limit of 100 MB for individual block parts". See the word "limit" in there? That will be enough for people to freak out :)

block parts = txs

which is already bounded

<ofrnxmr:xmr.mx> Rbrunner, you didnt read getmonero.org? Blocks are unlimited

#define CRYPTONOTE_MAX_TX_SIZE 1000000

oh also

#define CRYPTONOTE_MAX_TX_PER_BLOCK 0x10000000

^ also size limit

<ofrnxmr:xmr.mx> oh thats racist

<rbrunner7> I am stealth "small blocker", what do you expect.

that is 2^28

<ofrnxmr:xmr.mx> you have to change that to infinity

1000000 * 2^28 bytes to TiB = 244 TiB blocks

yet another limit

<rbrunner7> Well, maybe we could live with that limit if we drop blocktime down to 1 second.

<rbrunner7> More transactions that way.

bring it down enough that speed of light and distance starts making 10+ blocks orphanable so all miners need to coexist the same server rack

<kayabanerve:matrix.org> If we had asynchronous consensus, blocks could be produced per throughput, not an arbitrary time interval.

<rbrunner7> Note to self: If people around me throw reason and logic overboard and act almost purely on emotion, it doesn't help if I do likewise as my reaction to this happening.

With the current monerod limitations, miners will start limiting block sizes way before 100 MB

I mean performance limitations

Qubic even mined empty blocks for a while to be "more efficient"

P2Pool has a packet size limit of 128 KB which limits it to max 4k transactions per block

<gingeropolous> we need to build a fab

<sgp_> lazy developers need to do their job reddit.com/r/Monero/comments/1peug7…o_developers_are_on_track_to_add_an

<sgp_> shame on you all for prioritizing fcmp++. We all know that will lead to way worse privacy than simply allowing big blocks. shame!

<rbrunner7> A sad day for Monero. I can hear Monero's enemies rejoice.

<sgp_> This scaling death cult was a sleeping issue all along unfortunately. These network vulnerabilities finally being challenged is a step in the right direction

<rbrunner7> I would like to see LMDB manage a multi-terabyte blockchain file. Would be an interesting exercise.

<syntheticbird> @rbrunner7: LMDB2: eletric boogaloo when

<boog900> I am happy to see some push back on reddit, starting a propaganda war is stupid.

<ofrnxmr:xmr.mx> so.. wen serialization limit fixes? 7999 8867 9433

<boog900> cuprate has already done it :p

<ofrnxmr:xmr.mx> Since those limit blocks to ~30mb

<ofrnxmr:xmr.mx> @boog900: Right, but were fussing about 100mb genesis when we have a 30mb limit added in 2020

<ofrnxmr:xmr.mx> Thats been fixed since like 2021

<boog900> I am really surprised it has taken so long for 9433

<boog900> like the others I kinda get taking a while to review and whatever, but that should be a simple change.

<ofrnxmr:xmr.mx> Considering 9433 is just a stop-gap/bandaid, im also surprised that it hasnt yet been reviewed/merged

untested, removed the never used txin/txout values irc.gammaspectra.live/b11e6d8f7bdf2…and-serialization-code-for-tx.patch

mainnet node just works :')

> 6 files changed, 5 insertions(+), 292 deletions(-)

<ofrnxmr:xmr.mx> Had anyone compared 7999 and 8867 to see which actually perforns better?

<boog900> Proposed some different scaling parameters: seraphis-migration/monero #44#issuecomment-3617687600

<ofrnxmr:xmr.mx> 8867 has, aiui, started to be merged in pieces, but 7999 is the smaller pr and (again, aiui) has demonstrated much improved performance

<gingeropolous> so these things could address the 90MB block limit. And have been sitting in PR limbo since 2021

<gingeropolous> so it'll soon be 5 years that these fixes have sat there.

<ofrnxmr:xmr.mx> @gingeropolous: The 30mb limit

<ofrnxmr:xmr.mx> The 90/100mb limit is unaddressed

<ofrnxmr:xmr.mx> Theres also a 50mb p2p packet limit, also inherited

<boog900> @ofrnxmr:xmr.mx: I am working on a proposal to change how blocks are synced. Hopefully fixing this and adding a couple nice features.

<boog900> @ofrnxmr:xmr.mx: Also I checked and I can't see where this is enforced.

<ofrnxmr:xmr.mx> Fluffy blocks during ibd w/ split messages

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: ?*

<boog900> I mean we could reuse the messages but that wouldn't be ideal IMO. But if you just mean just the gist of fluffy blocks then yes.

<ofrnxmr:xmr.mx> download all block headers first, then add the txs 🧠

<boog900> If you are taking the mick, then I don't see why. I want to add more to it than just that, for example adding support for not always sending the miner tx in a broadcast and not disconnecting if the block has enough PoW but is invalid, plus some more. I would prefer us get all these changes in at once as its a good time to do it.

<boog900> Having a spec we can discus before I just put some code in Cuprate is the better way to do this.

I will comment here as I don't have a github account, the comment "The spam attacks we have had in Monero were stopped by by the short term median."

1) so we can distinguish spam :)

2) I thought why this wasn't successful is that the blocks did not grow at the expected rate, that there was a bug that kept fees too low to expand the blocks

I am thinking of the most recent episode, am I remembering this correctly?

<rucknium> nioc: Mostly the spam was using minimum fee. If the real users had auto-adjusted their fee to the next level, their txs would not have been delayed. I don't think the auto-adjust would have increased block size much because the vast majority of txs were the low-fee spam. More info: github.com/Rucknium/misc-research/b…d/pdf/monero-black-marble-flood.pdf

yeah I though the low-fee spam was low fee due to incorrect auto-adjust

vague memories

<321bob321> CRS

for nioc 2) monero-project/monero #9219

<tigerix:matrix.org> I believe in the good will of the people in this community with the Blocksize limit.

<tigerix:matrix.org> Satoshi also introduced a Blocksize limit with good will for safety reasons. This turned out to be the nail in the coffin for Bitcoin as money.

<tigerix:matrix.org> This shouldn't be done, because temporary things usually stay the way they are. That's just life experience![... more lines follow, see mrelay.p2pool.observer/e/zuK5zc8KX19ob2VN ]

it's already in the code and introduced. we are trying to remove it.

it came with cryptonote.

<tigerix:matrix.org> Zcash has a Blocksize limit of 2 MB and thus will never be more than private gold. Monero can be more than that!

<redsh4de:matrix.org> To be clear, the blocksize will still be dynamic. The limit is not arbitrary like 1MB or 2MB, it is literally under what would break the Monero network with the current code if it gets there

<redsh4de:matrix.org> things start breaking at 32MB already

<redsh4de:matrix.org> the cap is 3x that

<tigerix:matrix.org> It sounds reasonable, but isn't this a nice problem to have?

<tigerix:matrix.org> I mean, if Monero gets used that much, great! We can introduce an emergency fix for that. But does it have to be rushed beforehand?

<redsh4de:matrix.org> @tigerix:matrix.org: It is not a nice problem to have if it renders the network unusable. What good is a unlimited block size if the nodes can't sync those blocks?

<redsh4de:matrix.org> Plan is to set a temporary cap on growth which would not be reached within 6 years. During that time it should be enough to resolve the underlying technical debt and fix the serialization issues with with the C++ daemon that prevent us from safely scaling. After that, the cap can be forked away, because nobody wants it to be t [... too long, see mrelay.p2pool.observer/e/4KOIzs8KLXBfUV9k ]

<redsh4de:matrix.org> On Bitcoin, the 1MB block size limit was set to avoid spam. The 90MB block growth cap here is to ensure Monero doesn't literally die by bigger blocks than the reference client can chew if it gets that much activity

<articmine> The 90MB cap doesn't do anything that is not addressed in my proposal, unless the fix for the 100 MB bug is not fixed in six (6) years

<redsh4de:matrix.org> Yes, it is imperative to fix the 100MB bug asap

<tigerix:matrix.org> If Monero gets used more and more, we see it way before the worst case Szenario happens.

<tigerix:matrix.org> To be fair, currently there is no Blockstream in Monero luckily, who wants to make money by offering custodial services. But we never know which state actor is trying to stear Monero in the wrong direction.

<articmine> What in reality is going on here is that people are arguing for this cap in order to avoid dealing with this bug during the next 6 years

<articmine> @tigerix:matrix.org: There does exist a conflict of interest with strong links to US Law enforcement

21:36:03 <br-m> <tigerix:matrix.org> I mean, if Monero gets used that much, great! We can introduce an emergency fix for that. But does it have to be rushed beforehand?

that's what we are trying to. not have to rush it. then forked away (or even remove before next hardfork if we fix the issues)

<articmine> Way worse than Blockstream

<redsh4de:matrix.org> @articmine: Not setting the cap would be a "gun to your head" to get it fixed within 6 years, yes. Unironically can be a motivating factor

like. it can be exploited today even worse with existing scaling

the packet size cap is 50 MiB, levin deserialization 100 MiB ... and as listed last night there are other fixed caps existing already inherited from cryptonote

<articmine> With existing scaling one needs about 5 months

<articmine> In fairness to cryptonote. In 2013 they were looking at over 2000 TPS. That was less than VISA back then

<articmine> The TX size was like ~500 bytes

<articmine> It was still a bad idea back then

<gingeropolous> i mean call me crazy pants, but I think 6 million transactions of FCMP is better privacy than 900 gajillion transactions of ringsize 16. FCMP gets in, then its optimize and fix all the things, like the PRs that have been sitting since 2021 that are kinda related i think

<articmine> Actually no

<gingeropolous> i really think we're missing the forest for the trees

<articmine> Especially with quantum computerss

<gingeropolous> well thats a whole other kerfuffle

<redsh4de:matrix.org> @gingeropolous: anon / perfect-daemon had made PRs that upgrade serialization/etc, right? Maybe we'll see something of that sort from him now again after his CCS got funded

21:57:29 <br-m> <articmine> Especially with quantum computerss

^ especially. FCMP++/Carrot includes specific changes to improve PQ

current addressing scheme does not.

<articmine> @gingeropolous: It t actually a valid research topic

<boog900> @articmine: are you saying RingCT is better than FCMP for QCs?

<datahoarder> ^ > <@datahoarder> The conflict of interest here is delaying FCMP++ due to scaling issues which would already cover the part of breaking surveillance for rings, so that must be prioritized. Adding sanity scaling parameters/adjustments so that can exist happily with current implementations can speed the process of deploying this in an agreeable way and stopping BS

<articmine> I am saying that with QC forward privacy can be broken by combining BS with QC

goal shifting now, FCMP++ deals with BS, but suddenly, that's irrelevant

<articmine> One needs to hide the public keys. This is in the Carrot specification

<boog900> yes, currently you can break it without even the public keys. Its even worse.

the carrot specification was changed recently :)

I implemented it

<articmine> DataHoarder: It is not irrelevant, but it is not a complete panecea

<articmine> DataHoarder: Do you still need to hide the public keys to have forward secrecy?

given current BS and you placing that much importance in it, I'd say FCMP++ completely neuters them except in specific future cases, which we built protection/fallbacks for (PQ turnstile test being one)

<boog900> @articmine: even if you did this is a step up.

<articmine> It is a yes or no question?

internal sends (change) is protected, even if they know all your public keys ArticMine. non-internal sends are protected, given that all public keys are not shared.

if they know explicitly your target address (not any) they can do quantum stuff there to learn amounts

learning a different subaddress is not

also - jeffro256/carrot #6

<articmine> ... but some pubic are available to a BS adversary

<articmine> Public keys

<boog900> why are we taking about this at all?

<boog900> talking*

goal shifting boog900

<boog900> 100%

articmine: you have 0,2, BS has 0,3, they learn nothing

they have 0,2, they learn amounts.

in quantum

<articmine> What does the sender have?

if exchange sends, they have 0,2

that is what BS has

but then you receive with 0,3. they get nothing

<articmine> So then BS has 0.2 for some of the public keys

0,2 IS the public key

it's not shared with 0,3 or 1,2

that's why they are derivated with proper methods

(I mean 0,2 as account/index)

basically. exchange sends you money at address A (0,2).

They can break it! (but they already have the info). They can later break using quantum outputs received with specifically A (0,2)

you receive using B (0,3). this is not broken, this is an entirely new set of public keys

<articmine> Yes but all the current outputs were received with 0.2

what do you mean

so they already know the details of the outputs?

then why do they need to learn them

there isn't carrot deployed yet

that's why it's important to have it

<articmine> The existing outputs if the public keys are known

<articmine> The address

there aren't carrot existing outputs

<articmine> Correct, but if they are not transferred after FCMP++ they are still vulnerable

they are vulnerable regardless. it's not carrot outputs

so yes, migrating to FCMP/Carrot is important

without carrot you don't even need pubkeys > 22:01:24 <br-m> <boog900> yes, currently you can break it without even the public keys. Its even worse.

<articmine> DataHoarder: You have to

why are non-carrot outputs even considered. they are broken under a quantum adversary directly

when you bring it up. migrating would be a factor. I'm answering > 22:00:07 <br-m> <articmine> I am saying that with QC forward privacy can be broken by combining BS with QC

<articmine> Because BS relies on correlations between outputs,. So broken some not broken

<articmine> They are not isolated from each other

<articmine> The worst part of all of this is it doesn't even have to work. All the government has to do is to convince a judge and not a professional mathematician that it works

<articmine> Then they can convict an innocent person

so back to hypothetical that regardless what we deploy even sending everything to burn addresses, a judge can convict you

so doesn't matter what we do. close the chain right?

<articmine> My point is that we need multiple layers. Not just one protection

<articmine> ... and yes sheer volume can and should be part of the equation

so let's deploy these layers no? specially the ones that cover PQ and ring surveillance

<articmine> I am not against FCMP++ What I am against is a fanatical push to keep the existing chain as small as possible

I don't think it's fanatical nor push to keep at small. but to allow it to grow safely without exploding and causing chain splits that require emergency changes

<articmine> To give an example. Many of the devs are concerned about a growth rate of 2 and propose growth rates between 1.2 and 1 7. I come up with an effective growth rate of 1.085 and they ask for more and more drastic restrictions

so bring people or gather devs for making it work now, instead of bringing people to bicker around 90 MiB permanent size forever, which was not discussed at all. We can remove it before next hard fork, let's do so, but otherwise a bomb is left planted (which is already there)

<boog900> way to misrepresent it

<boog900> disgusting

<boog900> trying to win the propaganda war again

<boog900> I have said again and again my position, here it is: seraphis-migration/monero #44#issuecomment-3617687600

<boog900> your 1.085 increases no matter what

<articmine> Your position is 1.2.

<boog900> not exactly equivalent

<articmine> I am offering 1.085

<boog900> oh my days

<articmine> @boog900: Over time it is

<boog900> if my proposal was really more, you would like it more, the more dangerous the better right?

<articmine> @boog900: No I am arguing for shot to medium term flexibility

<articmine> Long term no more than 1.5x per year

<articmine> I originally had a long term sanity median of 1000000 blocks

<articmine> With a growth rate of 2

<articmine> I actually believe that Tevador's proposal is way better for a sanity cap

<boog900> @articmine: where? not in the proposal I am looking at

<articmine> I have given multiple talks with the long term sanity median of 1000000 bytes

<boog900> as so this one proposal in the past that wasn't the one you wanted for FCMP?

<boog900> like come on

<articmine> The last was at MonerKon 2025

<boog900> I wont be talking about this with you anymore, we gone round in circles enough over the past couple weeks.

<articmine> MoneroKon

<articmine> I even discussed this there with Jeffro256 who told me it was unnecessary. That is why I took it out

<articmine> Of CT this was fi FCMP

<articmine> Of course

<articmine> @boog900: Then don't.

<articmine> I know what is really going on her. It has nothing to do with scaling parameters

<articmine> here*

we have pointed at the specific code that would break already. bring people, or let the existing people to fix it without sending hordes in misinterpreted social messages

there isn't a consensus for 90 MiB anymore, besides the 5m where there was an abstain from you. so, why all of this?

same limit exists on all other cryptonote derivations, too

in the end it doesn't matter if the technical limit is in or not. BS will exploit it and kill the network :)

or well, have some emergency deployment. wouldn't that be fun

I think it's more of a philosophical question. Any software has its limits. Even if Monero declares "unlimited" block size, there's always a physical limit of what the network can handle. Dev team's responsibility is to ensure that this limit is always bigger than the real world usage at any time, but setting a fail-safe (hard cap for the known

value of the limit) is perfectly normal, assuming that this hard cap gets increased with every node optimization (every new software release)

<articmine> I ABSTAIN that does not mean I support it. When I see posts on r/BTC on this. This tells me that this 90 MB limit is very controversial outside of t MRL

we couldn't do an emergency release for dns checkpoints either because of existing technical debt, too. it's not a first

ofc, you abstaining can still mean you are against. usually it means that you let the rest of the consensus move forward and not move instead to try to misrepresent it elsewhere

<articmine> I am not misrepresenting this