Monero: [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

[fluffypony]

I support this. I'm perpetually worried about someone wanting to pack stuff into tx_extra unnecessarily.

[ghost]

Are you suggesting giving mining pools the privilege to store arbitrary data into the blockchain?

[sumogr]

afaik there is a proposal (an open pr) already from mooo to make use of extra to encrypt recipient's private data into it which is quite interesting https://github.com/monero-project/monero/pull/6410

[tevador]

Are you suggesting giving mining pools the privilege to store arbitrary data into the blockchain?

No. Currently anyone can store arbitrary data on the blockchain. We could either completely remove this option or keep it just for miners (e.g. for merged mining).

afaik there is a proposal (an open pr) already from mooo to make use of extra to encrypt recipient's private data into it which is quite interesting #6410

The problem is that the consensus mechanism cannot force the data in tx_extra to be encrypted. A malicious sender can still include arbitrary data and claim that it's the ciphertext. Additionally, even the mere presence of encrypted data is a distinguishing factor for transactions (unless all transactions include data of the same length).

[sumogr]

The problem is that the consensus mechanism cannot _force_ the data in tx_extra to be encrypted. A malicious sender can still include arbitrary data and claim that it's the ciphertext. Additionally, even the mere presence of encrypted data is a distinguishing factor for transactions (unless all transactions include data of the same length).

There's supposed to be an off-chain agreement-trust between sender and receiver already, for this to be working, i agree with that, that's the point (assuming i understood mooo's intentions correctly). Padding of arbitrary data up to a pre-specified size was already suggested for uniformity, indeed.

[tevador]

There's supposed to be an off-chain agreement-trust between sender and receiver

A malicious sender doesn't need an agreement with anyone. As an extreme example, imagine a KYC exchange started sending the recipient's name and amount in tx_extra.

[sumogr]

There's supposed to be an off-chain agreement-trust between sender and receiver

A malicious sender doesn't need an agreement with anyone. As an extreme example, imagine a KYC exchange started sending the recipient's name and amount in tx_extra.

there i agree but i already can encode in the tx extra my name or yours, if i knew it, into any tx. Anyway it will be an interesting discussion, lets see

[ghost]

@tevador

We could either completely remove this option

I like this.

[hyc]

* losing the ability to soft-fork the transaction format

This bothers me a bit, but really, when have we soft-forked anything? So far all changes have been hard forks.

[SomaticFanatic]

Also support removing tx_extra. Increasing fungibility is always a good thing. Is this a holdover from Bitcoins way of doing things? What, do people imagine, was the motivation for including it in the first place?

[tevador]

This proposal by @UkoeHB is also relevant: https://github.com/monero-project/monero/issues/6456

It suggests removing all non-optional parts of a transaction from the tx_extra field.

[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 extent, it is up to users how Monero actually gets used. If there is a feature which only a subset of Monero users find valuable, it requires adding data to transactions, and the core team either isn't interested or does not have the resources to implement it, then the only way that feature can exist without a fork is with something like the extra field. Moreover, if for some reason periodic hard forks become no longer feasible, then without an extra field the Monero transaction structure will be frozen for eternity. Just as Monero is changing today, who knows how it will change in the future. An extra field permits changes that don't depend on hard forks.

[tevador]

If there is a feature which only a subset of Monero users find valuable, it requires adding data to transactions, and the core team either isn't interested or does not have the resources to implement it, then the only way that feature can exist without a fork is with something like the extra field

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 in the future, which could be enough to tag users based on the specific set of extensions they use. Do we want this?

[UkoeHB]

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 in the future, which could be enough to tag users based on the specific set of extensions they use. Do we want this?

The biggest problem is if a feature clearly improves the Monero user experience in some way, but for a reason we don't know about today a hardfork isn't possible, then that feature can't be implemented without the extra field. It's painful from a privacy perspective, but I feel we shouldn't underestimate the danger of backing ourselves into a corner by mistake. Imo the extra field is an insurance policy that acknowledges our fallibility as protocol designers.

[fluffypony]

You don’t need tx_extra for that, you can use the range proofs for data storage and all sorts. If we’re going to go down the road of ossifying our tx format then the current one is woefully unsuitable, with or without tx_extra.

[moneromooo-monero]

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.

[ghost]

you can use the range proofs for data storage and all sorts

Can you explain what you mean or give some reference?

[UkoeHB]

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 statement?

[moneromooo-monero]

"You don’t need tx_extra for [embedding extra data for future use]" implies removing extra will not prevent people putting custom data in a tx, which was the intent of the issue. The comment was used in support of extra removal though, so it relies on the intent of the issue being made moot.

[Gingeropolous]

I favor removing tx_extra for tx uniformity. A potential hybrid approach that would allow opt-in tx_data is a secondary chain/database that is linked to the main monero chain.

Basically, you have the tx, and then you have a data packet that sticks onto the tx by referencing its tx_hash. Thus, if a node wants to participate in relaying these data packets, they can signal that they offer this service. Otherwise, the node just relays the tx without the data packet. The data packet isn't mined into the chain, instead it exists as a separate database linked to the chain.

Well, this might be tangential.

[SamsungGalaxyPlayer]

While I really like removing tx_extra for uniformity, I strongly recommend that we take a cautious approach here. We should aggressively solicit feedback from services to make sure they have no intended use for tx_extra. Sadly I am aware of at least one service that plans to use tx_extra in some capacity as a stopgap for Travel Rule compliance until industry tools are available and adopted. To any outsider observer reading this, services should really prefer to use off-chain solutions. However, we may see creative (undesired) use of tx_extra to aid compliance before the industry gets its shit together.

[tevador]

I suggest to at least make an announcement that Monero is planning to discontinue the tx_extra field in the near future to discourage new implementations. We can then discuss the details, e.g. if we allow it for coinbase transactions and if we phase out integrated addresses at the same time.

Keeping tx_extra for coinbase txs could alleviate some of the concerns regarding the ability to soft-fork. Future extensions could be placed there by miners similar to how SegWit works in Bitcoin.

[UkoeHB]

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 make them harder to deprecate.

[SamsungGalaxyPlayer]

It's my recommendation that we announce a plan to phase out tx_extra by late 2021, and solicit feedback like we did for address types.

[Mitchellpkt]

An arbitrary plaintext data payload in a system whose privacy relies on indistinguishably is like a screen door on a submarine. 😂 ❤️

[Mitchellpkt]

Hahah, Neptune and I analyzed tx_extra use and found some interesting on-chain data 😆

High-level overview:

• 350+ dates
• 80+ email addresses
• 10+ URLs
• 100+ variations on "X is the best X"
• 250+ messages

Examples

Dates

Multiple formats observed, including:

• Repeating YYYY-MM-DD: 2017-05-22DM2017-05-22DM2017-05-
• "ID" + YYYYMMDD + tag: ID201904060422492k5oCZ1K71J8ZODB9d
• YYYYMMDDhhmmss + tag: 20190406042249vxBGF5xa5jqbb3GT1Q

These dates and PIDs are often repeated, probably for convenient transaction linkability.

Email addresses

There are a large number of email addresses, including personal domains, and several widely-known cryptocurrency ecosystem contributors.

URLs

There are a variety of URLs including:

• LinkedIn profiles
• A short story
• An article about a ring size update

X is the best X

There are boatloads of transactions with variations on "X is the best X", a few examples including:

• fluffypony is tge best pony ever
• fluffypony is tha best pony ever
• fluffypony is the best pony eveB
• fluffypony is the best pony ever
• fluffypony isbsýìûr5st pony ewww
• fluffypony&86(G(e best pony etRû
• xmrscott is the best Scott

Messages

There are hundreds of messages, ranging from jokes to vulgarity. MANY include PII such as names, handles, transaction amounts, credit card info, and contact information (not included below):

• LEALANA 5 XMR RCT( û(bí)ì 1C!2S(
• <*> Joins [#xmrchain] ->Guest1
• FUCK BINANCE FUCK CHAINALYSIS
• Mining Payout
• Here, have some kitt-katt - -
• 1000000 Monero blocks - XMR4ever
• ThisthebestpaymntIDwehaveeverhad
• anycoin040820190441anycoin040820
• 50X.COM Best Exchange "ç
• For guns, drugs and prostitutes!
• RouziLovesPLGuitarAndLSMusic
• MONERO.RS 100 XMR Giveaway W#1
• This is a test transaction
• @@~:good luck in life:~@@
• DEADINSIDETID4
• ¡¿¡They are watching you
• This tx was generated by Coinomi
• Fuck-your-donations,assholes!
• trololololipopspaymentidmymoscow
• Monero is AWSOME!!!
• FUCK THE SYSTEM
• ETCheckThisOutHereIsYourFirstXMR
• EPOL Group 2 #ICSSS2019 Victory!
• Here'sAnotherMoneroFundTransfer!
• Sic semper tyrannis!
• hallohallo eine neue monero troœ
• Everyone should use Monero!!!!!!
• SleezyMacMoonster(1800-225-5324)
• hei dette er meg
• warm summer buffer zone
• minexmrcomdevfeeminexmrcomdevfee
• thanks for everything
• Test 0.1 XMR to Personal Account
• Yet another uneventful hardfork
• thanks a lot for sharing ideas!!
• 13 tx.s: ASCII_EPOL.html.tar.bz2
• im the king of monero fuckyouall
• >>FUCK YOU BYTECOIN SCAM PIGS!<<
• THANK YOU!
• #Egö !"#$%&'()0123456
• Thou shalt not track my Monero!!
• myfirstmonerodonationtopiratebay
• This is the end my friend again8
• forgot to send this a while ago!
• WE WANT TO USE MONERO TO UPGRADE
• Istanbul 1st monero meetup
• To the Moonero!
• I\'d like to eat some bananasyoy
• ADD-BITCOIN-AND-MONERO-PAYMENTS
• Electroneum Wallet----Payment ID
• Drugs@FBI-Catch-me-if-you-can
• LOL@Chainalysis@LOL
• thisismypaymentidyoufucker!
• DONATION FOR AN AMAZING SERVICE!
• We are the champions, my friends
• XMR IS ANONYMOUS. TRACK MY COCK!
• Thanks for the helphavesome beer
• ICSSS-2019-EUROPOL-GROUP2-FTW!:)
• WhenIwasachildIspakeasachildIun
• Hallo Hallo das ist ein test fƒr
• it's been a pleasure trading w/u
• We need more DOGE smut for ads
• thanks for the graphs theyrecool
• monerogenesismining

[TheCharlatan]

This is great! I'm surprised there are not more malicious payloads, which I guess is what <*> Joins [#xmrchain] ->Guest1 tried to achieve, targeted at whatever is indexing the transactions.

[tevador]

Any progress on this issue? Is there consensus to put this on the roadmap for a future protocol update?