A proposal regarding the MRL meeting later today: monero-project/meta #797#issuecomment-1430847786

"Doing the same over and over again and hoping for a sudden change in outcome is madness"

Since all the arguments have been made over and over "ad nauseum" for years, couldn't we just have a vote today to throw out or keep "tx_extra"? Why is everyone so afraid to make a decision?

This isn't a democracy, so our vote doesn't really matter. It's about convincing the core team.

And it shouldn't be a democracy either.

You are right. It is not a democracy. But, the MRL can come up with a consensus by voting, can't they?

Setting up a precedent for these sorts of decisions to be decided by a majority vote is a very damaging prospect.

a majority vote isn't consensus. maybe a 2/3 vote or something but simple majority no way

something near a 50/50 split is the opposite of consensus, it's contentious

voting on a purely technical question is idiotic

Even 2/3 vote is trash. 2+2=4 even if 2/3rds vote that it isn't. And you'd be surprised at how many people would vote that 2+2=5.

sech1: Exactly.

also true though I'm not sure this is a structly technical question

strictly

O.K. So don't call it voting. Call it a poll.

the technical question is to gather all current uses of tx_extra and replace them with something else that doesn't let users embed bee movie scripts into transactions

There's one easy question that can be posed to determine your position on tx_extra, as I've mentioned in the issue: are you for or against arbitrary data in Monero? Personally, I'm strictly against it.

And I believe that Monero's design principles and goals are against it as well.

<one-horse-wagon[> "Since all the arguments have..." <- The best projects are benevolent dictatorships, and other pretty much crumble

If we want privacy by default transaction uniformity matters more than the flexibility tx_extra offers

That is not quite right: to determine your position on tx_extra [...] are you for or against arbitrary data in Monero?

You could have a fixed encrypted blob attached to every tx. This would allow arbitrary (within some small size constraint though) data, without tx extra, or more generally without the ability to tell whether any data is in or not.

You could also embed data in existing tx data (though it has other drawbacks).

moneromooo: Wouldn't doing this keep both parties happy?

moneromooo: So now everyone pays for extra tx fees regardless of whether its utilized or not, essentially making txs that don't utilize that field be unproductive.

If both parties are "people who want arbitrary data" and "people who want to remove extra", then yes.

Alex|LocalMonero: that is a very poor excuse...

<sech1> "voting on a purely technical..." <- ^^^^

moneromooo: Excuse for what?

For being against a mandatory fixed size encrypted addition.

Fees are already tiny. Too tiny, probably.

moneromooo: Yes if those people who want to remove tx_extra do so for uniformity reasons

fees are not tiny

they make any amounts below 0.00001 XMR useless

Are there any downsides to having fixed sized encrypted blob to every tx?

even below 0.00003 XMR

That's less than a USD cent. Tiny.

moneromooo: Permanent unnecessary space requirements and fees on the potential future standard currency of the globe? Can you imagine how many equivalents of trillions of dollars this scales out to?

is 1 XMR = $1,000,000 it's $10

*if

Yes, increases size, so storage space and bandwidth. Also can be unprunable, depending. Also fees, at a push.

Not to mention that this now incentivizes people to utilize the field since they'll be paying for it anyway, which will direct them to sub-chains and applications, creating fungibility risks.

Alex|LocalMonero: that is a stupid argument. 256 bytes is like 15% of an tx size. If 15% of a tx fee becomes trillions, what does the 85% become ?

You'll get priced out by the tx before you get priced out by such an addition.

Other things will have to be worked out before then to survive this.

moneromooo: 15% extra transaction costs for the global economy won't scale out to trillions equivalent in your mind?

Re-read.

(I mean, this is not what I said)

I know what you said, I don't think you understood what I said.

Over the long run, if the currency becomes a global standard, an extra 15% in tx costs is a massive point of friction.

And a currency that offers the same but without the extra 15% tx costs will easily win over.

Then I was replying about this specifically: "So now everyone pays for extra tx fees regardless of whether its utilized or not, essentially making txs that don't utilize that field be unproductive."

I did not calculate any absolute value, as it's not relevant to what I intended to say. It may end up being trillions, or not.

OK. I accept your argument. I do not agree with your characterization that it is too large a problem. Which I think you implied ?

I do imply that it's a large problem in the context of Monero competing on the global currency market for dominant status.

Any point of friction will be outcompeted by a more efficient currency.

I don't think something being 15% cheaper is ever going to be remotely enough to overcome network effect

Lyza: Wise and other international payments providers are easily overcoming SWIFT's network effect by being cheaper.

Are there many people or applications who depend on tx_extra? Is it a must for someone?

As far as I know there is nothing using tx_extra yet, if we exclude the pub key which could be moved to another field

<Alex|LocalMonero> that's a different situation because each of those networks can move the same currencies. Only XMR network can move XMR

I think seraphis does this.

Lyza: That's not an important distinction for the argument, though. What I'm saying is tx fees matter. Unnecessary friction makes a currency less competitive.

Re-reading, to be clear, when I said "I accept your argument", I mean it as "I understand your argument", not "I agree with it". Just to be sure :)

I think that being able to add public and arbitrary data to the transaction could be very interesting, especially for NFTs and decentralized domain names; however, I think that Monero, as a currency, should not allow adding chain bloat. There are other blockchain specifically made for this kind of things.

I agree with this ^

Exactly.

to be clear I'm in favor of removing tx_extra in whatever hard fork would happen next and don't fully understand the need to embed arbitrary data myself. but I'm definitely trying to hear arguments the other way

Somewhat too. I had high hopes for extra being used for interesting stuff, but it did not, and ended up really pointless in practice.

anyone know offhand if the proposals that have been made for payment channels with XMR use tx_extra?

<moneromooo> "That is not quite right: to..." <- Technically everything is arbitrary data. it would just be gibrish to anyone else

ghostway[m]: You can split it into chunks. But it would be really expensive

<moneromooo> "Somewhat too. I had high hopes..." <- I fully believe in trying things. Sometimes they succeed and sometimes not. At some point, you do have to move on from those that didn't work out.

I believe Monero succeeeds very well in not repeating Bitcoin's mistakes. Let's not break that tradition by keeping tx_extra

I wouldn't be surprised that if tx_extra is kept we will eventually see "litenero" which will advertise itself as a Monero that's cheaper to use.

Now that's appeal to fear.

And takes less space, less bandwidth etc.

I hope tx_extra gets removed in the next big release

And AFAIK Bitcoin does not have an extra equivalent (and people started using a hack to add arbitrary data).

It's not appeal to fear or greed. It's a statement of fact if the efficiency of Monero is not optimized for transactions.

That might also work with monero actually... I wonder...

I think it is possible actually :)

moneromooo: Bitcoin is one big tx_extra field essentially.

I’m not convinced that a fixed size helps much for the problem of arbitrary data stored on the chain. If we consider the ‘opt out privacy’ principle, what we have now already satisfies that - the default is an empty tx extra (ignoring ephemeral pubkeys). Using a fixed size encrypted field just means the default for new uses of the field is to be hidden among old default-conformant uses (not necessarily a bad thing

to aim for - the trade-off is chain bloat). The thing with opt-out privacy is it does literally nothing if you choose to opt out. For tx extra and ‘pasting in data’ in general, the only thing you can do to counter opt-out usage is increasing fees (1. Increase the tx extra fee rate so it matches the equivalent fee cost of steganography, 2. Increase the base fee rate). Everything else amounts to making it harder to

opt-out, which is not a good argument (your whole effort evaporates as soon as someone publishes an open source tool). I’m personally in favor of tuning the fees as best we can, and feel skeptical about the chain bloat implied by a fixed size field (mainly considering how little the tx extra is actually used outside the default).

maybe Light Nodes get more attention too monero-project/research-lab #69

Is there a reason not to have all-or-nothing? Zero length or length N? Then most txs would have a zero-length tx_extra. Protocols/wallets/users that use it would all have the same tx_extra length. There would be a reduction in tx uniformity compared to fixed length for all tx, but it would just split the anonymity pool into two ponds instead of having many puddles when users can use any length.

Good point, UkoeHB, fixed length doesn't make sense

Rucknium[m]: not a bad idea, I had a similar thought just now lol (to specify a tx extra value type that’s fixed length and generic)

