tevador: which rust code? you mean dalek lib or which?

i already started writing benchmarks in halo2 now

narodnik: github.com/simonkamp/curve-trees

Meeting 2.25hr

Meeting in 45 minutes

<Rucknium[m]> "Meeting in 45 minutes" <- on matrix?

Yes, here

meeting time monero-project/meta #811 hopefully the matrix bridge works

1. greetings

hello

hello

Hello

Hello

Hello

Hi

Hi!

2. updates, what's everyone working on?

hi

I am looking into the discussions happening in "Consider removing the tx_extra field" (issue #6668). I have to say it's a really long one

Due to the power of (research) persuasion, the average waiting time to first transaction confirmation has fallen by a full minute in the last two months: reddit.com/r/Monero/comments/11nu4a…ransaction_confirmations_are_now_60 . Thanks to DataHoarder, sech1, ofrnxmr, xmrack, plowsof, and gingeropolous for helping the research process and/or contacting mining pools.

me: merged and updated ghostway[m]'s block id checkpoint cache to be used in enote stores, then jberman[m] sucked me into some deeper design optimizations for balance recovery

Hi

Rucknium[m]: good work, quite an achievement

Thanks :)

Yes very good work

Yes, that's amazing

Somebody should calculate how many waiting years were wasted over the history of Monero :)

good work Rucknium! Lovera also joined the effort in contacting pools

Awesome Rucknium !

rbrunner: The time savings will become apparent when Monero scales to it true potential

Hard to calculate now

Right. Transactions now confirm in Rucknium time.

3. discussion, today we return to the tx_extra topic

as a reminder, this is the choice matrix:

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

B) [keep tx extra in some optimized form]: 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) (option: encrypted by default)

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

Can we narrow this down to A and B3

I still against removing tx_extra field. Size limit/increase pricing for people trying to dump things inside this field sounds good.

(Basically choose B)

Ok for me to narrow down thus, I still stand at the same point regarding this.

To start the discussion, let's do a temperature check of the room. Let's have a period of 4 minutes where the only message people should post is in this format: LETTER [rating 0-5, 0 is abstain, 1 is strongly oppose, 5 is strong desire], for choices A and B3. If you have a strong opinion about something else, you may post that as well.

Starting now

me: A[2], B3[5]

Is there any support for B1, B2, B4 or B5?

A[2], B3[4]

B2

* B[2]

Me oppose anything other than A or B3

please follow the format

* B[2] / B[3]

Could we create a poll to simplify this?

A[5] (keep for coinbase)

A[4],B3[3]

A[4], B3[3]

A[3], B3[3]

A[3] B3[4]

A decidedly inconclusive poll

A[2], B3[5] (altho I'm not sure if my opinion is relevant. I'm just a pleb🫠)

A

A[5]

A[5]

B3[1]

Anyone feel like BRIEFLY summarizing the case for A?

I think of it simply as "No tx_extra, impossible to have any problems with it", fwiw

Still supports merge mining / p2pool etc. Doesn't incentivize other, unproven or malicious purposes

It's the simplest solution, and hypothetically the theoretical best for transaction uniformity. Steg, while possible, seems a bit unwieldy, costly, and unlikely to be commonly used.

The case for B3 is: reduces the chance of needing future hard forks to support arbitrary non-core functionality/innovations. Removing the tx_extra is an implicit commitment to perpetual future hard forks, which I view as a critical long-term weakness.

* A[1] / B[4]

Aka "painting yourself into a corner"

(Some) of the case for A:... (full message at <libera.ems.host/_matrix/media/v3/do…1fba811d1d5baa0a98e565669ae7dbf7e0e>)

What would prevent us from adding it back?

Id like it removed sooner than later. And we can revisit when we do Seraphis (or another) hard fork.

The same thing that prevents its removal for almost 3 years already? Split dev community.

ofrnxmr[m]: it's much easier to move to e.g. B3 then to A at a later date than from A to B3

And no accepted decision process yet beyond "loose consensus" ...

from that standpoint alone, it is the more conservative choice

A would move data from Txextra to dedicated fields > wouldnt that be preferable to just leaving it in Txextra?

B3 is the more conservative approach*

B3 does follow the principle of: When in doubt, make the least adjustment necessary.

ofrnxmr[m]: not everything that makes sense to go in a tx should go in a tx. Subaddresses were an experimental feature not enforced by consensus, as a prime example. They are being formalized in jamtis after what, 6-8 years of experimentation and experience?

Agreed it is the more conservative approach. But being making compromises or concessions doesnt necessarily make sense when the damage from removing it = "use monero how you thought I was last week".

Leaving doors unlocked, or bridges down, just leads to abuse (see mrl logs on chain)

The case for A is that there is no application now outside of merged mining in coinbase. This discussion does not apply to coinbase.

not everything that makes sense to go in a tx should go in the consensus-enforced structure of a tx.*

The case for B3 is to allow for some protocol flexibility outside of hard dorks

<UkoeHB> "The case for B3 is: reduces..." <- Have you ever tried developing an enterprise application for Bitcoin? It's a nightmare of libraries and applications that are often mutually incompatible. Someone implements one BIP, someone else thinks that BIP is a scam and ideologically rejects it. Every wallet/app becomes its own little application island that requires all other users have to use the same wallet/app to get

the benefits. This is not good, this is awful. I feel like there's a case of dev blindness. Just because something makes life more exciting for a dev doesn't mean it will lead to more actual usage. Code is read much more that it is written, therefore it's more important for code to be readable that for a coder to write a one-liner that encompasses 15 different ideas. Similarly, protocols are implemented more than they are

extended. It's much more important for the application builders to have less complexity to deal with than for a protocol dev to have more soft forking capability

