00:54:14 <m-relay> <m​oneromatrix:matrix.org> Is this true?
00:54:16 <m-relay> <m​oneromatrix:matrix.org> "Carrot could be implemented today without FCMP, it does not require a hardfork."
00:56:32 <m-relay> <v​tnerd:monero.social> Maybe? there's a new output type that's needed to prevent the janus attack, so if we dropped that from carrot then I think it would be possible
00:57:17 <m-relay> <v​tnerd:monero.social> But the sender doesn't know whether the address is carrot or legacy
01:31:56 <DataHoarder> This is in the context of the carrot addressing scheme (not output format)
01:32:26 <DataHoarder> Basically it could generate addresses and be sent funds there, but no one has bothered to define it in spec
01:32:56 <DataHoarder> So yeah you wouldn't gain a bunch of features but you could have the addressing scheme for it
05:18:21 <m-relay> <j​effro256:monero.social> Not really without losing benefits. If you send XMR over CARROT, it wouldn't be spendable under RingCT without modifications. If you modified it to work under RingCT, you would lose OVKs and quantum forward secrecy.
05:20:10 <m-relay> <j​effro256:monero.social> You could have Janus protection with CARROT on RingCT by simply stuffing that data into tx_extra
05:29:19 <m-relay> <v​tnerd:monero.social> Ah yes tx_extra, that great perpetual stew
05:56:49 <DataHoarder> many reasons why making a new output format and derivations for it was done indeed
21:11:42 <m-relay> <u​ser5864:matrix.org> The whole fud with carrot getting out of hand
21:13:17 <m-relay> <o​frnxmr:xmr.mx> dev channel, not fud discussion channel
21:13:36 <m-relay> <s​yntheticbird:monero.social> this
21:13:40 <m-relay> <s​yntheticbird:monero.social> with all respect