I don't think there is a reason beyond the one you mention already.

So if it's zero or N, doesn't this hurt fungibility?

Aren't we segregating the chain into two subchains?

That *is* the reason Rucknium[m] mentioned.

So if fixed length doesn't make sense and zero or N hurts fungibility, then zero wins?

Alex|LocalMonero: the chain is already split into puddles based on ‘default’ vs ‘nondefault’ use of the tx extra, so 0vsN would be an improvement in the current default (I like orienting design decisions against what we have now)

tx_extra length wouldn't be the worse source of tx uniformity defects. I would put wallet fee algorithms and decoy selection algorithms above tx_extra length probably. (The Seraphis upgrade will help reduce fee diversity by discretizing fees.)

UkoeHB: so basically we're close to a "Zero or N" state now, recognize that it's a fungibility problem, recognize that a more perfect zero or N state is also a fungibility problem, therefore, if we move, we should move to zero?

Any downsides to having zero length other than the possibility that someone can use tx_extra in the future? In that case can't people simply fork Monero and introduce this field? Is there a point in caring?

0vsN would be a significant improvement since all non-null fields would be private by default (within the set of default-confirming N-size fields).

Rucknium[m]: It's not just length but also content, though. Eve can see which txs are related to what apps. Some regulators might start requiring their local exchanges to encode national IDs onto txs of their users withdrawing.

kayabanerve has already made the point that people can put arbitrary data that reduces tx uniformity into others parts of Monero txs.

Fake out pubkeys ? :)

There is a discussion underway on whether statistical checks on tx_extra contents can in effect make the tx_extra field be encrypted

If something reduces tx uniformity I'd much rather it be stegged into the chain so as to look normal to any observer that isn't in the know than out in the open

And also, how would the stegger excludes txs that have fake out pubkeys that accidentally match his format @moneromooo?

s/fake/real/

I do not understand that question. Can you rephrase ?

Alex|LocalMonero: if fixed length were mandated then it would be encrypted by default

who are you defeating, with steganography? afaik it takes very little analysis to extract steg data

hyc: you defeat constraints on the tx extra

Hypothetically

If a stegger wants to encode things onto the chain in order to access it later how can the stegger, when later reading the chain, exclude the noise (outputs that match his format by chance despite being genuine)?

You could include a bit that tells you that.

So ECC

Well, in the case where Alice sends to Bob and Bob reads, at least. I did not think about the case where Alice sends to Bob and Alice reads.

how is ECC related to steg.?

Hiya 👋... (full message at <libera.ems.host/_matrix/media/v3/do…626082410b75a75fe428c3726d67b8d3677>)

It's not ECC fwiw (though you can use it too).

pls ban that scammer

@kenzie_jonn:matrix.org

endor00

moneromooo: not sure I understood your answer. If you include a bit for noise that bit itself can also match the noise, can't it? Maybe I'm just not getting something.

Also, "afaik it takes very little analysis to extract steg data" <- I think you're thinking about hiding stuff in low significant bits of structured data

Well, no. You include a bit that does NOT match the noise.

It just has to be equiprobable for an attacker.

Are you assuming that Bob knows which tx he needs to read?

I'm thinking in terms of a decentralized data transmission network.

I do this in a monero fork, and AFAIK an observer cannot tell which txes have embedded data and which don't, and the receiver can tell with certainty which do and which don't.

Bob will see which txes are for him, like he normally does.

Do you mind linking how you do that?

Ah, I think I see what you're saying: this requires an output to go to Bob.

Right.

Thx

and git.townforge.net/townforge/townfor…0ef6e4900434e54cb7cf071074d3d4da66b

First is the bit that monero could share, second is the "application layer".

(it has drawbacks though, no free lunch)

moneromooo: from the commit description it sounds like the only drawback is ringsize reduction for the receiver

AFAIK, yes.

Well, I guess from your point of view there's another drawback, which is a whole new tx's worth of fee :)

The input mixring also allows you to embed arbitrary data up to (num_rings * (num ring members - 1) * log256(total chain outputs)) bytes, which also poisons everyone else's decoy selection. Once we tackle tx_extra, this should be the next target IMO

moneromooo: I don't mind that if something looks like a tx, walks like a tx and talks like a tx and pays a tx fee is a tx on chain. I do mind things on top of a tx that are added regardless of whether the end user is utilizing it or not and thus needs to pay extra

Oh yes, that make sense.

jeffro256 can you, though? you can't just add arbitrary ring members, they need to exist on-chain (and belong to the same hardfork as the other ring members for that tx type)

The data is in the index, not in the referenced public key.

You can stuff low bits with your data.

I'm not sure how it poisons other people's rings though ?

right

Because obviously bad decoy selection = tx that stands out with its own outputs = less "real" transactions borrowing your outputs as decoy inputs

Why the last implication ?

> jeffro256 can you, though? you can't just add arbitrary ring members, they need to exist on-chain (and belong to the same hardfork as the other ring members for that tx type)

Hence the log256(total num of outputs on chain), you can make the indexes anything as long as they're less than the total number of outputs on chain

> Why the last implication ?

I guess the same reason why p2pool is bad for decoy selection and output flooding is bad for decoy selection. More junk outputs = more junk decoys for real transactions

Junk outputs here meaning outputs from transactions which obviously stand out for a certain application, embedded with public data

Ah, because you're assuming someone will always use this system for all their txes ? Fair enough.

Yeah without automated checks for these transactions to avoid using them as decoys, normal wallets will statistically use them more, reducing the effective decoy input size

All this will presumably get fixed with: monero-project/research-lab #100

They'd use them at the same rate I think.

> All this will presumably get fixed with: monero-project/research-lab #100

This could be also fixed with the determinstic output binning right?

tevador: are you aware of any arbitrary data injection techniques in zk_SNARKs?

The reduction would come from the fact that another person would not use the system, therefore an observer would remove outputs from a tx using the system (assuming the sender always uses the system).

Am I missing a reason why normal wallets will statistically use them more ?

Alex|LocalMonero: no and also Seraphis won't support the method moneromooo mentioned

Yes, sorry I wasn't clear. I meant "more" as in more than if they didn't exist

today's meeting is in 1hr

UkoeHB Does output binning as implemented now use the Hash-to-distribution method, or are the bins still picked manually by the transaction creator?

AFAIK the current impl has 16 bins that are indexed the same way as current decoys, so user-selectable.

tevador: right

Wasn't there problems making the distribution function reproducible against floating point hardware?

*across

Well it’s one challenge you’d face

What were the other challenges if you don't mind me asking?

Thoroughly understanding the edge cases, and getting locked into a heuristic-laden algorithm

not to discourage an answer but here's the research lab issue <jeffro256[m]> monero-project/research-lab #87

If we adopt a next-gen membership proof with a reference set size of 2^40, there is no need to have a decoy selection algorithm anymore.

Indeed.

Lyza That's a good thread which I haven't yet seen. I was talking about monero-project/research-lab #84, but that's also an interesting idea to discuss

