Meeting here in 30 minutes.

meeting time monero-project/meta #801

1. greetings

hello

Hello.

Hi

Hello

Hi

Hi

Hello

hello

2. updates, what's everyone working on?

Hello

me: OSPEAD coding work. Also set up a little C++ exercise for Geometry Labs/isthmus.

me: trying to catch up with the new curve discussion and structuring what needs to be done for the wallet transaction history

me: getting back into my todo list, these are the major items on it: refactor enote store to use block id checkpoints, refactor enote scanning to use a re-usable state machine that can be adapted to scanning backends, review dangerousfreedom's seraphis knowledge proofs PR, then finally update the seraphis paper

me: need to push my mocks to github(the mocks should demonstrate a way to use 2 different transaction classes)

What are these "two different transaction classes" for?

3. discussion; today we were supposed to return to the tx_extra discussion, however the lower turnout makes me unsure if we can resolve it in this meeting

In any case, I have a question there, because I lost track a bit in all the discussion

So currently we are using a single transaction class, but with seraphis we are adding a new transaction class, and we want a nice way to treat both of them, without, for example, save in each place that treats transaction two lists, one for storing cryptonote transaction classes and second for storing seraphis transactions

There was the proposal to mandate encryption for the tx_extra data

And check that with some heurisitic

Where does that discussion stand? Is that reasonably possible to achieve?

I don't know. We shouldn't use a heuristic by the way. Do a rigorous statistical test.

I meant to include that. I am pretty sure you can't prove something is encrypted

I think what you can hope for is an algorithm that says "This is probably encrypted"

I scratched the surface of cryptographic randomness tests. It can be complicated. If we treat it as just an unordered set, it is pretty simple Chi-squared test or similar. If it is an ordered sequence , then it gets more complicated.

and then hope that this does not fail and reject properly encrypted stuff sometimes

You can set the rejection probability by choosing the p-value to reject below

That's what a p value is

My take is you can't force people to not opt-out of privacy. In the case of a statistical test you can mask your payload with a fixed random bytestring for example.

It's the probability of a false positive

Thanks shalit I remember reading this in the chat at some point now that you've explained

UkoeHB: Yeah. There is a question of how someone might try to directly fool the test

That would almost count as encryption, no?

You probably want some form of deniable encryption then

I see this more as a political question: If the Monero Project gets attacked, we can show that we took reasonable precautions to ask for encryption

Attacked in the sense of politics: Somebody wants to throw mud at us

'political precaution' isn't in the design goals of the project

:)

Alright, but I got my personal question answered: That question is not settled, I can't assume encryption enforcement is on the table as option

If you wanted an answer on the feasibility of a statistical test, I could have researched it in more depth for this meeting.

anyway, here is the choice matrix for the tx_extra, we can at least discuss it with the people here

A) [remove tx extra]: cost is tx utility flexibility tied to hardfork (or steganography)

B) [keep tx extra in some optimized form]: cost is uniformity and scaling trade-offs depending on the solution

1) leave as unlimited-size TLV field

2) mandate maximum tx extra size (e.g. anything in 0 - 1000 bytes)

3) mandate optional fixed-length tx extra size + encrypt by default

4) mandate fixed-length tx extra for all txs + encrypt by default

5) other

I don't think that would be important enough, if only I am curious about this, while forming my opinion about tx_extra removal yes/no

I said last meeting "If there is a need/desire for a statistical check of the randomness (encrypted status) of the tx_extra field, I can help search for an appropriate statistical test." Maybe I should have asked for an affirmative "yes" if that statement was ambiguous.

Guilty. I somehow missed that.

Encrypting by default makes sense. Everyone who wants that privacy will have it without thinking. Trying to enforce does not make sense. If someone is trying to flood the network with identifiable outputs, they can just publish they don't need tx_extra for that in the first place so I don't see what the randomness check buys us.

So that's now a "no" from me: I don't think that merits further investigation right now.

here, but late, sorry

They can just publish their view key*

sorry Rucknium[m] your comment may have been lost in all the activity of last meeting

It's fine. No offense taken at all.

In that matrix you propose, can we mix the points 1 to 5? I would like maximum length plus an attempt at asking for encryption

Looks like that would be a new, additional number

Just an outsider's opinion: to me, the optional fixed-length tx_extra (with encryption on top) seems like the best compromise between all options. Users who don't need it don't have to pay extra fees and there's less bloat, and those who do will be still indistinguishable from eachother, so we'll have no idea what they're actually doing. Yes, it's still technically a puddle, but it would be a uniform puddle

a maximum or fixed?

My take is to narrow it down to A or B3. Thoughts

rbrunner: B) 2) mandate maximum tx extra size (e.g. anything in 0 - 1000 bytes) (option: encrypted by default)

actually maximum makes most sense

