<c​haserene:matrix.org> as said, one is that you build on what's semi-pejoratively called "moon math". 1) cryptographic hardness assumptions that seem sound, but haven't been so time-tested, 2) higher complexity, easier to make mistakes on multiple levels on the way from theoretical foundation to production code, 3) less people who understand it and can catch mistakes. up until 2018 Zcash had an inflatio<clipped message>

<c​haserene:matrix.org> n bug because a single operator in a single equation was wrong, and the smartest people in ZK at the time didn't catch it for years. things got a lot better since then, but it's still a relative risk. another downside is that, for Monero to work in such a fashion, you'd have to redesign the whole protocol to such a degree that it's not desirable or worth it at all (it's already be<clipped message>

<c​haserene:matrix.org> ing redesigned a lot as we speak with the work on Seraphis). but who knows, I've seen so mind-bending leaps in ZK that maybe at some point you'll be able to safely tailor such a proving system for Monero without having to change Monero, and people could just opt to use that sync mode.

<k​ayabanerve:matrix.org> We ask the initial 16 (15 decoys, yet we also include the real spend so the node can't look for TXs using those 15 decoys to identify the real spend). If one is invalid, we ask for exactly one more, effectively doxxing to the node the further selections are decoys.

<k​ayabanerve:matrix.org> > AFAIK relies on cryptographic hardness assumptions that are less tried-and-tested than what Monero relies on

<k​ayabanerve:matrix.org> chaser I would not say this, and I also wouldn't say we *can* create constant-sized proofs. At best, *without a trusted setup* you get a proof constant to the program size where the program enables verifying a proof of a large proof (which can be recursed ad infinitum to achieve arbitrary program space).

<k​ayabanerve:matrix.org> > as said, one is that you build on what's semi-pejoratively called "moon math"

<k​ayabanerve:matrix.org> People not understanding math doesn't make the math wrong. Most people don't understand Bulletproofs and yet here we are.

<k​ayabanerve:matrix.org> > cryptographic hardness assumptions that seem sound, but haven't been so time-tested

<k​ayabanerve:matrix.org> Again, this is not correct.

<k​ayabanerve:matrix.org> The complexity commentary is fair. I'm not entirely sure the less people commentary is when I'd posit most modern cryptographers work with such proofs. The underlying problem space is incredibly important, and solutions for it are widely usable. Accordingly, they frequently see use.

<k​ayabanerve:matrix.org> > because a single operator in a single equation was wrong

<k​ayabanerve:matrix.org> This isn't correct. The fact they had a bug which was missed during review for years is correct. Whether or not "the smartest people in ZK" participated in that review I cannot comment. I want to say Microsoft eventually caught it, presumably when one of their researchers decided to review it? Which means when some of the 'smartest people in ZK; did review it, they caught it, even<clipped message

<k​ayabanerve:matrix.org> if some of the other 'smartest people in ZK' missed it.

<k​ayabanerve:matrix.org> > you'd have to redesign the whole protocol to such a degree that it's not desirable or worth it at all

<k​ayabanerve:matrix.org> No, you wouldn't, and I'm pushing these exact scalability discussions with Seraphis. They technically *can* be done now, we'd just need more complicated circuits than would be needed under intelligent design.

<k​ayabanerve:matrix.org> > I've seen so mind-bending leaps in ZK that maybe at some point you'll be able to safely tailor such a proving system for Monero without having to change Monero, and people could just opt to use that sync mode.

<k​ayabanerve:matrix.org> It'd be a great hackathon project to run Cuprate in RISC-0. I'd expect a proof of concept to take less than a month depending on how Cuprate is architectured (monero-serai is extensively aiming to support no_std, and Cuprate is modular, yet you'd need a `libconsensus` equivalent (Bitcoin term) which is no_std and support for a custom database, which I haven't looked into).

<s​yscall:cat.casa> 1. An adversary conducts a flooding attack on the Monero blockchain, which costs him about 500$ for 100k txes per day. The dynamic block size adjustment works through penalty system which calculates for the latest M100 blocks. Let's say the "natural transactions rate" is 10k per day for Monero, so now its 10k natural + 100k flooding. After the dynamic block size kicks in an attack<clipped message>

<s​yscall:cat.casa> er stops the attack and in the next M100 cycle block size is readjusted again to its normal 10k per day rate. Does it mean that an attacker can bloat the blockchain each second M100 cycle?

<s​yscall:cat.casa> 2. If the Monero's price is essentially pinned down to everlasting 150$ by CEX manipulations - will be tail emission sufficient to keep the network working? Won't there be a situation when because the price is controlled through CEX (and it will be controlled in the observable timeframe) miners will lose the interest in the network?

<s​yscall:cat.casa> 3. How does the previous 2 stack up into the whole idea of a fullscale attack on Monero (e.g. government/Bitcoin whales induced)? How both is mitigated?

<s​yscall:cat.casa> 1. An adversary conducts a flooding attack on the Monero blockchain, which costs him about 500$ for 100k txes per day. The dynamic block size adjustment works through penalty system which calculates for the latest M100 blocks. Let's say the "natural transactions rate" is 10k per day for Monero, so now its 10k natural + 100k flooding. After the dynamic block size kicks in an attack<clipped message>

<s​yscall:cat.casa> er stops the attack and in the next M100 cycle block size is readjusted again to its normal 10k per day rate. Does it mean that an attacker can bloat the blockchain each second M100 cycle?

<s​yscall:cat.casa> 2. If the Monero's price is essentially pinned down to everlasting 150$ by CEX manipulations - will be tail emission sufficient to keep the network working? Won't there be a situation when because the price is controlled through CEX (and it will be controlled in the observable timeframe) miners will lose an interest in the network?

<s​yscall:cat.casa> 3. How does the previous 2 stack up into the whole idea of a fullscale attack on Monero (e.g. government/Bitcoin whales induced)? How both is mitigated?

Mitigations:

1. Submit very large transactions with fees you think are prohibitively high for the attacker to match.

2. Convince major pool operators to adopt a more restrictive minimum fee policy.

3. Try to investigate the origin of the transactions and ask him wtf (pretty hard to do, but who knows maybe he's just a malicious idiot with no opsec)?

<m​onerobull:matrix.org> >(and it will be controlled in the observable timeframe)

<m​onerobull:matrix.org> doubt it

<m​onerobull:matrix.org> imo most volume will be done via dexes very soon

<m​onerobull:matrix.org> imo most volume will be done via dexs very soon

<s​yscall:cat.casa> The current XMR volume on DEXes is 0.2 BTC. Its a joke. And even if it somehow occur which I doubt since nobody is willing exchange their XMR for dirty BTC/LTC/etc. (DEXes will be used exactly for this in case of Monero) - there still be CEXes, which will be the deciding factor for XMR price. When you will try to exchange your XMR to fiat - CEX price will decide. I might be missin<clipped message>

<s​yscall:cat.casa> g something for sure but your point is weak. I'd like to receive an expert response from the Monero team.

<e​ndor00:matrix.org> Whatever the response is, this isn't the place for it. Look for the Monero Markets room :)

<s​yscall:cat.casa> Its exactly the place for it - my questions if purely technical, they are listed above.

<s​yscall:cat.casa> Its exactly the place for it - my questions is purely technical, they are listed above.

<s​yscall:cat.casa> Its exactly the place for it - my questions are purely technical, they are listed above.

<e​ndor00:matrix.org> (Btw avoid editing messages please - it causes spam on the irc side of the room)

<s​yscall:cat.casa> This is exactly the place for it - my questions are purely technical, they are listed above.

<s​yscall:cat.casa> Tell me how this is related to Monero Market room

<e​ndor00:matrix.org> As far as the mining incentive is concerned, price is indeed important. The average amount of money paid to the whole mining network is: [coin price] * [block reward] / [target block time]

<e​ndor00:matrix.org> The block reward is just a parameter. If some outside entity wanted to suppress miners through price manipulation, all they'd need to do is to push the coin price low enough until the network becomes trivial to attack - regardless of how big or small the block reward is

<e​ndor00:matrix.org> As for how the price will actually behave in the future, you are making a lot of assumptions - which *seem reasonable*, but are objectively unverifiable (e.g. "the price is controlled through CEX")

A significat part of Monero network can keep mining at any price (botnets, free electricity miners etc)

<e​ndor00:matrix.org> How the market will actually evolve (price, volume, and where and how the trading will happen) is anyone's guess

<s​yscall:cat.casa> These are 2 separate questions.

<s​yscall:cat.casa> 1) The first one is about technical availability to make the Monero blockchain unusable each second 100 blocks timeframe.

<s​yscall:cat.casa> 2) The second is about tail emission which is directly stated as the key factor for keeping Monero mining profitable hence blockchain alive getmonero.org/resources/moneropedia/tail-emission.html:

