<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.

<articmine> @sgp_: Monero has been around since 2014 with far more generous scaling rates and there has been no "scaling disaster".

<articmine> I find statements that peer to peer electronic cash at scale is not possible in a decade actually very troublesome and such a philosophy does not belong at all in the Monero consensus code

<articmine> If there is a legitimate reason to temporarily throttle the growth of the Monero network there are many tools available through node relay to do this. Of course the consensus burden will then fall on those who wish to limit growth as opposed to those who wish to allow growth. That consensus would only be achieved if there is a [... too long, see mrelay.p2pool.observer/e/mMXwqcMKODFWVkFa ]

<articmine> I do believe that if Monero were to achieve say 200 transactions per second that would be the end of the Blockchain Surveillance industry, not only in Monero but also in so called surveillance coins

<articmine> This means that the viability of companies worth billions of dollars is at stake here.

There could have been a scaling disaster. github.com/noncesense-research-lab/Blockchain_big_bang

<boog900> just because something hasn't happened doesn't mean its not possible, stressnet has demonstrated it is possible

<articmine> It does not justify baking failure into the consensus code

<boog900> > there are many tools available through node relay to do this

<boog900> You cannot limit block size by node relay

<articmine> If the nodes limit bandwidth how can you grow the blocks?

<sgp_> Allowing 2x bloc growth ~2.5 times a year means that current scaling proposals would allow what, ~6x growth every year? A 10x increase at maximum than even the Moore Law calculation?

<articmine> You forget there has been no growth in the last 5 years due to the lobbing effects of the BS companies

<boog900> @articmine: failure here means it does not support enough txs (like bitcoin in your opinion). The real failure is being too aggressive with scaling and causing nodes to fall out of consensus with each other.

<sgp_> At 6x growth per year, why even have limits

<articmine> Bitcoin is a failure not only as peer to peer electronic cash but also as a central bank reserve asset

<articmine> It is only a matter of time

<articmine> @sgp_: We need to catch up to undo the harm done by the BS companies for starters

<syntheticbird> >undo

<boog900> @articmine: it is still alive, can we say the same of a coin that allows double spends due to nodes falling out of sync?

<syntheticbird> >blockchain

<syntheticbird> i think it's too late

<sgp_> @articmine: Even accepting that, why not set the current max block size to "the value Monero should be at this point" (calculated in my sheet at 193 MB blocks) and then set the max growth rate to 50%/yr?

<articmine> Who do you think is behind the lobbying of governments to delist Monero from exchanges?

<syntheticbird> @articmine: police?

<syntheticbird> (ik BS)

<articmine> No those who profit from selling blockchain surveillance even though it does not work.

<articmine> It is a multi billion dollar industry

<articmine> I was arguing the danger of blockchain surveillance back in 2018

<boog900> *it does work at low tx levels

<articmine> It does not work in Bitcoin

<articmine> @boog900: Kind of

<articmine> Enough to fool governments to part with their money

<syntheticbird> probabilities becomes certainty, and suspicions turns into culpability

<boog900> maybe controversial opinion but we should not be limiting ourselves to VISAs txs/s, if we can do more we should do more

<articmine> ... and the innocent get convicted

<articmine> @boog900: Of course

<boog900> if we can't, we should do less

<articmine> @boog900: Or wait until we can

<syntheticbird> @articmine: I won't wait

<articmine> Which why I am so opposed to consensus limits

<syntheticbird> I've the finger on the red button waiting to release Seraphis

<boog900> @articmine: again the limits are not bandwidth or CPU currently

<boog900> it is code

<sgp_> is 6x scaling a compromise then in your view, with the alternative being no limits?

<articmine> @boog900: Which is and can be fixed

<boog900> @boog900: so baking in scaling that we are not sure if we can hit is not a great idea

<articmine> @sgp_: My position will be in my personal

<boog900> @boog900: although a sufficiently "slow" expansion of blocks is probably ok

<articmine> @boog900: Scaling was baked in since the genisis block

<boog900> exactly and how often has it been in play?

<boog900> last time was the spam IIRC and that broke wallets

<articmine> People bought into Monero on that understanding

<boog900> as we had bugs

<articmine> Which were fixed

<boog900> testing in production isn't a great idea for Monero ngl

<syntheticbird> @articmine: if there is one thing i've understood since i joined the monero community is that the colossal majority of people using monero understands what they want to understand, so no guarantee about that

<boog900> @articmine: yeah a sufficiently slow expansion of blocks I would support

<sgp_> I bought in for the transparent amounts /s

<sgp_> fwiw I 100% agree that scaling up capacity is an important value for Monero to retain

<sgp_> but it's obviously not the only value, or else RingCT would have never happened

<articmine> What determines capacity especially in the future?

