Monero Research Lab Meeting - Wed 07 May 2025, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. FCMP stressnet preparation.

4. FCMP++ transaction weight formula. And PoW for high-input txs.

5. Web-of-Trust for node peer selection.

6. Unit test for implementation of subnet deduplication in peer selection algorithm.

7. Any other business

8. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#1197

[Rucknium]

Logs:

< r​ucknium:monero.social > Meeting time! #1200

< r​ucknium:monero.social > 1) Greetings

< v​tnerd:monero.social > Hi

< rbrunner > Hello

< a​rticmine:monero.social > Hi

< c​haser:monero.social > hello

< a​ntilt:we2.ee > seawas

< j​berman:monero.social > waves

< r​ucknium:monero.social > 2) Updates. When is everyone working on?

< rbrunner > Better subnet de-duplication when connecting to peers, to connect to less "spy nodes". Made good progress in the last few days.

< r​ucknium:monero.social > me: Working with rbrunner7 on subnet deduplication for peer selection and setting up tests. I took over as maintainer for the IP package on CRAN: https://cran.r-project.org/package=IP . My xmrpeers package depends on it: https://github.com/rucknium/xmrpeers , but it was removed from CRAN in January due to issues that I've now fixed (with some help from moneromooo ). Working o<clipped message

< r​ucknium:monero.social > n a custom loss function for neural net classification of real spends when multiple decoy selection algorithms are used in the wild.

< j​berman:monero.social > me: moving forward outstanding PR's, pushed a draft PR demonstrating memory safe FFI usage (seraphis-migration/monero#39), currently working on removing the FCMP++ input limit for the alpha stressnet May 21st (we seemed to have solid support in favor of PoW-enabled relay for larger input txs >8 last MRL meeting, so that nodes don't expose a vector to hog CP

< j​berman:monero.social > U verifying invalid FCMP++'s)

< v​tnerd:monero.social > Me: finished lws-frontend subaddress support and restore from height. Currently working on tx construction for same frontend and x25519 updates for arm64

< r​ucknium:monero.social > jeffro256: ping in case you want to join the meeting.

< r​ucknium:monero.social > 3) FCMP stressnet preparation.

< j​effro256:monero.social > me: successfully tested Carrot+FCMP transaction construction and scanning in the GUI wallet. Working on improving code quality wrt documentation and error handling

< r​ucknium:monero.social > It has been brought to my attention that a few PRs intended to fix issues found on the last stressnet have not yet been merged into the main Monero repo.

< r​ucknium:monero.social > ✅ mean merged. ❌ means not merged

< r​ucknium:monero.social > ✅ Blockchain: fix temp fails causing alt blocks to be permanently invalid

< r​ucknium:monero.social > ❌ Daemons processing big blocks may bump against serializer sanity checks and fail to sync

< r​ucknium:monero.social > ✅ tx_pool: update internal data structure to boost::bimap.

< r​ucknium:monero.social > ✅ cryptonote_core: only verify txpool when the hardfork value has changed.

< r​ucknium:monero.social > ❌ src: dynamic span, to calculate span limit dynamically

< r​ucknium:monero.social > ❌ src: dynamic block sync size

< r​ucknium:monero.social > So, will the FCMP stressnet have these PRs, or not? If yes, then it would be assumed that these are necessary PRs to deploy before or at the time of the FCMP hard fork.

< r​ucknium:monero.social > The three that have not been merged are important to be able to not have a netsplit when blocks are large, IIRC

< j​effro256:monero.social > The last 2 should be less controversial IMO, and could probably be merged before then. But the "Daemons processing big blocks may bump against serializer sanity checks and fail to sync" is a little tricky in that directly increasing serialization limits directly increases area of attack for DoS

< rbrunner > Looks like #9388 fell through the cracks, as nobody looked at the possible dangers of higher limits in detail ...

