00:31:57 <Rucknium[m]> I asked Zcash's str4d about their encrypted memo and they said:
00:32:10 <Rucknium[m]> "We cannot enforce valid encryption in the regular consensus rules: ciphertexts are meant to be indistinguishable from uniform bytes, and within that uniform distribution lies every possible plaintext. Without the decryption key (which consensus nodes don't have), they can't confirm it is a validly-encrypted ciphertext.
00:32:21 <Rucknium[m]> "We could enforce it inside the zero-knowledge proof (i.e. have the ciphertext be a public input to the proof, its memo field and encryption key be a private input, and then enforcing that the ciphertext contains the newly-created note). We don't do that for two reasons:
00:32:37 <Rucknium[m]> "- It would require implementing ChaCha20Poly1305 inside the circuit, which is doable but expensive.
00:32:37 <Rucknium[m]> - It would prevent people from choosing to not send encrypted note data in-band / on-chain, and instead sending them directly to the recipient out-of-band (where they could choose to use whatever encryption scheme they want, including PQ schemes)."
01:21:07 <Alex|LocalMonero> <ofrnxmr[m]> "blankpage: I was typing the same..." <- One of the main issues with this debate is that it's treating the junk output exploit (which will be gone if/when zk-SNARKs is implemented on XMR) and tx_extra as being an either/or type of deal, when in reality the exploit is exploitable regardless of whether tx_extra is kept. But if tx_extra is kept post-Seraphis the "application layer" will reside upon it.
01:21:32 <Alex|LocalMonero> It was moneromooo that first pointed it out in the github discussion a long time ago
01:22:32 <Alex|LocalMonero> So, assuming there's zk-SNARKs and no tx_extra then arbitrary data storage becomes impossible as far as I understand until a hypothetical new way is figured out to steg things into the chain.
01:23:01 <Alex|LocalMonero> Which, to me, is a huge win.
01:27:48 <Alex|LocalMonero> https://github.com/monero-project/monero/issues/6668#issuecomment-647050277
01:31:37 <Alex|LocalMonero> <Rucknium[m]> "I asked Zcash's str4d about..." <- Would you kindly ask str4d if he thinks there's a hypothetical way to steg arbitrary data into the chain absent the memo field?
01:35:44 <Rucknium[m]> Into shielded Zcash transactions? Yes I can ask. Zcash is trying to add "Zcash Shielded Assets" (ZSAs) to their chain. I don't know how that may affect arbitrary data in shielded txs.
01:36:20 <Alex|LocalMonero> Rucknium[m]: Yes, into the shielded ones. Thanks.
01:42:34 <UkoeHB> Alex|LocalMonero: zksnarks does not stop you from putting data into fake outputs (probably around 60 bytes per output
01:43:11 <Alex|LocalMonero> I see, I was under the wrong impression.
09:28:03 <someguyalder[m]> Hi. I am just a regular donor. As an outsider following this conversation, also the last one, i'm with Alex' POV that Monero should be digital cash. Thats the main priority of the project. Nothing else. I personally see development going way too slow facing upcoming regulations the next years. There was once no p2pool or ThorChain, so i don't see the argument for keeping tx_extra because of them. I'm also not read into the
09:28:03 <someguyalder[m]> stuff too much to tell if they could make modifications on their end if there is no more tx_extra. From some statements here i understand without tx_extra, stuff just needs to be done in other ways. So that means no one really needs tx_extra.  Finally i would like to add, if its going to be removed long-term anyway, then remove it ASAP. Just ditch the thing and focus on other things.
11:36:32 <gingeropolous> for me it kinda boils down to - if we remove tx_extra, how damaging will the stuff_data_into_tx_some_other_way situation be
11:38:06 <gingeropolous> because in my head, that situation isn't as bad as leaving tx_extra in any form 
11:40:03 <gingeropolous> i mean, making tx_extra work by giving it rules seems like taping over the screen door in the submarine. the door needs to be removed.
11:46:09 <gingeropolous> and as stated by someone else, the possibility exists to re-introduce tx_extra if it is seen as necessary. but the default design choice should be privacy / fungibility, and these things aren't achieved by putting NFTs on the chain (regardless of how fancy they are dressed up)
11:48:43 <gingeropolous> i think i've waffled back and forth mainly due to the whole "soft fork" possibility, but as stated by others, that is achievable without tx_extra, and for further clarification, i always thought of the soft-fork functionality more as a way to modify consensus without a code release due to some unfriendly environment, but the more i thought about it, the more i reasoned that if you can get a "header script" out into the network to change 
11:48:43 <gingeropolous> consensus via a non-release mechanism, you can probably also distribute a code patch, so that whole thing for me is now moot
11:49:28 <hyc> softfork means it can take longer for the change to propagate
12:59:12 <ceetee[m]> >There was once no p2pool or Thorchain, so I don't see the argument for keeping tx_extra because of them.
12:59:12 <ceetee[m]> How much tx_extra data does p2pool need? Could that be stuffed in the ringsig as elaborated earlier, at the cost of slightly less privacy?
12:59:12 <ceetee[m]> I'm asking because I think p2pool is a valuable addition to the ecosystem.
13:13:15 <ofrnxmr[m]> P2 a'ready has with effective decoy reduction and Chain bloat. Post p2pool hard fork should mitigate some. 
13:13:15 <ofrnxmr[m]> I would assume stego to not be as bad as consolidations, and hopefully negligible compared to consolidations 
13:14:00 <ofrnxmr[m]> Already has problems with effective decoy reduction *
13:14:46 <moneromooo> It was suggested before that coinbase txes would keep some "extra" ability in any case.
13:34:33 <ceetee[m]> okey, so removing it wouldn't kill p2pool, that's good news
13:43:20 <Rucknium[m]> Is BTC Ordinal/Inscription/NFT data placed in OP_RETURN, the designated place for arbitrary data in BTC transactions, or in SegWit witness signatures, which could be considered kayabaNerve-"steganography"?
13:45:57 <ofrnxmr[m]> kayabanerve @kayabanerve:matrix.org: 
13:46:30 <UkoeHB> without tx_extra we would have needed a hard fork to get subaddresses, not sure why that hasn't been mentioned
13:54:09 <plowsof11> integrated addresses have long been 'deprecated' but some projects (and at least gate dot io) use them still afaik. if tx_extra is removed then this means no more payment id's?
13:58:28 <UkoeHB> plowsof11: if removed from the current protocol yes, in seraphis the jamtis address index is meant to supersede payment ids 
13:59:27 <hbs[m]> The Monero payment GW uses integrated addresses IIRC
14:53:16 <Alex|LocalMonero> <gingeropolous> "for me it kinda boils down to..." <- stuff_data_into_tx_some_other_way exists with or without tx_extra. The application layer stuffed txs by well-intentioned devs shouldn't take more than 1% of the entire network I recon, so the effect is minimal. Its the malicious actors that you should be concerned with generating junk outputs en masse to poison the network, not the tiny amount of txs those who would
14:53:16 <Alex|LocalMonero> otherwise utilize tx_extra.
18:12:44 <rbrunner> I am pretty sure that all uses of the Monero software itself for tx_extra are irrevelant for the discussion
18:13:15 <rbrunner> You can consider all those cases (subaddresses, payment ids, maybe some more that I don't remember) solved i.e. as no more needing tx_extra
18:14:01 <rbrunner> So tx_extra would become exclusively third-party use, so to say. The standard Monero software would be perfectly happy with transactions that don't have and don't need any tx_extra
18:14:31 <rbrunner> How would we achieve this? By either still hardforking with the "old" protocoll and move those things out of tx_extra
18:14:52 <rbrunner> Or we wait until we fork to Seraphis where all this stuff is alright anyway
18:15:25 <rbrunner> That's why proposal B3 256 (see log from yesterday) has two possible fixed sizes for tx_extra:
18:15:51 <rbrunner> 0 i.e. the transaction has no tx_extra (expected for the majority of transactions)
18:16:09 <rbrunner> 256 the transaction has a tx_extra of exactly 256 bytes
18:17:18 <rbrunner> With 0 as one of the possibilities for tx_extra size also the question of chain bloat becomes much less critical
18:17:50 <rbrunner> as well as "Why I should pay more for my transactions because of those third-party freaks": You don't, as your transaction won't have any tx_extra
18:19:13 <rbrunner> A fixed size of "only" 256 should also diminish the appetite of people stuffing NFTs directly in there to quite some degree
18:20:58 <rbrunner> And regarding time horizon of this decision: At least as I am concerned, I understand this decision to be indefinitely into the future, open-end
18:21:21 <rbrunner> Until we have an unlikely condition we bump into that will force us to switch course
18:22:03 <rbrunner> Or, if we decide to remove, it's gone, period, if we decide to not remove, it stays, also period.
18:22:19 <rbrunner> At least I discussed under these assumptions
18:25:20 <rbrunner> Hope this wall of text can help to clear some confusions about that proposal :)
18:26:46 <ofrnxmr[m]> Id like to HF pre seraphis to remove + deal with coinbase 
18:29:40 <ofrnxmr[m]> And explore the global membership proof when it makes sense. 
18:29:40 <ofrnxmr[m]> In strictly in the group A
18:32:15 <rbrunner> I guess if things crystallize as "remove" we can treat the decision "remove before or with Seraphis" as a second, independent decision
18:32:32 <rbrunner> Hopefully reaching consensus a bit faster for that question ...
18:34:46 <rbrunner> That pre-Seraphis tx_removal hardfork would not be too complicated, but would of course still eat some resources all around
19:12:13 <rbrunner> gingeropolous, regarding your submarine comparisons, a quick google gave me this: https://en.wikipedia.org/wiki/Escape_trunk
23:07:49 <UkoeHB> > You can consider all those cases (subaddresses, payment ids, maybe some more that I don't remember) solved i.e. as no more needing tx_extra
23:07:49 <UkoeHB> The point is these set a precedent for significant innovations using the tx_extra.
23:29:54 <Alex|LocalMonero> UkoeHB:  Subaddresses are the actual significant innovation, and they weren't added through tx_extra but a hard fork. They should've replaced the whole payment ID system in the first place instead of using the integrated addresses hack which only allowed the payment ID system to keep proliferating and allowing off-chain linking. If anything it's a point against tx_extra.
23:43:04 <UkoeHB> Alex|LocalMonero: subaddresses are in the tx_extra, and are not enforced by consensus afaik
23:43:40 <Alex|LocalMonero> I thought only multi-dest subaddress txs are?
23:44:51 <UkoeHB> even if they are enforced, they don't have to be - what I'm saying is the tx_extra enables innovations on the scale and importance of subaddresses
23:46:22 <Alex|LocalMonero> It also enables obsolete privacy-harming standards to keep existing for backwards compatibility.
23:47:12 <UkoeHB> There is room for improvement, but my point stands.