<articmine> Privacy is a huge value in the Monero community. Privacy is heavily dependent on scaling

<boog900> its just not, the scaling code has rarely been activated

<boog900> more txs are better sure, but not heavily

<boog900> and no parameters have been selected yet

<boog900> surly the best thing for privacy is 10 GB blocks right now?

<articmine> It works both ways . If one cripples scaling one is also testing in production. This is what Bitcoin did in 2010 with its "temporary" 1 MB block size limit > <@boog900> testing in production isn't a great idea for Monero ngl

<syntheticbird> @articmine: I mean, are we bound to be literally dev consensus ddosed like bitcoin core?

<sgp_> fwiw, I think that the Monero community has demonstrated a strong willingness to change things that need to be changed

<spackle> I would suggest that there should at least be hard agreement between the scaling design and the actual daemon performance in the short term.

<spackle> A simple rule might be that the daemon must be capable of handling the most extreme limits of the scaling design until the long term median adjusts.

<sgp_> We could pick 10% growth rate now and choose 20% later. Or a one-time jump. Or really whatever makes sense

<articmine> @sgp_: It has not diverged from its social covenant

<boog900> @articmine: we have changed the scaling code making block growth smaller before

<ofrnxmr:xmr.mx> @sgp_: i would pick 10%.. per day

<syntheticbird> @sgp_: fwiw there are already theoretical improvements cooking in the back of the kitchen. So it's not like we're putting a limit now that we don't know if it will be changed, we have short/mid term plans for improving things

<syntheticbird> e.g. curve forests

<spackle> With a daemon able to handle the full potential of the scaling design with a default long term median, a hard guarantee of ~2 months is in place for a development response without there being an issue.

<ofrnxmr:xmr.mx> 10% per year is WORSE than using our current low fee tier

<sgp_> worse how, specifically?

<ofrnxmr:xmr.mx> Low fee tier will raise block size by > 10% per year

<ofrnxmr:xmr.mx> 10% per year might as well be 0

<sgp_> oh you just mean more restrictive in terms of max scaling

<ofrnxmr:xmr.mx> yea

<articmine> @ofrnxmr:xmr.mx: I suspect that is the idea

<syntheticbird> @ofrnxmr:xmr.mx: too boring, we should make yearly block increase by O(n!)

<ofrnxmr:xmr.mx> So that spam that we had, at low fee tier, has more scaling than 10% per year

<ofrnxmr:xmr.mx> And crippled the network

<sgp_> I don't consider that an argument in your favor lol

<boog900> @ofrnxmr:xmr.mx: tbf the network stayed connected and in consensus

<ofrnxmr:xmr.mx> that we should cripple the network throughput intentionally?

<sgp_> no no no, that's a fundamental misunderstanding of fees

<ofrnxmr:xmr.mx> @boog900: When i say crippled, i mean, if the spam was consistent and reached 600+mb, then all new txa would be immediarwlt dropped

<ofrnxmr:xmr.mx> Because the spam was incompetent, ir never reached > 200mb, and txs werent rejected

<sgp_> users would need to pay higher fees than the spam to be confirmed with priority, like in any case

<boog900> @ofrnxmr:xmr.mx: so do you think we need more scaling?

<ofrnxmr:xmr.mx> @boog900: more than current? No

<ofrnxmr:xmr.mx> More than low fee scaling? Yes

<boog900> @ofrnxmr:xmr.mx: do you think we need less?

<sgp_> one major advantage of my proposal is the far greater ability for a fee market to address transaction priority, since there are so many more fee levels permitted

<ofrnxmr:xmr.mx> @boog900: i dont know what the actual limits are

<ofrnxmr:xmr.mx> I thought it was 30mb until 100k blocks, but i hit 40mb on testnet

<boog900> @ofrnxmr:xmr.mx: stressnet fully broke after what, a week?

<plowsof:matrix.org> replace by fee would be nice sometimes 😳

<ofrnxmr:xmr.mx> @boog900: Much less than that. Broke in like 2 days on my private testnet

<ofrnxmr:xmr.mx> Took like 1700 blocks to realize a lot of things dont work

<sgp_> In no circumstances should a backlog of spam cripple the network. Lee few txs should be deprioritized (and dropped from the mempool if necessary)

<ofrnxmr:xmr.mx> @sgp_: Well then fiz the txpook

<ofrnxmr:xmr.mx> Because at current, a large txpool cripples nodes

<boog900> 🦀

<sgp_> That seems unrelated to either of these proposals, that's just a bug that needs fixing lol

<ofrnxmr:xmr.mx> @sgp_: Related 100%

<ofrnxmr:xmr.mx> Bugs effect scaling

<ofrnxmr:xmr.mx> Without these issues, like spamming 9tb per day for 900mb of txs, scaling aint so bad

