encrypted recipient private data in extra #6410
Conversation
The payload can hold between 1 and 16320 bytes. The ciphertext size is quantized to 32 bytes.
|
In order to ensure homogeneity of transactions, we could consider padding data up till a certain fixed length. This ensures the length is equal for each message. |
I agree but wouldnt that unnecessarily bloat the chain? with payment ids it was easy how about now? |
|
It's a sweet spot between any size and fixed size. The current patch quantizes to 32 bytes. If people want more tx homogeneity at the cost of some bloat, it's possible to have, say, 32 bytes (which can be secretly empty if needed), 256 bytes, and 4 kB. Only three cases, and most txes will likely use 32 bytes. Also, we may want to define a kind of expected format inside. It might be useful to suggest the use of json with some known field names (non exhaustive of course) when one wants to carry more than one piece of info (typically a hash or a key for 32 bytes). |
|
It may sound stupid (and forgive me if it is indeed stupid :) ) but how about padding up to a small multiple of 32 and for messages above that split tx along with the message (and pad the last tx's part of the message up from the remainder to that multiple) |
|
This extra bloat, does that show in the tx-fee ? |
It should cause the fee to increase since the tx size/weight will be increased, and fee is calculated from that. btw, this upper limit of tx extra should eventually be eliminated, since there is already dynamic block size that works with the fee market. |
|
I was thinking: (sizeof extradata / 32) * calculated fee. |
|
For optimal uniformity, the field should be required and of a fixed size. But at that point, you effectively have a larger encrypted payment ID field, and the functionality overlaps. Allowing even a quantized variable size opens the door to multiple anonymity pools and fingerprinting. |
|
This feels like a backwards step to me. The motivations to remove the old payment IDs were a) they were unencrypted and b) they stand out, which opens the door to fingerprinting. By allowing the optional inclusion of private extra data like this opens the fingerprinting door again, exacerbated by the fact its length can vary. In an ideal world all transactions should look the same and be enforced as such. Granted, we don't currently enforce what can be shoved in tx extra (as it would add to the verification time), a patch like this will surely lead to many people naively adding some private extra data and ultimately weakening their privacy. |
|
It is true that privacy would be weakened, but the goal of having the ability to add bytes to the Putting a disclaimer for users would be good enough to asses the risk of putting whatever they want in the |
That maybe some peoples goal, however, the primary purpose of Monero is not to be some generic decentralized ledger for things other than private money. Anything that knowingly weakens users privacy should be avoided at all costs IMO.
I strongly disagree. Most people fail to grasp the nuances and implications of how things may affect their or others privacy.
Attracting people to "contribute and use the blockchain" outside of Monero's purpose of private digital cash is not the goal of this project. Thus it is not "a necessity to have that capability". We have strived, and continue to strive for a private as possible digital cash. If there are compelling use cases to need extra data in tx extra, we at minimum should be ensuring we are not taking a backwards step in terms of users privacy. Enforcing all transactions include a fixed size encrypted bock of data (much like our encrypted payment IDs) is one way of achieving this. Another is enforcement of how/what goes into tx extra (though there has been pushback on this in the past due to the extra verification overhead). |
|
I agree with @jtgrassie about the fingerprinting issue. I'd prefer to see some compelling use cases for this feature before making something like this available. If there are compelling use cases, I'd want them to be compelling enough that it'd be worth enforcing a fixed size encrypted memo field on all txs (to avoid fingerprinting). |
|
As mentioned in #7889, we need some way for a user to pass transaction intent non-interactively. Instead of storing the entire contents of this in a payment ID or in the remaining |
|
I agree with jtgrassie's comment. This is just a bad idea and completely opposite to the goal of privacy. |
The payload can hold between 1 and 16320 bytes.
The ciphertext size is quantized to 32 bytes.