[Discussion] Consider removing the tx_extra field

[tevador]

First discussed here: https://github.com/monero-project/meta/issues/356

We should consider removing the tx_extra field from all non-coinbase transactions.

Main reasons:

1. Enhanced fungibility due to a more uniform transaction format.
2. Protection from the risks of arbitrary data on the blockchain, e.g. copyrighted material, privacy violations, politically sensitive or illegal content etc.

Required data that is currently stored in tx_extra (e.g. transaction public key) could be moved to a dedicated field.

Miner (coinbase) transactions could still allow the tx_extra field for the following reasons:

• coinbase transactions are already distinguishable
• the risk of harmful content is lower because it would require mining a block
• tx_extra is needed for merged mining

Disadvantages of removing the tx_extra field:

• losing the ability to soft-fork the transaction format

[hbs]

The recent debate on channel MRL got me thinking about that whole tx_extra and more recently m0rdinals issue. Please excuse my potentially naive ideas, I've only recently started diving into the code base so some of my ideas may be totally stupid, both from a protocol or from an implementation perspective, but hey, this is how you learn, so don't hesitate to point out anything in my reasoning which just doesn't work. So far I've leant towards the removal of tx_extra as a solution but the more I dig the more my conviction crumbles.

If I understand correctly, the tx_extra field can contain multiple chunks which are prefixed with a byte indicating their type, 0x01 for public keys, 0x04 for additional pubkeys and 0x00 for padding. My understanding is that this padding type is the one allowing arbitrary data to be included in tx_extra. The first good thing is that we can then easily identify tx_extra fields with arbitrary data since they will be the ones containing 0x00 tags.

The issue with tx_extra uses (with 0x00 tags I presume) is that they make transactions stand out since it somehow breaks uniformity (few transactions make use of that tag). My understanding of this is that this somehow taints the outputs of those transactions which may help chainanalysis actors to gain a clearer image of the tx graph. This is still something I need to get my head around though, as I may miss some impacts of that lack of uniformity.

One alternative to using tx_extra, though more costly, is to use steganography to create dummy outputs which will contain roughly 30 bytes of arbitrary data each. This approach may impact the chain by creating more outputs than what "normal" use of the chain would do.

Whether via tx_extra or via steganography, storing arbitrary data has at least two consequences. The first one is that it increases the amount of data stored in the chain, hence increasing the cost of operating nodes. The second one is that it taints outputs and may ease the work of chainanalysis processes which attempt to identify true spends.

The tainting of outputs seems to me the most impactful for normal users since without them knowing it it will reduce their privacy because some outputs chosen as decoys might be useless and their rings might in reality provide the security of far less than the current 16 membership.

While using the Monero chain for storing arbitrary data is far from the original goal of true digital cash, as some have pointed out, given the Monero transaction protocol is a data protocol it seems rather intractable to ensure that this type of usage does not occur. But what if the use of the tx_extra field to store arbitrary data was assorted of an explicit reduction of privacy? What if transactions which include arbitrary data were limited to inputs with no mixins, hence exposing the true spends? The use of tx_extra for storing arbitrary data would therefore be done knowing the privacy would be reduced. This in turn would allow to mark some outputs as effectively spent and they would not be accepted as decoys anymore. This would induce a Monero chain with really two sets of outputs, those that are known to be spent and the others. What I am struggling to grasp is if it is really a pitfall to have those two sets of outputs when it comes to privacy of the "normal" users of the chain.

I have not a good enough understanding of the actual transaction protocol to determine if it is possible to have a "ring" size of 1, but I guess the protocol could be adapted to allow the spending of outputs this way.

If solution B3.x is implemented, the net effect on the stored size would be potentially negative since removing decoys will reduce the size of the inputs spent in those "doxing" transactions.

For uses of the tx_extra field in some applications (exchanges?), I don't really see an issue in terms of privacy since those applications could introduce an intermediary transaction to first consolidate whatever outputs into a single one before tainting this single output in a txn with tx_extra set.

Again, sorry if this doesn't make any sense.

[martin-braun]

Mental Outlaw has mentioned this issue.