<s​yscall:cat.casa> > Tail emission ensures that a dynamic block size and fee market can develop.

<s​yscall:cat.casa> But since the price is manipulated through CEX - it is a question if tail emission really "ensures"

<e​ndor00:matrix.org> Like I said: the actual block reward is just a parameter. So if the reward is 1 xmr/block, then you push the price below, say, 50$. If the reward is 2 xmr/block then you have to push it below 25$ and you get the same effect. A bigger block reward means you'd have to push the price lower and lower (which is *presumably* harder, but the difficulty depends on how you're actually supp<clipped message>

<e​ndor00:matrix.org> ressing the price), but it also means more inflation in the short term

<e​ndor00:matrix.org> The reason why the site says that the tail emission "ensures" that the network will keep going, is because transaction fees are not enough to maintain a big mining incentive over time. For example: in 10-30 years, as the block reward keeps halving, the Bitcoin network will see a huge decline in hashrate - to the point where even someone with 5-10% of today's total nethash could ea<clipped message>

<e​ndor00:matrix.org> sily 51% their network. And this is inevitable unless they change their emission curve (to include a tail emission) and increase their blocksize

<e​ndor00:matrix.org> (Or rather: Bitcoin users would have to start paying >30-50$ fees *per transaction* (for a basic 1in-2out) to sustain their current mining incentive of ~700 $/second)