<ofrnxmr:xmr.mx> Or if fluffyblocks were broken

<ofrnxmr:xmr.mx> Werent* broken (they are)

<ofrnxmr:xmr.mx> The network cant stay in sync because we ddos ourselves

<ofrnxmr:xmr.mx> Decentralized denial of service 🥲

<boog900> FWIW I don't necessarily support any proposal, I just think we should be working with the limits of Monero rather than some arbitrary targets.

<ofrnxmr:xmr.mx> I think we should work on fixing monero so that it can operate at max efficiency

<ofrnxmr:xmr.mx> Then use the limit of efficiency or bandwidth

<sgp_> No, I want to purposefully add bugs to lower efficiency

<sgp_> :)

<ofrnxmr:xmr.mx> Not "10% per year" which we can already do on 1 leg

<ofrnxmr:xmr.mx> I understand that at current, monero is terribly inefficent, to the point it feels negligent or malicious

<sgp_> Your argument is basically "We could easily handle more transactions if these basic bugs were fixed, so I'm in favor of aggressive scaling"

<ofrnxmr:xmr.mx> @sgp_: half right

<ofrnxmr:xmr.mx> Maybe 3/4

<ofrnxmr:xmr.mx> Essentially, yes. If these basic bugs were fixed, stressnet can go from 3mb breakage to 40mb smooth sailing

<ofrnxmr:xmr.mx> where the issue would be storage

<blurt4949:matrix.org> Just a cool 10.5 TB per year

<ofrnxmr:xmr.mx> @blurt4949:matrix.org: exactly why the limit there would have to account for non-code related bottlenecks

<blurt4949:matrix.org> (assuming consistent 40MB usage, which may not happen)

<ofrnxmr:xmr.mx> 40mb blocks are like 5x bitcoins bandwidth on fcmp++

<ofrnxmr:xmr.mx> 5x bitcoins tx volume**

<blurt4949:matrix.org> which is pathetic

<ofrnxmr:xmr.mx> So no, not something i expect overnight

<ofrnxmr:xmr.mx> We average 40 tx/block

<ofrnxmr:xmr.mx> Bitcoin does an equivilent of 15x our throughout at 600tx per 2min

<blurt4949:matrix.org> I know but needing 40mb (200mb BTC equivalent) blocks just to 5x it is absolutely pathetic

<ofrnxmr:xmr.mx> @blurt4949:matrix.org: Its more like 20x if were talking about fcmp

<ofrnxmr:xmr.mx> Which these discussions apply to. I dont think anyone is talkibg about changing scaling numbera before fcmp hf

<blurt4949:matrix.org> ???

<blurt4949:matrix.org> If we say an FCMP tx is ~10kb, then 40mb blocks can handle ~30-35 TPS

<ofrnxmr:xmr.mx> Gimme a sec, not sure my head is on straight

<blurt4949:matrix.org> that's about 5x bitcoin?

<ofrnxmr:xmr.mx> @blurt4949:matrix.org: 30-35tps is about 5x btc, yea

<sgp_> I've been using 10kB for my FCMP estimations

<ofrnxmr:xmr.mx> @sgp_: same

<blurt4949:matrix.org> yeah so 200MB BTC blocks just to compete with 2MB BTC blocks

<blurt4949:matrix.org> (counting segwit)

<blurt4949:matrix.org> err, sorry, ~10MB

<sgp_> this is why Monero's competitive advantage is not efficiency, or even low transaction fees

<ofrnxmr:xmr.mx> Yea. 20x

<blurt4949:matrix.org> oh I thought you meant 20x the tx volume, which is what I was referring to

<blurt4949:matrix.org> but yeah anyway, point is FCMP doesn't scale unfortunately

<blurt4949:matrix.org> but RingCT doesn't either so it's okay :)

<ofrnxmr:xmr.mx> ringct scales enough that nobody has noticed how broken our protocols are

<ofrnxmr:xmr.mx> like, how has fluffyblocks been broken since implementation and nobody ever noticed?

<ofrnxmr:xmr.mx> Supposed to save bandwidth, but never worked

<boog900> @ofrnxmr:xmr.mx: also the fact the scaling code hasn't been used very much

<blurt4949:matrix.org> yeah because a literal actual self-described sh*tcoin (Doge) does 2x our daily transactions

<boog900> @ofrnxmr:xmr.mx: which bug?

<ofrnxmr:xmr.mx> Fluffyblocks relay the full block

<blurt4949:matrix.org> obviously we won't notice scaling limits at this scale

<boog900> @ofrnxmr:xmr.mx: that only affects miners

<boog900> everyone else relays the blocks properly

<boog900> if you get sent it over RPC tho you send the block full