yeah 87 also links to 84 and 86 (:

all kinda related

+

whoops meeting time

UkoeHB: Ready to start meeting?

1. greetings

hello

Hi.

Hello

Hello!

Hello

Hello

Hi

Heya

Hallo

Hi

2. updates, what's everyone working on?

Hi

Heya

I’m chatting with Rucknium about providing support on OSPEAD computational work. The plan is to have one of my engineers convert the R prototypes to a compiled language, and then we’ll run the faster code for tens of thousands of CPU hours on GL’s scientific computing infra. The benefit of being able to process more rings will be better precision in the final OSPEAD parameterization.

The plan is that we’ll first build a little demo for Rucknium pro bono, showcasing the relevant engineering skills, and then move the CCS forward for the main project. Even though we’re still in the pre-CCS demo phase, I went ahead and uploaded a draft of the CCS proposal (#375) in case anybody is curious wants to take a peek at the details in the interim.

hello!

me: Learning how to connect C++ and R. I left a comment on isthmus's proposal: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/375

jo

hi

hi

Is this the tx_extra discussion? I just came to watch.

Ive been working on webhook support for lws, which is not really mrl related. unfortunately no recent progress on bp++, but I pushed back the 2nd feature set for webhooks to get some bp++ time in the upcoming weeks

someone just needed lws stuff with a very high priority (or so they claim)

Monegro: Yes, in a bit

me: I've been building an experimental tasking system which may or may not be useful in the seraphis wallet migration project. My threadpool appears to have comparable performance to the current one tools::threadpool, but lets you 'sleep' on tasks inside the pool which increases throughput drastically if you have tasks that would normally hang to sleep for a long time.

Monegro: yes

ukoehb is it published anywhere? I can give immediate feedback

it will take my mind off going through the math you want me to go through :/

I will comment on the read/lock thing you did, a couple of trivial comments

UkoeHB: does it make sense to focus on that at this second? i bet parallelization could be added later

vtnerd: github.com/UkoeHB/monero/tree/seraphis_lib/src/async

endogenic: don't know, don't care!

wonderful

forget asking me for feedback then

vtnerd: I haven't been able to figure out how to do very small tasks quickly unfortunately.. might be unavoidable overhead of the extra things I have in there.

yeah the allocations and locking usually kill that

3. discussion, today we are supposed to talk about possible consensus rule changes around the tx_extra

its typically better to have largish tasks for a system like that

People may have seen my idea to talk about alternative ways to get consensus about such consensus rule changes, see the meeting issue

At least as an additional thing to discuss

re: tx_extra there has been considerable debate in these places monero-project/monero #6668 monero-project/meta #797

rbrunner: Can we do this next time please? There's no point in this last minute change

I read all 150 comments on tevador's GitHub issue. I don't have a strong opinion on the matter due to the tradeoffs between different options. 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.

If there is some progress today, we can easily move that weeks. If not I see it getting important.

My summary is: Steganography has multiple performance impacts and is a uniformity trade off, not solution. I personally appreciate TX extra. I'd advocate a 255 byte limit, and wouldn't mind a statistical check/ASCII ban.

There's a lot of further discussions possible, and I'm unsure, per rbrunner, we'll actually reach consensus. I'd advocate either we take steps to limit it, which have minimal disagreement, we vote, or we drop the discussion entirely for consensus process discussions.

The current situation is that we have tx_extra as an arbitrary size field for arbitrary data. Does anyone think the current state is ideal?

no

no

No

no

no

Nope

no

no

and projects publicly listing their decryption keys for new tx_extra, is also not ideal

So we can have at least some consensus.

so steg

if the steg is public, its the same problem as public decryption keys

I have a hard time estimating what is ideal and not logically impossible

I see that the same as view keys @vtnerd

steg has to remain private to work, thats the difference between it and cryptography

but I'll accept 'could be improved'

monero doesn't advocate that large projects publish their view keys publicly

Any public output set is a privacy issue so long as we have subset membership proofs.

at least afaik, like many people are on edge about MyMonero and privacy, and don't want it worsened, etc

And her we do explicitly state view keys can be shared for verifiability.

which is irrelevant to what Im saying

thats just whataboutism on some next level crypto talk

*and yet

If arbitrary data is to be stored it should be stored in a way that makes it look just like any other tx to the greatest possible extent

there are researchers working on this stuff right now

why doesnt this room care?

the problem is this DEX (thats whats tx_extra) cannot market itself as a privacy solution, only a decentralized exchange

they're the experts

Somewhat? I'm more trying to comment this isn't an issue unique to extra and I don't care to premise this extra discussion on it.

provided the community understands this, its probably no worse than Kraken having a bunch of view_keys and info

Can we find a compromise on TX extra?

just include it with a fixed size, thats probably the most reasonable thing to do at this stage

There's an active PR to make it ~2kb

ArticMine: why is a compromise with arbitrary data injeciton desirable?

I'd advocate 255b.

I thought that's what #8733 is, a compromise

tevador?

If we can achieve a rough consensus that compromising is within reach.

I really like the Zcash approach - fixed size encrypted memo on *every* transaction so that no transaction with a memo sticks out.

If people are not ready to compromise ...

Along the lines of a limited number of fixed sizes

Some options are: 1. Limit the size. 2. Make it fixed-size. 3. Make it optional with a fixed size.

isthmus: this means that 99% is paying additional 15% tx fees (not to mention space and bandwidth) for the benefit of the application layer

Correct, it's for uniformity and everybody's privacy

Yeah, or tx_extra can just be dropped for even more uniformity and privacy

No free lunch

Alex|LocalMonero : yup :/ and I agree with tevadors condensed description, thats really what the debate is over

And pusedo enforcement of randomness via node relay

#8733 is a stop gap measure before Seraphis can change tx_extra.

vtnerd: why isn't removing it an option?

Mandatory blob of fixed size would have very low computational/verification cost, yes? Downside would be purely storage/bandwidth

moo had a patch a while ago that did that (fixed size extra) if IRC

blankpage: fees

And a terrible hit rate, very few people wanting to store something there, and doing so

One of the size choices can be zero

As distinct discussion, if tx extra is kept, I believe it should be prunable and prunes by pruned nodes

Just reduce minrelayfee by 15% and the fee issue disappears

your right, there's no reason why we cannot force steg approaches, even though they are suboptimal

Would forcing steg reduce the frequency of usage?

#8733 should be a nobrainer whilst other things are worked out

vtnerd: they are suboptimal for arbitrary data, which makes monero more optimal for tx data

*As a, pruned by

Monegro: probably, as its much harder to do

Monegro: A higher cost of arbitrary data injection disincentivizes its usage

Rucknium[m]: Not that simple

Alex | LocalMonero | AgoraDesk: Not definitively

From a protocol design standpoint, our goal is privacy by default (i.e. opt-out privacy). It is impossible to mandate privacy, so any proposals with that goal should be discarded. What are the default-usage privacy defects of tx extra? Lack of uniformity among tx extra users (non-users are uniform in that they all have 'empty' fields [excluding ephemeral pubkeys]). Assuming we want to keep a tx extra in some form, we

can A) improve uniformity globally by mandating all txs have identical-looking tx extras by default (fixed-size and encrypted by default), B) improve scoped uniformity by mandating all txs have EITHER no tx or a fixed-size tx extra (encrypted by default). (A) is better than (B) in terms of uniformity, and (B) is better than (A) in terms of scalability (a fixed-size tx extra would be a big chunk of txs, maybe 25%).

Option (C) is deleting the tx extra if we decide it isn't a feature needed by default (steganography could be implemented as a non-default alternative).

the problem is that theoretically monero could support _some_ application layer stuff without being a privacy sieve

Re: optimality

I believe thats why tevador tentatively agreed to keeping tx_extra around - theres a way to use the memo field "properly"

does no one care that actual qualified researchers specialize in this

and that we have blinders on

we could invite them into the room as a community

but we choose to wander in the dark

I think we have a handle on this

no you dont

you cant predict the future of tech or you'd be those researchers

besides

endogenic: Sure. Invite them.

what kind of nonsense is it to not decide we need people who actually specialize in this

and researchers are never wrong? please, dont waste our time

what motives do you have exactly?

vtnerd: "proper" use of the arbitrary data field is an oxymoron if the design goal of monero is to be the best possible digital cash

endogenic: The room is open, feel free to invite “them”

vtnerd what a ridiculous argument

> Can we find a compromise on TX extra?

I'll summarize the idea I had for tx_extra. I discussed it with kayabaNerve, but didn't make it public. Disclaimer: kayabaNerve doesn't necessarily support this idea. Make tx_extra a public ed25519 point + signature (proving knowledge of private scalar corresponsding to aforementioned point) which reduces the amount of arbitrary data possible to encode into a transaction limited to just a few brute-forced bits. However, any

arbitrary data could be privately verified to be "attached" to this transaction by hashing to the point provided in the transaction. This tx_extra is small and fixed size but allows for off-chain verification of arbitrary data. ALSO, for data availability, "archival" nodes would relay and save corresponding blobs which match the tx_extra of certain transactions. Full nodes would also relay and save for up a week (this period

could be determined later). This solves the data availability problem, the DEX problem, and increases transaction uniformity. It does have tradeoffs, but I like this solution.

I have invited plenty of researchers here. Some have showed up.

i have invited them

they often feel disregarded

surprise

that's why i said as a project

if it were fixed size, and always encrypted by all parties, its no worse than ring signatures

none of you seem to value their free contributions