As a business that utilizes both Bitcoin and Monero, I can tell you that it's much easier to develop for Monero than for Bitcoin because there isn't a million soft forks that our devs need to deal with on a constant basis.

A [1] from about the insinuation that "dev blindness" could be a major factor for those voting for B3

*from me

Alex|LocalMonero: that is a risk yes, but at the same time the tx_extra has not led to bifurcation of wallets after 8 years so it's not immediately clear that is a priority issue here

Communitues looking into tx extra, bar kaya and thorchain, are mostly looking into nfts, chat apps, and other stuff that I dont need in my blockchain storage devices

Wownero has Txextra 👍

For me the choose B:... (full message at <libera.ems.host/_matrix/media/v3/do…f04e32957f3cda3867bb1a80ccaa4d14811>)

NFTs and chat apps? Now it gets a bit funny.

Alex|LocalMonero: This is a very valid point. The reason for Bitcoin's problems with multiple soft forks is a fundamental design flaw in Bitcoin that is not present in Monero

* For me the choose B:... (full message at <libera.ems.host/_matrix/media/v3/do…a0fbe52b1caaa529ed63b6365e8b43c535f>)

Exchanges can put your username in Txextra

Yes. Do they? Today? We have tx_extra now, lest somebody forgets.

Bitcoin cannot hard fork because it cannot face this flaw

And do people really think that if we go for B3 now, but come under a large-scale attack by somebody using it, we won't be able to react somehow?

Regardless of the decision between A and B3 I do not see Monero having Bitcoin's problems

React by doing A?

Yes, of course, depending on the severity of the attack. I am not stupid.

<UkoeHB> "Alex | LocalMonero | AgoraDesk..." <- Yeah, mass adoption is saving us from that issue, *for now*.

^

One can raise the fee on tx extra transactions via node relay to respond to such an attack

Everything is *for now*, no?

Which is why tx_extra needs to be removed rbrunner

And for now, there are no uses nor anything on the horizon that needs it

Do support

Sadly kayabanerve is not here to contradict you

ofrnxmr

Exchanges can put your username in Txextra

removing tx_extra doesn't prevent attacks, since the same kinds of attacks can be trivially done with steganography\

Kaya doesnt need Txextra.

Its just a convenience

Yes and no.

I don't need it because of steganography. I do need it to be on-chain to ensure atomicity.

There's a loss of funds risk without on-chain data encoding.

*within my model which cannot be resolved without placing data on Monero in any model AFAICT

Putting username in txextra is alone against keeping it

Sending Monero, with no instructions on what to do with the Monero,, and no way to send it back, means the sender loses it. That requires some flow ensuring the Monero funds come with the data.

But tx_extra will be encrypted

I have an issue fully covering this discussion. While I do not need TX extra, I want to clarify it's only due to steganography tha's true.

That "putting username into tx_extra" seems to impress.

Right 👍 @kaya

And because of stego everybody will wade through fake outputs. That's fun.

BawdyAnarchist[m: It can be encrypted to allow the recipient to read it

Instead of tx_extra that they can simply ingnore.

BawdyAnarchist: Enforcing "encryption" on tx_extra would not be easy.

It could already be encrypted. We already know they use funky ring members etc

This is a complete issue, on my end, discussing the lack of any data encoding. Please note the atomicity section specifically.

rbrunner: Having 0.01% extra outputs is better than having a loosy-goosy blockchain

:)

I estimate +4 outputs per TX. TC does thousands of BTC TXs a day AFAIK.

kayabanerve: Did you read in the backlog about the opinion poll? Where would you stand regarding A versus B3? That 0..5 story.

Sorry, I literally just got here. I'll read up no

*now

TC wont integrate monero til im 1063 year old. And they "promised" not to abuse tx extra

Sounds reliable.

TC being Thorchain?

Yes sir

Removing tx_extra kind of ensures that some people will use steg, doesn't it? Which harms the weakest part of XMR privacy - the # of ring members.

B2 is my preference, yet B3/B4 would also be fine. I think A is stupid yet I'll survive.

... but someone else may fork TC

Which I say as a real world user while I also legitimately expect to be a significant real-world TX driver in the future.

Kaya ^ ArticMine @ArticMine:libera.chat: serai works like thorchain

Yes, I did mean THORChain. Specifically, I'm interested in: If Serai matches TC' BTC swap count, with XMR, then that may be thousands of 'poison' outputs a day without TX extra

Why is it a poison output if it's just a transaction?

The larger issue is we publish our entire wallet info, so the TX extra privacy issue is irrelevant.

Without TX extra though, we're now putting forth more bad outputs, assuming we haven't moved to a full chain membership proof yet

Alex | LocalMonero | AgoraDesk: Globally increased scan time + invalid decoy

Yeah, but will outsiders be able to determine they are invalid?

... immediately defeatable decoy

rbrunner: We publish view keys and all TX data.

Either way ^

That's not a TX extra issue, that's an accountability issue.

kayabanerve: and how exactly does having tx_extra prevent a malicious actor from poisoning everyone's decoys in the same way?

Aren't you conflating two separate issues?

It doesnt

Except instead of poisoning the one output to us, and noting the other output in the TX is a Serai user, we're now discussing poisoning 5 outputs and fingerprinting a sixth.

Alex | LocalMonero | AgoraDesk: It makes the issue 5x worse if I don't have TX extra.

Bro I'm not worried about Serai poisoning, I'm worried about an actual malicious actor poisoning the chain.

Which is counterproductive to doing it

Your DEX won't have any impact compared to a determined attacker.

"Use xmr for private swaps that hurt privacy"

Since TC has had 25k TXs today, if I assume they're all swaps, and BTC (tied for the largest pool) is just 20%... we're discussing 20k publicly revealed outputs if TX extra isn't available.

Without a full chain membership proof, that could be extremely damaging.

Haveno and bisq dont use Txextra, right?

