UkoeHB

My argument against removing the extra field completely (copy pasted from #6456): The Monero core team cannot see the future nor evaluate all possible usecases of Monero. To a large...

> If such feature is only used by a subset of transactions, it will affect the privacy of everyone using Monero. In theory, there could be dozens of these extensions...

>That's not a good argument, since it's relying on extra removal not preventing the thing that was sought to be prevented in the first place. @moneromooo-monero can you clarify this...

> and if we phase out integrated addresses at the same time. @knaccc expressed concern during discussion of #6456 that moving encrypted payment IDs out of the extra field would...

> With Seraphis/Jamtis, that would be about 87 bytes of data per output (Ke, v, t~, Ko, a~ can contain arbitrary data. I recently added a rule that all `K_e`...

I am not a big fan of restricting the tx extra beyond stricter semantics (sorted TLV) because it's a field that's literally 'for anything we can't know in advance or...

Steganography does not excite me (typically you want tx output + memo - stenography means adding additional outputs which is just a DDOS on scanning), mandatory inclusion implies adding way...

@arnuschky #8220 adds a key exchange round, this is a change to the key exchange protocol that's in master. The reviews on that PR did not validate the kex changes.

This is an oversight in the verifier code. MLSAG and CLSAG both include `sc_check()` calls for tighter semantics (it may also be necessary depending which crypto ops you are calling...

Nonreduced scalars passed to `ge_double_scalarmult_base_vartime()` are effectively treated as 'some other scalar'. This means, in practice, that nonreduced scalars recorded in the chain data for Borromean signatures have a nonstandard...