+1 vtnerd

the more options _allowed_, the more problematic it becomes

+1

Interesting

vtnerd: it is worse because its an extra added on top that everyone has to pay for whether they use it or not

using steg approaches works, but its funky

endogenic: if you have something to say, be specific

i have

stop strawmanning

jeffro256's idea has a pointless component, otherwise I'd have a similar option

endogenic: Give us some names

Im not talking about cost, Im talking about privacy, which is why isthmus gave me the +1

koe has names

and there are more of them too

I suggested one of the options being zero

dont think i'm talking out of my ass

endogenic: please be useful or shut the fuck up.

i'm not that flush with free time

i am

from a stat perspective, a symmetricall encrypted field is not going to be worse than the ECDH madness

try to listen

vtnerd: Fine with me, if 256b (> than a jamtis addr)

Link us to whatever work is there, fr instance. Dont' say "why don't we listen to them".

It's a bit bloated, but it solves the privacy, usability, and soft fork discussions

i habe

habe

have

it has been ignored

I believe a compromise is possible here

and it's notable there are individuals with conflicts of interest here

Sorry, I missed it then. I'll re-read.

We can also make TX extra prunable to help there

If referring to me, I don't mind disclosing, yet I'll comment I am minimally effected by this discussion.

1. If it's fixed length and encrypted then everyone is overpaying and overusing resources for the benefit of the few (and the junk outputs are still exploitable)

2. if it's optional then fungibility is harmed as we have what are essentially subchains

3. if arbitrary data injectors are forced to make their data look as txs then they effectively are txs and for all intents and purposes are a legitimate use of the Monero chain

I read the discussion of jeffro256s idea recently and I think it is very interesting. I do wonder if there are use cases which are only serves by the arbitrary data being on chain though, rather than a hash representation of what is happening in a mempool of blobs

But sure, I work on a real world use case of TX extra for arb data.

I re-read, no link or similar searchable info.

We can have a limited number of anonymity sets like we do with tx outputs

Alex|LocalMonero: 2. is not much worse than 3. because transactions with more than 2 outputs already stand out.

jeffro256[m]: my take is your proposal implies quite a large engineering effort (maybe more than is justified by a field that's barely used right now). Uniformity isn't really improved if you can just connect archived data to txs (there is no way to upload a tx and archive data at the same time without linking them).

Alex|LocalMonero the problem is that the steg approach are almost certainly less optimal than the encrypted approach, thus why we keep going in circles

tevador: txs with more than 2 outputs standing out sounds like a separate protocol issue to be fixed

vtnerd: less optimal for arbitrary data, so who cares?

I have a question

arbitrary data isn't monero's design goal

moneromooo: it has been over the past year

Alex|LocalMonero: and 2. is much better for scalability than 3.

i will dm you

Who here actively wants to remove, not fix, TX extra?

I am not the one that'll do the work anymore. Link it here please.

the record can be searched. time for you guys to stop trampling on people

If we can limit this discussion to improvements, which we can discuss incrementally, that may be more effective as right now we're exhibiting the concerns stated before this started

I also interested in this research or whatever, I don't see the point in complaining without bothering to share what you're trying to talk about

I support that question. Full removers, please wink.

tevador: scalability of arbitrary data? Again, who cares? We should be optimizing he scalability of tx data. The 0.01% usage of application layer data being unoptimized is not a concern

+1 remove - it sounds like arbitrary data can be added in other ways

some people might know what you're talking about <endogenic> but I would wager most of us do not

... but if people insist on uniformity adding 128 bytes to each tx is less than 2 months of Neilsen's law

+1 remove

Because getting full removal out of the way, per way of compromise, would be progress

> the record can be searched. time for you guys to stop trampling on people

For everybody's sake could you please link it if it's relevant? I want to know about formal research around this topic if it exists. It would be helpful to everyone who is not on here 24/7

Two votes so far for full removal. Any more?

+1 remove

remove

+1 remove

ArticMine: nielsen's law sure but what about fees?

Lyza: i have been laboring for years to bring that research here

now when i've been treated like i'm the asshole i have to forget all that?

The impact on fess is minimal

How about hard-limiting tx_extra as a immediate action, and then jeffro256's idea could be further thought through to see if it covers all use cases?

smh ok don't share it then but if you're not trying to be helpful waht are you doing here

Hmm, with 5 removal votes compromise will probably be difficult ...

As meeting leader, I'm going to slow this down (getting a little too chaotic). Let's get a read on everyone's stance. I will list some options, then everyone should reply with the number they like best, and a small comment justifying your position.

1. get rid of tx extra and be done with it

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 (specify)

I would be okay with a fixed-length mandatory encrypted field

1

I personally don't mind removal (that was my original proposal), but I'm open for compromises (since pretty much anything is better than what we have now).

Some of the latest work of Moreno Sanchez, he said in private. In case someone wants to search/read.

All NRL research points towards tx_extra being Monero's Achilles heel as of 2023. While the most straightforward solution would be to remove it, I also understand that there are valuable ecosystem components coupled to this, so I am also very open to discussing improvements. Anything better than currently.

This is like 5% of tx size

the case for keeping seems to be only for unknown future use cases

I'm also fine with removal

thx moo

please no more comments other than replying to me for 4 minutes

I need to moderate this

4

UkoeHB: 1

blankpage: There's a PR for a hard limit

1

Kinda conflicted between 1 and 3.

1

2,3,4

1, 4, open to others' 5

1 , possibly 4

jtgrassie: fair point, and we could always bring it back in a hard-fork

2 because length restriction, plus the encryption from 3

vtnerd: exactly

1 or 3 are probably the best.

UkoeHUB: In order of perference, best to worst: 4, 1, 3, 2

3

/iwn 21

sorry

1. remove. Better for uniformity of transmissions.

1 or 3

1. Fallback 4

3

hence #1 is the ideal and #2 at least nudges in the right directon (quick change)

Like I said, I don't have a strong opinion because of the complicated tradeoffs. If I have to choose a single option, I would choose (1).

2

Lyza: this is the help the project needs. the people here repeatedly throw away connections i've made. i'm not going to name names

4 minutes are up, shall we tally?

Oh. 1 would also prevent merge mining fwiw. But I'm biased of course.

1 [alex, jeffro, dangerous, moo, hbs, isthmus, fred, tevador, tobtogh, john, jtgrassie], 2 [kaya, rene, jtgrassie, uwanted], 3 [moo, kaya, tevador, artic, koe, tobtoht], 4 [jeffro, blank, kaya, isthmus, fred, john], 5 [isthmus]

We have to keep tx_extra for coinbase in any case (at least a fixed size one).

Sorry, I forgot to include a comment explaining my votes: I said 1 & 4 because they maintain transaction uniformity (central to user safety) and preserve a single anonymity pool. I am open to others’ suggestions for 5 if they maintain transaction uniformity.

It sounds like due to fragmentation among 2,3,4, 1 is the most popular option there

+1 isthmus

tevador: For merge mining or yet something else?

extra nonce

UkoeHB: You didn't count my vote for 1.

kayabanerve[m]: the field is used for additional pub keys

sorry I may have missed a couple

TIL That's how that works

kayabanerve: If we had ranked-choice "voting", the vote-splitting between similar options would be less of an issue

Yes but a binary vote keep or not would be helpful

1 [alex, jeffro, dangerous, moo, hbs, isthmus, fred, tevador, tobtogh, john, jtgrassie, onehorse, rucknium], 2 [kaya, rene, jtgrassie, uwanted], 3 [moo, kaya, tevador, artic, koe, tobtoht], 4 [jeffro, blank, kaya, isthmus, fred, john], 5 [isthmus]

Democracy is irrelevant here IMO. No one has technical objections to limiting the size so let's just do that. Then if the ideas like jeffro256's turn out to be infeasible or not useful then we remove it completely in the future.

kayabanerve[m]'s idea (link to TF above) ensures uniformity and allows arbitrary encrypted data. So I also like 5 :D

we have t keep it till the tx structure is changed, hence why #2 is a good stop-gap to #1

The current PR #8733 is a soft-limit for tx_extra. It cannot be removed right now because it contains mandatory public keys.

I think when Seraphis comes near we will have tons of things to discuss. I would love to decide this today.

We already immediately have a PR to limit size. I believe this is discussing changes to make at time of seraphis.

To get it out of the way, so to say.

Seems like removing it is the option the most people find acceptable. Not that this matters to the technical soundness of it.

We can either:

- Remove

- Call for a ranked choice vote

- say one IRC Nick != one vote

Though as noted, coinbase will still need extra

I said it before, and I say it again: voting is idiotic in a technical matter

@sech1 where do you stand?

whatever path forward is taken, it must be justified

... That'd be option #3 :p

I prefer option #1 eventually (after HF)

all needed like tx pubkeys can be moved to separate fields

I thought this discussion was meant to mean removing it post seraphis?

Did people discuss removing it now?

Why would that matter?

Time for people to swithc

The "when" is a separate question

I mean #1 after seraphis

Seraphis already moves public keys from tx_extra, so it would be purely for arbitrary data then.

UkoeHB: I also vote 1, if my vote counts

What would we do with payment ids ? Some poeple like it even with subaddresses available.

before that, it can be size-limited and have higher fee per byte

Voting on keeping it or not should be separated from how to keep it

+1 artic

moneromooo: Deprecate it :))

