<r​brunner7:monero.social> Meeting in a bit more than 1 hour

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1202

<s​needlewoods_xmr:matrix.org> hello

<j​berman:monero.social> *waves*

hello

<r​brunner7:monero.social> So, what is there to report from last week?

<r​brunner7:monero.social> I finished coding the improved peer selection code. Rucknium is currently testing it.

<s​needlewoods_xmr:matrix.org> working on replacing wallet2 with Wallet API in simplewallet

<r​brunner7:monero.social> Oh, good. That will become a nice milestone.

<s​needlewoods_xmr:matrix.org> I noticed I missed some functions for the API that are in wallet.h but not in wallet.cpp for #9664

<r​brunner7:monero.social> Nothing beats actual use of an API to check it :)

<j​berman:monero.social> me: mostly worked on FCMP++ input limit-related work last week. I bumped input limits to 128, tested it out, and shared in MRL some preliminary thoughts on using groups of max 8-input proofs in single FCMP++ txs rather than individually large input proofs

<j​effro256:monero.social> Howdy sorry I'm late

<j​effro256:monero.social> Thanks for taking the initiative there !

<r​brunner7:monero.social> By the way, I tried to find some clear info about the size in bytes of FCMP++ transactions, depending on the number of inputs and outputs. I am pretty sure that exists already, and that I saw that once somewhere, but couldn't find it. Does somebody have a link?

<r​brunner7:monero.social> jeffro256: Yeah, I surpised myself to find such a nice piece of Monero coding work within my reach.

<j​effro256:monero.social> I can post a template for that today assuming default carrot tx extra size

<j​effro256:monero.social> *table not template

<r​brunner7:monero.social> It might get more interesting still because somebody might have found yet more "spy nodes" ...

<r​brunner7:monero.social> (talk over in /dev)

<j​berman:monero.social> here's a table that shows membership proof byte size by n inputs and n layers: github.com/j-berman/monero/blob/84d…cb/src/fcmp_pp/proof_len.h#L43-L173

<j​berman:monero.social> doesn't include other tx components

<j​berman:monero.social> the tree currently would have 6 layers, and bumps to 7 layers around 300mn outputs in the chain total (we're currently at ~150mn, probably a bit higher now)

<j​effro256:monero.social> SA/L proofs are an additional 384 bytes per input

<r​brunner7:monero.social> jberman: At first sight, that table looks pretty strange What is such a table needed for?

<j​berman:monero.social> We determine how large the FCMP++ proof should be from a tx's n inputs and n layers in the tree when de-serializing the tx. That calculation is slow/expensive. To avoid making de-serialization slow, we include a table with all pre-calculated values for fast lookups

<j​berman:monero.social> note if we were to stick with max 8-input proofs in single FCMP++ txs, that table would be way way smaller (only the first 8 rows)

<r​brunner7:monero.social> Ah, ok. I just hope that won't be brittle somehow.

<j​berman:monero.social> fwiw I also included a unit test that re-does the calculation for every table value and checks against the table

<j​berman:monero.social> Although that doesn't address all brittle-prone concerns

<r​brunner7:monero.social> Oh, that's nice

<r​brunner7:monero.social> Good idea

<r​brunner7:monero.social> And now to my weekly curiousity question: Anything new regarding the contest? How many entries does the leaderboard have already :)

