15:03:09 MRL meeting in this room in two hours. 17:00:44 Meeting time! https://github.com/monero-project/meta/issues/1333 17:00:51 1. Greetings 17:00:52 Howdy 17:01:00 Hi 17:01:05 Hello 17:01:08 howdy do 17:01:31 hi 17:01:38 hullo 17:02:00 hi 17:02:23 Hello 17:02:44 waves 17:03:19 2. Updates. What is everyone working on? 17:04:20 RandomX V2 testing, specially around new prefetch parameter tweak now part of the main design https://github.com/SChernykh/RandomX/blob/v2/doc/design_v2.md (and is considered finalized for the PR) 17:04:28 trying to put the final touches on the monerosim package. 17:04:29 me: Selfish mining countermeasures analysis. 17:05:12 @gingeropolous:monero.social: How did your 1000-node test go? 17:06:06 Me: finished reviewing @j-berman's unbiased hash-to-point changes, fixiing beta scaling tests, working on my Monerotopia presentation 17:06:11 its working well. I want to demonstrate something useful, so im getting a simulation that does a network upgrade (going from one version of monerod to another.... in this case, one that that has tx relay v2 pulled in). Currently the user agent code isn't handling the wallet correctly during the daemon restart. But otherwise it runs 17:06:38 me: preparing the FCMP++ integration code for auditing, finalizing tx relay v2 17:06:48 @gingeropolous:monero.social: Fantastic. Thanks. 17:07:28 3. FCMP and CARROT reviews and audits status (https://cryptpad.fr/sheet/#/2/sheet/view/yPVIUywwA9-deE9VF6GYm9bXbPdCerdST3UDEEfBxcM/embed/). 17:08:08 Was the Cypher Stack Generalized Bulletproofs review & suggestions posted? I didn't see it. 17:08:09 No updates from me 17:09:29 @diego:cypherstack.com: Has the Generalized Bulletproofs new review been posted? 17:10:55 @sgp_:monero.social reached out to zkSec (specifically a curve trees author) to review divisors, don't believe there's been an update 17:11:58 re: integration audit, I'm aiming to have the code ready by EOW, and will start planning an audit approach then 17:13:49 @brandon:cypherstack.com: Any update on posting the Generalized Bulletproofs review draft? > <@brandon:cypherstack.com> yeah, i plan on posting it soon(tm) 17:14:24 "I'm still cleaning it up" is a valid response :) 17:15:01 I'll go to the next agenda item. Maybe Cypher Stack staff will come in later. 17:15:11 5. FCMP alpha stressnet (https://monero.town/post/6763165). 17:17:15 yes > <@rucknium> @diego:cypherstack.com: Has the Generalized Bulletproofs new review been posted? 17:17:19 I'm still thinking it would be nice to have tx relay v2 tested on alpha. I'm going to prepare all the changes that would be solid for a v1.6 release (nothing significant at this stage), and also port those changes to the staging branch in prep for beta 17:17:20 it's on iacr 17:17:56 If we have capacity to get a v1.6 release out, then that would be solid, but if not, then we'll just have it ready for beta 17:18:09 sorry Im late, here now 17:19:38 So tx relay v2 changes coming along well? 17:19:57 Generally, I remain confident that alpha achieved a level of stability that is ready to move to beta 17:20:08 grabbing the link, moment 17:20:11 @jeffro256: Yep, changes are pretty much done 17:20:39 Completed @boog900:monero.social 's latest review round 17:21:17 I submitted the generalized bulletproof paper to iacr last week but the editors have not posted it yet. As soon as I get the link sent to me I will share it here. 17:21:34 @brandon:cypherstack.com: Thank you! 17:22:01 @jberman: agreed, thanks for all that work 17:22:54 I agree that alpha should try tx relay v2 because we don't know yet if beta stressnet should have changes to Generalized Bulletproofs (GBP). 17:23:44 ack 17:25:11 6. Bulletproof prover and verifier optimization research. 17:25:31 @emsczkp:matrix.org: Did you find time to look at https://moneroresearch.info/285 Wang, N., Wang, Q., Liu, D., Esgin, M. F., & Abuadbba, A. (2025). BulletCT: Towards More Scalable Ring Confidential Transactions With Transparent Setup. ? 17:25:50 > <@rucknium> @emsczkp:matrix.org: Could you read https://moneroresearch.info/285 Wang, N., Wang, Q., Liu, D., Esgin, M. F., & Abuadbba, A. (2025). BulletCT: Towards More Scalable Ring Confidential Transactions With Transparent Setup. BulletCT: Towards More Scalable Ring Confidential Transactions With Transparent Setup. 17:25:51 I don't want to dominate this agenda item, just share some thoughts on BulletCT 17:26:06 BulletCT contributes to RingCT signature schemes with a “K-weight” version of K-out-of-N proofs (K/N proofs), inspired by the Any-out-of-N proofs (Any/N proofs), and proposes a new Tag proof. 17:26:06 BulletCT doesn’t bring improvements to Bulletproofs proof system itself; rather, it compares mainly against the Any/N RingCT scheme, the Omniring and RingCT-3.0. 17:26:19 Overall, BulletCT constructs a RingCT signature by combining four proofs, K/N proof, Tag proof, Balance proof and Range proof. The authors only provide the K/N proof and Tag proof. Moreover, both K/N proof and Tag proof follow the Bulletproofs-style proof for two different objectives: K/N proof proves the “existence of a val [... too long, see https://mrelay.p2pool.observer/e/qLCO-eAKUDhwYVY3 ] 17:26:19 However, it is unclear to me why the authors use separate Bulletproofs-style proofs for the K/N proof and the Tag proof. While the K/N proof appears to be motivated by Bulletproofs’ bit-decomposition constraints, an analogous motivation is not evident for the Tag proof. Finally, neither construction presents an explicit redu [... too long, see https://mrelay.p2pool.observer/e/qLCO-eAKUDhwYVY3 ] 17:26:34 this is my brief review 17:27:04 i don't agree Bulletct will benefit for Bulletproofs neither FCMP 17:27:53 i didn't read the other paper, but i will do 17:28:39 Thank you @emsczkp:matrix.org ! 17:29:10 welcome 17:30:20 Fwiw I don't think anyone claimed that bulletct as written would benefit Monero directly 17:31:10 @emsczkp:matrix.org: Do you draw this conclusion because you think there isn't enough support for their idea? In other words, do you think they could take your feedback specifically from the second paragraph and iterate? Or that it's fundamentally flawed 17:31:30 here maybe > <@rucknium> Has anyone here closely read any of the papers linked above? It looks like at least one of them (BulletCT) could help with Bulletproofs efficiency. Anyone know anything about it? 17:32:14 So my hypothesis was wrong :D 17:32:57 @jberman: i don't see the prover/verifer optimizations in BulletCT. I would like more details on that particular optimizations, or at least which papers do 17:34:19 here the authors claim there are "it seeks to halve the number of computationally expensive group exponentiations required by existing Bulletproofs-based constructions, yielding an almost 2X practical speedup" ... i haven't find this yet > <@ack-j:matrix.org> MAGIC recieved a project proposal with the following research goals that we'd like community feedback on: 17:34:48 BulletCT is related work, but it's not "using BulletCT as a direct starting point, we changed this and this to create a Monero compatible proposal". Ack-j can chime in if my understanding is wrong 17:35:39 Right. I was trying to get an idea of the researcher's research agenda . 17:35:45 They aren't saying BulletCT accomplishes the scope/claims 17:36:30