< j​effro256:monero.social > > The three that have not been merged are important to be able to not have a netsplit when blocks are large, IIRC

< j​effro256:monero.social > If anything it's the opposite for the 9388. Everyone having the same low limits means no netsplit, the block is just rejected outright. If people had different limits, that's what would actually cause a netsplit

< j​berman:monero.social > would need to review these all in more depth

< r​ucknium:monero.social > I recall differently.

< rbrunner > Aren't connections drop after receiving big blocks with the current limits in place? If I remember correctly it's also a security issue

< s​pirobel:kernal.eu > >Block sizes at this height were about 1.5MB. Then it banned some peers. The bans expired after 2 minutes because we set a new ban duration in the code.

< r​ucknium:monero.social > Or maybe possible netsplit in both scenarios.

< rbrunner > Problem is, the blocks were perfectly legit, just chock full with valid transactions

< r​ucknium:monero.social > IIRC, what happened early in the stressnet was that miners started mining just on top of their own blocks because they started banning other miners with big blocks.

< j​effro256:monero.social > True, might just be different types of net splits, I need to look at it again. I can imagine where the serialization limit is enforced when the packet is formatted a certain way, but if the packet changes, but contains the same block, it's accepted

< b​oog900:monero.social > here is a PR increasing the limits: monero-project/monero#9433

< j​effro256:monero.social > Ah, makes sense

< s​pirobel:kernal.eu > and another one https://github.com/spackle-xmr/monero/pull/12/files

< b​oog900:monero.social > if its a fluffy block the number of txs sent depend on the number of txs already known

< j​effro256:monero.social > Excellent point

< rbrunner > Ah, yes, I now remember #9433. So we just did not achieve consensus there, and merged the bloody thing :)

< j​effro256:monero.social > So it's deeper than just simply increasing limits, since the method by which it's limited inherently causes net splits

< r​ucknium:monero.social > IIRC, things got bad when a node fell behind by more than one block. Then, probably, the node needed to do a normal full-block sync instead of a fluffy block sync.

< rbrunner > Not sure whether the net will split, or whether the daemons with too-low limits for all the huge blocks simply stop working

< r​ucknium:monero.social > And then got banned

< b​oog900:monero.social > yeah I think to properly solve this we need a better epee bin impl

< j​effro256:monero.social > Perhaps we could name this PR "Replace serialization functions"

< rbrunner > Anyway, as I said, it's also a security problem, somebody could now spam the network so hard as to create mayhem because of those limits

< s​pirobel:kernal.eu > are the epee limits to prevent a memory leak? what if all kind of throttling / banning was removed and rethought from the ground up? it seems so entangled everywhere. be it rpc code, serialization, p2p

< rbrunner > Good luck with replacing those functions :)

< rbrunner > No, I think they are there to prevent out-of-memory attacks with specially crafted packets

< rbrunner > There are some details in the PR discussion

< r​ucknium:monero.social > IIRC, some of the limits were put in place to handle deserialization explosion during the December 2020 network attack.

< rbrunner > at #9433

< j​effro256:monero.social > Yeah what if we used a streaming serialization model instead of DOM? And maybe put it in a cool number PR number like 8867

< r​ucknium:monero.social > AFAIK, a good solution would be to prevent deserialization explosion in the first place.

< s​pirobel:kernal.eu > rbrunner: how come something like protobuf never runs into issues like this. what is wrong with epee? :D

< b​oog900:monero.social > cuprate has no limits like this 😏

< rbrunner > Maybe nobody feels like attacking protobuf?

< rbrunner > And it's not possible to exhaust the memory with Cuprate?

< rbrunner > If we just take out those limits, we don't have any either :)

< r​ucknium:monero.social > Monero Unlimited

< b​oog900:monero.social > We don't use a DOM, I don't want to say impossible but I don't know a way.

< b​oog900:monero.social > or epee bin impl is also zero copy for the most part, using references into the original bytes.