I think it may be hard to require changes to tx_extra by changing node relay rules. About half of all nodes were running old software in the August hard fork. At best, the mining pool and p2pool nodes (maybe) would reject the txs when they came to them if they were running new new-rules nodes.

Also, the pros and cons of each point can be hashed and rehashed ad infinitum. I think the best option is to choose an arbiter (either an individual, or a small group) that we "trust", who will make a final decision on the matter

And that decision will be final

basically tevador was on the right track with that pr, as per usual lol

The problem of max size is that it really leads to tx fingerprinting

UkoeHB: That 2) sounds good to me :)

I kinda like the stego option, despite the ring size decrease to the recipient (and only the recipient).

yeah but you gotta know what your doing if you dont follow the guidelines posted by core

as in core will set guidelines for tx_extra, and so forth

"stego option" does not look like an option to me, just the likely consequence of removing tx_extra

so you can make it variables size with a cap, but we'll set a tighter spec for normal usage

Otherwise B3.

Max size (instead of FIXED size) would lead to all sorts of fungibility puddles

yeah but youre just destroying your own privacy first, everyone elses second

Yes, but still progress, as the most blatant nonsense is prevented

blankpage[m]: 👍

Just to make sure: In any fixed size discussion, it's already assumed that tx_extra is ONLY there if somebody puts something there?

I.e. the "normal" uses we have today are away

With additional keys and such, don't remember exactly

Yes

rbrunner: that is the difference between B3 & B4 surely

Hmm, not sure, I think it's a technicality that does not yet occur here

But anyway, it's important to understand the proposal

vtnerd: the tx_extra as a generic field has a broad range of 'default behavior'. Since our goal is 'private by default', imo we should think about all natural uses of the tx_extra as part of the design scope - which includes any field someone adds for their personal project, etc. That what B3 and B4 are all about - setting up the field so all default-conforming uses (both 'not using it at all' and 'using it with some

personal field but following spec') have a higher degree of privacy than we have now.

Selecting coinbase outputs in rings might be having more effect on reducing effective ring size right now than tx_extra ever will. And we haven't made real moves to address it besides sech1's work on p2pool output efficiency: monero-project/research-lab #109

a lot of words ukoehb, but you might be in the minority atm

Maybe

the project is about continually improvement, sometimes it takes a while ... anyone enough rambling from me

*anyway

The option is 0 (effective) A or a small fixed size say 256 bytes. This is enforced by consequences.

Randomness Is enforced only by default encryption and multiple randomness tests via node relay

vtnerd: to be more blunt, design choices have to be focused on our design goals

which are: privacy, security, scalability, longevity

Enforced by consensus

Well, discussing our design goals would probably end in a similar going round and round ...

As soon as I try to add "flexibility" or "real-world usefulness" in there probably ...

I believe we can start by eliminating options a clear majority disagree with

rbrunner: those are secondary goals, I listed the primary goals

The difference between B3 & B4 (whether the fixed soze encrypted blob is mandatory or not) comes down to scaling of storage requirements, because these blobs have very low verification costs. It seems to me that scalability of verification is likely to cause problems long before scalability of storage/bandwidth.

I’d vote to remove the tx_extra field (A) and enforce a certain number of outputs for each transaction (2,4,8,16) to prevent output stego

I think you might be out voted on that now xmrack[m]

xmrack[m]: that doesn't prevent output stegonography

yeah exactly, and it doesn't solve the problem

I only see B) 1) as having clear majority against right now ...

Actually bandwidth is the biggest scaling challenge

Verification can be processed in parallel

This is why I do not like B4

And B) 5, we seem to have no other clear proposals

Anyway, from the pro fixed size voters, what do you imagine as a reasonable fixed size?

0 or 256 bytes

Maybe we could make those proposals a bit more precise for a vote in the near future

ArticMine[m]: I was wondering if maybe 128 bytes per output would be more useful (2-out txs would be 256 bytes)

If the consensus is for something in option B. I’d prefer either 3 or 4

Ah, per output is of course a possible variant

128 bytes or 0 is fine

But then people may produce many dummy output to get their GIF or JPEG into there, surely

Per output is messy

In my scratch of the surface at cryptographically randomness tests, most tests had O(N^2) complexity at worst case. That may matter if we want a fixed/max size + statistical test of randomness.

We have the nodes pick a test at random from a set that can change over time

ArticMine[m]: how so?

256 is a nice round number. Anybody here who thinks they cannot live with that?

Randomness test is only useful as a sanity check for stupid clients. Someone can still "encrypt" with a well known secret key, which should defeat any statistical test (that works).

If the blob is fixed per output, it would require fees per output to scale much quicker than now surely

moneromooo: That is the point

As an outsider that might consider integrating with Monero, I'd find a fixed tx_extra with encryption to be the better choice. 0 or 256, 1000, whatever. If you think you can actually validate randomness efficiently then that'd be fine. I'd just rather not suffer random failures because of this.