<ofrnxmr:xmr.mx> @boog900: no, it effects the whole chain from my observations

<ofrnxmr:xmr.mx> My intermediate and tx-origin nodes both receive the full block

<blurt4949:matrix.org> There's also the fact that pruning doesn't automatically enable --sync-pruned-blocks which save >60% bandwidth

<boog900> @ofrnxmr:xmr.mx: almost certain it doesn't

<ofrnxmr:xmr.mx> so why is my tx-origin nodes received data jumping by 40mb when i mine a block?

<ofrnxmr:xmr.mx> When the origin node has all of the txs

<boog900> I think it was because your node lied about not having the tx due to D++

<boog900> it hides stem txs

<boog900> not 100% but that would be my guess

<ofrnxmr:xmr.mx> Looks like the fix agrees with you > <@boog900> that only affects miners

<ofrnxmr:xmr.mx> seraphis-migration/monero #155

<ofrnxmr:xmr.mx> I havent tested on private testnet, but it fixed the fact that block sizes were crippled at 4mb

<ofrnxmr:xmr.mx> Since fluffy blocks had a 4mb cap

<ofrnxmr:xmr.mx> seraphis-migration/monero #159

<ravfx:xmr.mx> tee.fail

<ravfx:xmr.mx> In TEE we trust!

<ofrnxmr:xmr.mx> seraphis-migration/monero #140

<ofrnxmr:xmr.mx> Note how many minutes it too for a peer to successfully send me the block

<ofrnxmr:xmr.mx> "The problem is that the node is relaying the full fluffy block to its peers, and that full fluffy block can exceed the byte limit of 4mb:"

<ofrnxmr:xmr.mx> Im 100% sure that many nodes in the above log werent all sending me the mined block. Looks to me like they were (probably) sending full blocks (which were above the fluffyblock 4mb limit)

<ofrnxmr:xmr.mx> Anyway, just an example of a small bug that crippled scaling

<spirobel:kernal.eu> amazon.com/Seagate-3-5-Inch-Enterpr…ST12000NM000J-Renewed/dp/B0BNW797DN > <@blurt4949:matrix.org> Just a cool 10.5 TB per year

<sgp_> something something ssd

<sgp_> a new one of those each year isn't exactly promising for my wallet

<syntheticbird> @spirobel:kernal.eu: best way to make your node unusable

<syntheticbird> remember

<syntheticbird> hdd

<syntheticbird> is very... VERY slow

<ravfx:xmr.mx> Just use nvme cache

<ravfx:xmr.mx> problem solved

<ravfx:xmr.mx> IMO I would just say no because it say Seagate

<kayabanerve:matrix.org> With FCMP++, old blocks can be moved to slower storage and the output DB can be pruned.

<boog900> @syntheticbird: someone needs to test cuprate with a HDD

<boog900> and with our new DB changes

<syntheticbird> @boog900: you literally did that

<syntheticbird> @boog900: ah yes

<ravfx:xmr.mx> @boog900: Are you only caching write?

<ravfx:xmr.mx> please say yes

<syntheticbird> no

<syntheticbird> (say no boog)

<ravfx:xmr.mx> 😢

<boog900> I tested USB SSD > <@syntheticbird> you literally did that

<boog900> haven't done a HDD yet tho

<syntheticbird> @boog900: oh

<spirobel:kernal.eu> should not be a bottleneck to participating in consensus. > <@syntheticbird> is very... VERY slow

<boog900> @ravfx:xmr.mx: I don't know what you mean but I got our DB around 40 to 50 GBs smaller than monerod

<syntheticbird> >enter

<syntheticbird> >"our db is 50gb smaller than monerod"

<syntheticbird> >leave

<syntheticbird> boogchad.gif

<ravfx:xmr.mx> @boog900: reading all over the place to verify transaction pollute the cache and make normal hdd extremely slow for nodes. If you only cache write, then only the most recent part of the blockchain is cached (The decoy distribution is balanced to use more recent tx), assuming at least 32GB of write cache you can make an hard drive to sync the blockchain in like 12-15 hours.

<ravfx:xmr.mx> That being said, that methode of acceleration will get deprecated with FCMP+

<boog900> @ravfx:xmr.mx: I store ringCT outputs in a tape, contiguous, so they can be indexed and don't need to be searched for

<kayabanerve:matrix.org> A cache for random reads as currently seen, combined with a migration from fast to slow storage, would presumably restore HDD usage decently.

<boog900> also from what I have read LMDB can have high write amplification which wouldn't help with syncing times

<kayabanerve:matrix.org> We'd only require some limited amount of fast storage for key data structures and recent blocks.

<ravfx:xmr.mx> I tested id, about two years ago

<ravfx:xmr.mx> with 16GB worth of write cache

