<jack_ma_blabla:matrix.org> dns patch should be fastest to apply & we shouldn't wait for another attack while a permanent/better solution is found > <@angled:matrix.angled.rip> as in there is a plan to actually implement one of the other non temporary solutions? which one(s)?

<ofrnxmr:xmr.mx> @jack_ma_blabla:matrix.org: Wish it was so simple

<ofrnxmr:xmr.mx> But the reorg handling was broken (perhaps always has been) and needs a rewrite

the dns patch works and we have the tools. running an active checkpointer can get nodes stuck, effectively, on reorgs, so that must be fixed before using it (see backlog on previous MRL meetings)

<monerobull:matrix.org> monero-project/research-lab #152

<monerobull:matrix.org> doesnt this destroy fee uniformity?

<torir:matrix.org> Instead of four fee levels, it adds ~50. I personally think actual fees will cluster around only a few fee levels (depending on market conditions). But.... people are often not rational with fees. Also, different wallets may have detectable bias when it comes to fee selection, so yes, it is likely to hurt fee uniformity in some way. How much it does so is difficult to quantify.

<torir:matrix.org> I don't think current fees are governed by consensus at all, but by a gentleman's agreement between most wallets to only use specific fee levels.

<torir:matrix.org> Forcing fees to be a power of 2 as a consensus rule is an interesting idea.

<torir:matrix.org> @torir:matrix.org: Indeed, on today's chain we still see non-standard fees sometimes.

<torir:matrix.org> I think the idea maybe needs to be taken back to the drawing board and properly analyzed for privacy impact and other concerns that were not addressed in the proposal.

<monerobull:matrix.org> "lmao ill have my program use 67 picos as fee so funny" -> all users tagged ✅️

<torir:matrix.org> Having fee levels be a consensus rule is probably not a bad idea, but the flex block space part of the proposal seems to forget that Monero already has a block scaling algorithm in place.

<torir:matrix.org> From the proposal: "To add more predictable scaling parameters."

<torir:matrix.org> Okay, I suppose the existing algorithm for block space is maybe not very predictable. I guess I just want a comparison of before/after to be able to properly evaluate this proposal.

<torir:matrix.org> I don't understand how scaling works presently to understand how this proposal differs.

someone might find it curious, I implemented the low order torsion attack on key image described on getmonero.org/2017/05/17/disclosure…in-cryptonote-based-currencies.html as part of the ring signature tests (done on original pre-ringct signatures)

it makes a ring of 3 decoys + 1 spend, verifies it; then attempts to forge the same ring (and private key) except with the key image torsioned by a low order point

it confirms it'd pass verification, if not for the explicit torsion checked Verify method

the test uses deterministic rng to ensure the random tries find a point in the given attempts (given this runs on CI) paste.debian.net/hidden/7ee64f03

hello

what is the difference between this group and #monero-research-lab?

<torir:matrix.org> Research lab is pretty strict about being on-topic, but otherwise they are pretty much the same.

Which chanel should I use to ask my questions about Monero Cryptography?

<basses:matrix.org> here

++

<basses:matrix.org> for general questions, unless you are proposing a change or noticed some issues

no, just studying and learning it

I'm learning xmr cryptography for a while, and I already studied the main part (RingCT, ring sig -MLSAG and LSAG-, stealth addresses, pedersen and rangeproofs etc.), and I wanna study FCMP++ now.

The problem is that I cannot get the intuition from raw maths, and only sources I was able to find were the papers of IACR (Curve Trees, ZKP of EC Inner Products from Principal Divisors etc.) -and some notes from dev github repos-.

My workflow is more about having a main article which simplifies the maths and highlights the intuition, and I bounce between the main article and IACR,MRL papers and codebase whenever I need more accurate informations and to make certain points more clear.

So, is there any articles or explanations about FCMP++ which would give me intuition first, so that I can dive into maths with this intuition?

I'm also open for any cryptography, monero and math workflow recommendations.

<torir:matrix.org> Start with how Zero Knowledge proofs work: blog.cryptographyengineering.com/20…knowledge-proofs-illustrated-primer this focuses on intuition, but the ZKP used in FCMP is different from the one demonstrated in the article.

++

<sgp_> ArticMine look up what firm Edman works for bitcoinmagazine.com/news/tornado-cash-trial-defenses-digi-forensics

<sgp_> I was an expert for Pertsev's defense

<sgp_> stop speculating about crap you don't understand

<articmine> I do understand what is going on here

<articmine> BS does not scale big time

<boog900> @articmine:monero.social: so in your opinion monero would be more vulnerable with FCMP and @sgp_:monero.social proposal, than current day RingCT given our tx volumes

<boog900> Or do you think monero can be traced right not due to our tx volume and RingCT?

<articmine> Chainalysis did get some tracing to work

<articmine> The issue is that if the anonymity set is small enough Monero would be vulnerable.

<articmine> The real attack is forcing moat transactions of chain onto centralized ledgers

<articmine> This is what has happened with Bitcoin