The only safe way is encryption

I don't really understand how a statistical test is useful if the default wallet behavior is to encrypt the field.

Otherwise you stand the risk of being caught by some "randomness" test

Kicking third party wallets in the butt till they bother encrypting :)

shades of opting out? seems like a pointless exerciese

Well, I am sure lawyers have a nice term for that, "reasonable effort" (of the project) maybe, but anyway, that's again "political" :)

There are going to be random failures of valid (encrypted) tx_extra contents. The failure rate can be set by the p value. If you set the p very very low, then you will have more false negatives (i.e. let a transaction through yet tx_extra is not encrypted).

So you could set p to 0.00001 or something and we would expect 0.001% of all valid tx_extra contents to not be relayed by nodes.

Is this also dependent on the length? Is the false positive danger bigger with shorter lengths?

Yes. If you have 1 bit, then...

in my view it's fairly black and white: either an implementer tries to be default-conforming, or he doesn't and all bets are off. If encrypting is too much of a pain, then the implementer will just find some cheap workaround to a statistical test.

I like using extreme values as a sanity check.

I agree that statistical tests seem relatively pointless. The effort for someone to create a blob of the correct length with clear text identifiable text is much higher than typing troll comments in the tx_extra field as it is now

We make the default encryption

rbrunner: The false negative danger would be greater when the length is shorter. Usually with these tests you, the decider, set the false positive probability (that's the p value).

Yeah, moneromooo's 1 bit argument is pretty convincing. But I guess with 256 bytes we get something working reasonably.

So if the tx_extra byte length is really short, then it might be pointless to do a test since you would have to set p to be low and only catch really unencrypted text rarely

Yes, but even that cheap workaround will prevent we have blatant nonsense in the blockchain open for everybody to pick up trivially

This is just general statistical theory that almost certainly applies to a more specific test. I have not looked deeply into what specific tests could be used

But here are some materials I was looking at:

The statistical test sounds “hacky” and bad UX for those handful of users

rbrunner: that is a bad argument, there are many trivial ways to put nonsense in the blockchain with a statistical test

Intuitively the shorter the field, the more failures you'd have. Probably deserves some research. All for an encrypted fixed length field if you send it.

for example, you can XOR each set of 32 bytes with one of the key images; trivial to decrypt

Ok, maybe I am not used to think like an adversary ...

Testing for "randomness" doesn't stop determined individuals from harming their privacy. Seems the only practical impact is causing occasional tx failure. Just making encrypt the default is good enough.

I agree that there are multiple ways to get around these types of statistical tests by a determined programmer.

Can't we solve that random failure problem easily? Allow to hash after encryption, have a counter how many times you hashed, hash until the test is ok

in the end we'd just look stupid for trying, if some one-liner is all you need to decrypt the field

You can't, since 000000...00000 is very likely a valid ciphertext.

Zcash has an encrypted memo field. I'm not sure how they do it. Maybe they encrypt with users' private keys.

Which immediately takes away much of its usefulness for our tx_extra if true.

They are looking to improve it by the way for messaging: forum.zcashcommunity.com/t/rfp-zcas…ld-secure-messaging-extension/44069

“Zcash lacks several essential features necessary for secure messaging, such as being signed to verify the origin of messages”

Doesnt sound like they use their private key

we are at the end of the hour so I'll call it here, we will return to the tx_extra discussion in the next meeting

thanks everyone

Anyway I vote b3 or b4, leaning towards b3. My reasoning is that two puddles is not as good as one puddle, but perhaps on a practical level two puddles is good enough considering the space savings compared to mandatory fixed size blobs. And two puddles is much better than potentially hundreds of puddles of the present situation.

Does anyone want me to research options for statistical tests for next meeting?

Maybe xmrack and I could do it together.

I'm personally not excited by the idea of a statistical test

It's not clear to me what problem the statistical tests would be truly solving

Rucknium[m]: are you arguing for one in consensus, or just as a "look out, moron" sanity check on daemon RPC ?

Not a technical one, if you ask me. A psychological one, and maybe even a juristic one

moneromooo: I am just trying to be a resource for the discussion. I think it would be probably not a good idea to put it in consensus. Node relay level is where we were discussing it I think.

Rucknium[m]: Within reason. If the probability of failure can be kept say below 0.001% for valid encryption

And if the wallet can re-roll automatically.

While getting rid of almost all the junk

We are here in the MRL alright, but out in the world lazy exchanges search for pretexts to drop XMR support. We could show we are *seriously* against some abutes.

*abuses

And take some wind out of their sails.

This is about the legal case of reasonable efforts

I think if someone wants an excuse to drop monero, there are various compelling ones in existence.

Ok I will put in maybe 8 hours into researching what the options are. Focusing on options that would be good to block an "adversary" that is trying to defeat the test with filler text or something.

Seems the answer on "how often will tests mess up legitimate txns" depends on the tx_blob length, which has not been agreed at this stage. I guess as a warning for users it makes sense, but maybe a low priority issue.

Yes, and maybe I am too optimistic there that we can make a real difference

blankpage: It depends on the p-value, which can be set directly in software.

If anything, dropping tx_extra altogether would probably the strongest possible action in this particular regard

rbrunner are your concerns here about illegal/obscene content on the chain? My understanding is this already exists on BTC and others and there have been no consequences. Also a size limit would seem to stop most possibility of this.

Mostly, yes. To this I would say we are not BTC which by sheer size and momentum is currently immune to almost anything

"BTC does it, so we can as well" is maybe a bit optimistic

Zcash memo is encrypted using the transaction view key.

“exactly 512 bytes long. If a sender doesn’t specify a memo, then the memo that is sent is all zeroes (before encryption), and if the sender includes a memo shorter than 512 bytes, then the remaining space is padded with zeroes (before encryption)…. The encrypted memo is visible only the to recipient, unless the transaction view key for the transaction gets shared”

But I think a size restriction to 256 bytes would already go a long way here. Not much porno fits into 256 bytes :)