<kayabanerve:matrix.org> Wallet syncing is a sequential iteration so HDDs hopefully aren't problematic there?

<boog900> @boog900: we also move block/tx blobs out of LMDB into a tape which should lessen the write amplification there

<kayabanerve:matrix.org> Outputs are extra nice as they're fixed-size though

<boog900> oh yeah 100%, I would be interested to see how well the OS caches the outputs too, as we use a memory map and most used outputs will be at the top ....

<kayabanerve:matrix.org> @boog900:monero.social: You can probably make blocks fixed-size too, if you set a default size and then have an extension node for large blocks.

<kayabanerve:matrix.org> So all blocks are the presumed case of 200 TXs, but then anything greater gets flagged, so we have fixed-size block indexing except for large blocks

<syntheticbird> optional walking

<syntheticbird> could be great indeed

<kayabanerve:matrix.org> I'm not saying worth it, I'm saying possible

<boog900> the benefit probably isn't there, under normal operation you don't really pull just block headers

<boog900> you do at startup tho

<boog900> @kayabanerve:matrix.org: this is part of the reason I didn't change the whole DB, storing everything in a different file is more effort than it is worth for most tables

<boog900> even tho it would save some GBs

<spirobel:kernal.eu> also consider this: if demand really scales this much, we can just communicate which outputs the wallet received out of band. So wallets dont have to check every single output on chain. All the information is still there and if someone really wants to scan the whole chain they can. It wouldnt be like lws. More like you selfhos [... too long, see mrelay.p2pool.observer/e/hti5rcMKOVQyV1pa ]

<articmine> tevador: This is like 6 years old. We added the long term median in 2 HF ago response to this theoretical attack that never happened

<articmine> The long term median is valuable in that it solved the MRL issue 70

<articmine> The one spam attack that had happened was in ZCash where the blocks were grown by a factor of 300x in a spam attack that lasted a year

<articmine> This proves the utter failure of the Bitcoin approach

<articmine> Interestingly the spam did not kill ZCash

<blurt4949:matrix.org> ZCash was never alive in the first place

<articmine> In my view with Monero we have a scaling system that actually works.

<spirobel:kernal.eu> hard limit 100mb for getblocks.bin response as well. > <@boog900> FWIW we cannot handle that with the current code, you will hit serialization limits in the P2P network

DataHoarder: I think some of the most recent blocks listed as unknown are from cubist blocks.p2pool.observer

as they limit the # of txs in a block

they are, and they are detected by the api I have nioc

probably monero-blocks ignored them as it's a slow call

I see some just changed from unknown to cubist

yeah, it takes time

nioc: there is some entity mining blocks that is unknown, though

not merge mining, either

yes

which qubic is

maybe some pool blocked the api lemme see

some of the unknown looked like unkown and some looked like cubist

if they are recent, say, 30m

that's fine

the old ones I see seem to be from nanopool

whose api returns 502 bad gateway

and whole site apparently

link to specific ones, nioc, I can look them up

for example blocks.p2pool.observer/block/c6df50…8dc72a5c725ea1f819c79f0398ea18e67fb

this is very likely nanopool

here is one

that is not qubic

it's not merge mining

plus other details

they can also have max ~24 txs (they limit themselves to 20tx) due to their inability to have templates larger than 896 bytes

are you asking for cubist or non cubist

the ones you think are qubic

cause I should be catching them fine, although delayed (somehow monero-blocks took 30+ minutes in some areas to complete lol)

nanopool mining stratum is up, site is down

can't track blocks they get without miner proofs but they are mining (and hopefully API backfills data, though I can fill it via other means)

the older ones I suspected because of limited txs are not cubic, they were filled with large txs

Qubic is back at around 1.4 GH/s recently

it's less tx size and more just number of txs

they should get repopulated once xmr.nanopool.org/api/v1/pool/blocks/0/500 returns proper values

anything on here with view keys blocks.p2pool.observer/proofs is automatically detected regardless of their API (but I check if it exists on API or not, I have flagged several non-reported blocks on MO and NanoPool in the past, even when they reported the corresponding Tari found merge mine (and block is in Monero)

this is a 20 tx block at 316kB blocks.p2pool.observer/block/687f02…6b507c2ecbf19ac8e23d7f2f8ae0882bd6a

11 txs and 327kB blocks.p2pool.observer/block/01aa6e…7509716c0c51e386f76ca1d415bf630eead

<namenet:matrix.org> @rucknium:monero.social Even if the price in USD is an externality, this still prices out many people. If the USD price increases by a lot and we have a base fee, wouldn't it price out people from using Monero? I'm not an expert at economics, so if I'm wrong, I'd love to learn

not merge mining, both are not qubic nioc

but thanks for looking into it :)

yep

<rucknium> @namenet:matrix.org: Recently I have suggested using network hashpower as an oracle for the purchasing power of 1 XMR.

<namenet:matrix.org> @rucknium: Do you have a proposal I can read?

<namenet:matrix.org> That sounds cool

<rucknium> No, not a full proposal yet.

<namenet:matrix.org> Will hashpower act like a proxy for energy prices?

<rucknium> Empirically and theoretically, hashpower is strongly correlated with XMR purchasing power. @namenet:matrix.org Yes, basically.

<rucknium> It doesn't have to be perfect. Just needs to get the right general area.

<articmine> @rucknium: Over time hash power will drift away from purchasing power because of Moore's law

<articmine> For peer to peer transactions blocksize is a stronger indicator

<articmine> The assumption of course is that the distribution of economic activity does not change

<ofrnxmr:xmr.mx> @blurt4949:matrix.org @ 1.4mb blocks, thats 368gb per year on a full node.

<ofrnxmr:xmr.mx> Is it a lot? Yes, but you're paying for it.

<ofrnxmr:xmr.mx> currently 1.4mb is only 0.094416xmr

<ofrnxmr:xmr.mx> Privacy's #1 tradeoff atm, is chain growth

<blurt4949:matrix.org> That's still 5x less tx volume than BTC, not to mention costs beyond strictly storage like CPU, bandwidth, or scanning time. Also a serious attacker and/or parasitic activity like mordinals have proven themselves willing to spend lots of money on their nonsense.

<blurt4949:matrix.org> Runes, ordinals, etc on Bitcoin are an even better example

<blurt4949:matrix.org> Qubic too, they spent money on a different type of attack, but the point stands

<ofrnxmr> Right? and its still > 10% above the proposal

<ofrnxmr> Cpu, bandwidth, and scanning arent an issue at these levels

<ofrnxmr> We save 75% bandwidth by fixing txrelay, cpu and scanning even at 10+mb blocks isnt really an issue

<blurt4949:matrix.org> Scanning is already one of Monero's worse UX elements and you're saying that at 4x tx volume it'll still be fine?

<ofrnxmr> yes

<blurt4949:matrix.org> Also I was more referring to IBD but yes real-time propagation is another factor

<ofrnxmr> Because, again, we have crippled software

<ofrnxmr> On stresnet, wallet scanning is like 100x'd in speed

<ofrnxmr> What used to take 30mins, takes 5 seconds

<ofrnxmr> So "monero bad" = yeah, but its not like were running optimized software

<blurt4949:matrix.org> I wasn't aware of that, is there anything you can point to on that improvement or has that not been documented yet?

<ofrnxmr> the merged prs and open/closed issues on the fcmp++ repo

<ofrnxmr> fcmp exposes a lot of efficiencies in monero, and people like jberman and jeffro are fixing them. Monero gets away with it atm, because were not having to deal with the throughput

<ofrnxmr> But i ran private testnets on both master and fcmp, and discovered that a lot of the issues that i thought were fcmp related, were actually present on master

<ofrnxmr> fixing them doesnt require a hard fork, and improved monero with or without fcmp. Not fixing them, would have been an unbearable experience to a lot of people (with a little bit of volume)

<blurt4949:matrix.org> well, fair enough on that point then, but I think the other issues are still major ones, unless CPU usage has also been vastly improved on stressnet (I suspect it's worse due to FCMP++ but maybe I'm somehow wrong on that)

<ofrnxmr> rucknium has a monitor that shows his nodes cpu usage

<ofrnxmr> And in my experience, its not noticable at all, even under intense spamming. Wallet cpu usage is much increased though

<blurt4949:matrix.org> I'm not concerned with CPU for propagation, but instead IBD. Large blocks will build up quickly

<ofrnxmr> we havent tried to sync fcmp with checkpoints yet (monero ibd skips validation by using checkpoints)

<ofrnxmr> But when i checked the number on my private testnet, fcmp 300 kb blocks were about as fast to sync as ringct 300kb ones

<blurt4949:matrix.org> I know but even a few month's worth of uncheckpointed blocks can be a lot

<ofrnxmr> (with fast sync disabled)

<blurt4949:matrix.org> sure but that's byte for byte then, not tx for tx which is more important

<ofrnxmr> So i dont think there is a noticable increase in cpu per kb, but just more kb

<articmine> naxo.com/who-we-are

<articmine> Just a little investigation

<ofrnxmr> @blurt4949:matrix.org: Thats a tradeoff of using fcmp.

<ofrnxmr> Either you accept that 40tx under ringct is 1/4 the size of fcmp, or you dont

<blurt4949:matrix.org> FCMP isn't terrible WRT RingCT but RingCT is already pretty terrible WRT Bitcoin or pretty much any transparent chain