*If Serai has that same usage as TC has accomplished with BTC

If

Off topic, sorry

No. They also don't publish view keys of participants.

Alex | LocalMonero | AgoraDesk: Sure, if. I generally bet on myself and I don't feel this is a totally out of this world estimation.

I think it's decently sane and should be noted.

would an attacker abusing tx extra to poison outputs be like, effectively a normal flood attack, except the data for bad decoys becomes public?

A really good DEX could become a success. If people doubt that, that would be strange.

The theoretical model is the actor keeps it to themselves/chosen accomplices, but yes.

I cited the real world numbers of an comparable product.

It's past the hour and y'all are getting into the weeds so I'll call it here. The meeting is over but you may continue the discussion.

Thank you Koe

+1

so they would need to create a vast majority of the outputs to be effective right? it seems then like whatever mitigations we do for normal flood attacks apply fairly well to TX extra as well

I guess we know what we'll all be chatting about in Mexico City in between talks, lol

B2. It doesn't force anyone to bloat the chain. It doesn't cause a flood of pointless outputs (harming scan times for everyone, always, and decoys for as long as we have them).

if we make TX extra even more expensive fee wise that could also help

It doesnt help

Thank you Joe. The meeting has made progress on tx extra

It helps fingerprint the tx

A flood attack is possible regardless of TX extra.

kayabanerve: you keep posing your DEX's exploit of membership proofs as an argument for tx_extra but it's the same argument as a robber makes by threatening you with a knife to hand over your wallet. The exploit needs to be fixed just like the robber needs to be disarmed.

LyzaL: To a point. Too high, and you incentivize steg

Thanks UkoeHB

My comment is without TX extra, Serai becomes a flood attack.

"<ofrnxmr[m]> It helps fingerprint the tx" it's already "fingerprinted" by containing tx extra data?

<BawdyAnarchist[m> true

By the fee being non standard

kayabanerve[m]: So what? Regardless of Serai's or tx_extra's existence anyone can perform the same flood attack.

That argument is moot.

... right. Stopping flood attacks is one discussion. Removing TX extra shifts an entire use class into a flood attack. That's my contribution to the discussion.

<ofrnxmr[m]> well, it would be the standard for all transactions with TX extra, which already stand out, so I don't quite follow

Your contribution is conflating two unrelated issues?

Tx extra will likely require the next level of standard fee

In any tx extra transactions will be identified in chain

Rucknium: You mentioned that enforcing encryption is tricky. What kinds of problems are we looking at? Will this increase verification times?

LyzaL: pooling tx. . So if I never use tx extra and I have 15 ring members that do. .?

Thanks to us all being divided, tx_extra has survived for another hour :)

Alex | LocalMonero | AgoraDesk: I don't believe so.

BawdyAnarchist: you cant tell and encrypted string from a non encrypted one

Bawdy

ofrnxmr that's not a fee issue specifically though

No, its an issue period.

A[5]

anyway I'm feeling like I've been fairly well convinced to shift from leaning A to B2 or B3

LyzaL: Not exactly

BawdyAnarchist: AFAIK, and I've looked, there is no way to say that any data is encrypted if you don't have the ciphertext's public key at least. I assume tx_extra would not require publishing public keys or using a particular form of encryption for that matter. So the main way to "enforce" it is with a statistical test of uniform randomness of the data.

Removing TX extra, in your opinion, is beneficial for XYZ reasons. I'm saying it's detrimental as it makes data storage, which can be argued legitimate, an output flood attack. That's the downside I'm noting.

Encrypted data is approximately uniformly distributed. The statistical test is not a simple matter. Check previous meeting logs.

If localmonero promised to post view keys and make fake decoys, nobody would use it.

kayabanerve: if you just want to say "hey, don't remove tx_extra cuz I have this usecase for it" that's one thing. But what you're saying is "if there's no tx_extra I'll exploit the same exploit that someone else can use to poison potentially most of the outputs on the network" is only an argument to close the exploit, NOT to keep tx_extra. Don't you see?

Well, except for the same people who use mymonero

I don't see how you can disallow steg

ring sig tx extra lol

patenting it brb

Rucknium: That was my thinking. That some simple randomness test which produces a binary output, be consensus enforced. Altho I just read your comment about ChaCha20Poly1305.

Alex|LocalMonero: If I understand correctly there is a use case for tx extra and an exploit that can be used instead

randomness test :p

Alex | LocalMonero | AgoraDesk: Exploit/attack is possible in either case. So the debate seems to center around whether keeping tx_extra prevents degredation of outputs by honest users

ArticMine[m]: There certainly is a use case for tx_extra in kaya's case. I just have to reject the premise that a presence of an exploit is somehow an argument to keep tx_extra. The pointing out of an exploit's existence is only an argument for the expoit's elimination.

Tx extra is already an exploit (unlimited, unencrypted ).

Encrypting and limiting minimizes the tx extra attacks(s), but it doesnt stop someone from doing ordinals

Example. BTC went from 1-20 block backlogs, to 120+ and dropping tx from the mempool

BawdyAnarchist: I don't recall making any comments about ChaCha20Poly1305. Must have been someone else.

<Alex|LocalMonero> I don't think you can eliminate the possibility of steganography, maybe someone can tell me I'm wrong though

Rucknium: they are referring to the zcash quote

Rucknium: I think you were quoting someone from the zcash team

Oh. Right.

ArticMine[m]: There's a reason to store data on chain. TX extra offers that. Steganography also does. I care about a legitimate use case. That's my exact stance, yet your summary also works :)