Midget porn maybe ?

xmrack: Thanks! But do they verify somehow that the contents are actually encrypted?

Have we discussed if the encrypted tx_extra is only for the sender or if the recipient should be able to decrypt it by default?

Rucknium: I’ll check

rbrunner: Porno no. But there is plenty of room to advertise illicit web sites, sad to say.

Anyway, I have a hunch that a professional mediator / arbitrator would probably try to find some compromise, and B)3 or B)4 look like compromisable.

bitcoin debated OP_RETURN in 2013-2014 I think. Could we find some wisdom in the archives?

one-horse-wagon: true

UkoeHB: A

Sorry for the slowness

tx_extra has got to be available to the recipient, no? Seems like a lost opportunity if not.

There's so much time wasted on the tx_extra question when its already been discussed to death, core team should just make a determination and let's be done with it.

There's nothing new proposed by anyone.

kgsphinx: one would think, but I dont think it has been discussed

rbrunner: Stop compromising with Ethereum-wanting-devs. Monero is not that project.

How is that, history punishes the latecomers :)

I got it that I am not waving your favorite viewpoint.

Alex | LocalMonero | AgoraDesk: I agree with you on the removal but it seems the general consensus is to move towards options B3 or B4. I’m happy with the progress towards a definitive solution

B3 is fungibility killing, B4 is efficiency killing.

B4 with a fixed length of 0 is A

Any B is a B solution

Hmm, maybe not enough people in the meeting today to make a good judgement about current "general consensus"

rbrunner: Exactly

The general consensus was best shown in the first meeting as that had the most traction.

By the way, for me it's my decision how I waste my time today.

That's true.

Monero means money, mostly it turns out

I'm sure the public is going to love to hear that everybody will have to pay extra fees on each tx if B4 is implemented, why? Because 0.1% of the chain users want to inject arbitrary data we'll tell them.

Jesus, again...

Can we narrow this down to:

A

B3 256 bytes or 0 bytes?

Yup, Monero: compromising with the 0.1% for the detriment of the 99.9%

And please take good note of the "or": It's *not* true everybody would pay extra fee.

rbrunner: Was talking about B4 which is fixed length mandatory

B3 is a fungibility nightmare with infinite subchains

Ah, ok.

I support B4 with 0 bytes That is equivalent to A

Alex|LocalMonero: What do you mean by this?

Please, can we get that argument a bit less dramatic?

2 sorts of transactions, one with and one without tx_extra, is already a nightmare?

Fixed length of course

and probably encrypted

Yup. It effectively makes everyone outside of the without tx_extra chain stand out

ArticMine @articmine:monero.social: why do you favor a mandatory tx_extra with zero length over removing the field entirely? Just to keep the option of bringing it back later? Or do I misunderstand you?

B3 with 2 options is 2 subchains

I support putting up A versus B3 256 bytes to vote, in any case

Seems more like we'd be reducing from infinity to 2 with B3.

Or, if, tragically, tx_extra will be used for a soft fork then we'll end up in a situation where those who arent attaching tx_extra will stand out

kgsphinx[m]: Not really if we remove tx_extra

B3 is an option that includes tx_extra

Yeah and I'm against keeping it.

I get it :)

I'm saying that B3 will break fungbility.

As compared to not having it

Can't break what's already broken though.. we have tx_extra and it's not limited.

Sure we can limit it now, but post-seraphis it should be removed

I thought this was a discussion on the final fate of tx_extra and not on the provisional state?

blankpage[m]: It may be easier to implement transition wise but in reality it is equivalent to A from a practical point of view