<e​ndor00:matrix.org> (And that's assuming they can keep those block full all the time)

<e​ndor00:matrix.org> (I swear I'm gonna finish writing that paper some day 😭)

Bitcoin halving soon nicehash.com/countdown/btc-halving-2024-05-10-12-00 - we'll see if it sparks more discussions after miners get rekt

*Bitcoin miners

<s​yscall:cat.casa> I see your point and its valid against Bitcoin but:

<s​yscall:cat.casa> 1) The block reward is constant 0.6 XMR and miners don't pay for the electricity and hardware in XMR, they pay in USD. If the price is constantly suppressed via CEXes - where is that diverging point where the whole idea of sustaining the network become unprofitable?

<s​yscall:cat.casa> 2) Since the block reward is small, the only way for miners is the same as you mentioned for Bitcoin - to compensate the loss with fees

<s​yscall:cat.casa> 3) Let's say that now the "critical" point of profitability for sustaining the Monero is around 150$ for 1 XMR. That include both block profits & fees profits. If the price is consistently supressed down further and the network is attacked as I've mentioned in my first question (this is the primary question actually) - wouldn't that be possible to basically kill the network just b<clipped message>

<s​yscall:cat.casa> y driving the miners and users out of it?

<s​yscall:cat.casa> So the whole attack scenario is:

<s​yscall:cat.casa> 1) Keep the price at current levels or pin it down even further, since a CEX always can "temprorary shutdown withdraws" and replenish its wallets with real coins -> reducing fees & block reward profit