moneromooo: payment ids have been deprecated/replaced by encrypted address tags

Just to be clear a "no change" option is not what anyone wants, correct? Everyone thinks something should be done?

+1 ArticMine

So, it sounds like the agreeable option is remove with Seraphis. The only way to threaten this is to call for a ranked choice vote or to call voting idiotic

Exactly, as moneromooo points out its very impractical to remove tx_extra prior to seraphis

I think 1 is a strong option. We can divide the options into two categories: A) remove, B) keep in some form. The reason for keeping it is 'all the things we don't know in advance and don't want to depend on a hardfork for'.

Monegro: Looks like it, "doing nothing" only got "nos" earlier in the meeting

ArticMine: -1, there's no point in discussing how to keep it if we decide not to keep it

I did not intend to weigh in on the timing fwiw.

Of course

From a protocol longevity standpoint, keeping it is better because it reduces the need/desire for future hardforks.

At least A) or B) would give a clearer picture after the vote

also, did anyone do a research on how tx_extra is used now?

We vote first on whether to keep it

yes wanted to ask do anyone use it for something

what are the chances rn of having another HF before Seraphis? tx_extra aside

Yes: github.com/noncesense-research-lab/…_tx_extra/blob/master/ascii_data.md

UkoeHB: soft forks have proved themselves to be a disaster for BTC, hard forks have proved themselves to be a blessing for XMR

tevador 2020 != now

Then only if the decision is to keep them we work on the technical details

data might be encrypted

now it's mostly bee videos (anecdotally)

This room was bridged to tx_extra for a few hours a while back

*a Script for a bee video

I am in the "keep" camp mostly for softforks as an emergency option. Not terribly important to me personally what people do with it otherwise

is there info how much data is in tx_fields in total on blockchain?

i think the softfork for emergency option can be maintained with tx_extra in coinbase only

Softforks led to massive fragmentation and tribalization of the BTC network, which doesn't even rely on fungibiliy to work.

rbrunner:

Also we separate coinbase

Does anyone know what's the max size for legit tx_extra usage now? Not counting tx pubkeys?

I am also not concerned with soft forks regarding tx_extra. There is good reason why Monero never soft forks: it's bad for uniformity. The community/dev team has always gone with the principle of fast deprecation for non conforming transactions, which is a good thing

size restriction (per #8733) is the ideal stop-gap. One can still do non-standard "experiments" using extra. It may also help in future discussions on whether to keep or kill it.

soft forks are incongruent with fungibility

If coinbase tx_extra is kept, we can still have a soft fork.

I am talking about *emergency* softforks for problems that can't wait for a hardfork.

We could keep a 64b extra to hedge against wallet protocol updates? It'd be a minimal size

There have been some outliers (e.g. 1028 kB tx_extra for one of the txns mentioned above)

We have size data, though I don't have a summary handy

NRL uses len(tx_extra) as a go-to fingerprint for clustering transactions

asking again: if we do this before seraphis, would we be hardforking primarily for tx_extra, or what else might we be trying to do in a pre-seraphis HF?

oh boy thats a can of worms

Removing is easy and good for fungibility, so I change my vote to 1 unless there is a fully sketched out plan of how to keep it in a useful way similar to jethro's idea at a point X months before seraphis

Do people want an A) or B) vote? To simplify, and getting a clearer picture?

basically, it could be useful for unknown applications but unless someone goes the work then it is better to have it gone than as-is

I don't think a hardfork is planned before Seraphis. I think we can survive with #8733 until Seraphis.

Yes

yes

I'm for merging 8733 now. We have more time to work out what do with tx_extra in seraphis.

Alex|LocalMonero: hard forks work well for privacy and scalability upgrades, which is all they have been used for up to this point. The tx extra represents utility, so this debate is about A) all future utility changes/innovations that require on-chain data should be supported by hard fork (a change in hard fork policy), B) some future utility flexibility should be baked into the tx extra.

Lyza: Possibly ending user-determined output lock time. Improvements to the decoy selection algorithm can be implemented without worrying much about creating anonymity puddles with wallets using different algorithms. I think there are more.

I'm going for a bit, so dblp.uni-trier.de/pid/128/4640.html has the list of Pedro Moreno Sanchez papers, not obvious which one it might be that suggests an extra solution, I wasn't told. But it's his "latest" work if someone wants to look.

Fee scaling updates

Before merging 8733, we need wallet-side error checking!! I can PR that today, but we need a mechanism for the wallet to know the tx_extra size limit before constructing and attempting to broadcast a non-conforming transaction

UkoeHB: the only utility monero should be concerned about is utility as a decentralized electronic and fungible currency

tobtoht[m]1: it would be good to make a decision now because Seraphis is already (mostly) implemented.

Are we going to vote again on "A" or "B" option?

After almost 3 years we all *deserve* a decision

8733 could be a nice workaround until the actual tx_extra solution

I don't mind 8733 either.

+1 8733 seems like a fine stopgap

But I agree with rbrunner that this question needs to be solved for the sake of seraphis

Solved now ideally

jeffro256 agrees with isthmus but doesn't know how to talk in third person with the little blue text

one-horse-wagon[: I'd like to table further temperature checks until next meeting. This week I'd like people to ruminate on the A/B distinction specifically, and on the consequences of each one.

"/me <text>"

this has already been a long meeting

If there are just two options keep/remove, I'd lean towards remove (keep only for coinbase).

I think my position is that if we don't have a solid use case for it now, something most of the community wants that only can be done with tx_extra, we ditch it. I do think killing the ability to merge mine with monero is worth considering, for sure

tevador: the options are remove or keep 'in some as-yet-undetermined form'

And by the way @ArcticMine even a 0.1% difference in fees is enough to justify competition in the global financial markets, so 5% is massive.

not sure if proposals for payments channels used tx_extra or not

Let's vote then! Ppurely between A) remove entirely or B) keep is some undetermined form

Just want to say that fundamentalist approaches (and I see removal as that) rarely play out well.

Lyza: merged mining would still be possible because coinbase would keep tx_extra (it has to).

just remove that garbage and be over with it..... it's used by lazy devs that could do better without it.

I mean voting shouldn't decide it, but just to guage what smarter people than me have so say

rbrunner: was RandomX not a fundamentalist approach?

next meeting sounds okay if koe thnks so (gotcha tevador, ty)

I'm old enough to remember everyone decrying that we need to compromise with ASICs

to summarize:

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

Binary referendums where one option is not clearly defined often end in unsatisfying ways

let's end the meeting here, it is past the hour so we should not do any voting

thanks everyone

thank you UkoeHB

Thanks much @UkoeHB

Thanks

++

thanks UkoeHB !

thanks

Thanks y'all

thx

I vote for thanking :)

Especially koe

+1 to giving thanks

Thank you :)

Thanks.

Thanks

Thanks Koe

when tx_extra tshirts

Thanks koe and all

Regular user hopping here:

Limiting the size of tx_extra may incentivize users to attach data some other X way

- What would this X way look like? What effects would it have over the network?

The note on A) is not entirely true, you can attach extra data in a soft fork by putting a merkle root into the coinbase tx_extra.