<ofrnxmr> We do ~40tx/block today, so we are accepting a 4x in chain growth as soon as we fork

<blurt4949:matrix.org> (in terms of scaling)

<blurt4949:matrix.org> My point isn't about FCMP specifically but that it's digging us deeper in an already very deep hole

<articmine> The difference between RingCT in transaction size has already been addressed many time by Nielsen's law. This is not the real issue here

<ofrnxmr> Fcmp digs us deeper, and i believe we are accepting that as a tradeoff for the enhanced privacy

<ofrnxmr> @articmine: Exactly. The 4x increase doesnt hurt anything

<ofrnxmr> If monero tx volume increased by 4x, we'd have the same issues exposed as people are positioning as unfixable

<articmine> They are not unfixable

<articmine> In fact a lot of progress has already been made

<ofrnxmr> a lot imo, and a lot more to go

<ofrnxmr> And dont need a hard fork to fix most

<articmine> After reviewing this 10% proposal I am really very concerned.

<blurt4949:matrix.org> Yes but like I said my point is that Monero already scales poorly (meaning, in practice. The algorithms are clearly well thoughtout for theoretical scaling). FCMP doesn't make it an absurd amount worse, especially for the benefit it gives, but again that's not the point.

<articmine> For example it may in the future not be possible legally to increase the scaling rate of Monero

<blurt4949:matrix.org> @ofrnxmr: "a lot more to go" is doing a lot of heavy lifting there, any progress is great of course, but we are still nowhere near sustainable scaling

<ofrnxmr> @blurt4949:matrix.org: Its honestly just a lot of poor coding choices or bugs

<ofrnxmr> Not rebuilding the ship

<articmine> Fixing bugs is one thing, but a hard fork to allow a privacy coin to take on a CBDC is very different

<ofrnxmr> there are, of course, bigger changes that can be made to improve things, but atp there are big wins from small issues

<ofrnxmr> @articmine: Cdbcs scale though :D

<ofrnxmr> More like, a hard fork to turn monero into a meme

<articmine> If we undo scaling we may not be able to get it back

<articmine> If governments prohibited such a hard fork

<blurt4949:matrix.org> If Monero relies on government approval then it's useless to begin with so I don't follow?

<ofrnxmr> monero is the stronghold

<ofrnxmr> Every other coin with talking about has already thrown in the towel

<articmine> A government grandparents the existing consensus. Only allows fixing bugs

<blurt4949:matrix.org> Okay yeah but who cares what they allow? If Monero has to listen to governments then it's useless.

<ofrnxmr> Imo, if monero didnt exist, then full-privacy coins would be labelled as illegal

ofrnxmr how so

<blurt4949:matrix.org> That's in the process of happening across most of the developed world AFAIK

<ofrnxmr> The reason monero still is bot illegal, is the same reason that https or encryption is not illegal. Because its normalized.

<ofrnxmr> every other notable chain is normalizing surveillance

<articmine> .. exactly and if Monero could not scale making Monero scale could be illegal

<ofrnxmr> nioc: Name me 2 services that accept the private versions of optional privacy coins @nioc

<blurt4949:matrix.org> they tried to make encryption illegal back in the day (and IIRC places like UK have been trying it even recently?) but gave up because 1) obviously that's impossible and 2) encryption has a lot of uses that align with the government's goals. #2 is blatantly not the case for Monero and #1 depends on how centralized we make it.

<ofrnxmr> except, in crypto, they are winning the propaganda race

<articmine> I looked at the 10% proposal. It would take ~ 20 years to reach Bitcoins's transactions per second

<ofrnxmr> all of these privacy coins have added surveillance backdoors into their projects, and regulated entities are not safe accepting the private versions

ofrn I am clueless about the world of optional privacy coins

<blurt4949:matrix.org> nioc: that's for your own good, keep it that way

<ofrnxmr> nioc: If you send ltc mweb to binance, they just steal it. Wont refund it, wont credit jt

<ofrnxmr> At the same time they accepted xmr

<ofrnxmr> Why? Because regulations tell them its not a good idea to allow someone to hide their balance

<blurt4949:matrix.org> @articmine:monero.social: Yes the 10% proposal is bad (it's literally worse than dashjr's proposal for BTC!) but allowing massive effectively unbounded growth is not a good idea either

AIUI the 10% is not set in stone

<blurt4949:matrix.org> and yes, 6x compounding per year (assuming that is accurate) is effectively unbounded

<ofrnxmr> nioc: The idea of proposing 10% is asinine

<ofrnxmr> @blurt4949:matrix.org: Ive said a few times, but the upper bound of scaling shoukd cooincide with what we can handle

<articmine> Monero is very heavily priced. This is why the "unbounded" Monero had minimal spam when compared to the "bounded" ZCash