<s​yscall:cat.casa> 2) Attack the network by periodically bloating the blockchain every M100 cycle. The network becomes unusable, mempool is growing, transactions confirming for days - people leave -> reducing fees profit. That decreases "natural" txes volume further but miners is still compensated by an attacker and the block reward

<s​yscall:cat.casa> 3) Systematically drive the Monero out of the market, same as Binance delisting and EU ban, reducing the number of users and adoption -> reducing fees profit

<s​yscall:cat.casa> 4) This looks like enough to strangle the network but as the last resort there is always a possibility to basically zero out the price via controlled CEX if needed

<s​yscall:cat.casa> But my main question is still about the M100 cycling flood possibility, if you may please.

<e​ndor00:matrix.org> No, you are mixing things up

<e​ndor00:matrix.org> In order:

<e​ndor00:matrix.org> The tx fees are part of the total block reward used in the incentive calculation

<u​ntraceable:monero.social> Not sure where you get the 0.2 btc figure. The volume on Bisq alone for the past 7 days is 64.7 BTC (4 million usd). Other DEXs and Atomic swap volumes are harder to measure. When Haveno and Serai launch its not completely unrealistic that most Monero volume will then flow through DEXs rather than CEXs.

<u​ntraceable:monero.social> Not sure where you get the 0.2 btc figure. The volume on Bisq alone for the past 7 days is 64.7 BTC (4.6 million usd). Other DEXs and Atomic swap volumes are harder to measure. When Haveno and Serai launch its not completely unrealistic that most Monero volume will then flow through DEXs rather than CEXs.

<e​ndor00:matrix.org> There isn't a single "critical" price point. Rather, you can calculate the maximum network hashrate that could be supported for a given mining incentive and a given electricity price; and from there, see how many devices it corresponds to, and what would it cost to perform a 51% attack against them

<e​ndor00:matrix.org> Keep in mind that profitability is based on hardware efficiency, i.e. how many $/kWh you can earn on a given hardware vs how much $/kWh you pay for that electricity

<e​ndor00:matrix.org> Mining incentive goes down -> profitability goes down for everyone -> the most unprofitable miners tend to leave -> profitability goes back up for those who stay

<e​ndor00:matrix.org> It's an equilibrium

<m​onerobull:matrix.org> not for monero

<m​onerobull:matrix.org> we have botnets mining at zero cost

<m​onerobull:matrix.org> the closest comparison for xmr on serai is imo BCH on thorchain

<e​ndor00:matrix.org> Yes, sech1 already mentioned that. They still work under the same paradigm, they just happen to pay 0 $/kWh (though they probably have some running costs of some other kind)

<m​onerobull:matrix.org> and that had 55 million in volume in the last week

<m​onerobull:matrix.org> and thats for a chain you can get on any ccex

<e​ndor00:matrix.org> As for the "spamming the network every M100 cycle" - I suspect you misunderstand how the reward penalty works

<m​onerobull:matrix.org> and thats for a chain you can get on any cex

<s​yscall:cat.casa> I've just opened Bisq and I see there 261 XMR selling for 1 BTC, 523 XMR for 2 BTC. This is exactly what I was telling - nobody wishes exchange their XMR for _a priori_ dirty BTC unless its 2x times cheaper than XMR price on exchange. You can buy XMR for 300$ here if you like, no problem.

<m​onerobull:matrix.org> you dont get dirty bitcoin from serai

<m​onerobull:matrix.org> at least not if you provide xmr liquidity

<s​yscall:cat.casa> What will happen if all miners will be made unprofitable by CEX price pinning?

<e​ndor00:matrix.org> The reward penalty is applied per block, if the block you're mining is bigger than the short term median. That means that a spammer would need to spam transactions for *at least* 50 blocks at the minimum fee, before miners would start increasing the block size above the minimum.

<e​ndor00:matrix.org> Note that the goal of this would be to increase the blocksize in order to spam *even more* transactions per block. Otherwise, if they let it reset, then they would be limiting themselves a lot