tevador: I think that's cheating lol

but interesting idea

Thanks y'all

Oops it me'd all of them

Last I checked there were 11 different approaches in the wild github.com/noncesense-research-lab/…e-analysis/blob/main/analysis.ipynb

But there was no hard fork on the horizon, so it wasn't discussed much

11 recently, here's the whole blockchain (^^), you can see different implementations phase in and out

Where can I learn more in the next week about what applications (like DEX’s need to function), in terms of technical specs: - data size, - visible to whom (participants? platform? anybody?), - other requirements?

I’m genuinely open to and will back ANY solution that results in a protocol whose consensus rules only allow a single anonymity pool of indistinguishable / uniform transactions.

To this end I’d like learn more about what those solutions could look like that could preserve BOTH privacy and functionality, for my own edification.

isthmus: Why should Monero concern itself with what other applications need to function? They're responsible for their own metadata. The XMR chain should be optimized for txs only.

You're preaching to the choir :)

I still want to learn more

Never hurts to be informed for design discussions

True, though I don't think it impacts the basic principle.

isthmus: this might be the closest monero-project/monero #6668#issuecomment-1426505526 ping kayabanerve[m]

It does seem like, if people were forced to use steg, they'd likely just go use other chains than XMR

are payment channels done with multisig, as opposed to something special in tx_extra?

Lyza also brought up the question if payment channels use tx_extra

I think that's a big deal, and quite possibly contentious

What does "steg" mean here exactly ? I am assuming "steganography", but this comments implies not, since people ought not care how their data is transmitted technically.

Oh yes @UkoeHB thanks for surfacing this

And good point from Monegro, I'd also want to know :D

Steg = steganography

Then why would this mean people would choose to use another chain if monero were to ferry stuff using it ?

Is there a hidden assumption here ?

I think @monegro means that the arbitrary data storage inefficiency would drive some devs away from XMR in favor of more Ethereum-like chains

Monegro: I think the only payment channel technique that doesn't require a hardfork is PayMo

OK, then typo, right ? *Not* using steg would drive people away (since steg doesn't increase size, but other wauys would) ?

haven't read that paper in depth so not sure if it requires tx_extra data

Yes exactly. Why use a more inefficient system, when others are available?

OK, thanks.

Do we have an idea of the services which may have used tx_extra for data specifically related to them? Apart from paymentids?

@Monegro I think that's kinda the point. By making it less efficient for arbitrary data you make it more efficient for its core purpose.

@hbs mining pools, serai, someone used tx_extra to comply with OFAC according to sgp

hmm. I guess I'm misunderstanding then. My assumption was that tx_extra is simpler, and that devs were typically opting to use that over other methods

Monegro: Because some people will want their data to be stored on what may become most secure & long lasting database of the planet

I would value much more data stored in Monero than in some nameless protocol

tx_extra is certainly a great vector for evil regulators to exploit, some big oppressive government might arrest anyone who's caught transacting XMR without encoding their ID into tx_extra

Alex|LocalMonero: They also may arrest anyone that doesn't share their view key, you can't prevent users from willingly revealing their txs

@gonbatfire yeah but Monero isn't that, it's a value transfer system. There have been decentralized database projects already, most of them have faded into obscurity

ok Alex | LocalMonero | AgoraDesk, so maybe they need to be aware of potential removal so they can adapt their services, so the earlier they know the better.

gonbatfire: true

> tx_extra is certainly a great vector for evil regulators to exploit, some big oppressive government might arrest anyone who's caught transacting XMR without encoding their ID into tx_extra

I don't really see this as an issue because it's simpler for oppressive countries to just outright ban it

Which they do

Alex|LocalMonero: Yeah I agree that Monero's goal should be money, but still, I trust Monero to be around a lot longer than something like IPFS

Hence why I think people will always be incentivized to store data on it somehow

gonbatfire[m]: My understanding, that using viewkeys don't hurt overall fungibility, careless arbitrary data would

My laymans opinion - if tx_extra is required for payment channels, it should remain. While it's not the savior of scalability, it helps alot.

bit_thanos[m]: A public list of viewkeys does hurt Monero's privacy

gonbatfire: if monero is better at being a database its worse at being a currency; you need to understand that every tiny bit of efficiency needs to be squeezed out of the protocol in order for it to be competitive on the global instant financial market, otherwise someone else will win the competition; if XMR becomes a database like bitcoin is becoming then it is inevitably going to lose that competition

<Alex|LocalMonero> "@Monegro I think that's kinda..." <- That may be intent, yet that's arguably not the effecf

Good point.

And we wouldn't know until it was tried.

IMHO monero shouldn't be ever used for data storage other than transactions. We have problem with size by ring signatures and bulletproofs. I think we shouldn't allow to grow monero more than necessary

gonbatfire[m]: Thanks for clarifying.

Alex|LocalMonero: I really see this as a foolish "what if". Sure, it could happen, but it's not an effective idea and is extremely unlikely

molera: We basically can't stop that. Even if tx_extra is removed, people still encode data in multi-output transactions (and apparently bulletproofs)

Maybe limiting transaction size based on inputs and outputs?

kayabanerve: ok

or they could get in cahoots with a miner (aka block producer) to stuff data in a block

(if there's no tx_extra per tx and its limited to something new in a block header)

my sense is that we can't really prevent people storing data on the chain, but we can protect the fungibility of txs

molera: You run into usability. Plenty of legitimate use has ocassional disributions from one input to multiple parties (outputs)

> That may be intent, yet that's arguably not the effecf

so what's the effect kayabanerve ? That 0.1% of the chain that crypto gymnastics to encode arbitrary stuff will lose out over a competing coin that has a permanent 7.5%-15% global tx fee increase (in case of fixed-size tx_extra) or isn't fungible (in case of optional arbitrary N-sized tx_extra)?

that a chain that has 0.1% of*

<Alex|LocalMonero> "gonbatfire: if monero is..." <- I agree Monero should not persecute to be efficient for data storage, however since data storage is gonna happen in some form anyway, I think we should also look into minimizing the privacy drawbacks of those methods

For example, which method hurts other user's privacy the most?

Other people using tx_extra? Or other people using range proofs to store data?

gonbatfire: that sounds like a separate issue that needs to be fixed, and as pointed out won't exist if/when zk-SNARKs is implemented.

and by the way kayabanerve the foolish what-if is already happening

Hi... (full message at <libera.ems.host/_matrix/media/v3/do…2f70e9c274aa1c02b38c137807cc31c2bc0>)

Can someone help me clear up some terminology? I always thought steganography was used to hide/encrypt data right out in the open. But here it seems like "steg" on a set of "vanity address" outputs encoding data, is readily identifiable. So is the term just being used more loosely than normal?

Or is the data encoded actually difficult to detect in the output and bulletproofs space?

Payment channels networks are not a good scaling solution for Monero.

.... because....?

> Can someone help me clear up some terminology? I always thought steganography was used to hide/encrypt data right out in the open. But here it seems like "steg" on a set of "vanity address" outputs encoding data, is readily identifiable. So is the term just being used more loosely than normal?

Typically, I think they mean here that the data is in no way encrypted so it's out in the open, which means you can find it if you're looking for it, but could also just be a wallet with bad randomness

moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=120 Tang, W., Wang, W., Fanti, G., & Oh, S. (2020). Privacy-utility tradeoffs in routing cryptocurrency over payment channel networks.

"Our results suggest that in practice, PCNs should operate either in the low-privacy or low-utility regime; it is not possible to get large gains in utility by giving up a little privacy, or large gains in privacy by sacrificing a little utility. "

Payment channels are kinda useless, you're basically just doing PayPal with extra steps.

:)

I have not seen any way to do payment channel networks with good privacy.

xmrack[m]: you can send a bunch of dummy zero-amount outputs, then use the onetime addresses and ephemeral pubkeys to record arbitrary data (as long as they are valid curve points, which is trivial to satisfy if you just set the top few bits to zero)

But I don't think you need tx_extra for payment channels anyway

"PayMo does not require any modification of Monero and can be readily used to perform off-chain payments. Notably, transactions in PayMo are identical to standard transactions in Monero, therefore not hampering the coins' fungibility." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=48 Thyagarajan, S. A., Malavolta, G., Schmidt, F., & Schröder, D. (2020) Paymo: Payment channels for Monero.

I tried to read that paper. Just far and away above my level of knowledge.

I think this is the updated version of the PayMo paper: moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=123

Payment channel networks are a series of beads on strings. To move the beads between nodes to make a transaction across the network, you need to know which network nodes own which beads on which strings. That's the privacy issue with them.

Known topology is inherently contradictory to privacy.

I have to head out in a few minutes so I can't wade into a full conversation about payment channels, but I do want to note that I believe privacy-preserving L2's could be very important for Monero in the long run.

The dynamic blocksize is quite brilliant imho, and a very clever solution for handling throughput scalability challenges. But it does not change the fact that Monero's storage requirements scale with ~O(N) the number of txns. L2's allow us to break free of this, important if we want to one day handle transactions on the scale of Visa or something like that

Visa handles ~1800 txs per seconds, Monero can already handle that with current widely-available storage/bandwidth costs.

per second*

Rucknium: Hypothetically, a shared/known topology of a network of payment channels, which arises from an onchain network of solid privacy, should have significant advantages for practical, user-level privacy on the payment network, correct? Or do you not see it that way

?

1800 txs/sec = 155,520,000 txns per day. That'd take my node offline pretty quick, lol

You don't have 48 cores bro?

The Visa comparison is always brought up, but is that the goal? I personally think that Monero transactions will grow alongside the use of CC, not replace them, so I am not convinced the current Visa throughput is a good comparison.

I have 48 cores, but I'd run out of storage

Yeah its kinda the goal of decentralized digital fungible cash, to make visa and other intermediaries obsolete

This isn't to say that they won't exist, just that they're not necessary anymore

Monegro: I agree it's better than the L1 being transparent like BTC. With PCNs on Monero, basically the nodes will start to build a history and become mere pseudonyms over time. Would people want to transact XMR on a layer that doesn't have great privacy? People barely want to transact on BTC's Lightning Network.

Well I think it's more to provide an alternative, not to make them obsolete per se.

They already have alternatives, you can mail people cash for example.

They're just not practical in the global economy.

sure, let me rephrase that then, an alternative with similar benefits and similar latency :-)