Realistically it is A or B3 in my view

..and then go to vote

ArticMine: what's the consensus inside the core team on this? Do you have an internal majority for removing or keeping tx_extra?

I just do not see a consensus around the other options

It has not been discussed Other than here

Well perhaps you should. In the end this is a core team dictatorship.

And that's a good thing, by the way.

As for core team members here I see one for A and for voting between A and 3B

B3

CCS is a core team dictatorship, and so is merge authority on github. I don't think anything else is really.

It should not be

. . Realistically this is not a core team issue

blankpage[m]: Merge authority in github is effectively all you need if your github is what everyone is pulling from.

I doubt that most people outside the core community (which is mostly the same people year in year out) will care if the core community disagrees with the core team and forks away.

See: BTC/BCH civil war

Alex|LocalMonero: They have fundamental structural problems we do not have

In any case we are way off topic

Whatever the outcome of this contentious tx_extra issue is, I'm pretty sure that if the "losing" side forks away it's not going to get mass adoption.

Yes. Arguments by volume aren't very helpful.

I agree.

Act it then, please. Thanks.

Sorry, I'll just keep saying the same arguments over again like the rest of us.

Alright. Plonk time.

Shold have done that earlier I guess.

Please no

I jest

Did we talk about the drawbacks of the effective ring size decrease when using stego in sigs (kayabaNerve's method) ? I kinda remember having a talk about this, maybe here, not sure, and I kinda talked myself out of it IIRC.

But it'd be a great replacement for extra if the loss is deemed acceptable.

As a reminder, you can stuff about 31.5 bytes per ring member, which decreases the effective ring size by 1 for the recipient (but not for Eve).

Though of course if Eve is the recipient, she might publish that info.

Are there privacy implications beyond the recipient? Can't Eve always publish which outputs are true?

I am unsure how this would work for sending messages to more than one recipient in a tx though, if that is wanted.

didn't read all. Regarding encrypted/randomness test, can't wallet run this test before sending a tx and regenerate it if it fails? That will solve the random false negatives

Yes, it could.

sech1: the test isn't useful for core code, which would encrypt by default

even default encryption can fail the statistical test sometimes

oh your point is just for handling failures

Similar to the tx sanity check, which fails sometimes (and checks for a sane enough output age median).

That was to try and slap silly clients that used obviously wrong fake out selection. I think I didn't make it retry at first, but someone else added it (thanks).

So, no opinion on that stego thing. Guess most people left. Oh well. I'll try next time if I remember.

Removing tx_extra would simplify the protocol and save us a lot of time arguing about how to implement it.

The protocol doesn't care much about extra. It's just serializing an array of bytes.

So technically true for the first part, but by epsilon :)

If we wanted to make it prunable, there could be additional complexity around txid calculation.

Possibly a new tree branch here: UkoeHB/monero #8#issuecomment-1430207423

Sorry for missing the meeting. CLSAG steganography eliminates decoys to the recipient. A static random pad used to 'cheat' a statistical test is cheating by encrypting it. My vote on the matrix is B3.

I'd like to distinctly note if we keep TX extra, it should be prunable, as discussed at the end.

I agree on both points, if that matters

If we can agree on a vote A versus B3 256 or very similar, with enough attendance of course, today's meeting would have a very good result

rbrunner: if B3-256, 1. Why do you believe that the sacrifice of fungibility is worth it and 2. What do you think of the notion that an optional tx_extra field might become a mandatory field in case of a soft fork?

A "static pad" won't work in practice. It will fail the test with some probability (as any encryption), so it can't be "static".

Alex|LocalMonero: I only repeat an argument, I know, but I see it fit: We are living 8 years with tx_extra that is much more potent than B3 256 and the sky didn't fall

That's true but we're not the world's reserve currency yet.

We're kinda under the radar.

But anyway, yes, for me a fungibility that is somewhat reduced is worth it compared with what I hope to gain.

You can argue basically anything with future scenarious where nobody can prove they will happen, nor prove the opposite.

You argue with future world reserve currency, I argue with possible breakdown that we can only avert by using tx_extra. Checkmate :)

That's why, much to sech1's dismay, we will have to resort to some crude vote to decide the future course. It seems technical arguments alone won't convince enough.

Because you can *judge* those arguments in different ways.

Or better said, weight them differently

By the way, I have no fear that actually on the brink of becoming the world's reserve currency we wouldn't be wise enough to re-judge some things differently

The B3 option is a net improvement over what we have. Banishing it will only encourage steganography approaches in the case somebody needs extra bytes, which will cause bloat and reduce fungibility as well. Hence the reasonably sized, encrypted, 0 or N byte option seems pretty optimal.

Did somebody say "compromise" ... :)