< j​effro256:monero.social > A couple things: most protobuf libraries are SAX instead of DOM meaning that they stream the data directly into the deserialized types and constrain that data to the type's requirements, which greatly reduces the funkiness of the packet you can send to a Protobuf deserializer. This is effectively what PR #8867 aims to do. Second, the epee binary format is a lot like JSON: it is se<clipped messag

< j​effro256:monero.social > lf-describing and can have fields in any order with unlimited nesting. So even when you have a SAX-like API to deserialize epee binary format, you have to contend with jumping around in different places when deserialiing member fields or implement something like lookup tables. You also generally have to ignore valid key-values in objects when you don't know the name of the field, <clipped messag

< j​effro256:monero.social > which means an attack can stuff a weird payload in there

< v​tnerd:monero.social > Protobuf doesn't use a dom, so it partially prevents the issue, although it should still be possible to explode memory with a vector of strings

< v​tnerd:monero.social > Protobufs also typically have smaller limits on total payload size, whereas we have a big buffer for block fetching

< v​tnerd:monero.social > Like if we could limit the payload to 1mb, we probably wouldn't need to place additional limita

< v​tnerd:monero.social > *limits

< j​effro256:monero.social > It might cause a netsplit, but could a good long term option, when multiple blocks are fetched, be to stream the blocks one at a time over a keepalive connection, each limited to say, 1 MB? And the receiver would only deserialize the next packet after completely processing the former ?

< s​pirobel:kernal.eu > (sounds a bit like grpc :D )

< r​ucknium:monero.social > Some ideas have been proposed and discussed. I doubt this will be settled today. Next meeting, the PRs to be included in the alpha stressnet could be decided.

< r​ucknium:monero.social > Any more issues for stressnet prep that should be discussed today?

< a​rticmine:monero.social > What happens when the block size is over 1MB?

< s​yntheticbird:monero.social > connection dropped

< r​ucknium:monero.social > The #monero-stressnet:monero.social room still exists. Some coordination can be done there. It is bridged to ##monero-stressnet on Libera IRC, I think.

< a​rticmine:monero.social > So are we capping the block size?

< rbrunner > Indirectly, yes

< a​rticmine:monero.social > There is no consensus for this

< rbrunner > And blow holes into the network as a second effect

< a​rticmine:monero.social > Period This has to go.

< j​effro256:monero.social > The other option would be to split a large block over multiple discrete packets, but this has another DoS effect: the node sits there waiting around for the 2nd packet, wasting RAM until the connection drop

< s​yntheticbird:monero.social > akshually we could add some PoW for the block fragmentation

< s​yntheticbird:monero.social > yes this is a mad idea

< s​yntheticbird:monero.social > but i don't have a better one

< b​oog900:monero.social > I have thought for a while that the P2P messages need to be rethought, we already currently have a cap on block size.

< b​oog900:monero.social > everything needs to be able to broken down to sending 1 tx at a time as that is the thing that actually has a size limit

< r​ucknium:monero.social > The stressnet continues to provide valuable feedback, even almost one year later.

< a​rticmine:monero.social > That is a sensible idea

< b​oog900:monero.social > things can be batched but if they are too large they should be broken down, this also needs to happen on the response side as the requester often doesn't know the size of things they ask for

< b​oog900:monero.social > i.e. someone asks for a block but that block is 500 MB, we need to send multiple messages to actually send the block

< a​rticmine:monero.social > ... But still multiple packet connections are the norm on the Internet

< b​oog900:monero.social > also things like the tx-pool request have to be a DOS if the tx-pool is huge, it can't be good to load all the txs into memory.

< rbrunner > Uh, the tx pool is a whole other can of worms ...

< j​effro256:monero.social > And when syncing a single block header to check PoW, you only need <96 bytes. The transaction list inside a block is actually a merkle tree, so you don't even need to send the entire transaction list at once

< a​rticmine:monero.social > In fact more often than not the transactions may already be at the receiving end