Monero nodes can barely handle 100 tx/sec

just watch how fast it syncs and how many transactions are in a block on average

sech1: I see, I must've seen wrong calcs.

It's some bottleneck in Monero code, it just doesn't use all CPU cores

so it can be fixed, but right now it's 100 tx/sec

Because of the dynamic block size optimizing tx space is really important for global scalability, so a fixed-size tx_extra attached to all txs will severely harm Monero's competitiveness as an efficient payment system.

That PayMo paper lists DARPA as a funder.

link.springer.com/chapter/10.1007/978-3-031-17146-8_23

"The work was in part supported by THE DAVID AND LUCILLE PACKARD FOUNDATION - Award #202071730, SRI INTERNATIONAL - Award #53978 / Prime: DEFENSE ADVANCED RESEARCH PROJECTS AGENCY - Award #HR00110C0086 and NATIONAL SCIENCE FOUNDATION - Award #2212746. This work is also partially supported by Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) as part of the Research and Training Group 2475 “Cybercrime and

Forensic Computing” (grant number 393541319/GRK2475/1-2019), and by the grant 442893093, and by the state of Bavaria at the Nuremberg Campus of Technology (NCT). NCT is a research cooperation between the Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU) and the Technische Hochschule Nürnberg Georg Simon Ohm (THN)."

Random thought ... What if we convince WOW to remove their tx_extra and see what happens over there with memes and such? I mean, they're supposed to be the XMR memechain right?

is tx_extra even used on the WOW chain?

Hey, we could restrict our tx_extra to 32 bytes, just a txid for a second transaction on WOW containing the real tx_extra data. Presto, problem solved

+1

brilliant

just caught up on the meeting minutes

special thanks to UkoeHB for his patience and kindness

fluffypony: so what's your view on this?

Alex|LocalMonero: I'm firmly on the "remove" side of this

❤️

I feel like it's cathartic, too

I can relate.

the whole point of us doing hard forks vs. soft forks was to forcefully remove participants who didn't keep pace with development

and don't get me wrong - Bitcoin has different goals and different ways of approaching this

but with privacy as our core tenet, our primary goal, we need to *somewhat* force a degree of compliance

being non-compliant with the protocol puts you at risk, but puts downstream txs at risk too

so the protocol needs to have a reasonable level of enforcement in favour of our goal of "pretty solid privacy-by-default for as many people as possible"

culling tx_extra is in favour of that goal, so I support it

right, we're trying to eliminiate the possibility of other users' mistakes harming your own privacy

and, as has been pointed out before, we can utilise other (more fiddly) bits of the tx format to stuff random data if we need to for some future purpose

tx_extra is just lazy

OH!! Hazy memory from a few years ago...

Isn't there some extra room for data in bulletproofs? I think it was on the scale of tens of bytes, maybe enough to fit an address and some efficiently-coded instructions?

That'd be best of all worlds - indistinguishable to a non-involved party, but can be decoded by the recipient's keys

isthmus: yes - I alluded to that on GitHub, we can stuff data into range proofs *and* into tx output addresses

Ooh nice I missed that

there was a lot of room in original rangeproofs. I thought bulletproofs axed most of the deadweight

?

tx_extra is just the lowest common denominator because you don't need to do anything to use it

I vaguely remember somebody found something which makes that pretty infeasible, or at least quite hard

hyc: yes it does, but there's still some gaps

isthmus: yes, it's possible to encode 31 bytes in the range proof, but the drawback is that this reveals the change amount to the recipient.

^^

Ah that's unfortunate

Not a great tradeoff

also I'd like to add that removing tx_extra doesn't mean we can't add stuff in future

if payment channels or whatever need something in future it can get its own dedicated field

Hmmm ... just need 3 years to reach consensus about what and how to add :)

that is content-restricted, space-limited, and every tx has it

lol rbrunner

I'll take that over a free-form field that anyone can abuse

Yup, through a hard fork.

Not through self-segregated unfungible soft forks

So with a bit of bad luck we will have a completely mysterious and fully inexplicable rise of transactions with 5 and 6 outputs after we get rid of tx_extra.

Which won't stick out at all, and be no privacy problem :)

Pretty much all enterprise applications that utilize Monero will have more than two outputs rbrunner

Anything like Serai won't stand out that much

Do they, yeah? Whatever. Everything has trade-offs.

~95% of transactions have 2 outputs, everything else stands out. We just pretend it's OK.

This reminds me a bit of attempts of getting a fully clean society by putting 20 years of prison on merely carring 1 gram of drugs.

Net result is *not* elimination of drug addiction, but just pressing it underground. With quite some consequences.

Can't it remind you of attempts to cure cancer?

Exchanges, centralized mining pools transactions for example usually have more than 2 outputs

Cancer?

Zcash set low flat tx fees because a powerful adversary could spam the chain regardless of the fee level. That reasoning is technically correct, but their decision lowered the barrier to spam attack. Removing Monero's tx_extra would raise the barrier to arbitrary data on chain.

classic ZCash logic :)

tevador: by the way do you envision a solution for batching withdrawals for exchanges and the like without using more than two outputs?

"Speaking for myself: I think fee policy cannot be a particularly effective anti-DoS measure. Fees would have to be too high (for normal usage) in order to work for that purpose. Fee policy could potentially help to some extent to buffer spikes in demand due to organic usage. For now, I think that the changes in v5.1.0 are likely to be sufficient to address any short-term performance problems with current transaction load."

lol xfedex[m]

tevador: we could enforce 2 outputs at a protocol level and make them spread it over multiple txs, and maybe that's where we land if uniformity is the goal

If we want indistinguishability, we can't have batched transactions. Eliminating the 10-block lock would help.

but I don't think it's a today concern - let's focus the cat-and-mouse game on what is important today

tevador: that's a good point, the 10-block-lock is the real problem for transaction batchers.

yeah chained txs are a win there for sure

Average outputs per transaction are about 2.5. You can use monero-blockchain-stats to see it

The 10-block-lock is itself also a contributor to unnecessary bloat for people that are generating outputs for themselves.

from* people

Wownero might remove transfer_split and limit non-coinbase transactions to 2 output in the next hardfork, as an effort to annoy centralized mining pools