Yea bulletCT is different. The papers that are more relevant are SwiftRange and flashproofs. I will get you a link 17:36:43 To fund this, you would want to know if the objective of the research is feasible and if the researcher is likely to succeed in his/her goal. 17:37:35

https://moneroresearch.info/index.php?action=list_LISTSOMERESOURCES_CORE&method=creatorProcess&id=692 17:38:06

Here is the authors publications. 3 papers on range proofs and then bulletct is an outlier 17:39:24 I suggested the wrong one. Sorry. 17:39:36

Update on the MAGIC side. Dr. Nan Wang identified a soundness flaw in their proposed bulletproof+ optimization that affects the verifier efficiency. Their proposal still should double the prover efficiency and benefit verifier efficiency, but the 2x verifier estimate has been reduced. 17:39:36

We plan to make a reddit post soon and start the fundraising round 17:42:34 fwiw, I don't recall exactly how long it takes to construct the BP+, but I at least haven't noticed it to be a perf issue when constructing a tx 17:43:07 Especially after FCMP++ ... 17:43:15 right 17:43:36 Verifier efficiency is usually much more important than prover efficiency, for blockchains. 17:44:43 FCMP++ construction is still pretty slow especially for large input txs, to the point it would actually be a noticeable thing for users 17:46:01 @rucknium: This was emphasized to them by @ack-j:matrix.org fwiw 17:47:01

https://mrelay.p2pool.observer/m/matrix.org/tGRPFJzPclIFBXyRgcohWeCS.pdf (Monero_Proposal 3.pdf) 17:47:32

The author agreed to let us share the proposal. Here is the latest revision 17:51:24 @emsczkp:matrix.org: Any thoughts on the "Project Feasibility" section? 17:52:26 yea, now I see swiftrange promises BP rangeproof speed-up 17:53:29 I'm not in swiftrange, I'll take a look 17:54:21 It says communication cost up to 2x as the "range size" increases. I'm guessing that that's the 64-bit amount, and not the number of outputs ? 17:54:28 of course, don't want to block the fundraising 17:56:46 I think the risks are 1) Cannot be implemented in Monero for unforeseen reasons, 2) Becomes obsolete before a hark fork (after FCMP hark fork) occurs that could use it, 3) Speedup is very little, 4) Soundness does not pass peer review. 17:56:58 Of course, all research is risky, so that's not new 17:57:11 @jeffro256: it should be the bit-range domain yes 17:57:36 Communication = size in bytes, right? 17:58:44 @rucknium: usually the proof size = communication is bytes 17:59:54 Everyone should feel free to give more feedback on the proposal after the meeting or any time. 18:00:01 7. CARROT Outgoing View Keys (OVKs) (https://github.com/jeffro256/carrot/blob/master/carrot.md#22-new-wallets-only). 18:02:25 I have at least two questions. Is there any other known way to get quantum forward secrecy and/or prepare outputs for a post-quantum turnstile to prevent a quantum computer from counterfeiting XMR? 18:02:40 Other than OVKs, I mean 18:03:02 Current PQ Turnstile design for new Carrot wallet with Carrot tx outputs: https://gist.github.com/jeffro256/146bfd5306ea3a8a2a0ea4d660cd2243 18:03:42 Yes, you can still come up with a wallet format scheme that sends change to a symmetric secret without having an OVK. 18:04:54 And it should be possible to be made compatible with that turnstile design DataHoarder linked 18:06:02 @jeffro256: it would be akin to having two view-incoming keys: one for actual incoming XMR from others, which is the discrete log relation of your Monero address points, and one used for change. 18:06:10 Doesn't Carrot generate-image key + Carrot view incoming key effectively means OVK (you can scan inputs, you can generate key images to detect the spends) then, except for internal change? 18:07:04 Plus s_ga (to determine address-specific openings), yes. 18:07:41 right, s_ga is derived from s_vb, not k_v 18:07:44 s_ga meaning the "generate-address secret" 18:08:00 @jeffro256: The actual UX would be having two view keys? Or usually people would use a concatenated key, combining the two? 18:08:04 (current key hierarchy https://github.com/jeffro256/carrot/blob/master/carrot.md#52-new-key-hierarchy ) 18:08:29 Is midipoet still here? 18:08:57 @rucknium: For most use cases I envision, if you want the all-inclusive view-balance secret, you can just transmit that 32 byte secret, since it derives the others. 18:09:01 Yes 18:10:51 @rucknium: and how does this address the concerns that have been raised regarding OVKs? 18:11:05 There is a fear that users would be persuaded to give up their outgoing view keys to centralized exchanges or other surveillance-adjacent entities. Anyone want to write out thoughts on this hypothesis? 18:11:06 @jeffro256: But you can split it up however you like for different use cases 18:12:20 My opinion: the tangible benefits the OVK brings are still not very well understood, undervalued, and under-appreciated, especially in how the OVK would improve security (and usability) for hot/cold wallets, multisig, and hw wallets. 18:12:28 The arguments in favor of SMALL businesses (and businesses of ALL sizes) have been nicely expanded on in various places. 18:12:29 I have read of Monero users needing to submit cryptographic payment proofs. I don't know to whom or in what circumstances they are required. Anyone familiar with this behavior? I have not read of anyone needing to submit current incoming view keys. 18:12:39 On the nayside: the boogeyman argument of "they'll collect the keys and shut out people who don't provide them" is a hypothetical that rests on sheep being sheep and giving up their private keys. 18:13:02 So in sum: individuals and small businesses who want greater security using Monero, who want to build a circular unfuckwithable economy, are essentially being held back by hypothetical sheep being sheep. 18:13:36 OVKs would be a method towards compliance for any obliged entity, that's for certain. Whether there is appetite for CEXs to implement a system that maintains a database of OVKs for their customers is unknown. Though perhaps they could delegate the analysis to surveillance companies, who would certainly benefit from having access to an OVK database (one would assume). 18:13:45 @rucknium: You can accomplish most of the detailed items directly with view incoming keys, specially in legacy wallets, but FCMP++ also removes the ability to do any sort of output/decoy statistical analysis 18:14:51 (and on an aside, new Carrot wallet is not explicitly a change that is being hardforked, the tx output format change is the one being hardforked and this also benefits legacy wallets) 18:15:10 midipoet: Practically: they would benefit IMMENSELY from having many people's view-incoming keys. With enough keys in a strongly connected subgroup of users, it's similar privacy-wise to having OVKs. Why do you think that this hasn't been done? There must be some political reason, no? 18:16:14 midipoet: This is not to the fact that you can prove your entire tx history of a standard wallet with 100%, without OVKs. Yet there has been no push for this either. 18:16:23 AFAIK, if the CCS wallet had disclosed an OVK, the community would have known about the theft immediately instead of a month+ afterward. I think the same thing could have been accomplished by regular export and public posting of key images, but that creates its own type of security risks. 18:16:50 midipoet: Yes 1 hop compliance is a use case. It is what can be used for travel rule compliance. 18:17:33 @rucknium: When looking at the incident txs you could correlate that all inputs had been swept and directly attribute it due to the working of wallet change, but it'd have been entirely clear with OVK 18:17:37 This is a. far cry from the harm caused by BS 18:18:33 @rucknium: This is a classic very good use case for OVK 18:18:36 DataHoarder[m]: Especially since they used something akin to Monerujo Pocketchange and it was traceable for like 3 hops IIRC 18:18:44 @jeffro256: Convenience differs though, in one case there is a need for continous export of KIs, in the other the one time hand out of the OVK is suddicient 18:19:00 sure, but IVKs aren't negotiable are they? OVKs seem to be (as I understand it). The reason that CEXs haven't pushed for access to more view keys, is basically because it's been too complex to implement. It's easier to just delist. With more user friendly view keys this might (?!) change. 18:19:08 @jeffro256: https://blocks.p2pool.observer/tx/ffc82e64dde43d3939354ca1445d41278aef0b80a7d16d7ca12ab9a88f5bc56a and the 0-XMR change shows it's a sweep of n inputs! 18:19:44 midipoet: "So in sum: individuals and small businesses who want greater security using Monero, who want to build a circular unfuckwithable economy, are essentially being held back by hypothetical sheep being sheep." 18:20:22 on this @jeffro256:monero.social would a PQ Turnstile be possible without a general Carrot generate-image key for external incoming transactions? > <@rucknium> I have at least two questions. Is there any other known way to get quantum forward secrecy and/or prepare outputs for a post-quantum turnstile to prevent a quantum computer from counterfeiting XMR? 18:20:23 midipoet: It can also strengthens legal cases against Monero delisting 18:21:11 midipoet: What do you mean by "negotiable"? They aren't technically required for Monero to function, they simply make the UX suck way less. You can technically come up with a wallet format where the view key derives the spend key, no there exists no non-custodial IVKs 18:21:19 articmine: yes, that might be true. But ultimately any CEX can list or delist whatever coin they want. 18:22:22 @jeffro256: Or you can simply set them equal to each other, but that would be externally observable in the main address 18:22:31 Any legal challenge would likely target the regulators and regulations 18:23:06 jberman: I don't get the sheep being sheep bit, to be honest. Personally, I am not overly against OVKs, if there are legitimate purposes for them, aside from compliance. It seems (from what I have read) there are. 18:23:06 @jeffro256: @jeffro256:monero.social: I wondered about that. But that's a wallet-level change (like carrot), not blockchain-level, right? So it would always be possible to create a new wallet with an IVK. 18:23:34 @rucknium: it would always be possible to make a wallet with the scheme, or even a wallet that just reports proofs as needed 18:24:06 Someone who gives up their OVK is a sheep being a sheep. A business that requires OVK's is a sheep being a sheep 18:24:44 I am in favor of keeping the OVKs as proposed in Carrot at least as an option for wallet creation 18:25:39 the other suggestion was around UX. Don't display these in the GUI, but CLI only, or warn users about them. 18:25:50 i wonder if they can have a default expiration 18:25:57 That said, exchanges could always ask for your seed words :) 18:26:02 @rucknium: CARROT is primarily an addressing protocol. I want to separate that conceptually from its recommended wallet format. So many different wallet formats can, and will, communicate XMR to each other over CARROT. But yes, CARROT has no consensus level rules, except for the new output format, which is simply reserve b [... too long, see https://mrelay.p2pool.observer/e/jYXp-uAKV1JpQmdS ] 18:26:09 @gingeropolous: it's baked in address generation 18:26:19 jberman: ah ok. i.e submitting control of the information is the problem, as opposed to whether it's a view key, a transaction id, a private key, etc. 18:28:01 > it would always be possible to make a wallet with the scheme, or even a wallet that just reports proofs as needed 18:28:01 Exactly. If user convenience is the limiting factor for regulators, regulators could require you to use an auto-reporting wallet software TODAY, which is cryptographically verifiable if you try to evade that software, for that specific wallet, once you have disclosed the view-incoming key. 18:28:15 @gingeropolous: Sweep the wallet and claim the spend key was compromised . There are workarounds with very reasonable plausibility 18:28:22 ☝️ > <@jeffro256> Exactly. If user convenience is the limiting factor for regulators, regulators could require you to use an auto-reporting wallet software TODAY, which is cryptographically verifiable if you try to evade that software, for that specific wallet, once you have disclosed the view-incoming key. 18:28:56 Having said all that, there is a level of technological determinism to the whole thing. If we make view keys really easy to use, the use of them might become normalised. That would be detrimental to the way we imagine Monero being used as a currency. The fact view keys/key image sharing hasn't become normalised is probably very strongly correlated to the current technical/usability barriers to the sharing/generating 18:28:56 process. 18:29:35 Users use view keys already when they make a view-only wallet in GUI, or use a hardware wallet 18:29:43 (or multisig, but that is an advanced feature) 18:29:51 @gingeropolous: It's completely possible to export OVKs per-address. But in the boogeyman scenario, why would the boogeyman ask for the inferior per-address OVKs instead of the main one? 18:30:37 OVK in the case of these massively simplifies interacting with hardware wallets or making multisig txs. You also no longer need to bring the cold keys from storage or connect the hw wallet to check balances, as hw wallet setups atm can't export key images. 18:30:53 So you can't share these with a secondary wallet in a different computer. 18:30:54 midipoet: Collecting JUST view keys of today is effectively 99% as useful as OVK's, since they can see change and therefore see the vast majority of outgoing transactions as well (the spends are extremely straightforward to pinpoint) 18:31:23 ESPECIALLY to a surveillance panopticon 18:31:35 @jberman: Yeah. Today it would be quite harmful due to the ability to tag an output and trace it statistically in decoys. Akin to how https://p2pool.observer/sweeps works 18:32:05 "The fact view keys/key image sharing hasn't become normalised is probably very strongly correlated to the current technical/usability barriers to the sharing/generating process" -> there is no reason to think this 18:32:08 FCMP++ entirely removes the ability to do this, so a lot of the specific knowledge and behavior around view keys also changes 18:32:12 no evidence to support that claim 18:32:22 How practical is this at scale? > <@jberman> Collecting JUST view keys of today is effectively 99% as useful as OVK's, since they can see change and therefore see the vast majority of outgoing transactions as well (the spends are extremely straightforward to pinpoint) 18:32:23 One of the reasons can be to conceal their intentions until OVKs are adopted > <@jeffro256> Practically: they would benefit IMMENSELY from having many people's view-incoming keys. With enough keys in a strongly connected subgroup of users, it's similar privacy-wise to having OVKs. Why do you think that this hasn't been done? There must be some political reason, no? 18:33:11 @just_another_day:matrix.org: One can spin up boogeymen endlessly 18:33:30 > <@jberman> Collecting JUST view keys of today is effectively 99% as useful as OVK's, since they can see change and therefore see the vast majority of outgoing transactions as well (the spends are extremely straightforward to pinpoint) 18:33:30 Funnily enough, I have a link to a presentation video which covers this exact topic. I think you would be interested in it: https://www.youtube.com/watch?v=MYzZ1DzSWCY 18:34:02 Sure. spinning up boogyman is basically what threat assesment is. Monero users love doing it. 18:34:11 Doesn't invalidate it 18:35:10 the problem is that most of these boogeymen involve voluntary user actions, in the same vein you may be "compelled" to give up your private spend key 18:35:43 @intr:unredacted.org: So in sum: individuals and small businesses who want greater security using Monero, who want to build a circular unfuckwithable economy, are essentially being held back by hypothetical sheep being sheep. 18:36:19 @jberman: This is only part of the problem 18:36:47 How do OVKs provide greater security for an individual that uses Monero. Like what is the use case there? 18:37:25 midipoet: There is no longer need to bring any spend key online until it's time to spend, even in-memory. 18:37:45 You could now implement a wallet that has a different extra password to spend/show seed words 18:37:47 midipoet: 1. Hot/cold wallet users frequently check their balance. That occurs in the real world, they're going to do it. Not needing to load the spend key to do so is reducing attack surface for said users. 18:37:55 midipoet: Auditing and monitoring without using the spend key 18:38:25 light wallets work better too right 18:38:51 try as I might i've never gotten my mobile monero wallet to be useful. its always out of sync 18:39:34 Hardware wallets for example are just a special case of auditing and monitoring 18:39:40 So then most of here agree that the benefits outweigh the costs, and the potential (boogeyman) risks. What is the problem then? 18:39:48 *most here 18:39:56 2. Multisig users. Same for them. To see their balance requires communicating with other multisig users who all have to load their spend keys to generate key images. Eliminating that requirement is a +1 for multisig security and a MJAJOR +10 for multisig usability, which has been a MAJOR pain implementing for Monero 18:39:59 midipoet: Software wallets: spend key can stay decrypted during sync. Hot/cold wallets: improved UX and security b/c cold wallet does not need to be consulted unless to sign transactions. Multisig: improved UX and security b/c participants do not have to consult with each other to calculate key images during refresh. Hardware [... too long, see https://mrelay.p2pool.observer/e/hpac--AKYWlpV0o0 ] 18:40:27 @jeffro256: *spend key can stay encrypted during sync. 18:40:35 Another overlooked benefit for hw wallets is how much simpler it is to design a hw wallet that does not have to ingest outputs and generate key images and export them back to the software wallet 18:41:04 midipoet: midipoet: Informed consent. The information known here needs to be communicated better to the whole Monero user community. 18:41:20 rucknium: seems fair. 18:41:26 Has anyone noticed the plethora of failed hw wallet projects in Monero? How long have we been waiting for a seed-signer like device? Does anyone recall why Passport didn't end up supporting Monero? 18:42:20 On this part FCMP++ allows signing and then the wallet can be the one filling the membership proofs right? which also eases hw wallet construction 18:42:20 Simplifying hw wallet design will make it easier for various people to design hw wallets for Monero, again improving security for Monero users 18:43:30 @jberman: On a side note, with Ledger filing for its IPO in the US soon there is a non zero probability that Monero support be dropped in the future 18:43:43 @rucknium: perhaps we need a good long blog post on getmonero.org 18:44:12 you can't trust me to write it tho cause im hooked on llms 18:44:25 Is it so ... 18:44:32 @gingeropolous: The previous blogpost on the topic was https://www.getmonero.org/2024/04/27/fcmps.html (which mentions OVK) so this can be further expanded to Carrot tx output format and Carrot wallet 18:44:44 gingeropolous: do you have an llm-based partner as well? 18:45:06 Yeah, sometimes I like to write such posts, but right now I would rather wait for the storm to subside before even thinking about it 18:45:41 You could have a panel on risks v benefits at Monerotopia/MoneroKon 18:45:45 I see the discussions on Reddit over almost a week now as a more or less lost case 18:46:12 Why not @jeffro256:monero.social write it, then check for ease of understanding by someone else? 18:46:27 @jberman: Hardware / cold wallets' implementation requirements right now are basically an entire wallet engine, including burning bug mitigations, enote scanning, key image communication, BP+ proving (range proofs are included in signature hash), CLSAG proving, etc. After FCMP++/Carrot/new wallet format, it changes to just [... too long, see https://mrelay.p2pool.observer/e/m_Gz--AKTXMzY192 ] 18:46:55 Plus exporting the other keys. 18:47:30 @rucknium: I was planning on doing this for Monerotopia in just over 2 weeks ;) 18:48:52 I volunteer to review and comment anything in this direction, if that's of any use 18:50:05 If it has the form of a presentation, I mean 18:50:46 happy to review/comment as well! 18:51:24 I don't know if this message got lost in the discussion or was answered before (AFAIK we only answered what to do with internal change, not external incoming outputs) > on this @jeffro256:monero.social would a PQ Turnstile be possible without a general Carrot generate-image key for external incoming transactions? 18:53:18 Good question. It may be possible, but not with the current design AFAICT > on this @jeffro256:monero.social would a PQ Turnstile be possible without a general Carrot generate-image key for external incoming transactions? 18:53:25 oh, I see. A lot has been said on Reddit. Missed all of that. 18:53:59 About 1000 comments now in total, probably? Some people have been very busy, and very persistent. 18:54:22 Yeah. At least it's people getting enthused though. 18:54:55 Yes, lol. I look at a certain other coin subreddit and see 2, 3 messages per day. Well :) 18:54:57 +Twitter, and it woke up several people to come to reddit to start disproving lies in comments or misunderstandings 18:55:21 including fluffypony 18:56:29 @jeffro256: Might be curious how one would look as due diligence (with a wallet hierarchy to match) to see what such change it'd allow if each of the keys was shared except main spend keys (or whatever allows producing txs) 19:00:03 Changes in address format (cryptonote addresses) would allow much more IIRC but that's not in scope (JAMTIS is doing that) 19:00:19 We have spent an hour on this agenda item, so I will end the meeting here. Thanks everyone. 19:00:32 Thanks 19:00:37 Agreed. I'll into into it. I suspect an issue will be that if you make your opening over T depend on the opening over G, revealing the key image opening (to prove PQ soundness), will necessarily reveal your entire signing key, so authorization will be broken. 19:01:04 Thanks everyone! 19:01:45 Hmm, the ease of support in hardware wallets for Carrot wallets may mean that if somebody wants to continue with a legacy wallet, hardware wallet support may not be there anymore? 19:02:18 rbrunner: Some of the FCMP++ benefits also map over to legacy ones, regarding tx construction 19:02:38 online spend keys would still be needed for decoding spends 19:03:16