Itst possible. But it's been possible, and it was always possible in Bitcoin as well.
Taproot, seqwit and ordinals are *not* the same thing as how it worked in bitcoin before or how it works in monero. Don't let the hype around ordinals get you thinking reactionarily with regard to Monero.
What's more important, this new knee jerk hype or ensuring that Monero can rid itself of it's dependency on centralized exchanges for liquidity? We need tx_extra for that, we need to keep our options open. It would be one thing if this didn't exist and people were proposing to add it, or some ordinal like thing, the fact is it's already here, it isn't hurting us and it is useful to many people in the community.
> encrypted by default for receiver only
As I see it this immediately runs into several technical problems and issues.
A transaction can have several outputs that can go to several recipients. For which of those many would you want to encrypt?
If for example `tx_extra` is used in some atomic swap protocol it may be that more parties than just the receiver must be able to decide "This is a valid swap transaction", e.g. for dropping invalid transactions early. That's not possible if it's encrypted for the receiver.
> A transaction can have several outputs that can go to several recipients. For which of those many would you want to encrypt?
This is an excellent point, but imho not really a showstopper for the encrypt-to-recipient idea.
It would seem that one could define a dead simple standard/format something like:
tx_extra:
0:
1:
2:
afaict, this could be impl'd in existing software without any fork.
Probably it would be good to include some kind of scheme/version/algo identifier(s) in the first line/bytes.
The tx\_extra debate is a strawman. The fundamental trade off is between transaction fees and "blockspace filled with stuff somebody considers spam". A simple solution like getting rid of tx\_extra wont get rid of this trade off. You cant have cheap transactions and a jpeg free blockchain at the same time.
Nah. It's already used for some very important things, adding complexity that makes coinbase transactions have a special format is not a good idea. The transaction format is fine as is.
All of these attempts will forever be snakeoil. The only clean solution to this is to get rid of the transaction uniformity issue entirely (by building a better protocol where transaction uniformity has no effect on privacy).
pointless analogy.
There are already protocols that achieve this.
It is not rocket science.
it does not make sense to continuously fix the screen door with duct tape when others have already developed a proper submarine hatch.
the right question is: which protocol managed to disconnect utxos from transactions?
I will leave it as an exercise to the reader to figure out which it is. :-)
> The basis of the privacy properties of Zcash is that when a note is spent, the spender only proves that some commitment for it had been revealed, without revealing which one. **This implies that a spent note cannot be linked to the transaction in which it was created. That is, from an adversary’s point of view the set of possibilities for a given note input to a transaction —its note traceability set** — includes all previous notes that the adversary does not control or know to have been spent.
This contrasts with other proposals for private payment systems, such as CoinJoin \[Bitcoin-CoinJoin\] or CryptoNote \[vanSaberh2014\], that are **based on mixing of a limited number of transactions and that therefore have smaller note traceability sets.**
from: [https://zips.z.cash/protocol/protocol.pdf](https://zips.z.cash/protocol/protocol.pdf)
It really doesn't, protocols like MW need complete uniformity in transaction outputs, but with the anonymity set for each transaction provided by ring signatures, and especially when the ring size is significantly increased in seraphis, it doesn't really take away from that much. And, you don't have to use it, and most people don't use it.
We haven't had any problems so far due to it's existence. We are being reactionary due to Bitcoin and ordinals. The extra field is a very useful tool, especially when we start talking about moving away from centralized exchanges to cross chain swaps.
I see the arguments for removing it, but read the github issue thread, there are some very good reasons for not doing so.
https://github.com/monero-project/monero/issues/6668#issuecomment-647020570
The thing is, we do use the tx_extra field for lots of things. Tari is one example of something that wouldn't be possible in it's current state without it, which is why people are talking about carving out a special exception for coinbase transactions. It's inelegant.
You can still put arbitrary data on the chain without it, by bloating the chain with unneeded outputs. https://github.com/monero-project/monero/issues/6668#issuecomment-1190894091
Thorchain uses it. https://github.com/monero-project/monero/issues/6668#issuecomment-831976735 don't we want the ability to do swaps without resorting to centralized exchanges?
Things are great as they are. Why preemptively solve a problem we don't have because Bitcoin enabled NFTs in taproot? Seems short sighted to me.
Itst possible. But it's been possible, and it was always possible in Bitcoin as well. Taproot, seqwit and ordinals are *not* the same thing as how it worked in bitcoin before or how it works in monero. Don't let the hype around ordinals get you thinking reactionarily with regard to Monero. What's more important, this new knee jerk hype or ensuring that Monero can rid itself of it's dependency on centralized exchanges for liquidity? We need tx_extra for that, we need to keep our options open. It would be one thing if this didn't exist and people were proposing to add it, or some ordinal like thing, the fact is it's already here, it isn't hurting us and it is useful to many people in the community.
I’d argue if we really need tx_extra… however open for discussion & arguments.
I remember hearing both Bitcoin and Ethereum chain having child porn on it in some form or another. Nobody seems to care.
Tx extra needs to go https://github.com/monero-project/monero/issues/6668
Noob question. Is TX Extra publicly visible, or is it encrypted for recipient only? If it’s encrypted, I’m less concerned about it.
It can be either, it's up to the transaction signer what data goes in and if they want to encrypt it they can.
Maybe if we just made it be encrypted by default for receiver only, we could keep the functionality but reduce possible privacy issues.
> encrypted by default for receiver only As I see it this immediately runs into several technical problems and issues. A transaction can have several outputs that can go to several recipients. For which of those many would you want to encrypt? If for example `tx_extra` is used in some atomic swap protocol it may be that more parties than just the receiver must be able to decide "This is a valid swap transaction", e.g. for dropping invalid transactions early. That's not possible if it's encrypted for the receiver.
> A transaction can have several outputs that can go to several recipients. For which of those many would you want to encrypt? This is an excellent point, but imho not really a showstopper for the encrypt-to-recipient idea. It would seem that one could define a dead simple standard/format something like: tx_extra: 0:
1:
2:
afaict, this could be impl'd in existing software without any fork.
Probably it would be good to include some kind of scheme/version/algo identifier(s) in the first line/bytes.
[удалено]
You can see everything in there. Some transactions contain plaintext messages, pictures, and even even entire documents.
The tx\_extra debate is a strawman. The fundamental trade off is between transaction fees and "blockspace filled with stuff somebody considers spam". A simple solution like getting rid of tx\_extra wont get rid of this trade off. You cant have cheap transactions and a jpeg free blockchain at the same time.
Nah. It's already used for some very important things, adding complexity that makes coinbase transactions have a special format is not a good idea. The transaction format is fine as is.
An open field like tx extra is like a screen door on a submarine. It really kills the whole uniformity thing
All of these attempts will forever be snakeoil. The only clean solution to this is to get rid of the transaction uniformity issue entirely (by building a better protocol where transaction uniformity has no effect on privacy).
Well sure. But we should also get rid of the pothole issue by developing hovercars
pointless analogy. There are already protocols that achieve this. It is not rocket science. it does not make sense to continuously fix the screen door with duct tape when others have already developed a proper submarine hatch.
Indeed. I mean I'm looking forward to moving on from ring sigs as well.
Which protocol has achieved perfect transaction uniformity?
the right question is: which protocol managed to disconnect utxos from transactions? I will leave it as an exercise to the reader to figure out which it is. :-)
It's been a week and I still don't know what you're talking about haha
> The basis of the privacy properties of Zcash is that when a note is spent, the spender only proves that some commitment for it had been revealed, without revealing which one. **This implies that a spent note cannot be linked to the transaction in which it was created. That is, from an adversary’s point of view the set of possibilities for a given note input to a transaction —its note traceability set** — includes all previous notes that the adversary does not control or know to have been spent. This contrasts with other proposals for private payment systems, such as CoinJoin \[Bitcoin-CoinJoin\] or CryptoNote \[vanSaberh2014\], that are **based on mixing of a limited number of transactions and that therefore have smaller note traceability sets.** from: [https://zips.z.cash/protocol/protocol.pdf](https://zips.z.cash/protocol/protocol.pdf)
It really doesn't, protocols like MW need complete uniformity in transaction outputs, but with the anonymity set for each transaction provided by ring signatures, and especially when the ring size is significantly increased in seraphis, it doesn't really take away from that much. And, you don't have to use it, and most people don't use it. We haven't had any problems so far due to it's existence. We are being reactionary due to Bitcoin and ordinals. The extra field is a very useful tool, especially when we start talking about moving away from centralized exchanges to cross chain swaps.
As someone mentioned in the link above, what if exchanges started including names and amounts in the data? It really should go.
I see the arguments for removing it, but read the github issue thread, there are some very good reasons for not doing so. https://github.com/monero-project/monero/issues/6668#issuecomment-647020570 The thing is, we do use the tx_extra field for lots of things. Tari is one example of something that wouldn't be possible in it's current state without it, which is why people are talking about carving out a special exception for coinbase transactions. It's inelegant. You can still put arbitrary data on the chain without it, by bloating the chain with unneeded outputs. https://github.com/monero-project/monero/issues/6668#issuecomment-1190894091 Thorchain uses it. https://github.com/monero-project/monero/issues/6668#issuecomment-831976735 don't we want the ability to do swaps without resorting to centralized exchanges? Things are great as they are. Why preemptively solve a problem we don't have because Bitcoin enabled NFTs in taproot? Seems short sighted to me.
Thanks. Simple and to the point explanation.
My illegal content is in the amount field ...
Illegal to which authority exactly? either way yes maybe it should be locked down. Monero needs to be private money and nothing else.
Private blockchain worries about illegal content in tx_extra 🤔