00:30:03 Pros of carrot vs jamtis rct? 00:31:05 Why go "carrot > jamtis" instead of "jamtis rct > jamtis " 01:33:20 Carrot is heavily based on Jamtis. Quoting carrot: 01:33:21 > Carrot is not the only upcoming addressing protocol for Monero's FCMP++ consensus protocol. **The other big contender is Jamtis, for which Carrot is designed to be indistinguishable on-chain**, which will justify some seemingly strange design choices later on in this document. 01:33:23 > Special thanks to everyone who commented and provided feedback on the original Jamtis gist. Many of the ideas were incorporated in this document. 01:33:25 > A very special thanks to @tevador, who wrote up the Jamtis and Jamtis-RCT specifications, which were the foundation of this document, containing most of the transaction protocol math. 01:37:23 And iirc comments suggest that Carrot offer *stronger forward secrecy* than original Jamtis. Tho in practice no addresses should be known by the ECDLP solver. 01:38:23 cc jeffro256 01:44:39 Dan (Is not the man & Braxman Tomsparks Advocate) Backup: Carrot was created for FCMP++. The FCMP++ Research CCS isn't scoped to it. I don't personally want to risk wearing it thin for what is an optional add-on (there's a much much simpler scheme we could do if we just want to solve the burning bug/forward-secrecy aspects). 01:45:43 SyntheticBird: No, they aren't auditing the crate, they're expanding their prior work on security proofs in response to Aaron's review and an issue they noted when going from academia to practice. 01:47:44 IIRC, Carrot is effectively JAMTIS RCT, specifically the protocol on sending to existing addresses under JAMTIS RCT. JAMTIS RCT was also an entire new address format. That is not included in Carrot. 02:16:25 "Jamtis" was originally for Seraphis. If we stay on FCMP++, we'd only maybe do Jamtis-RCT, not Jamtis. Carrot and Jamtis-RCT are for FCMP++, Jamtis is for Seraphis 02:16:30 We're so good at naming things 02:18:05 The main pro is that we can have backwards compatible support for existing wallets 02:18:26 You'd have to regenerate account keys for Jamtis-RCT and the addresses take a different format 02:19:10 So we wouldn't be going Carrot > Jamtis, but we might go Carrot > Jamtis-RCT 02:20:29 Jamtis and Jamtis-RCT have the basically the same forward secrecy properties as Carrot, there's no real difference there 07:30:31 Yes i know. The "jamtis" step implied seraphis. And i assume we'd eventually move from fcmp++ on rct to fcmp on seraphis (?) 07:30:33 so now my q is: why would be bother with jamtisrct? Cant you add backward compatibility to jamtisrct _and_ still include new key/address generation by default? Seems strange that we'd change twice (or thrice) 07:32:11 Is there actually a compelling reason for Seraphis after fcmp++? The benefits seem minor 13:55:07 > so now my q is: why would be bother with jamtisrct? Cant you add backward compatibility to jamtisrct and still include new key/address generation by default? Seems strange that we'd change twice (or thrice) 13:55:09 ofrnxmr Carrot was written to be as close to Jamtis-RCT feature-wise while still keeping addresses in the same format. Any additional feature you would want from Jamtis-RCT that isn't in Carrot requires a change to the address format. Jamtis-RCT has a few thing going for it: 1) it has support for more private light wallets, 2) the key exchange is slightly faster, 3) subaddress lo okahead isn't needed anymore, and 4) you can encode small strings to yourself inside addresses 13:59:39 AFAIK, the one benefit would be performance, but I don't think there's been a direct comparison yet 21:31:51 IIRC, FCMP++ ended up faster than squashed Seraphis ofrnxmr jeffro256 21:32:49 So not only is FCMP++ feature complete (something I'm very proud of), the performance is also better. 21:33:12 (Unless you start discussing unsquashed Seraphis again)