kgsphinx[m]: I don't think it's reasonable to call something that conforms with a definition of a tx as bloat. One can argue that the definition of a tx needs to get stricter but one cannot use the laxness of a tx definition as an argument to support further laxness.

<rbrunner> "Because you can *judge* those..." <- The argument needs to be judged against the principles of Monero's design, not against the personal desires of certain devs.

I unselect my preference for CLSAG stego, since it doesn't carry over to seraphis, that was mentioned last week and I had forgot.

Bloat to me is whatever adds unnecessary bytes to the chain. I think you're saying that HOW fungibility is impacted is also important to you. So weird looking transactions are ok, in fact better than a 1 in 2 out transaction with extra data. Just not sure I agree. I also don't think it's "lax" to have a field like this.

Alex | LocalMonero | AgoraDesk: you keep mentioning that the B3 option would *completely* break *fungibility*. Could you elaborate how, exactly? Obviously we can distinguish between the (few) txes that have tx_extra from those that don't - but what other information could an external observer gather?

- How would it impact the *privacy* of that transaction?

- Would it reduce its effective ring members, or reveal any additional information about the contents of the tx in question?

- How would it impact other transactions that include this transaction's outputs among its ring members (whether as a real spend or a decoy)?

We have other examples of things that put transactions is different pools, like fees.. that's not killing the project either. Take the net gain man!

It would not *completely* break *fungibility*, that's appeal to fear again.

s/is/ib/

s/is/in/

I certainly never said that it would completely break fungibility, just that it hurts it.

moneromooo: I agree, that's hence my questions

Sure, just answering it :)

Lax is leaving tx_extra as is.

Still, how does it hurt fungibility?

You've explained it yourself. There's two distinct pools of txs now: ones that utilize the tx_extra field (a minority I assume <1%) which will stand out, and ones that don't utilize it.

And this is, of course, assuming that there is no soft fork.

A lot of people involved in these discussions seem to think that soft forks are a good thing and hence tx_extra is good to keep around.

Depends on the details, but it's a much less extreme version of "Alice uses 2 monero fee for every tx". Some people/usages will be more likely to have the option on than others.

It might break perfect transaction uniformity, but I don't see how it would break fungibility, per se

(I am assuming a hard fork scenario, if that helps)

So you can have a better than random chance to predict things. Maybe not much better, but still better.

So the problem is deciding whether that small loss is worth the added ability.

I mean, outputs that are consistently involved with tx_extra are clearly not good candidates for decoys anymore.

That's... subjective.

They would have to be excluded from the decoy selection. moneromooo do you see my messages or not? it's hard to understand who you're replying to

Like, you see a ring signature where a (small) number of outputs comes from txes that had a tx_extra, and the rest come from "normal" transactions. How would that impact the protection of the ring signature? Would it allow you to exclude certain decoys?

I mean both sides are subjective.

Alex|LocalMonero: I do now, request from UkoeHB.

Thanks, I asked

Sorry I'll get to your thread after I finish with endor

merope: So, it's basically impossible to predict all the scenarios in the future since tx_extra opens a pandora's box of possibilities that are hard to predict, so I'll simplify to two cases:... (full message at <libera.ems.host/_matrix/media/v3/do…2a4262cfa4ce8593aeb30546b678477f2de>)

But the premise was that the field is encrypted/obfuscated somehow, so the only thing an external observer could see is that the field is there, but not what it's used for

(Unless you literally have a single application using it, which would make it trivial)

You say that bloat are unnecessary bytes to the chain. First off, which bytes are welcome on the chain? As far as I understand the goal of Monero is to be digital cash. This goal is strict and narrow in definition, therefore any other application layer functionality is to be implemented on other chains or databases. So, if all but money transfers are deemed as acceptable on the Monero chain, then any other data that is to

be injected as a consequence of a not-strict-enough tx definition is undesirable data and hence its a good thing that its not efficient

So you'd have no way to tell if that tx was involved in a dex, or if it's a secret message, or it's the bee movie mp4 uploaded in very tiny chunks

And let's not forget that the good-natured applications of writing data into the chain will only take a tiny proportion of the overall txs so they really "bloat" the chain only a little bit, hence a tiny price to pay to maintain efficiency and fungibility

merope: Yeah but just because it's encrypted doesn't preclude the DEX from publishing the keys.

> <@alex:agoradesk.com> So, it's basically impossible to predict all the scenarios in the future since tx_extra opens a pandora's box of possibilities that are hard to predict, so I'll simplify to two cases:... (full message at <libera.ems.host/_matrix/media/v3/do…669b2ca83d4b85ddb4aca4171ec2c44d062>)

That's the idea.

Alex|LocalMonero: That falls outside the scope of Monero itself though. By that logic, I could also choose to publish my wallet's viewkey and spendproofs: that might impact the privacy of those who pick my outputs as decoys, but it wouldn't *completely* break fungibility - just slightly weaken individual ring signatures. The protocol itself would still be sound