<m​onerobull:matrix.org> btw this room is not the place to discuss this stuff

<m​onerobull:matrix.org> use community or research lounge

<e​ndor00:matrix.org> True ^

<e​ndor00:matrix.org> Monero Research Lounge let's move here syscall

<s​yscall:cat.casa> what this room is for then?

This channel is for research. The monero IRC channels are many, which might be obscured from wherever you connect from (matrix ?).

Then again, there's been a tendency to discuss code stuff here for a long while instead of in -dev for some reason.

#monero is the catch all channel, also includes broader privacy stuff not directly related to monero.

There are several more too. #monero-pools for pools and mining, #monero-markets for econ stuff. etc.

#monero-pow for, oh, I dunno... maybe pow...

<p​reland:matrix.org> I think part of it is also some survivorship bias

<p​reland:matrix.org> If I understand the point of this channel correctly, it should only be used during meetings

<p​reland:matrix.org> So by definition, anything said outside of meetings is off-topic

<f​r33_yourself:monero.social> I think price suppression is harder if people don't keep their Monero on exchanges or don't even use exchanges. Monero is in a good position to resist price suppression because a good majority of merchants only demand on-chain Monero, not off-chain claims on Monero. The network may be profitable at a lower block reward, but only for more efficient miners, so I don't really see the<clipped me

<f​r33_yourself:monero.social> problem with this. It lower's overall confirmation security of transactions, but this is just something that must be accepted.

<j​ack_ma_blabla:matrix.org> What is the effective ring size of Monero currently, assuming that 80% of daily decoys are controlled by a single entity which intends to conduct sell-chain analysis service? Also, what is the degree of probability for EAE and EABE transactions to be traceable? Ignore my grammar; I am Chinese and using a translator.

<r​ucknium:monero.social> My estimate says that average effective ring size is 5.5 right now if an adversary is producing the suspected spam transactions for a black marble flood attack.

<r​ucknium:monero.social> The success probability of an EAE/EABE attack is unknown. It actually has never been rigorously defined.

<j​ack_ma_blabla:matrix.org> Is the ring size of 5.5 derived from mathematical paper or did you conduct some analysis for last few days of transaction? Also, is this effective ring size sufficient? If one spends the coin on the same day as they received it, is the effective ring size 5.5? By what factor are EAE and EABE transactions more traceable with a ring size of 5.5 compared to, say, 16?

<r​ucknium:monero.social> I'm doing an analysis. I will post in 24-48 hours. Basically I assume that the 4 weeks of txs before March 4 were the non-spam rate of txs. Then the txs on top of those in the last week are "spam". The outputs of those spam are assumed to be black marbles. Then I run what the decoy selection algorithm would be at a specific block height

<r​ucknium:monero.social> Sufficient? We'll talk about it at the MRL meeting at 17:00 UTC Wednesday.

<j​ack_ma_blabla:matrix.org> Thank you for your valuable time. Please include some information about EAE and EABE if possible.

<r​ucknium:monero.social> I don't know what exactly is the minimum acceptable. I have been re-reading papers. We probably want to know what level of flooding would create conditions for a "chain reaction" or "graph analysis" attack. There is a theoretical paper about the exact thresholds that should be used, but its analysis assumes a different type of decoy selection algorithm. IMHO we could simulate bloc<clipped message

<r​ucknium:monero.social> k marbles realistically with what is on the blockchain now and then run a Dulmage-Mendelsohn decomposition with the Rust code that Vijayakumaran (2023) wrote.

<r​ucknium:monero.social> We probably need someone who understands how to run Rust, but I can create the simulated input data.

<r​ucknium:monero.social> The theoretical paper is Egger, C., Lai, R. W. F., Ronge, V., Woo, I. K. Y., & Yin, H. H. F. (2022). "On defeating graph analysis of anonymous transactions."

<r​ucknium:monero.social> But it assumes that a partitioning decoy selection algorithm is used. Monero uses a mimicking decoy selection algorithm.