<articmine> By the way I was certified in Blockchain Surveillance as part of my work for the defense in the Sterlingov case

<boog900> @sgp_:monero.social has said the parameters are flexible, what tx volume is enough to avoid blockchain surveillance in your opinion ?

<sgp_> @boog900: Maybe we could start with a base level of transactions per day, right now, to answer that Q

<articmine> BS has started to have issues at Ethereum scaling rates

<sgp_> (ArticMine's suggestion of what that should be today)

<articmine> The reality is that the greater the anonymity set the greater the privacy

<articmine> All of this is dynamic because technology does not stay still

<sgp_> suppose this second, there was a demand for a million Monero transactions per second. What would you want the Monero transaction limit to this second, for Monero not to be a failure in your view?

<articmine> This is why fixed limits are so dangerous

<boog900> both your proposals allow infinite growth over enough time

<sgp_> so you would want to fully accommodate the million per second in that example? If Monero only did 500k/second, that would be a failure in your view? Again, let's assume this is today and today's infra costs, not 10, 100, etc years from now

<articmine> It is not possible to reach those rates today. We both know that

<articmine> I do see VISA transactions rates as realistic in a decade

<sgp_> Yeah but I mean what would you say is reasonable today, so we have somewhere to start. Assuming infinite demand

<sgp_> @articmine: I can try to work back from this if you want me to, discounting by moore's law

<articmine> There is no sch thing as infinite demand

<articmine> You will get my proposal

<articmine> If you work back from VISA in a decade

<sgp_> yeah give me a sec to do that. I'll work back from 300 billion txs a year

<articmine> ViSA is about 7000 TPS with a surge factor of ~ 20x

<sgp_> what growth rate per year do you want me to use for moore's law? 50%?

<articmine> Yes

<articmine> 50% is correct

<sgp_> one moment

<sgp_> mrelay.p2pool.observer/m/monero.social/SGxprNVjqqMmPpAuVHDoKGIs.png (image.png)

<articmine> One has to factor in a 20x surge for holiday shopping

<sgp_> mrelay.p2pool.observer/m/monero.social/rfPOyYRsoFJWFgvYsRVyLOiM.png (image.png)

<sgp_> like that?

<kayabanerve:matrix.org> There is a dev draft of the FCMP++ protocol considered the FCMP++ paper @zarathust

<articmine> Yes

<sgp_> Ok cool, now we have a baseline :)

<articmine> The surge will be handled by the 16x in the short term median

<ofrnxmr> @kayabanerve:matrix.org: They left right before you responded

<articmine> So we are looking at the long term and sanity. Medians

<articmine> 2x maximum growth for the long term median and a factor of 256 to 1024 for the sanity median

<articmine> The thii to keep in mind is that growth will not be constant

<kayabanerve:matrix.org> ofrnxmr: :(

<sgp_> Can you remind me how long the long term median is? It's not 1 year right?

<articmine> 100000 blocks

<articmine> Sanity will be 1000000 blocks

<sgp_> so roughly 138 days

<articmine> Both grow at 2x

<sgp_> I see 193 MB blocks right now and tbh, I'm quite concerned. Even before the 20x surge feature. And I'm concerned about growth at 2x up to ~2.5x a year, even if it's unlikely to grow as fast as allowed

<articmine> How do you get 192 MB blocks right now?

<sgp_> that's the value when discounting 10 years of moore's law from Visa levels today

<articmine> Before the surge?

<sgp_> E2 > <@sgp_> mrelay.p2pool.observer/m/monero.social/rfPOyYRsoFJWFgvYsRVyLOiM.png (image.png)

<boog900> FWIW we cannot handle that with the current code, you will hit serialization limits in the P2P network

<boog900> even with stressnet changes

<sgp_> I know that's not the number used in your proposal, but it's the implied number that's needed to get to your goal of Visa level throughput in 10 years, growing 50% per year

<articmine> You are assuming a constant rate of growth

<articmine> We are also dealing with a priced network

<articmine> I have to leave now. At least some progress

<ofrnxmr:xmr.mx> @boog900: And packet size limits

<boog900> I don't think any rate of growth makes this possible FWIW

<ofrnxmr:xmr.mx> off topic: Boog, do me a fav and poke, prod, nudge 0x to wrap up tx relay 🙃

<sgp_> My point in going through this exercise is to help show why Visa rate isn't achievable, even in 10 years, without some major efficiency gain. And while I want efficiency gains, if we find one, we can always change the scaling again to account for that, rather than committing us to a scaling disaster that needs to be averted

<ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: Please and thank you

<boog900> @ofrnxmr:xmr.mx: lol I have been meaning to give that another review too :)

<ofrnxmr:xmr.mx> It has a bunch of review comments that need to be addresses before merge on stressnet

<kayabanerve:matrix.org> Re: bandwidth and ECC, Curve Forests would effectively flatten the proof size for membership at the cost of much more notable computation.

<kayabanerve:matrix.org> Moving into the future, the focus will need to be on delegating work out to users, block builders, and even segments of the network via RGC?, IVC, and L2-esque strategies.