There's a difference between controlling one wallet and publishing the keys and controlling an entire subchain application and publishing the keys.

* Got it, got it.. I like your hardcore attitude but I still like the tradeoff of the utility. If a DEX would rather not use this field then they could try steganography instead to claim "superior fungibility".

Are there any subchain applications that do this?

Or would actually choose this approach?

Not to mention the keys needs to be published for the DEX to work, as was mentioned by kayaba.

fluffy put it better than me: steg is a small price to pay for being rid of the tx_extra field.

So a necessary condition for building a dex that supports Monero is to publish the dex's viewkeys? And there's no other alternative approach (whether using tx_extra in an alternative way, or some other system entirely)?

(Like direct p2p transactions, even?)

Actually no, it's not a necessary condition to build a DEX at all, but one of the main proponents of keeping the tx_extra field in these discussions showcases his DEX as why tx_extra should be kept.

There is another DEX: Haveno, which doesn't utilize tx_extra at all.

I see

In fact, there's nothing within the concept of a DEX that necessitates having an arbitrary data field in Moner.

s/Moner/Monero/

* There is another DEX: Haveno, which doesn't utilize tx_extra at all (as far as I know).

So right now, this specific application of tx_extra potentially weakening ring members due to the data it publishes outside of the chain, is purely a hypothetical future scenario?

No, it's a real scenario. Some people proposed excluding outputs in txs that employ tx_extra this way from the decoy selection algorithms.

The soft fork scenario is hypothetical, though. Monero never had a soft fork that I know of.

But there's plenty of soft fork fragmentation evidence in the BTC chain.

As I said before, soft forks can be done without tx_extra, so it's not an argument for keeping it.

(Yeah I'm completely ignoring the soft fork scenario, I'm assuming a hard fork where everybody follows the same rules)

Serai

tevador: True, but tx_extra certainly makes soft forks easier.

Alex|LocalMonero: Are there applications that weaken ring signatures due to the data they publish in tx_extra+elsewhere, today? The only one I'm aware of that causes some issues is p2pool - but at least that is relegated to coinbase transactions. Are there any others?

How much harder is it to hide data elsewhere? Harder than "just use Litecoin/mW" or a sidechain? If its too much trouble, id imagine they'd use something more efficient

<merope> "Are there applications that..." <- Yes, Serai already exists, and there are other applications like thorchain: monero-project/monero #6668#issuecomment-831976735

ofrnxmr[m]: That sidechain data would have to be referenced into the main chain through tx_extra - otherwise you're just sending data out-of-band

ofrnxmr[m]: The truth is that its not that hard. The world financial markets developed around gold which didn't have a decentralized distributed database of scannable arbitrary data storage and there was no internet.

I apologize for repeating myself but I think UNIX philosophy applies to Monero's design goal: do one thing (be digital cash: decentralized, electronic, fungible) and be good at it. Any additional utilities make Monero less efficient at its core utility, that's just the nature of reality. You can't be a master of all trades, just look at how inefficient Ethereum is because it tries to be everything at the same time.

I don't have the details of how various apps use tx_extra, but instead of including metadata in the tx_extra field, they could be included off chain and tx_extra could simply contain a hash of those metadata, so their integrity could be checked and they would not bloat the chain, assuming tx_extra is there. So using tx_extra for direct inclusion of metadata for apps like DEXes seems like the wrong thing to do.

The link between the two would be the txid

The off-chain would of course be a side chain for decentralization purpose, even though it would have less nodes probably.

Am I wrong I summarizing that tx extra is essentially "marked bills".

Bad exchanges could mark everything they send to their users (say with an encrypted string derived from the username), and poison outputs and wallet balances (?)

I don't think you're wrong, that's exactly the analogy I used in the github thread.

Isnt that also a very real attack vector that binance could use today?

an optional fixed size tx_extra is like if every dollar bill had a detachable piece of paper for everyone to doodle on

It is indeed

No need to wait for a Dex, a cex can poison outputs

Basically anyone can mark bills and those that support keeping tx_extra want to homogenize by encryption, though nothing is stopping binance and the rest from publishing the keys to unmask all tx_extra-including txs that were sent from binance.

The counterpoint to this specific attack vector is that technically they don't need to use tx_extra nor publish anything, since they already know which outputs belong to them (and/or other exchanges, if we assume cooperation(

So it's just the "standard" poisoned output scenario

They know but with tx_extra anyone who scans the chain will know.

Sure - but why would they let others know too? They can already choose who to share that information with privately, so why make it persistently public?

And if most txs will be of the tx_extra variety then those that are in the minority will stand out.

merope: Perhaps they will be required to by regulators as a precondition to operate with XMR?

The problem with arbitrary data fields is that you have no way of predicting all the possible outcomes.

