[Discussion] Consider removing the tx_extra field #6668
Comments
|
I support this. I'm perpetually worried about someone wanting to pack stuff into tx_extra unnecessarily. |
|
Are you suggesting giving mining pools the privilege to store arbitrary data into the blockchain? |
|
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 |
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).
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. |
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 |
I like this. |
This bothers me a bit, but really, when have we soft-forked anything? So far all changes have been hard forks. |
|
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? |
|
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. |
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. |
|
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. |
|
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. |
Can you explain what you mean or give some reference? |
@moneromooo-monero can you clarify this statement? |
|
"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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
An arbitrary plaintext data payload in a system whose privacy relies on indistinguishably is like a screen door on a submarine. 😂 ❤️ |
|
Hahah, Neptune and I analyzed tx_extra use and found some interesting on-chain data 😆 High-level overview:
ExamplesDatesMultiple formats observed, including:
These dates and PIDs are often repeated, probably for convenient transaction linkability. Email addressesThere are a large number of email addresses, including personal domains, and several widely-known cryptocurrency ecosystem contributors. URLsThere are a variety of URLs including:
X is the best XThere are boatloads of transactions with variations on "X is the best X", a few examples including:
MessagesThere 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):
|
|
This is great! I'm surprised there are not more malicious payloads, which I guess is what |
|
Any progress on this issue? Is there consensus to put this on the roadmap for a future protocol update? |
|
@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. |
|
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. |
|
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. |
|
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. |
|
I am just throwing out ideas; I am new to blockchain development. If they are dumb, please tell me why. |
|
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.
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). |
@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? |
|
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
is incorrect. |
|
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. |
|
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. |
|
TLDR: 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. 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: 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... We ain't on Ringsize 3 anymore for very good reasons! |
|
@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. |
|
@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. |
These properties are already checked. Monero would have an infinite mint bug if we didn't. Please don't make me tap the sign: #6668 (comment) |
|
@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. |
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.
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. |
|
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:
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 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! 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: |
|
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
<#6668 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH4ZR52EMVP7SJ66L3R2KZDW5O4LNANCNFSM4ODJ5GQQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
and others
First discussed here: monero-project/meta#356
We should consider removing the tx_extra field from all non-coinbase transactions.
Main reasons:
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:
Disadvantages of removing the tx_extra field:
The text was updated successfully, but these errors were encountered: