DGoon[m], i don't particularly remember size being a problem. I think everyone just believes in the gospel of optimization. (but who knows maybe something else is in the logs and code :))

meeting 1.75hr

meeting time monero-project/meta #822

1. greetings

hello

Hello

Hello

Hello

Hi

Hi

Hello

Howdy

hi

2. updates, what's everyone working on?

I implemented the solution for research lab issue 109 in this PR: monero-project/monero #8815

me: new CCS repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/384 , updated the seraphis draft github.com/UkoeHB/Seraphis , next need to write the jamtis-instantiation companion paper

Monitoring Mordinals. In the last 3 days Mordinal minting has essentially ceased: gist.github.com/Rucknium/67cc9efdf7e43a40c52417611b322d43

LWS stuff, and reviewed jberman patch for decoy selection off by one

I also started reviewing jeffro256 's code ^ to avoid selecting coinbase outputs when spending non-coinbase outputs.

vtnerd__: how's it going with BP++?

I will probably do a write-up next week on the empirical privacy effects of Mordinals (+ coinbase outputs).

Nice

haven't had the time, busy with personal it stuff and taxes, etc.

UkoeHB: If you had to summarize the seraphis doc updates in one sentence, what would it be?

I'll ping you privately about it later, as there simply isn't enough to report here

vtnerd__: ok thanks

seraphis paper updates: minor cleanup, cut out implementation recommendations, simplified composition proof writeup, added grootle proof construction + security proof (mostly copied from lelantus-spark paper)

I wonder if compdec has something they want to bring up.

I decided not to do anything beyond that with the main seraphis paper, since security proofing and whatnot is not my area of enthusiasm or expertise. It is in a good spot to get help upgrading the security model.

Sounds like a good plan to me.

greets

will i get kicked now for saying hello

narodnik: no

3. discussion; today we must return to the tx_extra issue

about the ECIP proof, we are in the middle of some stuff and it takes all my time, but i started writing the benchmarks on the side

I summarized my position here: monero-project/monero #6668#issuecomment-1476531556

now im doing the normal pedersen commit, have the scheme written in sage, then will begin constructing circuits with modified ECIP proof to benchmark against normal pedersen commit

thanks narodnik

Does anyone have anything new to add on the subject of tx_extra?

I didn't see any discussion about tx_extra anywhere for quite some time now, seems the subject has exhausted itself a bit lately

there has been some activity here: monero-project/monero #6668

IMHO, the "encrypted by default" phrase is a little misleading to most readers. By default, wallet2 would not be able to put arbitrary data into tx_extra, encrypted or not AFAIK. And if the encryption "rule" has no enforcement mechanism whatsoever, then "by default" is misleading.

<UkoeHB> "I summarized my position here..." <- I mostly agree with this with one difference: I don't think we should trivialize that one bit of information of "is this field present or not?" This one bit of likability is different from other bits in say, input selection, in that the "cost" of this bit is very high compared to other entropy. It is represents whether or not a user uses some functionality. In can be reasonable

expected that a user who uses that field is more likely to use it in the future, and one who doesn't is less likely. Same for the users that a user interacts with. Long story short, tx_extra, if kept, should be mandatory because even giving transaction constructors the option of having it be present is a bigger privacy issue than initially assumed IMO

I think the phrasing is close enough, the information that goes into tx extra from wallet2 doesn't leak user info

Rucknium[m]: the current trajectory is changing tx_extra for seraphis, in which case there would not be wallet2. The core library would encrypt/decrypt tx extra contents by default. Whether anything above that adds tx_extra data to txs or uses recovered tx_extra data isn't pertinent.

but if accuracy is that important it can be reworked to say that

ah yes, seraphis won't use tx extra for the ecdh pub, right?

Intuitively, tx_extra is used for applications. Users who use an application interact with other users who use an application. Thus, whether tx_extra is present or not I think is a stronger heuristic for linkability than one might initially assume.

vtnerd___: right, currently there are no standard uses of tx_extra

the new tx_extra should also be prunable

tevador: yes I was thinking more about that today, it should be doable fairly easily

Agreed, it isn't used for consensus anyways

I agree near enough 99% with Ukoe's linked comment. The heuristic of "user uses app which needs tx_extra" will get weaker once there are more "apps" using this feature.

jeffro256[m]: the point of having 1 bit distinction is the two 'puddles' will be very large

If the two puddles are of equal size, we are halving the effective ring size. If one of the pools is much larger than the other, then one of the puddles gets screwed over incredibly hard

Halving the ring size? The two puddles won't only transact within themselves, one would think

> If the two puddles are of equal size, we are halving the effective ring size.

it's not that dramatic, there is only an analytical bias that may be stronger/weaker depending how much information you have

I think the effective ring size would only be halved if the recipient of the tx knew what kind of "user" they were dealing with, always. O if an external observer somehow knew.

Yes, but if you make the assumption that users with tx_extra interact with those who do, and vice versa, the effective ring size is half unles you do decoy selection for only outputs in transaction which matching tx_extra

And there, with that assumption, I have my doubts whether it's realistic

I don't think that's a reasonable assumption

regukar spends wouldnt use it

IRL the huerustic probably won’t be that strong , but we’re opening ourselves up to that possibility if we allow the field to be optional

I we think the portion of transactions using tx_extra will be significant, we should make it mandatory instead. The space savings argument becomes much weaker then.

only apps etc would

If a user gets their XMR from a DEX that uses tx_extra and then spends it like normal to a merchant (not using tx_extra), then the assumption would be incorrect

tevador: it would be easy enough to switch to mandatory

a merchant recieving the funds knows to exckude txextra (sorry for bad typing)

and unconstrained -> optional -> mandatory (-> removed) would be the conservative development path

id skip optional

That's also not the "faultline" of the community, it's question about a detail. The main question still is "remove" versus "keep in some form". We are stuck there.

Rucknium[m]: Right it wouldn’t be so cut and dry in real life but why allow it ?

(i mean, if were talking abot hard forks. optional right now isnt ideal either)

jeffro256[m]: It’s just simply worse for privacy by a large margin which is why we’re discussing tx_extra in the first place

It seems that nobody is arguing strongly for removal today.

I am

Ofrn is

rbrunner - remove is just an extension of 255 limit. need to start with relocating stuff furst

i sm as well

Oh, sorry, you meant like today today.

No yeah, post-Seraphis removal is what I mean

Yes, of course. I claim that we are (almost) all talking post seraphis hardfork anyway

I meant today as in in this meeting.

i dont mind sooner :)

post seraphis hardfork, or simply don't include it in seraphis?

yes sir tevador. technical difgiculties or id say more

v0.18.2.2 is tagged / to be released when binaryFate does the 'things'

Yes, and people who want to keep even want to keep tx_extra with everything else relocated, just to avoid misunderstandings

For what it's worth, I was once reading when sech1 seemed to explain that they changed their opinion, from "remove" to "keep" ...

tevador, are you in the party of standarizing outputs? any thiughts on inputs?

Of course the proposal that is on the table, keep with a quite small size limit and a strong push toward encryption

id just add the return address fuekd, encryot it with destination address, maje it a dummy if not enabked

You mean something like allowing only strictly 2 outputs?

yes sir

or 2 and 16

That's ... something else :)

largeky the sane topic of bad decits

decoys

Yes, but adding this to the already difficult and mostly stuck tx_extra keep versus remove discussion probably does not make things easier, no?

I believe that keeping tx_extra is signaling that arbitrary data injection has a stable standardized place on the Monero blockchain that is open and efficient. I believe that this is counter-productive towards Monero's goals. I believe that if arbitrary data is to be stored on the chain it should look just like any other tx data, meaning that only if a party chooses to reveal their keys may privacy be harmed, just like

with normal txs.

it does imo

That may bloom into some new argument?

I also believe that arbitrary data storage on the XMR chain should be disincentivized to the greatest practical extent.

arbitrary data can be stored in outputs, ~30 bytes per output and it's impossible to stop it

Because, after all, that's an important point: What is *new*?

but steg doesnt stand out

sech1: I understand, but it's better if it blends in with the crowd

which is why fixed small tx_extra is better than forcing arbitrary data into outputs

Nobody is forcing anyone to use outputs, people can use CLSAG too

and return address field + small msg is what thirchain or serai need

so.. they just beed anothey dummy change address

CLSAG after Seraphis?

afaict

And keep in mind, sech1 , that there is little business case to develop applications around an unstable API.

would the return address be one per tx or one per output?

If you want to make a stable arbitrary data API you are signalling that aribitrary data is welcome on the chain.

developers are now welcome to write arbitrary data and create an application layer and soft forks.

This will harm fungibility and privacy.

politicalweasel[: standarize to 2 out and question is answered

If it stays uniform (fixed size and encrypted), it doesn't hurt privacy

AFAIK, putting data in output public keys does not blend in. You can put plaintext data there that is easy to detect....with your eyes, for example.

sech1: 1. there's no way to ensure encryption

2. there's no way to prevent people from softforking that way

3. you are imposing a storage and tx fee burden on the most users for the benefit of the application layer and soft forkers; you're practically disincentivizing people from *not* utilizing tx_extra since they pay the fee anyway

I am going to implement tx_extra pruning + optional encrypted field in the seraphis library as a temporary solution. These changes can be considered incremental improvement over the current library. Future incremental changes are still on the table.

For example, the first output public keys of this tx is all zeros: xmrchain.net/search?value=35ccad6e5…34ce1591096658f236915943d2e55e43007

Alex|LocalMonero There are statistical randomness tests. We can tune them to be very sensitive to non-random data. Even if they give false positives on 10% of true random data, wallet can regenerate it until the test passes.

what does txextra in seraphis cyrrebtky look like?

ofrnxmr[m]: same as today except TLV is enforced

ok

And all standard stuff moved out, of course

So empty as default, I guess

Has a study on uniqueness of output public keys been done before?

AFAIK yes. There are many duplicates.

hbs: AFAIK, you generally will not have a collision unless it is deliberate.

sech1: Why are we bending over backwards to accomodate arbitrary data injectors? Why do they get a pass unlike ASIC manufactureres who used to be just as inevitable? Make arbtrary data unstable, inefficient, costly, and ideally indistinguishable from other data. Wouldn't you agree that this is the best solution

cuz its easier

Because outputs

Return addresses + stealth address + encrypted amounts field + ecdh key would likely be enough for at least 128 bytes of arbitrary data

jsut saying

sech1 with seraphis it would be 30 + 18 + 8 + 32 bytes per output (Ko, encrypted addr tag, encoded amount, enote ephemeral pubkey)

Tell me how to prevent stuffing arbitrary data into outputs and I'll change my opinion

politicalweasel[: which is fine if its akso a user feature

Deliberate cases could be an attempt to exploit the "burning bug" against a naive victim and victim's naive software

"Why are we bending over backwards" That's a funny description of what we do.

we are approaching the hour, are there any last-minute questions or comments on other topics?

sech1: 1. outputs are not going away just cuz we add tx_extra. Malicious actors can still exploit it, even non-malicious ones might prefer to use outputs if you put a low enough limit on the size of tx_extra. You would have a case if tx_extra closed the outputs exploit, but it doesn't, it just adds another risk to fungibility

2. well-intentioned devs can steg into CLSAG for now; as for post-seraphis, we'll have to see what other steg methods might be available

3. the honest subset of arbitrary data injectors are a marginal minority and do not at the moment pose a risk for the chain. if/when they do the question can be revisited, not the other way around

koe, just that i thinj standarizing in/out might be wirth more duscussion alongside coinbase and txextra

ty

there is a snowball effect: if you create a stable arbitrary data API you attract more people to rely on arbitrary data injection which will create more risk for output exploitation by honest actors. By disincentivizing arbitrary data injection, refusing to signal a stable API, you also minimize honest actor output exploit risks as well

protocol instability is the opposite of what want to aim for

For arbitrary data injectors? It should be, I believe.

We could abbreviate that to "ADIs" :)

good idea

that's the end of the hour, thanks for attending everyone; it may be a while before I implement those tx_extra changes, I'll keep the channel updated as usual

thanks koe!

ty koe 👍

I am in favor of 255 bytes per output optional with the requirement that either:... (full message at <libera.ems.host/_matrix/media/v3/do…f97ce9169f2d573a5f3a923af3a1233ea71>)

255 bytes per output? Damn.

I see this as a compromise between the current free for all and complete removal

But we already have a limit ArticMine , it's practically 32 bytes.

I mean, a soft fork limit.

How?

Not at the protocol level.

I am talking at protocol

We can keep node relay limits that are strcter

Stricter

ArticMine[m]: Why do you believe it necessary to compromise with ADIs?

tx_extra is not per-output, it's global to the transaction (AFAIK also in the seraphis implemetation)

Also my understanding, I think "bytes per output" solution variations were discussed much less

So you encrypt with which output?

Maybe I am wrong, but I think the idea is everybody can encrypt with whatever key they like

that's up to the protocol that uses it

they can slice it between outputs or use just one key

ArticMine: "I am in favor of 255 bytes per output" <- This is saying "Just add a dummy output if you need more space in tx_extra".

So then a global 255 or 0 instead per tx

Much simpler

At least that's my understanding, yes, and the point where I argue from

I am fine with that actually

Also tx extra transactions will pay as a minimum the normal as opposed to min fee

So one fee tier up

From the minimum

i dont want insert persons name looking at a tx i sent them and knowing 80% of my deciys areny the true spend

simply by excluding txextra, big tx sizes, fees, and non 2 outs

too many puddles for 16 rings

jeffro has a pr to remove coinbase from that list

Yeah, and even quite uncontroversial, as it seems so far

We. can restrict outputs per tx to 2, 4, 8, and 16

but morbinaks + coinbase were >30% and woukd have been higher is p2pool hf didbt happen

Or even 2, 4 and 16

ArticMine @articmine:monero.social: i think its a good idea to restrict outputs, but i have more thinking to do about inputs

tevador: to reasonably claim the field is 'encrypted by default', the encryption needs to be standardized in the core library

per-out field would be much more straightforward from a UX and implementation standpoint

Restricting number of outputs could have the side effect of services rapidly spending outputs as soon as the 10 block lock was finished. Identification of those txs wouldn't be deterministic, of course.

tobtoht[m]: that's the case with any incarnation of the tx extra

We eliminate the inefficient outputs such as 3, 5, 10, etc

So it does force the addition of dummy outputs

dummies arent bad

.. but it is still efficient

1/2 is 1.5kb, 1/16 is 3.2kb

UkoeHB: with 256-byte tx extra and 2/4/8/16 outputs, you have 256/64/32/16 bytes per recipient. Easy to implement.

so a 1/9 or a 1/13 isnt much of a size dufferebce

Is there an advantage of 255 bytes over 256 bytes?

how does that look with:... (full message at <libera.ems.host/_matrix/media/v3/do…356455e2699cea5251d3751fc961205b76b>)

tevador: would it make sense to tie tx extra decryption to the reverse-DH secret (amount baked key)? that way payment validators can decrypt normal enote extras, but find-received cannot