Its much cleaner if XMR is just for money transfers and strictly constrained.

If you wanna go full orwell, you might as well just force users to reveal viewkeys and spend proofs (and skip extra altoghether)

You might, but oppression advances in increments.

Personally, I think id like to see tx extra killed. Bring it back in some crippled form if it ends up being a problem / necessary for some required purpose

Asking people to reveal viewkeys will surely be met with more resistance than asking 4 major exchanges to encode tx_extras

But you can already force exchanges to reveal viewkeys privately to the regulator, without adding any new onchain data. Don't mix private individuals with public entities/large companies

You can't decode recipients with viewkeys, you can with tx_extra.

Though, I suppose, it can still be manually submitted with or without tx_extra

So yeah, that's not much of an argument.

Don't need to do that on-chain, since their wallets already know. Also, they already have an internal database with incoming and outgoing transactions anyway, for operational purposes, which is already audited

You're right.

Ideally the Monero chain should only contain transfers of value. For practical reasons that is impossible to ensure completely, but we can at least try to define a tx as strictly as possible and this way we get uniformity, fungibility, simplicity (both UX and DX) and efficiency at the same time. And to the greatest possible extent for our design goal: digital cash.

You've made some good points and I admit that I am now in the camp of "it doesn't matter". The reason being, if a DEX doesn't have tx_extra at its disposal, it will use steganography instead, still publish its public key, and all the fungibility problems will still show up when people use that to scan the obviously larger transactions for potential DEX information. Either way, just the existence of a DEX that is manipulating

chain data for its needs is really what is going to rub you the wrong way.

True, in principle. But don't forget that there are some unique applications that are not possible in traditional finance (such as decentralized platforms), which may come at the cost of some additional complexity. Hence the question: what is an acceptable tradeoff? Where do you draw the line?

While the "do one thing and do it well" philosophy has its merits, it also comes with rather strict limitations

<Alex|LocalMonero> "Ideally the Monero chain..." <- (^ In reference to this)

s/public//

There are plenty of other chains people can experiment on with their NFS or movie scripts

IMO, reimplement WHEN there are valid uses

.. or if.

👍️👏

Well, so far we have mentioned at least 3 "legitimate" uses: Serai, Thorchain (haven't read the issue you linked yet, will do when I'm less tired), and p2pool. So we are already in the scenario where somebody actually needs tx_extra, today

I dont see not actual Dex as "valid". They can attack the network some other way

ofrnxmr[m]: And the movie scripts and stuff, would fall in the "abuse" category

That use case is similar to allowing binance to write my username in every withdrawal

ofrnxmr[m]: But like we concluded above, they don't really need to

Right. So they dont need tx extra either. Just a convenience

Not sure about p2pool though ^

So the question becomes: how do you allow those existing applications to keep working, while still protecting users as best as possible? (Remember: stuff that happens off-chain regardless of the tx protocol is outside of our concern)

ofrnxmr[m]: P2pool strictly needs it, iirc. Though the fact that it exclusively affects coinbase txes puts it in a distinct category

Right. And thats a problem they should solve, not one that involves being fungible digital currency.

ETH is gas ie, it fuels the network.

monero is the network, it doesnt need tx eextra to fuel dex'

Unless we want to someday try to be eth

Do atomic swaps use tx_extra?

Ie, have applications and services build ON Monero, instead of around it

(I would also ask about payment channels, but since they're not a "live" application today, they would fall in the "fork later when you need it" case)

Seems to me that everything you fear can be done with tx_extra can also be done with steganography, except with steg it's more expensive in terms of space. Same fungibility loss albeit with a different look to it, same potential for tagging if a private key is published by a CEX or DEX. Am I mistaken? We want people to build on Monero, right? Make it reasonable to do that. I'm still not opposed to B3, but either way your

fears are not dispelled by banishing tx_extra.

I dont care about building ON monero. Thats what eth and eth like chains are for

And why they are POS

Except with steg it's more expensive in terms of verification, more so than space

How much more difficult is it to use stego vs txextra?

ofrnxmr[m]: (If you actually meant proof-of-stake, that doesn't make any difference in this case)

Because you are creating entire outputs rather than dumb blobs

ofrnxmr[m]: But if you prevent people from building on Monero, you are also limiting its usability - both present and future

blankpage: I was typing the same. Verification costs also effect the Dex. Regardless, an attack is an attack. I dont see either of these as beneficial, one is a compromise, one is an attack

Not to totally prevent building on monero, but tx extra makes monero a fuel, just like eth. It allows the creation of something like ordinals

Which none of which needs to be on the blockchain

If you need private originals, wownero still has tx extra. Maybe we can merge mine it

Ordinals*

Or maybe those Dex can use wow

Ok, let's say integrate with Monero instead of build on. You should want that kind of growth. It cements its place in the world and adds utility.