BawdyAnarchist[m: First of all, it's only an exploit today and it may not be an issue in the future. Secondly, keeping tx_extra simply to discourage honest users poisoning outputs is a complete red herring because it's not the honest users that we should be worried about.

ofrnxmr[m]: What does monero do? Rush and kill off the new businesses? They would be using xmr how it was designed, after all

kayabanerve: if you care find a way to do it without tx_extra or exploits.

You cant really call xmr a privacy coin and at the same time poison outputs intentionally. Id rather use Binance (?)

Alex | LocalMonero | AgoraDesk: I posted an issue detailing how it's endangering to users to not use on-chain data.

ofrnxmr: BTC is seeing 4MB jpegs in a single txn. Is a 1Kb tx_extra ordinal comparable to that?

Specifically, the lack of atomicity.

ordinals don't work on XMR anyway

BawdyAnarchist: it is is you spam tx in order to inflate the block size because you want to send more

Or you use use stego

kayabanerve: xmr is not your application database, nor should it be

ofrnxmr: How is that any different than a run of the mill flood attack?

All the same elements are there. All the same arguments against the prolonged viability of a flood attack are still valid in that case

Ordinals etc flooded btc with like 95% bullshit tx. Hows that for output poisoning?

Knowing 95% of tx came from some nft farm

like, the data storage part works, but then to "track" the ordinal you use accounting to follow a single satoshi that was the output for the inscribing transaction. the second part is obviously not possible with XMR

You can sent single outputs in monero

you can inscribe data but not create an nft from it

you can but, you know, ring sigs

Alex | LocalMonero | AgoraDesk: Yet it is what I connect with and if it does not carry data, there is atomicity issues.

you can't follow the whole trail of ownership to verify authenticity afaik

It makes it a lot easier to trail afaik

LyzaL: I'm pretty sure that it's viable with both tx_extra and steg. Altho steg is unweildy. I doubt we'll ever see a flourishing NFT ecosystem using steg, ever.

I do not care to further argue this with you when I do not believe we'll agree. I believe it's legitimate. You do not. I am here to advocate my position and discuss practicalities.

kayabanerve @kayabanerve:matrix.org: monero is used for this _because_ its the coin providing liquidity, right?

kayabanerve: not everything should be possible with XMR. This isn't Ethereum. You're free to advocate and I'm free to take down any red herrings and non-sequitors.

I just want to point out again, that when in doubt, the least change to the ecosystem is preferrable. Since everyone agrees that action is needed, if we can't agree to remove it, then the default should be to limit size and encrypt (if possible).

Compromises dont get you anywhere imo

It's not a compromise. It's going with a principle used in all large projects

What principal is that?

Bitcoin never hard forks. Monero does

ofrnxmr[m]: When in doubt, make the least amount of change necessary to a running system.

The least change is removing it.

Its currently not used.

The current state of XMR has tx_extra. Thus, "no change" is keeping it. The least amount of change is to limit the size.

ofrnxmr: When a user swaps XMR, they send XMR to Serai. Serai has to be told what to *do* with that XMR, else the user just sent their funds away for nothing. Accordingly, they must specify data.

There is no safe way to specify data other than including it with the sent XMR due to the fact that is the only atomic data transfer method.

(the funds are only sent if the instructions for it are explicitly sent, to prevent sending funds without instructions)

BawdyAnarchist: If someone declares a standard of using another part of a transaction as an one-time pad for tx_extra, they can publicly enter data that passes statistical tests as they please.

Even if the statistical tests are assumed to be perfect, they can only inconvenience the behavior, not ban it.

Then again, convenience can be all the difference in the world.

kayabanerve: Is there a way to use a reserve proof like MProve+?

Rucknium: It is computationally infeasible for a multisig to perform transaction scanning.

*with a shared view key, instead of a globally known view key

spackle_xmr: Yes, they theoretically could. But large parts of the ecosystem (like TC) almost certainly wont do that, so long as tx_extra meets their needs.

Again, we're susceptible to steg / attack regardless of tx_extra

Again:... (full message at <libera.ems.host/_matrix/media/v3/do…a444ceb050f54e898321608ab684abbcfdf>)

"almost no one using it" - that would mean nobody is using integrated addresses still?

Alex | LocalMonero | AgoraDesk: Wait I'm unclear on something. If (3 - no one's using it) is true; then is (1 - pandora's box) really an issue?

Hasn't that box been open for years now?

BawdyAnarchist[m: Yes because after mass adoption comes assuming tx_extra is not removed then the pandora's box will come.

plowsof11: Integrated addresses have been discouraged for years

pretty much everybody uses subaddresses

plowsof11: They need to stop

Some still do though, and they shouldnt.

plowsof11: Integrated addresses have been discouraged for years and yes, they're rarely used.

aslong as we are aware that alot of projects are using them - and make them aware theyre being dumb

Alex | LocalMonero | AgoraDesk If it does come, and it's a problem, then we can still remove it later.

??

Dejavu, is thus zcash?

"Spam is a problem. Dont worry. It wont come yet... oh shit.. out wallets dont work"

Isnt* a problem

BawdyAnarchist[m: Later when pandora's box is already open removing it would break the ecosystem and would be universally considered a rugpull. If we remove it, now is the time to remove it.

^^^^^^^

As I said, you cant wait for people to build on it, then say "hey, I dont like that"

We have Kaya here telling us that without tx_extra, he will use steg. This will harm the output set - the weakest part of XMR privacy. While keeping tx_extra isn't a hard stop against steg, it will reduce 99% of the cases of people who use it. The overall effect is that we have cleaner output selection

(*who would otherwise use it)

There is nothing magical about kayabanerve. If he or Serai didn't exist someone else can still poison the network.

And he WILL attack the network and be bsing on his exchange about privacy, since he himself will be ruining the privcacy if the chain.

Its not exactly an option

The argument is moot and needs to stop being repreated

* We have Kaya here telling us that without tx_extra, he will use steg. This will harm the output set - the weakest part of XMR privacy. While keeping tx_extra isn't a hard stop against steg, it will reduce 99% of the cases of people who would otherwise use it. The overall effect is that we have cleaner output selection

If I claim "ok, fine, ill spin up 4000 nodes and rent 5GH if hashrate" is essentially the same as saying "ill intentionally poison my customers outputs while im supposed to be a better option than a cex"

One of the (weak) defenses against a malicious attempt at de-anonymization through flooding (black marble) attacks is that it is expensive, i.e. the attacker has to have enough financial resources to pay the tx fees. With DEX steganography, the "flood" is self-incentivized. There is a difference there. With Seraphis-size rings, de-anon flooding efficacy reduces even further than now, by the way.

Not to take shots at kaya. Im just saying, if the result is steg + poisoned outputs, its not realistic and that is why he wants a route that allows him to work more freely.

The issue isnt serai. Its others who might take advantage

Alex | LocalMonero | AgoraDesk: And yet you want to practically force me into poisoning the network or having users of a legitimate serve lose the safety of atomicity.

kayabanerve[m]: Just like I'm practially forcing the robber to stab me because I don't want to hand over my wallet? What?

Alex|LocalMonero: Theoretically, yes. Anyone *could* try to poison outputs. But practically speaking, no. 99.9% of the times that people would resort to that, will be alleviated by keeping tx_extra.

BawdyAnarchist[m: Stop assuming only honest actors exist.

Honest actors aren't the issue.

Bawdy, you must have missed mrl logs being on chain?

Alex | LocalMonero | AgoraDesk: I'm not presuming honest actors. Malicious actors can poison outputs REGARDLESS of tx_extra

I believe a severely limited, increased fee TX extra, will prevent malicious actors from using Monero from data storage.

Encrypted or not, you can pass cables on chain.

BawdyAnarchist[m: Exactly.

What we're attempting to solve, is to not incentivize honest actors into behaving in ways that resemble malicious ones

kayabanerve: you are practically forcing us to turn XMR into ETH just because you can't think of a way to setup your DEX without writing things into XMR.

Threatening us with exploits

I would like to remind people that Alex|LocalMonero couches his arguments in emotive terms. See beyond this.

What

moneromooo: he started it

Hehe 🐄

I don’t understand why you won’t take the net improvement of minimizing tx_extra. One way or the other, people will impact fungibility.

Integration is important.

If legit services required some arbitrary data field, they should have it

Its not a small improvement. But.. also just moving the goalpost with no change to utility.

The only thing now, is instead of putting a beescript in 1 tx, it will have to be many

Here here.

Just give it some limit, not like kt ks rn

s/kt/it/, s/ks/is/

if this where a game tx_extra feels like a public cheat, that we all can use. if you bring in an anti cheat that totally bans tx_extra - then we're gunna get people snooping around in CLSAG's and what not to enable it again? like poking the hornets nest? dunno

Security through obscurity is absolute nonsense

You dont just poke the hornets nest, youre supposed to be immune to it.

Allowing people to take inches until they get miles is what ruins chains

> <@ofrnxmr:monero.social> Its not a small improvement. But.. also just moving the goalpost with no change to utility.

>

> The only thing now, is instead of putting a beescript in 1 tx, it will have to be many

That runs into fees. There's a natural disincentive to do that.

we're not immune though? thats the problem?

Look at it like this

Txextra is currently unlimited. Where are the attackers?

They dont even care about us.

As a small aside, the atomicity concern I have would be work around able if return addresses existed. That way, if data wasn't made available, it could be returned.

Just because we arent being slammed with 100kb tx for the past few years, doesnt mean the door isnt wide open

*the funds could be returned

That's actually feasible with Seraphis, as you probably know already

Why don't we work on encrypted return addresses? It's on the getmonero.org roadmap

"we fixed i

It could be feasible in the next hard fork

With the removal of Txextra

That sounds like a great solution if kayabanerve can make it work.

Abuse of tx extra is not an attacker problem, it is a tragedy of the commons problem. This is why removing tx extra is not a great solution:

The argument that tx extra allows an attacker to degrade ring signatures is untenable, since an attacker has a better way to do so: simply make the secret data for their txes public.

A well meaning user of custom data, however, will not do the latter (make secret data public on puropse), but will do the former (use extra in ways that are fingerprintable).

So helping well meaning users have data in a way that minimizes risk is good.

While removing extra does not help against attackers (excecpt maybe very dumb dones) while it kneecaps well meaning people with a use for it.

Let’s listen to the moo

Yep. But its the dumb ones who will flood the chain using Txextra and not know how to steg..

Thank you for the well written words.

moneromooo: 👏👏👏

moneromooo: and what do you see as the trade-off for keeping tx_extra?

Also

Txextra pre seraphis vs post

I like the optional encrypted 256 (or whatever) byte addon. My preference would be steg in CLSAG, but I hear it doesn't work with seraphis :(

(and yes, encrypted here is just a strong suggestion, cannot be enforced)

moneromooo: It also reduces sender privacy :/ steg is sender private.

Only to the recipient though.

Most recipients likely won't be attackers (who'd leak the info to Eve).

Sure, yet that may be everyone, as in my case.

Ah, you'd make the data public ?

If so, how many ring members become mooted ?

I did not read the meeting logs before I popped in, apologies if this was mentioned abive, feel free to tell me to RTFM :D

Not sure if this helps libera.monerologs.net/monero-research-lab/20230315#c217398

<moneromooo> "If so, how many ring members..." <- ~1 per 30 bytes, presumably 3, or ~20℅

So, if Seraphis has 128 ring size, you bring it down to 125 with that system. Right ?

Grootle proofs don't have the same method.

Or is that pre-Seraphis only ?

You can spoof the decoys selected so the selected ring members embed data.

If you select a decoy by offset, you can +- 128 to find a potential member with a leading byte you want. With it, you can include one byte per decoy with minimal privacy leakage.

I just don't dare suggest the privacy implications of doing so, though there was a paper on this concept under CLSAG.

cc Rucknium

<Rucknium[m]> "One of the (weak) defenses..." <- Flooding the network isn't that expensive, if I recall the stats about the most recent attack that happened. The fact that this exploit can be self-incentivized is, again, only an argument to close the exploit. If, for example, tx_extra is kept this, again, doesn't stop an attacker that's pretending to be an honest actor to build something like Serai that exploits the

output in a self-incentivized way.

So, again, the argument is moot.

I think you're not understanding that the "exploit" cannot be closed using our current understanding of cryptography.

But that's a temporary issue. Just like the 10-block-lock.

Or are you saying that this problem is provably permanently unfixable?

To be clear, if you intended to select output #500 under some distribution, and then offset it by 64 to get an output with some desired leading byte, that may be enough of a deviation from whatever DSA is used to greatly enable fingerprinting the real spend. This method may remove sender privacy.

*Not a response to whatever the last few messages are, a comment on the alternative 'solution' I mentioned to mooo.

I don't think we have tried to prove whether steganography can actually be eliminated through some clever cryptographic trick.

Surely if output poisoning is an unfixable problem then Monero has big problems in store if/when somebody decides to be serious in taking down Monero's privacy/fungibility guarantees?

<kayabanerve[m]> "If you select a decoy by offset,..." <- Fascinating

I'll caveat minimal to minimal, per my non-statistician non-reviewed opinion

Absolutely. Transaction flooding attacks have been known as a weakness of ring sigs since almost the beginning. It is in MRL research bulletin #1 IIRC

The solution for that of course being full chain membership proofs.

kayabanerve: would Serai be locked out of XMR given full chain membership proofs and no tx_extra?

No, we could steg outputs.

AFAIK, the only real defense to a flooding attack with a huge resource budget would be a decentralized counterattack. The main downside is massive chain bloat. With ring size 128+, an attacker would need to own an enormous share of outputs to make the attack minimally effective

And that wouldn't be harmful to everyone since full chain membership proofs defeat output spam attacks.

Eh. It'd still increase scan time...

Since it's essentially a tx I don't see it as an illegitimate scan time increase.

And if 20% of the XMR chain txs come thanks to Serai then that's great and I'll only be grateful to Serai.

It's a TX with 4 unspendable outputs being treated as spendable

That could be 20k extra scans a day per prior numbers

How much would that be in terms of proportion of total scans?

What's our current tps?

Around 16'000 per day maybe? bitinfocharts.com/comparison/monero-transactions.html#3m

XMR has ~20k txs per day, which is ~0.25 TPS

Uhhhh 40k current outputs, if we're discussing 5k swaps a day from Monero -> * via Serai, under Seraphis, would mean a ~60℅ increase in scan time

Which makes me wonder if we'd actually have that many. I'll have to do a deeper dive into TC's TX breakdown...

That's maybe a sane reaction :)

To be clear, I explicitly added a flow for high frequency swappers to *not* burden external chains.

You can add XMR to Serai once and use it in as many actions as you want.

High frequency swappers?

The on-Monero flow is only for people looking for an experience a la StealthEx.

I'm not *trying* to nuke Monero.

TradeOgre has got indicatively less than 500 trades a day in the XMR-BTC market, I doubt Serai would get more than that any time soon

rbrunner: Anyone who doesn't want to move to another coin, yet move back and forth while gaming the market.

TradeOgre's fee is 0.1+0.1 = 0.2%

Recent outputs per tx is about 2.4 according to bugfixed monero-blockchain-stats :)

xfedex: While I think our competition is StealthEx and Trocador, not TradeOgre, that'd still be 6℅.

what would Serai's swap fee be?

Undecided.

Rucknium: I assumed 2.

... Can we all agree tx extra has some positive value now?

I know. Close enough

I feel even those still calling for its removal should have that Ack.

I don't think anyone ever denied that tx_extra has uses kayabanerve , that's not the issue here.

The issue is that it opens up the protocol to other arbitrary data as well, which is undesirable for many different reasons which were hashed out many times over these discussions.

ETH is, perhaps, the most extreme mainstream version of prioritizing protocol extensibility. Monero's design principles are on the opposite side of that spectrum.

Protocol extensibility isn't free. In increases complexity exponentially. There's a reason why everyone is abandoning the very extensible OpenVPN for the lean and narrow WireGuard.

And why maxis are coping so hard right now. (Hard to put it any other way).

Not that there isn't a place for extensibility in the world, kayabanerve , it's just not in Monero.

Monero is here for one reason and one reason only: being digital cash.

Decentralized. Electronic. Fungible.

At least, extensibility shouldnt be a focus or burden of monero until we actually get the core done right.

Alex | LocalMonero | AgoraDesk: Monero has extensibility, and it seems intractable to the core protocol itself. So the question isn't about eliminating extensibility, because that's impossible. It's about minimizing the harm done, by people using the core protocol in an extensible way.

* that's impossible for the foreseeable future. It's

1. Monero without tx_extra has less extensibility than with tx_extra

2. Mitigating exploits is a separate issue from this one, honest actors are irrelevant for this discussion

3. Have you ever developed any enterprise application for Bitcoin and Monero? The difference will be very clear to you.

I disagree with the framing of the issue as an "exploit."

Or you could also say that tx_extra is the "exploit mitigation"

BawdyAnarchist[m: In the same way that giving everyone a key to your house is a mitigation to losing your house keys.

People can still break your window.

Like it or not, extensibility is part of the core protocol, and there doesn't seem to be any real fix for that. It doesn't mean we have to maximize extensibility. In the face of numerous tradeoffs, it seems like minimizing the harm done by the fact of this extensibility, by incentivizing honest actors to use a less harmful option.

And that protecting your house is easier if you let the burglar guy move in and feed him

* Like it or not, extensibility is part of the core protocol, and there doesn't seem to be any real fix for that. It doesn't mean we have to maximize extensibility. In the face of numerous tradeoffs, it seems like we should minimize the harm done by the fact of this extensibility, by incentivizing honest actors to use a less harmful option.

Extensibility is nit a part of the core protocol.

It is. It's called steg

Data transfer is and storage is.

BawdyAnarchist[m: Not really, no. Monero's protocol is very narrow and that's been a huge blessing.

Design intention is not the same as what actually is possible with the end product.

If the idea is "like it or not". Brb while I go collect my 625k bounty

BawdyAnarchist[m: That's true, but the design intention guides what you do with your product. If the design intention is to make Monero do one thing and be good at it then tx_extra needs to be removed. The other exploit needs to be closed regardless of whether you keep tx_extra or not.

I'd be 100% with you, if it weren't for the fact that people can still use the core protocol without tx_extra. I'd at least be 50/50, if we had full chain memebership proofs.

Its not like it or not. Its "I would attack you if I knew, and im going to use the easiest methods in addition to the hard ones"

Nothing against serai, but would you fund an exchange via ccs that planned to post view keys?

Thats like.. would you use mymonero uf Mymonero publicslly posted the view keys?

The idea of an exchange that needs to do so, is an extension that doesnt benefit monero

That's all theoretically palatable. But you can't ignore the practical world of attackers, or just people leveraging the protocol for what it's capable of.

Its not theoretical

Its "I can flood the chain right now"

That's always been true

And why arent I? Because we were asked nicely to stop.

The practical world of attackers is exactly why the output exploit bears no weight on the tx_extra issue.

We have chat logs on chain. Encrypted or not, we dont need matrix built on xmr

The confusion is that you're conflating malicious attackers with people who want to use/leverage the protocol for various use cases.

No im not

One in intentional, one is unintentional

This isnt a "guns dont kill people, people kill people" arguement, its handing the keys to your house to everyone in the neighborhood and assuming they're all nice people

The group of people who aren't malicious, and want to build products with Monero, will gladly not pollute the output set, if given another option.

Like Haveno?

Group of 1 who will steg if necessary and post view keys

If you incentivize them to act similarly to malicious attackers, that's what will happen.

Where is this large group of Txextra devs that dont hope to hurt privacy in the process of their developments?

BawdyAnarchist[m: No

Harming the output set is the worst harm to privacy.

So why would you base tour exchange on xmr and then ruin xmr?

Kaya is right here, using _extra instead of steg already. You're talking about incentivizing him into steg, which hurts privacy the most

You wouldnt. Unless youre houdiniswap

BawdyAnarchist[m: You're arguing that Monero, by being lean and sexy, is incentivizing people to rape it? Sorry, couldn't help myself 😁

Im not incentivizing him!

An exchange is a for profit venture

Just been posted in #monero:monero.social :

mordinals.org

These comparisons aren't helpful

How is killing your own exchange an incentive?

BawdyAnarchist[m: I know I'm sorry, just a jest.

Thanks boog

The tx_extra of such a transaction seems to be around 1 KB

> <@boog900:monero.social> Just been posted in #monero:monero.social :

> mordinals.org

I gotta admit I find that humorous.

BawdyAnarchist[m: Well, that's tx_extra.

I find the timing suspiciously convenient :)

Block 2841136

Go check your nodes

Nodes logs and see if you see what I see

(Weird behavior)

ofrnxmr[m]: Which log level?

> <@boog900:monero.social> Just been posted in #monero:monero.social :

> mordinals.org

TIHI

it's not even done well

I don't want ordinals on xmr but if you're going to do them, do them right

kayabanerve[m]: So, you're with us now? 😁

kayabanerve[m] Do you have a link on Serai? I want to understands how it works and would make use of tx_extra

Oh, wow, they even offer a doctored CLI wallet with a new mint command :) github.com/mooonero/mordinals

I'd be willing bet that without extra, Mordinals will never be a thing using steg alone. Like, it might get developed and we might see a few, but it'll never catch on.

Alex | LocalMonero | AgoraDesk: I never encouraged ordinals

kayabanerve[m]: Doesn't really matter what you encourage. We must assume ordinals if tx_extra exists.

Yeah

BawdyAnarchist[m: 💢

This is what ive said 500x

It's what we've been saying all along :(

Now, lets wait for the flooding and the dropping of tx

Then scramble to find a solution

Ordinals aren't the only extensibility though. I think it's a mistake to look at this problem in terms of ordinals alone.

And kill off a devs new project while were at it

So finally the sky is falling, right?

No

It fell years ago. We just dont listen

Even better, lol

Cant transfer ownership of an 'ordinal' on monero

Like bitcoin was surprised when ordinals popped up

tx_extra is from CryptoNote, Anno Domini 2012

Lying and cheating the code 💀

I have a crazy idea. Is it possible to add a bit in the transaction to signal that "This is a bad output used for dirty Mordinals. Don't use in your ring"

Now Peter Todd talks about how to make ordinals work

Since they cent hard fork them away

And they soft forked them in

BawdyAnarchist: delete tx extra. Do research. Add back when we have an answer

Research what?

How best to incorporate an arb data field, that doesnt include voting

Or how best to handle data data is essential to the ecosystem

That* is essential

And who decides that, what is essential? Permission free system my ass :)

ArticMine @ArticMine:libera.chat: Not a link, but it's just a NONCE LEN 127 *data* where data is a return address + swap info (coin, dest addr, min amount). About 100b

Alex | LocalMonero | AgoraDesk: I could do ordinals without tx extra

I for one gladly welcome the new Mordinal overlords. That fad will vanish in a few weeks.

I'm miffed at 1) on chain file storage (not using ipfs) 2) the lack of value to monero

Also the lack of a documented cryptographic transfer

<BawdyAnarchist[m> "Ordinals aren't the only..." <- Monero should be as narrow as possible, regardless of exploits and stuff. Monero has a clearly-defined purpose: digital cash. Anything more makes it less efficient at its core purpose. You cannot be a master of all trades, see ethereum, you can only be a jack of all trades. Monero is a master of money, that's the design goal. Are there exploits that need to be patched?

Absolutely. Does the existence of these exploits serve as a sufficient condition for abandoning Monero's design principles? The burden of proof is on you.

Hey, kaya, it's not more than a prank, a joke, a "look, we can too"

tevador: Issue with your indirect cycle.

Alex | LocalMonero | AgoraDesk: It's not an abandonment of design principles. Regarding the "exploits", you'd have a better case if there was any real way to prevent that exploit. We can't just assume that some unknown "future dev" will solve that problem.

We need to prove an ecc op *and* membership.

I found something old.reddit.com/r/Monero/comments/vu…ai_a_new_dex_for_monero_bitcoin_and

BawdyAnarchist[m: We also can't assume that it's unfixable. Accepting tx_extra means "we accept that this issue is unfixable so at least let's redirect honest devs to tx_extra".

... and this github.com/serai-dex/serai

The burden of proof is on your proving that this is unfixable.

So if an Ed25519 point is promoted to an X point then used in a YZ cycle, I don't think we can. The EC op would have to be performed on X yet maintain ZK into YZ.

Since we can't fix the exploit, the best we might be able to do is mitigate it, by encouraging honest users to behave in a way that is less harmful, until some fix is dreamed up (whenever that might be).

I'll write this onto the github issue when I'm home.

ArticMine @ArticMine:libera.chat: Those links work. I also gave you the exact usage of extra :p

BawdyAnarchist[m: It's not as simple as that! Tx_extra isn't just a bandaid on an exploit, it's a dimension of protocol extensibility and a redifinition of Monero's design goals to serve as arbitrary data storage.

Alex|LocalMonero: You're asking me to prove a negative. If there is some fundamental fix in the pipe, that makes steg impossible or totally impractical, then please show it to us.

Proving negatives is very normal in math

github.com/serai-dex/serai/blob/dev…p/docs/integrations/Instructions.md is our exact object ser ArticMine @ArticMine:libera.chat:

Can we please be practical? I'm sure you can admit that no one really has any ideas that can be implemented on any reasonable timeframe, to cut off extensibility via the core protocol alone.

Someone put some effort in: github.com/mooonero/mordinals

If/when we do, then by all means, let's come back to this and potentially remove tx_extra

But until then ...

kayabanerve[m] Thank you. So for Seraphis this would need over 128bytes because of the longer address. This is important in my view

BawdyAnarchist[m: 1. Monero means money

2. tx_extra means arbitrary data (not money)

3. Want arbitrary data? Must redefine Monero's design goals.

4. Removing tx_extra after an ecosystem is built around it will result in the greatest rugpull in the history of any successful crypto project, there is no "we can remove it later". We either remove it now when pretty much nobody is using it or never, because then its too late

ArticMine: Yes. ~110b for Seraphis, 32b for ext addr, 8b for amount... 4b for structure/misc? 160b total?

Sorry I have to go BawdyAnarchist , you can PM me if you want to continue.

> <@alex:agoradesk.com> 1. Monero means money... (full message at <libera.ems.host/_matrix/media/v3/do…bbdcc035120b5906905b24aa2ec70b18793>)

It's not a redefinition

Alex|LocalMonero: Thanks. I think we both got our points out there. I understand where you're coming from.

kayabanerve[m]: Only if you believe that arbitrary data storage is an essential component of money.

I must say I puke at Alex|LocalMonero's way of constantly couching arguments in emotive and manipulative ways. Jerk.

It's intellectually dishonest, and make at least me want to do the opposite just because of it.

your argument is moot!

mooot.

xD

Intellectually dishonest? I'm not saying anything that I don't believe to be true.

Nor am I intentionally saying it in a way that intends to deceive people

I mean the couching of so much in appeal to fear, ridicule, etc. It's just... worded in manipulative ways, regardless of the belief or truth of it. It is of course a subjective reading, but it is mine, consistently.

And I do not like it one bit.

If I'm misunderstanding something fundamental about this question then I apologize, but I harbor no ill intent towards anyone in this discussion. I apologize to moneromooo if anyone had the same reading as moneromoo.

And to anyone else that had the same reading as moneromoo*

Thanks. Since you're being level about it now, I'll give examples of what I mean in the spirit of good faith.

It'll be a bit, I'll look at the scrollback to copy.

kayabanerve[m] The info you provided on Serai is very helpful. I want to do some more research on how this works with ETH, Polygon (Matic) and similar smart contract chains that are in many respects complementary to Monero

Or I can do that by /query actually. Won't spam further.

Alex|LocalMonero: While I wasn't offended, it was a bit distracting. I can give you credit that it wasn't your intention, but it did come across that way.

moneromooo: Would you please PM it to me so that we don't occupy this room?

Sidenote: would it be possible/make sense to resurrect blackballing to ignore "moordinals"-related outputs?

Doing smart contracts on Monero is of course a big no no, but providing the hooks on the Monero's side so that one can move efficiently in a DEX between XMR and a smart contract chain is a plus in my view

Agreed ^

Being isolationist and cutting Monero out of the general crypto ecosystem is not a good principle

(Within reason, of course)

Sorry, late to the party. Was reminded in another room and worked myself through he backlog.... (full message at <libera.ems.host/_matrix/media/v3/do…65460d0f36eca5d5f9e10923808ac60c762>)