< b​oog900:monero.social > yeah let alone the fact now we send every tx, in full,when syncing not just the hashes.

< b​oog900:monero.social > before we know the chain is even valid

< j​effro256:monero.social > Exactly

< b​oog900:monero.social > rename FCMP++ to Monero 2 and change everything?

< s​yntheticbird:monero.social > I've the impression that in many aspects, the original monero code has been done the "naive way"

< s​yntheticbird:monero.social > or maybe they were ultra optimistic

< r​ucknium:monero.social > 4) FCMP++ transaction weight formula. And PoW for high-input txs. seraphis-migration/monero#26

< j​effro256:monero.social > I think they just hacked something together with 2013 cryptocurrency knowledge until it started working

< j​effro256:monero.social > Which, like, fair

< b​oog900:monero.social > they had to get the scam out quick

< a​rticmine:monero.social > Bytecoin

< r​ucknium:monero.social > So, it is thought that PoW for high-input txs is a good compromise that prevents the DoS attack vector of verification of invalid inputs proofs and allows high-input txs for good user/service experience.

< r​ucknium:monero.social > So maybe everyone can be happy

< rbrunner > Yes, somewhat surprisingly

< r​ucknium:monero.social > At the cost of more protocol complexity

< r​ucknium:monero.social > The RandomX difficulty threshold and the max allowable number of inputs is still to be decided, AFAIK. But maybe those exact values can wait until there are benchmarks on the optimized verification code.

< a​rticmine:monero.social > I don't have a case against this POW thing over 8 inputs.. This being said large transactions will have to pay a higher minimum fee so that they don't depend on smaller transactions to do the scaling for them

< a​rticmine:monero.social > As is the case bow

< a​rticmine:monero.social > Now

< a​rticmine:monero.social > Right now scaling is based upon 3000 bytes. After FCMP++ this will rise to 10000 bytes. Anything larger will need to pay a higher fee so that it can scale on its own

< a​rticmine:monero.social > Essentially every transaction needs to pay a large enough fee so that it can pay the penalty at the start of the penalty

< r​ucknium:monero.social > Is that at the minimum fee level (first tier), or a higher fee level?

< a​rticmine:monero.social > The minimum fee is currently based upon 3000 bytes and will rise to 10000 bytes. So these large transactions will have to pay a higher minimum fee depending on their size

< r​ucknium:monero.social > 5) Web-of-Trust for node peer selection.

< r​ucknium:monero.social > flip flop gave some thoughts about this at last meeting

< j​effro256:monero.social > Why isn't the minimum fee set as a factor of the weight of that transaction ?

< a​ntilt:we2.ee > Some thoughts:

< a​ntilt:we2.ee > a) We operate in an environment where a global actor may rent CPUs. I think in the long run relying on hashrate alone for consensus will be difficult. If solo-mining becomes more profitable that might raise the bar for an adversary.

< a​ntilt:we2.ee > b) WoT: A naive rating system as in pgp key signing may backfire. I thought about the concept of "anchor nodes". Would it be feasabile to zk-proof good behaviour such as availability, contribution to consensus, or even taking on a watchdog role? The idea is that an adversary might have trouble faking such a track record.

< a​ntilt:we2.ee > Just brainstorming.

< r​ucknium:monero.social > https://libera.monerologs.net/monero-research-lab/20250430#c522508-c522510

< a​rticmine:monero.social > This is the change that I will be proposing

< rbrunner > Won't the introduction of FMCP++ take away a lot of the possible / plausible reasons of attacking / subverting the network, like the "spy nodes" now?

< r​ucknium:monero.social > If I understand correctly, BTC has a ban score that raises if a node seems to be misbehaving. When ban score 100 (I think) is exceeded, the peer is banned. I think Monero does not have a ban score. An offense is either bannable immediately or not bannable.

< rbrunner > Ah, no, trying to defeat Dandelion++ stays of course

