15:27:12 I cant make it for today's meeting but I would like to share my initial thoughts about the proposed FCMP+SA+L. First, it is really amazing to see kayaba and tevador exploring new ways to integrate FCMP into Monero now. IIUC, the proposed scheme would replace Seraphis entirely (from the functional POV) if it can solve the FS problem. The question is then what do we do? I dont have enough knowledge to give an educated answer now so my immediate task is to understand it since it will have a huge impact on all development tasks of everyone. I do see a relatively clear and conservative path to regtest/testnet/mainnet with seraphis (regarding implementation and its crypto solidity). I do not see the same for FCMP+SA+L as I dont grok it. So I will try, for the ne xt weeks, to only focus on understanding it. 16:04:16 MRL meeting in this channel in one hour. 16:56:25 I'd clarify "would" to "could" and continue my immediate advocacy for a shorter timeline, FCMP for RingCT with large amounts of work reusable by Seraphis. If once that's done, there's interest in adding F-S, we can. If once that's done, there's interest in adding the wallet code for it (can be done at any point, not a hard fork), we can. If once that's done, we want to move to JAM TIS, or to Seraphis + JAMTIS, or release a new TX version, we can. It's a literal sea of options which can be discussed nearly infinitely. That's why I'm saying the core of this, FCMPs on RingCT, faster than Seraphis, with large swaths reusable for Seraphis, is a good proposal we should move forward with now (as prior discussed). 17:00:44 Meeting time! https://github.com/monero-project/meta/issues/992 17:00:50 1) Greetings 17:01:00 hello 17:01:03 Hello 17:01:15 On the contrary (which hopefully we can did into more in the meeting), I'm opposed to doing this upgrade AND Seraphis for these reasons: https://gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86?permalink_comment_id=5027156#gistcomment-5027156. If we are going to do the FCMP+SA+L networj upgrade, we should ditch the idea of doing Seraphis altogether. Trying to do 2 monu mental changes to the protocol back-to-back is not a great idea in my opinion. 17:01:19 Howdy btw 17:01:38 👋 17:01:51 hello 17:02:30 hello 17:04:26 2) Updates. What is everyone working on? 17:04:35 jeffro256: The whole point was to minimize the amount of changes it is. It's theoretically only a replacement for the CLSAG with the new tree database from a protocol point of view. It doesn't inherently introduce new keys/TX structures/wallet send protocols. 17:05:05 Let's discuss FCMP and Seraphis when we get to that agenda item. Thanks. 17:05:35 (sorry for breaking the meeting timeline, I'll hold off on further comments) 17:06:05 me: I developed the first version of `xmrpeers`, an R package for analysis of Monero's peer-to-peer node network: https://github.com/Rucknium/xmrpeers . A few people are using it to collect data on peer-to-peer network latency when using `set_log net.p2p.msg:INFO`. 17:08:33 me: recently finished the async scanner using the Seraphis lib, I'm seeing 50-60% faster syncing over clearnet using one of gingeropolous ' remote nodes, and wrote up a proposed plan to deprecate wallet2 + replace with Seraphis lib while keeping the existing wallet API: https://github.com/seraphis-migration/strategy/issues/3 17:08:33 @Rucknium that's nice. to be clear, the data can be collected without handling R, right? 17:09:28 me: finishing last bits of Cuprate's database API, somewhat equivalent to `monerod`'s BlockchainLMDB 17:10:18 chaser: You can use the `set_log net.p2p.msg:INFO` to get the info on who is sending you txs and when, but you don't get a ping network latency measurement from just the logs. It is best to know when your peer is _sending_ that data, not just when you receive it. The latency measurement in `xmrpeers` is for the latency measurement. 17:11:05 Or anyone can write their own pinger and parse the log to get their peer IP addresses. 17:11:10 I see, thanks 17:12:07 Good work Rucknium. Would this work allow us to empirically test the privacy of Dandelion++? 17:12:31 jeffro256: I hope so. I can discuss more in the next agenda item 17:12:38 kk 17:12:45 3) Discuss: Potential measures against a black marble attack https://github.com/monero-project/research-lab/issues/119 17:13:03 There was possible spam on April 12-13 again. Then a large number of consolidation transactions April 16-17. 17:13:58 I have been working on collecting data that can help guess the node origin of the spam transactions. I originally was going to use the techniques in Cao, Yu, Decouchant, Luo, & Verissimo (2020) "Exploring the Monero peer-to-peer network." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=99 17:14:12 to collect the node list and edge list of the P2P network graph. Then I noticed the relevant log messages had `last_seen: Never`. Cao et al. (2020) used `last_seen` to figure out which peers were connected (i.e. the get the network edge list). 17:14:36 Why would a spam attacker consolidate funds if they intend to produce more spam? Maybe they had a very limited budget and each enote is worth less than the fees required to create a 1 input tx with that enote? 17:15:45 jeffro256: Maybe they don't intend to produce more spam. But your other hypothesis is possible. Their spamming script may require more fees per output. 17:16:15 I did some searching and found that moneromooo patched the `last_seen` potential privacy issue: https://github.com/monero-project/monero/pull/5481 https://github.com/monero-project/monero/pull/5682 17:17:30 So that would make it much harder to do statistical analysis to defeat Dandelion++ like suggested by the simulations of Sharma, Gosain, & Diaz (2022) "On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=130 17:18:15 But with a strong enough signal by the spam, maybe we can still narrow down the spam origin, which would provide more evidence that this is actually spam. 17:18:40 If they do us the "favor" to continue to spam? 17:19:19 Those hundreds of consolidation txs are a very strong signal. I am collecting data now because without log data collection, the p2p message data is lost forever. Then I can analyze later. 17:20:02 We should have several sets of log data for the April 12-13 and 16-17 incidents already. 17:20:18 Interesting. 17:20:19 So I could analyze just that data if no more suspected spam occurs. 17:22:02 My opinion: If Cypher Stack is not able to produce a mathematics security proof for Generalized Bulletproofs in their expected 1.5 months of work, a hard fork to increase ring size and maybe change tx fees should be considered and prepared for. 17:22:33 In that situation, it is not clear that FCMP will be possible with the Curve Trees design. 17:22:44 That possible mitigations GitHub issue excludes the "hot topic" everybody is talking about, FCMPs ... 17:24:25 rbrunner: It is listed under "omitted measures" https://github.com/monero-project/research-lab/issues/119 : "introduce full-chain membership proofs (FCMP) with Seraphis: FCMPs are the ultimate solution to attacks related to ring signatures, but they are currently not in a deployable state. ideally, they would be introduced together with the Seraphis transaction protocol. these two , presuming the current rate of progress won't change, are estimated to be ready in 5+ years." 17:24:50 Yeah, "omitted", not "excluded" 17:25:10 I agree with that omission. 17:25:58 I think that it be be worth researching into how effective FCMPs would actually be from large rings in REAL terms, in regards to decoy flood attacks. if I, as a flooder, own 90% of all enotes, and thus 90% of decoys, what is the actual privacy impact for non-specifically targeted individuals if the EFFECTIVE ref set size is 16 versus half the chain? 17:26:04 The long and detailed comments that jeffro256 linked to right at the start of the meeting look interesting at first glance, but I think time would be needed to digest it all 17:26:07 We should have a fallback for if FCMPs don't work out, which they may simply 'politically'. 17:28:03 I think we are moving to the next agenda item: 17:28:04 I favor the FCMP+SA+L proposal, but I don't consider FCMPs as a short/mid-term solution to the black marble flood threat, not even with the best-case timeline (12 months). I think a fork with any one or multiples of the listed countermeasures is warranted, because right now, we have our guards down. 17:28:08 4) Research Pre-Seraphis Full-Chain Membership Proofs https://gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86 17:28:13 FCMPs are amazing and necessary for preventing EAE, EABE, and other counterparty de-anonymizing attacks, but how useful are they really against decoy flood attacks versus large rings? I don't have any formal answers, although if you want to perform a deterministic tx graph analysis with a decoy flood, it gets exponentially larger with a bigger ring size 17:28:33 *larger->harder 17:28:39 Assuming that we do that research, and it would produce results, how would we *judge* those results then? 17:29:08 There is in any case a large "psychological" factor in all this 17:29:13 @jeffro256 Rings fundamentally don't stop attacks such as the EAE and have explicitly bad spend patterns. 17:29:14 Spam under FCMPs is ignored. Spam under CLSAG needs to be proportionately adjusted to. 17:29:15 That's incredibly surface commentary but it doesn't change it's not wrong. 17:29:24 rbrunner: First, define an economic utility function for Monero users.... 17:29:50 (And you acknowledged the first set, I know) 17:30:59 Should we take 5 minutes to read jeffro256 's comments on FCMP/Seraphis that he posted before the meeting? https://gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86?permalink_comment_id=5027156#gistcomment-5027156 17:31:48 I wouldn't say spam is ignored under FCMPs, just from a privacy perspective. From a decentralization perspective, spam still needs to be considered and adjusted to if we don't want to end up like Ethereum with an unmanagebly larger L1, that doesn't allow for end users to run nodes 17:32:02 To read "Quick Summary of Concerns with FCMP-RCT" then, in 5 minutes 17:32:08 Ok. Do we know if this assumption is true? "For efficiency, security, cryptographic clarity, elliptic curve changes, perfect forward secrecy, or other inherent protocol properties, the network WILL want to migrate to Seraphis at SOME point. If this assumption is NOT true (which could possibly be the case since FCMP-RCT achieves feature parity with Seraphis with F-S added), then yo u can ignore this entire post altogether." 17:34:31 Can't judge. Just want to make sure everybody understand that Seraphis and Jamtis are already *implemented*, by an effort of about 1.5 man years 17:34:39 Sorry forgot about meeting, hi 17:35:06 It took that much for a careful, solidly engineered Seraphis and Jamtis library 17:35:16 "only" you could say 17:35:52 (I mean that "only a library" of all this effort may look small) 17:36:29 What is missing is all the rest, a decent wallet, a new tx class, and more 17:36:49 The post is mainly against doing FCMP-RCT as a stop-gap measure. It has theoretically feature parity with Seraphis. So we should decide to do one or the other for the health of the protocol IMO. Seraphis (even with FCMPs) is *probably* always going to have less CPU required for nodes, unless there's something that I'm not seeing. Seraphis has more upfront work. Seraphis has less t echnical debt for future upgrades inherently because of the proof structure. FCMP-RCT can be done sooner. If we do Jamtis on RingCT after FCMPs, that will likely cement us into FCMP-RCT for a long time. Seraphis integration has a head start. FCMP-RCT probably takes less work to first hard fork. There are a lot of considerations to make 17:37:33 But just to re-iterate, because I think it's impiortant, that post is against doing FCMP-RCT AND Seraphis 17:37:44 I have so many disagreements there yet I don't want to be a dick. 17:37:58 It's okay, you can be a dick 17:38:32 It might take weeks to discuss all this to a good extent ... 17:39:25 I disagree every listed section is so notably modified. 17:39:25 The Seraphis design would be simpler and potentially more efficient. The exact bounds aren't known yet. 17:39:26 We don't need to increase reliance on wallet2. cc jberman 17:39:33 Better weeks to discuss then make the wrong decision imo 17:40:00 They rewrote the wallet2 API around the Seraphis lib, which includes RingCT, for cleanliness. 17:40:00 We can discuss deploying that pre-Seraphis. 17:40:06 Right, but there are young horses here that just long to finally start the race :) 17:40:21 I'm also looking through the lens of someone who looks at the Blockchain code a lot, is currently working on implementation of a network upgrade, someone who values L1 simplicity seriously, and doesn't necessarily have FCMPs as my firstmost priority 17:40:36 kayabanerve @kayabanerve:monero.social: did you figure out the offloading for signing (for hardware wallets?) 17:40:43 "Overkill" They're more efficient than large CLSAGs IIRC, and the research carries to Seraphis. 17:40:57 @Reuben same proof separation as Lelantus (Spark)/Seraphis. 17:41:06 Nice 17:41:33 rbrunner: Seraphis is years out. I made a proposal for 6-12m. Every week in meetings is another week I wouldn't call Monero more sender private than plausible deniability. 17:41:42 What about multisig ? 17:42:01 So yes, I want to actually want to move forward and not debate in committee ad infinitum. 17:42:15 Yeah, if you can make those 6-12m. 17:42:18 Iirc Triptych wasn't implemented cause of poo multisig. 17:42:20 Overkill from an engineering perspective in terms of effort required, changes in how we model privacy, etc. Again, we can do FCMPs on Seraphis, I'm not opposed to that, but as stated in the post, spam attacks shouldn't be a factor each which way 17:42:40 It's a generalized schnorr protocol and Schnorr multisig quite directly applies (by eye, not by academic proofs). 17:42:58 Nice 17:43:04 @jeffro256 The spam attacks, if for poisoned outputs, should be. Rings are at best a stop gap there. 17:43:40 Jeffro what would you need to put kayabas proposal to funding as-is? 17:43:55 Also, larger attack surface due to SA+L??? 17:43:56 It's using a proof proven from 2009. Seraphis uses a novel proof. 17:44:16 (Though i did suggest replacing the Seraphis proof with that 2009 proof as well) 17:44:45 plowsof: I don't understand the question. Do you mean "need" financially? 17:44:46 Yes, we have to argue the statement composition secure, yet how is that a "much larger attack surface"? 17:45:04 On technical debt: Current monerod code did not handle the suspected spam very well. If tx verification is a lot slower with FCMP, won't the monerod code have to improve to avoid major problems? 17:45:19 > then background syncing will necessarily consume more storage/RAM. 17:45:21 ??? 17:45:39 It's explained later down, in more detail, I think 17:45:44 Not financial, just unknowns to be known if any or its a fundamental disagreement of our near futures dorection 17:45:46 Wallets wouldn't sync FCMPs, they'd be pruned. There's no impact there. 17:46:09 Each individual proof component in Seraphis has a lower attack surface being split into ownership, unspentness, membership. Overall is a different story. But in effect, one would have change larger portions of the proof assuming proof changes in the future, and those changes are more compartamentalized under Seraphis 17:46:13 To get FCMP-RCT done within the timeframe, it would probably make sense to do implement wallet2 FWIW 17:46:26 to implement in wallet2* 17:46:34 And I'd probably agree w those changes BTW 17:46:35 Oh, literally due to storing more potential key images, yet that ignores how it adds ovks. 17:46:41 the wallet API is not rewritten yet for Seraphis lib, I just wrote up a proposal to do that here and estimated full-time work minimum of 3-6 months: https://github.com/seraphis-migration/strategy/issues/3 17:47:04 That is what some people here fear to hear, jberm, that "yet more complicated wallet2" story 17:47:06 Assuming Seraphis after FCMP-RCT, it's probably a fair assessment that the Seraphis lib would then be extended to also construct FCMP-RCT txs in order to deprecate wallet2 17:47:12 Yes but background view key syncers have to store key images that they don't know whether or not are theirs (since they don't have the spend key) 17:47:42 My literal take is the document is overly critical and conflates a variety of different things. It says FCMPs is worse because X, yet not because X disappears with Seraphis, because it's just under a different name for whose problem it is. That applies to several of these points. 17:48:12 With OVK, depending on the definiton, that issue might disappear 17:48:21 The "attack surface" and "sync" comments trivially classify there. 17:49:24 Do OVKs require changes to the cryptonote addressing scheme? 17:49:54 I'm fine respecting @jeffro256 as a developer while completely disagreeing with at least the presentation of their analysis. I don't care to bicker with a friend for the next hour in public so I'm fine leaving them the "opposition" and the community to think about it independently. 17:49:56 No. 17:50:18 OVKs and F-S don't require a new protocol. Solely newly generated addresses to take advantage of those featurez. 17:50:33 *features 17:50:46 kayabanerve, if you say 6-12m, what point would be reached then? Feature complete, and in *theory*, from a purely technical standpoint, ready for hardfork? 17:51:02 jberman: Thank you for the context. 17:51:25 IMHO, we need to bicker on this because it is a very important fork in the road. 17:51:56 Agree, even it may turn out to be hard 17:52:20 I'm confident, within 6m, we can have an impl for auditing. For integration, please ask jberman who is my deferred to. 17:52:21 Let's also clarify as impl + audits of impl + PR integrating, and drop the integration review when discussing timeline. 17:52:58 Maybe I am bit overly dramatic, but this has the potential that in the end 2 teams walk into 2 different directions, which would be quite unfortunate 17:53:12 No. I need to write a full response to jeffro256 when I'm not on an IM platform, and potentially privately reach out to form a mutual summary which provides clear comments for review (without conflicts). 17:54:00 I don't need to feel like I need to immediately respond, and write short/snappy messages which don't best represent myself nor my thoughts. 17:54:29 Sounds good to me. Might mean that the discussion today won't get much further, but then be it so. 17:54:42 Ok. We can wait for a full response to jeffro256 's comments. 17:54:45 The core of the FCMP work, 80% of this proposal, should be reusable under Seraphis. I keep saying that to show we're not yet actually deciding and to try and move forward as I can :/ 17:55:07 I might be wrong, but I think the confusion here might stem from the fact that I'm looking through the lens on a person that has to look at and maintain BOTH protocols if they BOTH get implemented. A lot of these points aren't harping on something lacking in FCMP-RCT, it's harping on the added complexities and worse overall timelines regarding X if we try to do both 17:55:21 That way, we can make distinct discussions when we're farther down the road. That wastes effort at worst, that doesn't leave us with the wrong decision. 17:55:25 jberman: is there a rough timeline on your side of the integration for FCMPs? (excluding review time) 17:55:55 4-6 months on my end 17:56:00 Is the addressing change/work a re-computation for sending only? Meaning calculating received funds and spent funds will not change? 17:56:26 I for one don't see anybody pressuring kayabanerve into fast snappy answers, and if he fails to come up with them, he will have lost :) 17:56:35 There is no address change proposed with FCMPs. 17:56:53 Old addresses won't have OVKs and F-S. Newly generated wallets will. 17:57:15 (if implemented. Implementation isn't required for full set privacy alone) 17:57:36 Ok, are you still adding view balance key to FCMP proposal? I'm eyeballing LWS changes needed 17:57:38 That means finding received works as it prior did. 17:57:46 I probably need to clarify, I'm not entirely opposed to do FCMP-RCT. I'm biased towards Seraphis obviously, but I'm okay with ONLY doing FCMP-RCT, especially since feature parity seems to be achieved. But what is unacceptable to me is trying to do both for numerous reasons related to health of future Monero Core code 17:58:10 New wallets would be able to output an outgoing view key to calculate key images. I believe that's view balance 17:58:24 Maybe it would simplify things for the discussion if anything beyond pure FCMP-RCT is left out for the time being. Things like OVK and F-S on top of that. 17:58:52 I understand those are not really essential to the proposal. 17:59:05 Things can fly already without them. 17:59:07 yes, the view key currently cannot compute key images, so LWS only knows "candidate" spends. Sounds like I may need a slight LWS update for this 17:59:16 adding the OVK scheme to wallets would add maybe 1-2mo+ to the 4-6mo estimate 17:59:17 I also don't want to be rude and propose we get rid of Seraphis. If jeffro256 wants to discuss one or the other, I'll say it's feature complete with Seraphis, on a potentially quicker timeline, with much more incremental changes and no migration. 17:59:48 rbrunner: It is for jeffro who wants to discuss one or the other. 18:00:04 my main disagreement with the post is the implication that funds are either-or for this or Seraphis 18:00:09 @jberman Though that can be done outside any hard fork. It's purely wallet side. 18:00:11 I've seen no reason to suggest this would be the case, I think Seraphis will have no problem getting the funds it needs either 18:00:34 The most significant impact on current dev resources for Seraphis I think is that it would pull me away from coding on Seraphis 18:00:42 jberman: I don't think thats true for funds, but could be true for current usable manpower 18:00:52 If anything, people may find it easier to compromise on a FCMP+RCT proposal that is as small as possible 18:01:00 I disagree with that premise as well, and it's why I've been trying to move forward this CCS which is largely reusable for Seraphis. It isn't explicitly one or the other. 18:01:17 I also disagree about the relative importance of FCMPs, I personally see it as priority #1 even assuming black marble attacks don't matter, strictly for EAE 18:01:32 Like a lot of R&D/charity/etc, Monero community has shown it has deeper pockets than the people that are physically able to enact the change 18:01:36 so I don't think I will be convinced to not work on it 18:01:42 rbrunner: RingCT and Seraphis have different first layers in the circuit. I would have to pick one. 18:02:30 A bit unfortunate that my "crypto" knowledge is not sufficient to understand that ... 18:02:39 I see removing rings and F-S as our only first priority with literally everything else secondary, so long as it meets setup (trustless)/performance requirements. 18:02:57 I as assuming a clear and reasonable path first to FCMP+RCT and then Seraphis+FCMP is possible 18:03:03 *I was 18:03:27 Ignoring the tech debt concerns, the work for the former covers most of the latter. 18:04:19 Is this a "yes" to my assumption? Sorry, I am not sure 18:04:51 Pretty much 18:04:57 Ok, thanks :) 18:05:41 So we could make it as small as possible, and look at OVK and F-S and possibly other things only later 18:06:15 The CCS is so small. The initial deployment proposed is so small. 18:06:17 You said it wonderfully, that we are swimming in a veritable sea of options. This makes it difficult, no? 18:07:00 So we don't need to make it as small as possible because I already did that to minimize contention :/ 18:07:15 :D 18:07:47 It would help at least me to leave out any mention of stuff like OVK, F-S and whatnot *for the time being* 18:08:03 Everything is so complicated and multifacted already without that stuff. 18:08:07 Just saying :) 18:08:24 Idk if it's helpful to leave out, unfortunately, because Seraphis will 100% add those things in the key migration 18:08:45 FCMP-RCT can do it incrementally, though 18:08:54 It's the potential path forward after and notes the benefits of this work, even if not realized yet. 18:09:03 ^^^ 18:09:24 So yes, it's simpler to leave out but less fair to the proposal. 18:09:50 Now I am totally confused. I hope that's only a temporary state. 18:09:55 Tbh, I wouldn't really consider FCMP-RCT over Seraphis for the network if those things weren't possible at some point in the future 18:10:24 And jeffro will only consider FCMP-RCT if over Seraphis. 18:10:39 jeffro256: any particular reason why ? 18:10:46 rbrunner: do you want to buy a computer with 8 GB of RAM soldered in, or upgradeable to 32 GB? 18:11:32 Well, if everything goes as planned, Seraphis will arrive in a reasonable timeframe, to the rescue. Thinking positively 18:11:42 My CCS is for 8 GB. I am noting the option for 32 GB in the future as my due diligence because that's a notable feature. 18:11:47 Because then assuming we want those things, we would have to do another non-trivial network upgrade to get them. Seraphis already does that, so we should go with that instead. 18:12:16 Though, to be fair, that assumes Seraphis is better. 18:12:30 If feature parity though why bother with Seraphis? 18:12:45 Iirc it would only be marginally better 18:12:45 Migration 18:12:46 Incremental, with more immediate benefits and no new anonset 18:13:12 That's the point up for debate 18:13:20 Seraphis is a simpler design in theory that could lead to as much as... ~25% faster membership proofs, at the cost of ~six hundred bytes in bandwidth? 18:13:28 I think you have to look at some things that are details, but maybe important details 18:13:48 Seraphis, with squashed enotes, does a range proof on inputs. This doesn't squash so it doesn't. 18:14:10 And, to say it again, Seraphis is *implemented*. It's existing code. 1.5 man years went into that, remember? 18:14:21 Seraphis could not squash. Due to padding rules, I don't think that shaves the necessary power of 2 to have a faster membership proof at this time. 18:14:58 So there's a bandwidth/computation trade off to discuss. 18:14:59 Best not to consider that since it might be a sunk cost fallacy though I guess FCMP-RCT might have unknown roadblocks 18:16:08 Hence why I didn't want to have this discussion, though I'll note the remaining work on Seraphis is still taking longer than estimates for the initial improvements here *and they're not incompatible*. 18:16:32 They're only incompatible if you refuse a year of full sender privacy for less tech debt :/ 18:17:58 I really wonder how timelines will develop. If you ask me, and that is maybe a bit unfair as a comment, your journey until hardfork may take twice as long as currently estimated 18:18:13 It could. 18:18:28 (That's about on par with estimates that Seraphis may be 5 years out) 18:19:23 I prefer the 1.5-3y estimate, and .5-1y for FCMPs. 18:20:51 Basically. Again, I'm willing to be a complete dick about this ("either this or that") since I personally highly value protocol and library simplicity for practical adoption and decentralization reasons 18:21:40 But my affinity for certain protocol design over full sender privacy is subjective 18:21:52 I care about Monero's privacy not being as arguable as plausible deniability and not being a honeypot of historical data for QCs to deanon. 18:22:20 No input from koe on this yet? 18:22:35 Not that I know of. 18:23:03 I also appreciate the lack of an explicit migration, yet I can concede the Seraphis design's benefit in theory. 18:23:08 He doesnt want to learn rust iirc :) 18:23:32 For FCMPs, what state are the circuit designs ? 18:23:37