<j​berman:monero.social> No valid submissions yet :( We got a couple that both look like AI unfortunately, neither work (one doesn't compile the other doesn't pass tests)

<j​effro256:monero.social> I've seen several private repo invite links but honestly haven't looked at any submissions

<r​brunner7:monero.social> So at least there is some movement, somewhere

<j​berman:monero.social> xmrack is reaching out to zprize contestants from here zprize.io/blog/announcing-the-2023-zprize-winners

<j​berman:monero.social> it should help that the fiat value of prizes has gone up too

<r​brunner7:monero.social> Certainly. XMR in USD has a remarkable run lately. One can only wonder.

<r​brunner7:monero.social> Alright. Anything more to discuss today beyond the reports?

<s​yntheticbird:monero.social> *Luke if you see this message please submit the best code imaginable anonymously pretty please 🙏*

<r​brunner7:monero.social> Doesn't look like it. I think we can close the meeting already. Thanks everybody for attending, read you again next week!

<s​needlewoods_xmr:matrix.org> thanks everyone

<s​needlewoods_xmr:matrix.org> I noticed I missed some functions for the API that are in wallet.h but not in wallet.cpp for #9464

<j​effro256:monero.social> rbrunner7:

<j​effro256:monero.social> matrix.monero.social/_matrix/media/…ero.social/DxYhgCCxiouMqobACZzVyYbp

<j​effro256:monero.social> Some tables for Carrot/FCMP++ tx raw byte size

<j​effro256:monero.social> "varint fields minimized" means that where there is a variable-length fields, it takes on its minimum-length value. Same for "varint fields maximized" but opposite

<r​brunner7:monero.social> Thanks, jeffro256 , very interesting!

<r​brunner7:monero.social> The minimum size is a bit of a shocker at first, frankly. But thankfully it does not get worse too fast with higher numbers of inputs and outputs. Sizes go back more or less to pre-bulletproof times.

<o​frnxmr:monero.social> Looks like size growing by ~50% everytime you double inputs... sooo.. more inputs = less bloat 🙃?

<o​frnxmr:monero.social> re jeffro256: 's chart

<o​frnxmr:monero.social> Like, the chart makes 2x4 input tx's look terrible compared to 1x8

<o​frnxmr:monero.social> (20kb vs 15)

<j​effro256:monero.social> This is true, the FCMPs scale decently in terms of size with increasing number of inputs. The main issue is turnaround CPU time for verification

<o​frnxmr:monero.social> how does the cpu time scale though? 4x8 vs 2x16 vs 1x32

<o​frnxmr:monero.social> If its linear, i'm not sure i'm understanding the/any reason for limiting

jeffros ods chart node2.monerodevs.org:9000/uploads/2…108e3c87161/carrot_fcmp_tx_size.ods

<j​effro256:monero.social> Because a high-input FCMP will take a concretely high amount of CPU time to verify. If a peer spams fake txs, this can cause a DoS attack

<j​effro256:monero.social> ofrnxmr: matrix.to/#/!toFcRZtpaiwiyapgVO:mat…a=monero.social&via=cypherstack.com

<e​longated:matrix.org> Block peer if they send more than a few fake txs

<j​effro256:monero.social> You can't block someone without first attempting to verify the transaction, which is the part that takes time

<o​frnxmr:monero.social> Why would you need more ips?

<o​frnxmr:monero.social> And you can already hammer a node with simple rpc calls

<o​frnxmr:monero.social> Dont have to send anything to the node

<e​longated:matrix.org> So it can dos with 2-3txs ?

<o​frnxmr:monero.social> Theres nothing stopping me from submitting 1000s of tx immediately right now

<o​frnxmr:monero.social> From 1 ip

<j​effro256:monero.social> Presumably you get blocked after a failed verification time. So if some operation takes 200ms and then you can ban, versus 20ms and then you can ban, to get the target to waste 200ms of CPU time, you need 10x more IPs with the 20ms operation

<p​lowsof:matrix.org> public rpc nodes have many vulnerabilities as we know

<j​effro256:monero.social> I'm taking about the p2p protocol

<o​frnxmr:monero.social> How are you going to block me when i submit the tx before you verify any?

<e​longated:matrix.org> 200ms to verify tx with how many inputs ?

<o​frnxmr:monero.social> Hm.

<o​frnxmr:monero.social> 8

<j​effro256:monero.social> With a sufficiently high input count and depending on the target CPU capabilities and what you're trying to achieve with an attack

<e​longated:matrix.org> And how much time for 16/32 inputs ?

<o​frnxmr:monero.social> Linear, sounds like

<o​frnxmr:monero.social> An 80inout = 2s

<o​frnxmr:monero.social> (seems what jberman was saying)

<j​effro256:monero.social> Submitting the txs don't really take any CPU time besides what is need to allocate buffers, etc. FCMP verification *does* take a non-trivial amount of CPU time

<o​frnxmr:monero.social> An 80input = 2s

<j​effro256:monero.social> I don't have to verify anything you send me if I don't want to

<o​frnxmr:monero.social> Ok, so if i consolidate 100 inputs, youll block my node?

<o​frnxmr:monero.social> I dont see how this prevents anything

<e​longated:matrix.org> Don’t need 80 inputs, 16 input 400ms 32 input 800ms would be bearable

<e​longated:matrix.org> This is all without optimised code right ?

<o​frnxmr:monero.social> If i'm relaying 80 inputs, i'm doing it regardless of whether its 200ms * 8 or 2000ms * 1

<j​effro256:monero.social> Idk if I have exact numbers for this on hand for a realistic number of FCMP tree layers atm, sorry

<e​longated:matrix.org> To verify

<e​longated:matrix.org> Let’s get numbers before we cap 8 input

<o​frnxmr:monero.social> or, i guess it depends if its a malicious tx that fails to verifh

<j​effro256:monero.social> If we limit the tx input count by consensus rule, I won't ever call `verify()` on a tx with 100 inputs and skip the DoS

<j​effro256:monero.social> If >350ms on my machine, I know that

<j​effro256:monero.social> Which is pretty significant

<e​longated:matrix.org> That’s for 16 inputs ?

<o​frnxmr:monero.social> No way to do some sort of light verification before spending time on the full tx?

<o​frnxmr:monero.social> **jeffro's AMA**

<j​effro256:monero.social> I'll just ban you by reason of sending me a 100-in tx to deserialize when you should know it isn't allowed

<b​oog900:monero.social> libera.monerologs.net/monero-research-lab/20250507#c524274

<j​effro256:monero.social> This is basically the PoW idea proposed in the MRL meetings

<j​effro256:monero.social> Could be >1000x times faster to verify RandomX PoW than FCMP proofs for high-input txs

<o​frnxmr:monero.social> libera.monerologs.net/monero-research-lab/20250507#c524279

<o​frnxmr:monero.social> I can also agree that we don't _need_ huge input sizes like 146 (which is currently obnoxiously 1/3rd of the block size)

<b​oog900:monero.social> if we take the current consensus limit on tx size that would be about 120 inputs max, which seems fine 🤷

<o​frnxmr:monero.social> But that 8 harms ux and bloats nodes

<b​oog900:monero.social> UX?

<j​effro256:monero.social> monero-project/monero-gui #4443

<b​oog900:monero.social> it's batches of 8 inputs per FCMP, the proposal was for a single tx to have multiple FCMPs

<b​oog900:monero.social> I see the bloat argument - its a trade off

<j​effro256:monero.social> Yes, this is also the other dimension that I hadn't brought up yet that I should have

<b​oog900:monero.social> what do you value more/where are the limits

<j​effro256:monero.social> If we keep using the checkpoint system in the future, the asymptotic cost of CPU verification time of the chain is O(1). But the bytesize bloat stays forever

<b​oog900:monero.social> but if the P2P network can't handle txs that take 2 seconds to verify, we can't get the savings without putting nodes at risk.

<o​frnxmr:monero.social> spam attacks can, imo, cripple the network (with valid tx)

<b​oog900:monero.social> I agree, it will be interesting to see how much that is due to inefficient in the implementation rather than the tx protocol though

<b​oog900:monero.social> I would lean to it more being a monerod issue rather than a Monero issue

<s​yntheticbird:monero.social> are there Monero issues that aren't monerod issues ?

<b​oog900:monero.social> every Monero issue is a monerod issue not every monerod issue is a Monero issue 🧠

<o​frnxmr:monero.social> P2pool consolidations

<s​yntheticbird:monero.social> don't hesitate to repeat it for the next century or so, maybe sech1 will consider it

<o​frnxmr:monero.social> Probably an elephant in the room

<s​yntheticbird:monero.social> extremely small elephant imo

<s​yntheticbird:monero.social> inb4 400 page essay about why p2pool consolidation is le bad

<e​longated:matrix.org> Small elephant with big bloat

<o​frnxmr:monero.social> Non-p2pool consolidations are one thing, but most "normal" people end up with thousands of inputs of less than 0.0005 xmr

<b​oog900:monero.social> its average 😠

<o​frnxmr:monero.social> Maybe an order of magnitude off,its been a whole

<s​yntheticbird:monero.social> Want to reduce bloat lads? JUST ZIP THE DATABASE

<o​frnxmr:monero.social> Ozempic

<s​yntheticbird:monero.social> anyway im very happy to have led this serious channel into a useless discussion

<o​frnxmr:monero.social> thanks syn

<o​frnxmr:monero.social> the 16*8 isnt that much larger than 146 current

<o​frnxmr:monero.social> About 171kb for 146 inouts using the 16*8 math

<s​yntheticbird:monero.social> # "x*y math"

<o​frnxmr:monero.social> About 70% larger🥲

<o​frnxmr:monero.social> The issue of peers spamming bad tx via p2p - what stops my node from relaying 1000 tx to your node? You can block me after the first bad one, but you're still stuck with the 999 other tx

<o​frnxmr:monero.social> Its not like the node only allows 1tx per node, and i dont think nodes track where the txs came from (?)

<b​oog900:monero.social> the txs are added one by one, if one is invalid the others are dropped

<b​oog900:monero.social> we verify 1 and don't verify the other 999

<s​yntheticbird:monero.social> inb4 but muh bad tx can be put at the end

<e​longated:matrix.org> Track which tx was sent by which peer, discard tx pending verification which was going to be blocked when they sent 2-3 fake txs ?

<s​yntheticbird:monero.social> at which jeffro said it could be shuffled

<b​oog900:monero.social> any valid txs have to pay the fee

<s​yntheticbird:monero.social> ?

<b​oog900:monero.social> github.com/monero-project/monero/bl…ryptonote_protocol_handler.inl#L944

<b​oog900:monero.social> the loop adding txs just exits

<b​oog900:monero.social> if you put the invalid tx at the end then all the first txs will get added to the tx-pool

<s​yntheticbird:monero.social> yes, i assumed we were talking of trying to bloat computational time

<s​yntheticbird:monero.social> if sending the bad txs first the rest of the txs are going to be dropped. so you could send them at the end instead so that it also lose time verifying the valid one

<b​oog900:monero.social> although yes you will have spent time, the txs are still valid so no different than receiving a valid tx on its own

<b​oog900:monero.social> the tx is still added to the pool and has to pay a fee

<s​yntheticbird:monero.social> 💡 very true lol

<r​ucknium:monero.social> This isn't just a theoretical risk. PirateChain had severe chainsplits when it was hit with tx spam because verification time of Zcash-Sapling txs is high: web.archive.org/web/20230803171107/…ains_045_spam_attack_2_months_later

<r​ucknium:monero.social> AFAIK, PirateChain's problem was too many _valid_ tx at very low tx fee. What is being discussed with FCMP `MAX_INPUTS` is defense against invalid txs, since it is "assumed" that Monero's fee structure protects against valid tx spam that would cause node instability.

<r​ucknium:monero.social> > FAUSA's impact on mining was significant and immediately apparent. At times, up to 80% or more of the network's total hashrate was dropped, but this number stabilized at approximately 60%. This "lost" hashrate was unable to keep up with the blocks from other miners, resulting in at least 3 distinct and competing chains which I was able to identify. At some points, some of the sl<clipped messa

<r​ucknium:monero.social> ow miners were able to catch up with the main chain, only to split off again soon after. The numerous forks relatively quickly re-established consensus after the conclusion of FAUSA.

<s​yntheticbird:monero.social> Can't wait for stressnet this may to start placing bet on if its so over

<j​effro256:monero.social> Rucknium: do you know off hand what the Sapling verification times are ?

<r​ucknium:monero.social> No