I really hope there will be progress on this issue, because NFTs and Monero don't belong together imho. NFTs are the exact opposite of privacy and the tx_extra field is mis-used for that purpose, similarly to Bitcoin's Ordinal Inscriptions.

[rwjack]

As someone mentioned above, to me it makes sense that monero (cash) should be like cash and have it used exclusively for transactions. If a user needs to store additional metadata related to the transactions, then that should be done within another piece of software.

From my shallow understanding, setting a fixed size for tx_extra and disincentivizing users to use it, is the way to go. On the other hand, this may be exactly the direction "someone not friendly to monero", would want it to go in.

So the main question would be, what would be the best possible use case for keeping tx_extra, in the xmr vs fiat duel?

[povertyhacked]

I am going to keep this very simple. I am not a miner and I do not have a node but I care deeply about privacy and by extension of that, Monero. Having said that, I've never gotten involved in Monero matters because I do not know code and there is a competent team, and community, in place - I've just stuck to advocating for privacy through law.

Having said all of that, the tx_extra field needs to be removed. Monero is privacy and any other considerations do not matter. People will come to Monero and inscribe NFTs because the R:R is great. If that means, even for one person, that one of the 16 decoy sigs is distinguishable, that's a big problem. But what if it happens for me? Or for you?

The 3 letter agencies will jump on the bandwagon when they realise the size of attack vector at play here (I don't even want to put this in writing on the Internet but I'd be kidding myself to not acknowledge that they are clever and will get there anyway, if they haven't already).Just look at the block bloat size BTC has experienced... couple that with a significantly cheaper price, and it becomes a no-brainer for them to try, or another entity to try and then collect the bounty/bounties.

I've read through a fair few comments that note that tx_extra is needed for other things like merge mining - if this is true, merge mining isnt the focus of Monero; privacy is. The only fair comment(s) I've seen against removing tx_extra have been that people will just find another way to store data. Those considerations are fair and probably correct but if that happens, if it opens up an attack vector, then work needs to be done then again.*

Simply put, Monero is meant to be very simple (aside from the processes used to achieve anonymity/privacy). Privacy is the name of the game and other add-on's are cool but not at the expense of losing privacy. Lets not become ZEC.

*For the avoidance of doubt, I am not attacking anyone's position - I am simply advocating for the most privacy possible.

[UkoeHB]

I really hope there will be progress on this issue, because NFTs and Monero don't belong together imho. NFTs are the exact opposite of privacy and the tx_extra field is mis-used for that purpose, similarly to Bitcoin's Ordinal Inscriptions. @martin-braun

Monero is a system for recording and transferring ownership of money. It is not appropriate for the core team to adjudicate the reasons that people transfer money, whether they be NFTs or anything else. The main reason for considering consensus rule changes around the tx_extra is that its current incarnation has very weak privacy under generally-supported-use.

The current leading proposal that keeps the field specifies an optional fixed-size field (which would be encrypted by default). That proposal reduces the privacy cost of default use to the smallest possible non-zero level: 'is a field present or not?' (that's a lower privacy impact than all other sources of distinguishability in txs: tx input/output counts, ring member selection, tx fees, potential for steganography). Decrying 1 bit of distinguishability as a privacy disaster, as some have done, is pure hyperbole.

The other leading proposal, which is to remove the field completely, has two weaknesses:

1. It is not a conservative change. The current protocol has a tx extra, so keeping the field in some form is more conservative than removing it. In some sense, the current protocol is the most canonical representation of what Monero 'should' be.
2. It encourages a higher rate of future hard forks. Removing the field is a clear signal that future features must go through core team assessment and then be proposed for a hard fork. In my view, it sets the expectation that future features will be assessed and proposed for hard fork, which basically cements perpetual hard forking into the ecosystem. As we have seen with comments like @martin-braun's, people are more than willing to advocate for censorship via hard fork. I predict that over time we will just see more and more calls for censorship via hard fork, and for much less benign reasons than opposing NFTs. It is not reasonable to expect that future incarnations of the core team will be as opposed to censorship, or to weakening of other essential properties of Monero (e.g. immutability/permanence - we have already seen some people in favor of 'pruning' old block contents), as the current core team. Next to critical security vulnerabilities, hard forking is the greatest long-term threat to Monero (bitcoin maxis understand this well).

[trymeouteh]

My opinion as a XMR user is to remove tx_extra. If not tx_extra should have a size limit and perhaps additional fees. The NFTs on Monero chain is a privacy concern and to also keep the chain from storing bloat and nonsense.

[Burnsedia]

@trymeouteh we could use fixed compression with a default message/data in the tx_extra, so all blocks have the same size, and all wallets in the ring signature are the same. there are non-NFT uses for having the ability to store data in any blockchain, but if tx_extra is kept, we need to anonymize it as much as possible.

[hyc]

You'd have to use a fairly primitive compressor, like Huffman Squeeze. LZW-based compressors don't just fail on uncompressible data, they make it larger. The usual approach taken by standard compression programs is to pass the original data through unmodified when this happens, but we have to guarantee that the unmodified data is never passed through.

[Burnsedia]

Ok, my bad. Maybe instead of on-chain storage, use an RPC with something like Gunjs to store data. Use the transition information from the monero rpc to generate the seed data in gunjs and key-value pair.

[kayabaNerve]

This does not open the door for "Tracking Organizations" to flood Monero to increase traceability. That is a distinctly possible issue due to the decoy model.

I'd encourage community members without a clear understanding of the actual technicalities to withhold their commentary.

[Burnsedia]

I am just throwing out ideas; I am new to blockchain development. If they are dumb, please tell me why.

[kayabaNerve]

I was responding to dylanthall, who treated the transaction flooding attack present under the decoy model as being premised on TX extra when it isn't. Any bad actor can flood Monero with outputs in order to achieve a large amount of decoys, and Monero has prior experienced such attacks. They did not rely on TX extra. Removing TX extra would actually increase the amount of low quality decoys by non-malicious actors under practical use cases.

If you, or anyone else, wants to learn more, I'd encourage reading through the entire issue and potentially asking around the IRC channels.

For your (Burnsedia) commentary specifically, I'd point out your idea mentions compression yet doesn't actually use compression AFAICT. It suggests a fixed-size TX extra, which isn't achievable with compression, yet with a commitment or with padding.

if tx_extra is kept, we need to anonymize it as much as possible.

Is a generic comment prior stated many times throughout this very long issue, without a new contribution. While I don't want to be too harsh on community members trying to contribute, I'm personally frustrated by some comments making this very long issue longer (which is why I haven't replied to all of them, as now I'm making the issue longer. I only do so here per request).

[LocalMonero]

Removing TX extra would actually increase the amount of low quality decoys by non-malicious actors under practical use cases.

@kayabaNerve is it my correct understanding that you can steg into CLSAG with essentially no network privacy implications, as CLSAG steg only reveals the decoys to the receiver instead of any observer like with output steg?

[kayabaNerve]

It depends on what exactly you do. If you write raw data in there, it'll still damage network privacy. It also reveals decoys to the receiver, which I personally don't consider acceptable.

Output steganography would also only reveal its data to the intended sender if encrypted, and appear normal to everyone else, so

instead of any observer like with output steg

is incorrect.

[LocalMonero]

Right, the question was operating under the assumption of stegging encrypted data in CLSAG vs encrypted data in outputs and the impacts on decoys. Meaning that assuming you're stegging encrypted data into CLSAG you're affecting network privacy to a lesser extent than if you stegged into outputs.

Though, in the case of Serai specifically it doesn't really matter as you're revealing the encryption keys anyway, from what I understand.

[kayabaNerve]

Encrypted data in CLSAG/outputs is indistinguishable to outside observers. In CLSAG, the receiver learn the decoys. In outputs, there's no privacy loss of the sender, though there are more outputs 'contributing' to the decoy set. The outputs only damage network privacy if they're known to be meaningless (such as if the sender publishes their recipient). There are also network privacy implication if the receiver of a message in CLSAG publishes the message, as it harms the tree Monero transactions form.

[kkarhan]

TLDR: OPINION: tx_extra should be removed completely.

---

Reasoning:

As someone interested in Monero and considering to mine it, the tx_extra field is a legal liability amidst the amount of documented abuse of said function.

Notwithstanding the technological disadvantages like the fact that Ordinals as a means to do NFTs will baloon the block- and chainsize and harm legitimate users wanting to use Monero as actual online payment this can and will be used as a nail in the coffin for payment providers to reject it's use, cuz the last thing any bona-fide business [i.e. in Germany] wants to be associated with is "distribution of CSAM" which is a felony.

This is why Ahmia only releases hashes of the onion sites they blacklist which are almost exclusively CSAM so other search engines can do the same or at the very least compare their index and decide what they want to blacklist.

I think that Monero's prime goal was to be an actually fungible currency and a better option than PayPal.

Considering that @fluffypony went out of the project based off solely on random accusations was a clear sign that like OpenBSD, Monero would not compromise it's security at all and would rather go out of it's way to shed staff/personnel/contributors/maintainers and features than lessen it's security.

As a matter of fact tx_extra data (or the absense of it) not only can but will likely be weaponized against users to the point that it'll harm everyone's privacy.

So as much as I hate it, removing it seems to be the only feasible option to do so. After all, Monero isn't intended or designed to be used as a Messenger or something else but a payment & transaction system.

If anyone wanted to communicate something like "This Transaction is a Payment to B for Purchase X from Customer A" that's not part of the payment system and not only can be handled sufficiently by other communications [i.e. Accounting System] but in many places (again thanks to German Bureaucracy) must be handled by a seperate system as per law, thus tx_extra already falls flat in terms of bona-fide use-cases.

At the end of the day it would be far easier and simpler to just copy & paste the txid and block_id for the completed transaction as proof of payment and sent it to the seller by eMail or Messenger or whatever.

After all, Monero can be otherwise operated completely legal and compliant with accounting regulations using the ViewKey. It's not perfect and it should also show outgoing transactions and has severe security and privacy drawbacks but that's outside the scope of this, since this feature isn't bad per-se and has valid use cases, is opt-in per wallet.

Unlike choosing to use a "lite wallet", the use or rather abuse tx_extra isn't something the reciever can actually deny or prevent, copying the whole TornadoCash prank issues and not only incentivize bloatware like MetaMask that should not exist to begin with but will inevitably get us NFT-Malware that exists in the wild already...

I mean there's a reason why there ain't Smart Contracts on Monero: Because for any "Smart Contract" to work would inevitably need privacy to be weakened and expose at least the wallets and amounts to be interacted with, reducing the privacy for everyone else when Multisig can basically do the same as a private smart contract and is pretty straight-forward.

For those that want to use NFTs [which I don't but that doesn't matter!] there are better and more efficient blockchains like Solana to handle those.

Similar to the clear stance against ASICs by Monero there should also be a clear stance against "Ordinals" / NFTs that are exploiting tx_extra and attacks that tried to distinguish transactions by reducing the ringsize to 0 or allowing for different and/or distinguishable ringsizes, thus making transactions stand out.

After all, if people wanted "scarcity" on a privacy blockchain, they could just use Wownero or opt-in privacy chains like Dash or Zcash instead.

I'll await the decision re: this issue before considering to contribute anything further...

---

Addendum:

If someone wants to self-d0x their income in Monero, then that's their choice by publishing the ViewingKey... But Ordinals like NFTs threaten the fungibility of Monero and the privacy of everyone else, thus are non-consensual anti-anonymity exploits that should be regarded with the same severity as past issues and thus fixed accordingly.

We ain't on Ringsize 3 anymore for very good reasons!

[UkoeHB]

@kkarhan The problem you describe can never be resolved by consensus rules. You can always encode at least some data in a transaction using user-defined data fields in ways that cannot be prevented or 'forcibly privatized' using consensus rules.

[bt4599]

@UkoeHB You may be confusing user submitted data with arbitrary data. Fields with a defined purpose can potentially have such a purpose enforced at consensus level since the range of allowed values can be smaller than the range of numerically possible values. For example, placing arbitrary data in the decoys could be made much more difficult by requiring - and checking at consensus level - that the decoys really are decoys, e.g. that they actually exist on chain, that there are no duplicates in the selected decoys and so on. Even if some data can still be encoded, the amount can be reduced.

[kayabaNerve]

and checking at consensus level - that the decoys really are decoys, e.g. that they actually exist on chain, that there are no duplicates in the selected decoys and so on.

These properties are already checked. Monero would have an infinite mint bug if we didn't.

Please don't make me tap the sign: https://github.com/monero-project/monero/issues/6668#issuecomment-1480536557

[bt4599]

@kayabaNerve Which is why i said "for example". It was just one of the easiest ways to illustrate the difference between user submitted and arbitrary data. The "amount that could be reduced" was not referring to the specific example.

[UkoeHB]

Fields with a defined purpose can potentially have such a purpose enforced at consensus level since the range of allowed values can be smaller than the range of numerically possible values.

This doesn't solve anything, because there are still bits available for encoding data even if you constrain everything as much as possible. In practice, a large amount of tx output data is semantically unenforcable.

You may be confusing user submitted data with arbitrary data.

This is just an arbitrary distinction with no functional value in terms of security analysis. All unchecked/uncheckable data is arbitrary data. Even parts of a tx that are highly-checked, like signatures, can be brute-forced to encode information.

[Rucknium]

I analyzed the privacy impact of Mordinal "NFTs" that store data in tx_extra: https://www.reddit.com/r/Monero/comments/12kv5m0/empirical_privacy_impact_of_mordinals_monero_nfts/

[kkarhan]

I analyzed the privacy impact of Mordinal "NFTs" that store data in tx_extra: https://www.reddit.com/r/Monero/comments/12kv5m0/empirical_privacy_impact_of_mordinals_monero_nfts/

Thanks @Rucknium for that deep dive analysis.

This CONFIRMS my fears that this not only can but actually decreases the security of Monero:

"[...] attacks that tried to distinguish transactions by reducing the ringsize to 0 or allowing for different and/or distinguishable ringsizes, thus making transactions stand out. [...]"

• https://github.com/monero-project/monero/issues/6668#issuecomment-1492016289

I don't want to sound alarmist, but this could be the state-sponsored attacks by Chainalysis et. al. who got awarded $625k from the IRS After all, they don't need to break the chain entirely from one day to the other, but slowly downgrade it's privacy to be useless.

The data suggests that this is partially successful to the point that it undoes the ringsize upgrade for quite a significant chunk of transactions.

Which brings me to the next point:

What we've not considered is the abuseability by regulators! Imagine if - due to it's widespread use - Regulators and Exchanges give up on discriminating and trying to ban Monero but instead make up arbitrary bs rules like requiring individuals and businesses i.e. to add their Tax-ID to every tx_extra field when they sent something... Kinda like the ham-fisted approach to cannabis relegalization in Germany being landmined with regulatory bs compared to tobacco and alcohol.

Cuz that would be another "well-meant" but actually cyberfacist & dysthopian law and not be used to enforce taxation of i.e. billionare wankers but go after small coin investors with - compared to Banksters - basically nonexistant wealth.

[Okay, legit businesses would likely have to provide bulk access to their accounting systems and accounts when audited but that would not impact the privacy and security of Monero as a Payment System in General]...

My opinion still stands: tx_extra should be deprecated as it's a security issue - period!

[Burnsedia]

OK, my bad

On Wed, Mar 22, 2023 at 11:02 PM Luke Parker @.***> wrote:

This does not open the door for "Tracking Organizations" to flood Monero to increase traceability. That is a distinctly possible issue due to the decoy model.

I'd encourage community members without a clear understanding of the actual technicalities to withhold their commentary.

— Reply to this email directly, view it on GitHub https://github.com/monero-project/monero/issues/6668#issuecomment-1480536557, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH4ZR52EMVP7SJ66L3R2KZDW5O4LNANCNFSM4ODJ5GQQ . You are receiving this because you commented.Message ID: @.***>