< r​ucknium:monero.social > Ban score is not exactly web of trust, but similar

< a​rticmine:monero.social > The main attack it takes away is Flood XMR / black marble

< r​ucknium:monero.social > Maybe IP-based de-anonymization is all that an adversary would have left, so more effort would go into it.

< r​ucknium:monero.social > AFAIK, Nym has done interesting things in this area, since they have some mechanism to check if a mixnet node is actually providing the bandwidth it says it does. This check is necessary for their economic rewards to mixnet nodes.

< a​rticmine:monero.social > True but Monero privacy uses the whole is greater than the sum of its parts

< a​ntilt:we2.ee > no... worst case is Monero becomes sucessful ad adopted. Then the attack vector is 50% hashrate.

< a​rticmine:monero.social > So completely breaking tracing will have an impact on IP address based attacks

< r​ucknium:monero.social > And Tor does something like Nym to measure node bandwidth, but simpler I think. Maybe their method isn't trustless.

< c​haser:monero.social > re a): not relying on heaviest-aggregate-PoW as the fork choice rule on a PoW chain seems to be contradictory. I've been thinking about a short-term PoS overlay for reducing the n-block lock depth, but the eventual chain should follow heaviest-aggregate-PoW.

< r​ucknium:monero.social > I don't think p2p web-of-trust could prevent a 51% attack.

< a​ntilt:we2.ee > yeah, WoT is ot the way to go. I thought about the concept of "anchor nodes".

< a​ntilt:we2.ee > *not

< a​rticmine:monero.social > We have to be very careful reaching conclusions here regarding POW. Accounting for the value and cost of the heat produced by POW and environmental considerations strongly favor decentralization

< a​ntilt:we2.ee > articmine:monero.social I am with you. Is solo mining profitable right now ?

< a​rticmine:monero.social > It depends on the temperature outside

< a​ntilt:we2.ee > I want some chinese miners, also.

< r​ucknium:monero.social > By a standard economic argument, mining XMR is unlikely to be very profitable as long as it is only feasibly mined by CPUs. CPU mining allows free entry, which drive economic profits to zero.

< r​ucknium:monero.social > On average

< a​rticmine:monero.social > I January are you in Alice Springs, AU or Winnipeg, CA?

< r​ucknium:monero.social > Solo mining vs pool mining are only different in the frequency of payouts, and therefore the risk.

< c​haser:monero.social > "anchor nodes" turn economically incentivized, permissionless consensus into social consensus.

< a​rticmine:monero.social > Or is the outside temperature 40 C or - 40 C?

< a​ntilt:we2.ee > yes, thats my argument: adding a trust score to augment PoW -- in case of a 51% attack.

< r​ucknium:monero.social > Having a rolling checkpoint would be a simpler 51% attack defense. It would require nodes to stay online to avoid being confused by which chain is the "correct" one.

< a​ntilt:we2.ee > yes, thats my argument: adding a trust score to augment PoW -- in case of a 51% attack. It happened to Firo. They had to augment PoW with "masternodes"

< c​haser:monero.social > how do you do that "augmentation"? the idea of PoW consensus is that you rarely if ever have to rely on social consensus, and social coordination happens outside the protocol. if you include it in the protocol, the anchors can 51% attack consensus for cheaper than adversarial hash power could.

< a​ntilt:we2.ee > yes, i thought about "light nodes" to do that

< a​ntilt:we2.ee > catch 2:2. The question is open.

< c​haser:monero.social > this would add a novel liveness assumption to the consensus model, and it's exactly something that Nakamoto consensus is designed to partially remedy.

< r​ucknium:monero.social > chaser: Right.

< a​rticmine:monero.social > Still Monero defeated a 51% attack in 2018 with the ASIC dock.

< a​rticmine:monero.social > Food for thought

< a​rticmine:monero.social > Fork

< r​ucknium:monero.social > This is in the bitcoin white paper abstract:

< r​ucknium:monero.social > > Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.

< a​ntilt:we2.ee > I just want to raise awareness that the $ cost is about 500k per month to rent 5G hashes

< r​ucknium:monero.social > So the block checkpoint defense is contrary to the bitcoin white paper protocol.

< r​ucknium:monero.social > Arguably

< a​ntilt:we2.ee > I'd like to see more rewards for miners.

< r​ucknium:monero.social > Let's "officially" end the meeting here since we are 50 minutes past the hour, but feel free to continue discussing. Thanks everyone.

< c​haser:monero.social > yes. notably, Nakamoto consensus can't answer what to do if you come online and see two equally heavy chains, or solve the problem of not hearing about a heavier chain, but it reduces the probability of those events considerably.

< c​haser:monero.social > that you can achieve only through a higher inflation rate while the fiat price of XMR stays the same, or an absurdly high minimum fee requirement in the consensus. both are unlikely, especially the former. there is a very strong consensus on Monero's monetary policy, and the demand for XMR wouldn't increase in proportion to the added supply.

< a​ntilt:we2.ee > You tough on an interesting point here... but I am so innocent, miners could get donations, right ?

< c​haser:monero.social > if the $/second PoW "security budget" for Monero is too low compared to a level you'd prefer, I hear you. the way to improve on that is to make XMR more valuable through research, development, adoption, education, community building, UX improvements, and so on.

< a​ntilt:we2.ee > Well, it could be a self-adjusting system, where the price of XMR rises with adoption, which in turn makes 51% attacks way harder to do, because hashrate increases. Thats an optimistic outlook. I like that.

< c​haser:monero.social > they already can, but you can't make sure they'll use those funds for hashing. that would require some kind of on-chain donation box that would drip its contents over time to the miners.

< c​haser:monero.social > was there an actual 51% attack in 2018?

< j​berman:monero.social > Going to share some preliminary thoughts on using groups of max 8-input membership proofs in a single tx for txs with more than 8 inputs, versus just using a single n-input membership proof

< j​berman:monero.social > Pinging kayabanerve (especially in case there are inaccuracies in here)

< j​berman:monero.social > Pros:

< j​berman:monero.social > 1) Constructing proofs for large-input txs takes forever (minute+ for 32-input+, and looks like potentially double digit minutes for >100-input proofs)

< j​berman:monero.social > On those grounds alone it probably makes sense for each tx to have groups of max 8-input proofs. Maybe kayabaNerve has thoughts on potential optimizing for that scenario?

< j​berman:monero.social > 2) Looking at preliminary verification times, max 8-input proofs make a lot of sense too, even ignoring the benefits of batched verification for multiple 8-input proofs being superior to the aggregate (mentioned by kayabaNerve)

< j​berman:monero.social > E.g. a 64-input proof is taking 2.4s to verify, compared to 1.4s for 8, 8-input proofs individually verified (179ms each)

< j​berman:monero.social > 3) There is also the benefit boog900 highlighted last MRL meeting: if an attacker wants to hog a node's CPU with invalid txs, for maximum damage, they could include all valid proofs except the last, which means they have to do additional work to construct valid individual proofs (have all valid proofs except the last to hog node resources). Constructing valid proofs is not an ins

< j​berman:monero.social > iginifcant amount of computational work

< j​berman:monero.social > 4) More conducive to multithreaded verification of single txs

< j​berman:monero.social > Cons:

< j​berman:monero.social > Proof size. A 128-input membership proof is expected to be 79232 bytes, versus 16, 8-input proofs is 153600 bytes

< j​berman:monero.social > The former is pretty comparable to CLSAG. So we're talking about large input txs nearly doubling byte size

< j​effro256:monero.social > Another benefit (or con?) that I haven't seen mentioned: it opens the door for collaborative multi-sender transaction building without the need for MPC as long as the inputs are grouped in different FCMPs. It wouldn't be very dependable since one of the parties need 8 contiguously ordered key images that don't overlap with the other party, so ....