<ofrnxmr> Fcmp can offload historical blocks onto slower storage. Fcmp works better on hdd than ringct. Bandwidth is a non-issue. Verification has to be fast enough to not cause chain splits

<blurt4949:matrix.org> Monero has a sane fee system unlike ZEC, sure, but ZEC at least had a limit on the spamming rate.

<blurt4949:matrix.org> (Yes I know Monero has short term limits but I mean long term)

<boog900> @articmine: yay monero didn't get spammed enough where it would have caused issues with nodes! (~4 MB?)

<articmine> @ofrnxmr: Connecting the dots back to those close to government is even more asinine

<blurt4949:matrix.org> @ofrnxmr: Could the tiny tree root (or whatever the correct term is) plus the entire key image set feasibly be cached in RAM? Unless I'm missing something it should be right? If so that's at least great news

<blurt4949:matrix.org> Like a few gb I think?

<ofrnxmr:xmr.mx> @blurt4949:matrix.org: iiuc, yes, but dont quote me

<blurt4949:matrix.org> Napkin math says caching the full KI set in ram wont work at scale unfortunately

<ofrnxmr:xmr.mx> @boog900: sustained 100mb txpool, 1.5mb blocks (broke IBD), 4mb blocks (broke fluffyblock relay), etc

<boog900> As I said earlier I don't necessarily support any specific scaling proposal I just want us to actually take moneros limits into account rather than just targeting arbitrary payment networks numbers.

<boog900> I would rather blocks be too small than too big

<boog900> one is catastrophic one is not.

<blurt4949:matrix.org> Well put

<boog900> I do support assuming the limits will rise over a sufficient amount of time FWIW

<articmine> @boog900: Have you considered the possibility of not being able to reverse a change in the future for legal reasons?

<articmine> I have and it scares me

<boog900> @articmine: have you considered not having a chain to propose a change to?

<articmine> @boog900: It is nowhere that drastic

<blurt4949:matrix.org> I still don't follow your point with legality. Either we have to listen to the government (meaning Monero is useless) or we don't (in which case their declaration that a HF is illegal is irrelevant)

<boog900> @articmine: nodes falling out of consensus allowing double spends is one of the worst things for a crypto

<articmine> We have to listen to t government but we do not need to

<boog900> and like whats the point?

<boog900> we can't handle txs above the limit anyway

<ofrnxmr:xmr.mx> So 5% :P? > <@boog900> As I said earlier I don't necessarily support any specific scaling proposal I just want us to actually take moneros limits into account rather than just targeting arbitrary payment networks numbers.

<ofrnxmr:xmr.mx> Starting at 300kb :P (im joking. Dont shoot)

<blurt4949:matrix.org> @ofrnxmr:xmr.mx: Don't be crazy. 1%. Starting at 100kb.

<ofrnxmr:xmr.mx> Lets get to 0.65 tps in 2035

<blurt4949:matrix.org> 30kb blocks NOW

<articmine> @blurt4949:matrix.org: If the government says no hard fork, but what we want is already there then the question is moirt

<boog900> assuming a government would freeze the protocol but can't also enforce changes is silly IMO

<articmine> Moot

<blurt4949:matrix.org> It could just ban monero outright in that case

<boog900> they could just nuke scaling by forcing a change

<articmine> @boog900: This and banning is way harder

<boog900> its not really, it could be a soft fork

<boog900> no hard fork needed

<blurt4949:matrix.org> if they can prevent a HF then they can also ban it. If they can't ban it then they can't prevent a HF

<articmine> Not necessarily

<articmine> In an adversarial situation one wants the status quo in one favor

<boog900> A government right now could spam monero enough for all nodes to fall out of sync within a week

<boog900> these arguments are stupid

<boog900> hell they wouldn't need to spam txs they can just mine

<articmine> @boog900: ... and loose in their own courts

which govt are we talking about, the world govt?

<boog900> @articmine: relying on the legal system to keep monero alive is crazy

<boog900> not all governments play fair

<articmine> You want inertia on your side not against you

<boog900> I have already said I support "infinite" scaling FWIW

<boog900> it just has to take a sufficient amount of time

<boog900> and before then we need to work with our limits

<articmine> 15 years ago "spam" was given as the reason for crippling Bitcoin with a 1MB blocksize. The goalposts of the limitations have moved drastically. The 1MB limit remains in Bitcoin

<articmine> This is a lesson I will not forget

<boog900> so do you support allow more tx/s than monerod can handle?

<boog900> in blocks fwiw*

<boog900> on the months scale*

<articmine> It has worked for over 11 years. So yes

<articmine> The alternative is far worse

<boog900> fair, crazy.

<boog900> we have had vulnerabilities for years should we just not fix them?