fluffypony: Maybe enforce 4/8/16 ?

nikg83[m]: yeah tons of options, but definitely a tomorrow problem!

nikg83[m]: I don't think that would be actually useful

Anything more than 2 outputs would just bloat the chain the slow down wallet sync.

I just realized that I never voiced my position on the debacle. I am in favor of option (1) to remove tx_extra in favor of transaction uniformity

🥂

Hopefully it can be settled next week.

Fee policy is the only practical tool to deter spam, DDOS etc on a privacy network where all the txs are designed as much as possible to look alike

tevador: 2 outputs and batched transfers would handicap many usecases

I think it would be better to discourage the user from creating transactions greater 2 outputs, like the this-is-probably-a-spy-node option

* creating transactions with greater 2

The disadvantage an attacker has is the need for volume to have an impact.

a 16-out transaction costs about double the fees of a 2-out tx. But allows attackers to create 8x as many poisoned outputs.

What about bumping up fees for "non standard" transactions like 16-out ones?

tevador: that's a good point

tevador: True in theory. 2-outs was used in the only documented case of an apparent flood incident: mitchellpkt.medium.com/fingerprinti…ero-transaction-volume-a19cbf41ce60

Maybe it will be different "next time"

Rucknium[m]: but if it's cheaper to create 16-output txs and an attacker wants to Sybil then that makes more sense

if they just want to flood then 2-output txs make sense

<xfedex[m]> "Wownero might remove transfer_sp..." <- Would this affect p2pool payouts?

It's true that flooding with 2-out txs has a lower chance of being detected.

xmrack[m]: No, because the limit is just for non-coinbase transactions; p2pool pays out miners using coinbase transactions.

p2pool uses coinbase

It would only affect centralized mining pools

but how many poisoned outputs are needs for a viable flooding attack?

Increasing the ring size is the answer here

Understood, thank you

Poisoned outputs can be a problems especially because of light wallet such as MyMonero. I don't exactly know how many transactions MyMonero handles, but I guess it's a lot.

I am for reducing the total number of anonymity sets; however I am far from convinced that having just one is optimal from the perspective of privacy

For example we can reduce the possible number of outputs to just 2,4,8,16 or even 2,4,16

I much rather have a handful of large anonymity sets than just one small one. So we have to balance this with usability, efficiency adoption etc.

<tevador> "a 16-out transaction costs about..." <- What is the computational cost for each additional output from the context of a node? Linear?

The 16 out tx is prive to balance the computation cost with the space savings

priced

That is why weights were introduced

FWIW, I am less concerned about wallets/users that occasionally create stand-out txs (e.g. w/more than 2 outputs) than I am about users/wallets that always do the stand-out thing. Wallets doing stand-out things is the basis for a lot of tracing in bitcoin.

arxiv.org/abs/2107.05749 Möser and Narayanan (2022) "Resurrecting Address Clustering in Bitcoin"

if anyone is "always" doing that, they're intentionally shooting themselves in the foot

Yes, I think a good first step would be to have a limited set of transaction shapes, e.g. #inputs = { 1, 2, 4, 8, 16, 32, 64 }, #outputs = { 2, 4, 8, 16 }.

"We’ve compiled and evaluate a set of 26 [BTC] change address heuristics based on previous literature and community resources. Most heuristics individually produce few false positives at low to medium true positive rates."

i have posted about this issue online multiple times over the past few years and we have some discussion threads on github too

limiting txn inputs will interfere with e.g. sweep_all

Seraphis will already impose a limit of 112 inputs per tx

yeah limiting inputs like that would make input selection way harder

tevador wouldn't constraining the number of inputs to a fixed set of possible numbers lead to usuability issues, forcing churning before a spend?

By the way a lot of tracing on Bitcoin actually does not work. There is a big difference between the marketing claims of the blockchain surveillance (BS) companies and reality.

if only we cared to invite the academics working on this stuff :)

yes, it could cause some issues in a tiny fraction of cases

MAGIC Monero Fund directly reached out to a few academic researchers who have shown an interest in the Monero ecosystem. We haven't gotten any grant applications yet.

ignoring fees, if i have 10 outputs of 0.1 and want to send 1 monero, this is a trivial 10 in 2 out tx. now you must send-to-self outputs until you have 2 that combined = 1 :(

There is a big difference between legitimate scientific research and marketing BS when it comes to tracing transaction on any chain

well i have gotten offers of free involvement, Rucknium[m]. but what message do they get when we indicate we wont benefit from them?

that is what they have been told both directly and indirectly by us

I am all for inviting and encouraging the legitimate scientific research. As for the marketing BS this belongs in the courts not here

monero will be a footnote if we dont take our blinders off

research continues quickly elsewhere

endogenic: are you ok?

what blinders do we have on?

tell me hyc what are the latest advances in research on the techniques monero could apply for solving these problems? past 2 years or so?

anyone?

no. i'm not okay.

A lot of trustless zk-SNARKS that are not battle-tested.

and still a lot more resource-intensive than our stuff

Or even have formal peer review

and probably infested with govt backdoors...

what is that belief that academic research is on the forefront of every subject? There is a balance to have between fundamental research and hands on implementations, neither side can be blindly trusted

nothing to do with snarks guys

I belive we are on the right track here with Seraphis and 128+ ring sizes

<tevador> "Yes, I think a good first step..." <- By the way, could powers of two number of outputs pose a benefit for verification/batching?

that doesnt solve a variety of fingerprintability causes

Seraphis actually solves many fingerprintability issues, e.g. with discretized fees, fixed number of pubkeys, (possible) removal of tx_extra etc.

hbs[m]: the sort of research i'm talking about has only begun here *today* apparently aside from my past few years of suggestions. so it doesnt count if we dont consider the problems important enough to research

tevador: P.S. Plus decoy selection enforcement possibly. (I know some people are against that)

today? you mean this discussion of how to keep txns uniform, that has been a constant theme for the past N years?\

that's obviously not it. please stop sabotaging the discussion

or is it you who doesnt understand the difference ?

hyc

We are talking of trust-less zk-SNARKs? Is there something that is competitive from a verification time and size perspective?

We carefully avoid to make any too specific statements, that way the "discussion" would be over too soon ...

Yes: monero-project/research-lab #100#issuecomment-1423154798

endogenic: sounds to me like you're the one trolling here. There are no easy answers, all of them have been taken already.

lol rbrunner with that wit again

Thanks I will take a look

every suggested change has tradeoffs that will affect usability

dont want to join that heated discussion, and it is not realy a zk-SNARK, but from what i understand Curve Trees could work for a global anonymity set

endogenic: is referring to mandating a fixed number of tx inputs and outputs, and also some payment channel research that Mr. Moreno-Sanchez has done (that has not received too much attention since sarang stepped away).

pedro has done a lot more than that

you can hardly categorize all relevant academic work that way

atomfried[m]: yes, Curve Trees are mentioned in the discussion I linked.

and. there are other researchers

dblp.org/pid/128/4640.html payment channels, swaps, and related is what I see

yes. related.

Not sure why I am your spokesman endogenic, you are an adult who happens to be older than me by numerous years.

good question

i also have been writing software for about ... 25 years

but ignore me

it's ok

the point is, speak clearly and directly and don't waste everyone's time

i hVe

stop wasting my life

The world of Open Source is not about seniority or academic track record, it's above all about contributing in a collaborative and constructive way

this isnt an open source project anymore

wool pulled over y'all's eyes

wool is more comfy than tin foil

I've met countless people who tried to impose their views not by the quality of their contributions, however small they are, but by external metrics, that never ended well

good talk, folks. guess it's over.

<tevador> "Yes, I think a good first step..." <- Enforcing a limit on the amount of inputs can cause situations, where the user can't spend more that ≈50% of their balance at once (2^n-1 equally valued coins in their wallet, n→∞). Bad ux imho, as users shouldn't have to know how the protocol works on a technical level in order to use Monero.

I've been advocating for dummy inputs, which would solve this problem: monero-project/research-lab #96

tevador👍

tevador: in the dummy inputs issue I asked if they would solve the 10-block-lock problem, what do you think?

<endogenic> "this isnt an open source project..." <- Are there any pull requests pending from you ?