< j​effro256:monero.social > That is, without revealing the true spent output to the other party. If you don't care about that, you can always have the other party prove the FCMP for all inputs in the group.

< j​effro256:monero.social > Although, if we write the code to support multiple FCMPs per transaction, we could likely trivially configure it so that the transaction creator can provide an arbitrary grouping of FCMPs (as long as they're of size <= 8). For example, if only a 2-in, the tx could provide 2 1-input FCMPs. That's actually sort of usable for collaborative transaction building

< j​effro256:monero.social > There's the uniformity issue of allowing arbitrary groupings, though

< j​effro256:monero.social > IDK just food for thought

< j​effro256:monero.social > > There is also the benefit boog900 highlighted last MRL meeting: if an attacker wants to hog a node's CPU with invalid txs, for maximum damage, they could include all valid proofs except the last, which means they have to do additional work to construct valid individual proofs (have all valid proofs except the last to hog node resources). Constructing valid proofs is not an insi<clipped messag

< j​effro256:monero.social > ginifcant amount of computational work

< j​effro256:monero.social > On this, we can always shuffle the order in which we verify FCMPs so it's not predictable to the sender. Then in the best case (for us) we fail after the first FCMP. The attacker can only expect 1/2 of the FCMPs to verify on average

< j​berman:monero.social > Yep^ that would make it even harder on attackers with the max 8-input proof construction

< j​berman:monero.social > main point being the max 8-input groups obligates the attacker to do more computational work on their end to attack a node

< j​effro256:monero.social > Depending on our threat model, this might be enough to thwart most of the DoS attacks without explicit PoW. Let's assume two things A) it is more expensive to prove a valid FCMP than to verify one, and B) we are okay with an 8-input FCMP verification worth of turnaround time before the sender must prove that they spent more work on this FCMP than we will take to verify it. If th<clipped messag

< j​effro256:monero.social > e tx has 1 8-input FCMP, then we try this one and if it fails, ban the peer. If it has 2 FCMPs, then if the first fails, then ban the peer. If the first succeeds, and the second fails, ban the peer. We spent time verifying two FCMPs, but we know the attack spent time proving at least one FCMP, so they spent more time than us.

< j​effro256:monero.social > This scheme could be hardened by rejecting very old FCMP reference blocks by consensus. IIRC, 3 days is the mempool timeout, so that could be the consensus timeout for FCMP reference blocks too. This would prevent building up FCMP work for weeks on end (or more) and dumping it all at once.

< j​effro256:monero.social > This won't effect cold signers or other people who sign transactions very far in advance since FCMPs can always be proved after SA/L signatures

< j​effro256:monero.social > This is also probably a good rule anyways to prevent silly wallet implementation mistakes like what happened with Wownero

< b​oog900:monero.social > it would be sad to not be able to batch verification of these single tx FCMPs

< j​effro256:monero.social > You could still batch them if they were inside a block for which PoW verification passed, i.e. during block sync

< j​effro256:monero.social > As I see it though, I really can't recommend it for mempool txs

< b​oog900:monero.social > It will be interesting to see timings if we are getting 1.4s for 64 inputs without batch verification, this could be pretty comparable to current CLSAG right? IIRC that was 1 second for the max size tx.

< j​effro256:monero.social > A 16-input CLSAG takes 3.7ms to verify on my machine, so it would be ~237ms for 64 inputs, ~5.9x faster. But you would also have to include SA/L verification times in the FCMP++ measurement if you wanted to be fair to CLSAG...

< j​effro256:monero.social > Sorry 16-member, not input

< j​effro256:monero.social > Btw CLSAG verification time scales perfectly linearly by number of inputs, since they don't batch at all, so you can freely extrapolate the verification time for N CLSAGs based on the measurement for 1 CLSAG