<jtgrassie> "By keeping the field but size..." <- If the size is fixed then every user will be paying for tx_extra regardless if they're using it or not, which means that, say, 99% of honest users are paying more fees due to 1% non-financial usage. If the size is not fixed and can be zero then you end up breaking fungibility. Both scenarios also lead to bitcoinization.

<politicalweasel[> "Preventing steg is impossible..." <- You don't need to make steg impossible, you only need to make it impractical.

tx chaining is independent from the 10 block lock

Alex|LocalMonero: yes, which is why i favor B2/3 over B4

Alex | LocalMonero | AgoraDesk: It's not "breaking" fungibility, for the reasons already mentioned. Besides, things like Ordinals dox their own relevant tx's anyway so they're identifiable regardless. You can't prevent people from degrading their own privacy if they really want to, and trying to shoot them down will just be an endless cat-and-mouse where bystanders are caught in the crossfire. Restricting to 2 outputs is

another example of this. All it does is hurt UX and needlessly bloat the chain, meanwhile spammers just make use of chained transactions. Or maybe their protocol uses self-sends anyway, so it doesn't even affect them. You say that these speed bumps will discourage abuse but... no, it won't.

Someone correctly pointed out earlier that these minor annoyances are just one library away from being easily defeated. And, again, if someone is going through the trouble of creating a new app or whatever in the first place, they'll probably accept the 5 minutes it takes to bypass all of these limits. Preventing spam will be a never ending witch hunt of removing functionality when we could just define a way to do it

which causes the least damage.

Like bitcoin

Looks like a lovely blockchain right now. So many real tx /s

politicalweasel[: stopping people ruining their own privacy is different to users degrading others privacy

that's why tx uniformity is important

How? If those real tx are being exposed to the public as fake

yes, but part of my argument is that the improvement to tx uniformity is negligible in practice and outweighed by the damage caused by output spam

Uh. Look at btc and tell me more out output spam

What about it?

I still don't get the point

ofrnxmr[m]: because it's not the odd individual here, its a protocol being aiming to mass (ab)use the Monero blockchain

Serai uses Txextra and posts view keys

which I also think is harmful

Nfts use Txextra and will do the same

again, which I think is harmful

Output spam? Without full membership proof these use cases are useless

If someone wants to steal my car, they will do it. So ill just leave it unlocked with the keys in the ignition so that they can borrow it instead

That way, they wont break my window.

that's not an accurate analogy, the point is that removing tx_extra doesn't actually solve the problem while making the damage worse.

That is exactly what I daid

Txextra is lending my car to strangers

But removing it is doing the same. There's no meaningful difference

Disabling it doesnt stop people from stealing it. They can steal and damage my car whether I leave the keys or not

unless having the keys to a car

unlike*

If someone wants to steal my car to go do burnouts, theyre going to do it.

Im not offering my car for purposes that damage it

Output spam is mitigated by simply limiting the number of outputs. With tx chaining this limit won't even matter it would seem. Keeping tx_extra only reduces output spam under a very specific circumstance that there's no limit on outputs and the degraded data storage efficiency burden is economically feasible to overcome to make your app competitive in the market. These are very tough conditions to satisfy. So keeping

tx_extra only eliminates a narrow "honest" subset arbitrary-data-injecting of output spammers, while doing absolutely nothing to mitigate malicious actors (the security assumption) and contributing to a permanent degradation of fungibility as well as bitcoinization on top of that.

The "cure" that jtgrassie and co are proposing seem to be not only worse than the disease but also don't even cure the disease.

I'm not suggesting a "cure", merely steps that can be taken to mitigate the issue

Step 1 remove

Step 2 membership proof

Step 3 revisit

Step 1 incentivize

Step 2 panic

Step 3 membership proof

Because Alex, even restricting to only 2-outs and no tx-extra, still doesn't "cure" the issue

Bad outputs arent as big of an issue if real tx volume was higher, or the decoy selection also was better, or if we excluded coinbase from ringmember etc

Alex | LocalMonero | AgoraDesk: "With tx chaining this limit won't even matter it would seem" ... thus it doesn't matter for output spammers either. If you can limit outputs while relying on chaining to maintain a good UX for users, then the same is true of spammers.

Again, you're underestimating the money people are willing to waste. Ordinals spammers are already paying tens of dollars just for the meme. And Monero fees are astronomically cheaper.

And yes ofrnxmr, a full membership proof certainly more desirable, but that's some way away

jtgrassie: Correct. But it maximizes transaction uniformity, fungibility, disincentivizes arbitrary data storage to the greatest possible extent, and mitigates bitcoinization.

ofrnxmr[m]: not if the enote set must still be scanned by nodes to verify a transaction, and/or if they cannot be pruned.

which may be the case of full-membership proofs, to be fair, but I don't know enough to speak on that

or NOT be the case, rather

Alex|LocalMonero: yes, but it's downsides are no more batching

Im saying high tx volume + large blocks + nfts might not be bad.

Low tx volume = spam outputs

and the car analogy still doesn't work. The car is getting stolen anyway, tx_extra or not. Giving the keys has no effect.

Itbdoes have an effect

Leaving the keys = for some reason my tires wear a lot faster

Probably because im offering free wheels to whoever wants it

you still havent addressed the fact that removing tx_extra solves nothing

and isntead of "keys" it's more accurate to say you get to choose between them using a bazooka or a baton to get into your car

Everybody knows you can steal a car. Only bad actors do it

If you have access to borrow a car, you will do that.

The demographic of borrowers and thiefs are not the same

Thieves

> <@politicalweasel:matrix.org> Alex | LocalMonero | AgoraDesk: "With tx chaining this limit won't even matter it would seem" ... thus it doesn't matter for output spammers either. If you can limit outputs while relying on chaining to maintain a good UX for users, then the same is true of spammers... (full message at <libera.ems.host/_matrix/media/v3/do…0e3febf28d8cb64b00cdb36bdf3b3d854ec>)

jtgrassie: With tx chaining you have what is essentially batching. Ask tevador

Will someone who wanted to borrow your car just steal it if you dont offer the keys? Sure. But we call that a wrench attack

Thats not a friend who wants to borrow a car, thats a thief. Thats not someone who wanted to use your car for valid purposes, its someone who doesnt care about you or your car

Alex|LocalMonero: chaining doesn't achieve quite the same thing as batching. Presently batching allows paying 16 different people in a single tx

chaining doesn't do that

It kinda does, though. Albeit slightly less efficiently, depending on the actual implementation.

yes I understand that, but it's more costly, so hurts honest users

Alex | LocalMonero | AgoraDesk: 1. Then you do 1 steg per tx, each being a self-send. Simple. 2. I'm not convinced it's that much of a cost difference, though maybe I'm wrong. Also we're talking more like 10 cents vs 30 cents, if anything. Unless you're okay with "bitcoinization" where simple transactions cost 10's of dollars. Output spam also has a higher cost to the *network*, which isn't factored in with raw tx fees to

the spammer

steg is actually quite limited currently, due to the output count restriction

jtgrassie: the overwhelming majority of users will not be batching transactions, see how few txs there are with more than 2 outputs

sure I get that, but exchanges and pools are still honest users

ofrnxmr: but again you're not "giving the keys". It makes it sound as if theres a sort of solid moral reason to object in defense of your property rights, when there's not. with tx_extra, you're not giving keys, you're either giving them or a baton or they'll use their bazooka regardless. There's no getting around it

No. You're giving them keys. You're inviting usage

jtgrassie: Not really. Current RingCT steg could do more than B3 would provide, easily.

(256 bytes)

You're saying "heres 256bytes. Go wild"

but the "keys" of tx_extra don't open the car. They can get in with their own "universal remote"

jtgrassie: As a representative of a business that batches our withdrawals, but also as someone who wants Monero to be the best it can be with maximum fungibility and tx uniformity, I can say that we can easily shoulder the slight increase in fee for the fungibility/privacy benefit that all our users will get when there's tx chaining that their outputs no longer standout as being part of a batched transfer most likely done

by a pool/exchange/trading_platform.

politicalweasel[: "could do more than B3 would provide, easily"<- depends on size of B3

politicalweasel[: Called breaking the window and hotwiring it

true

uh no

Alex|LocalMonero: indeed, which is why I do not disregard your comments

* true (to jtgrassie )

Yes. Steg = breaking the window

And taking the car anyway

Just with a bit more work and damage

And more importantly, demographic

ofrnxmr[m]: ^^^The part that seems to go over everyones heads

jtgrassie: It was very costly for us to switch from integrated addresses to subaddresses (when we launched subaddresses didn't exist) but we did so to maximize our users' privacy by preventing off-chain linking. Assuming we have tx chaining available to us, it becomes realistic to process our withdrawals in a way that every user's withdrawal tx looks exactly the same as any other tx and doesn't stand out like batched

withdrawals do on the network.

And because of Txextra, exchanges can still opt to say eff subaddresses and use integrated addresses

ofrnxmr: You still haven't defined the actual real difference as it applies to Monero. We can argue back and forth about analogies all day, which is what we're already doing. Unless you can make a legitimate logical case against tx_extra then I have to assume you're arguing emotionally, which ironically is what you were accusing me of doing earlier

Politicslweasel its hard to talk to you because you dont seem to understand what youre trying to speak on

Alex|LocalMonero: yes I'm aware, again, reasons why I don't disregard your comments

Which is why everyone turns to metaphors

ofrnxmr[m]: tx_extra is, like, miners adding extra transactions, right? /s

Alex|LocalMonero: so you're strongly in favor of 2-outs and removal of tx_extra?

Yup.

seriously though if you can't address me then that's not my fault

2-outs assuming there's tx chaining.

Alex|LocalMonero: I don't think you need the chaining caveat, as code can create batches of txs

If I say it isnt your fault, I would be insulating you intentionally. So ill just leave it at that. You said it, not me.

Enforcing 2 outputs just turns one transaction into several. this is true of both spammers and regular users

yes, but it does limit the effectiveness of steg for things like inscriptions

unless there's an argument that enforcing 2 outputs itself, outside of this whole discussion of spam, has a significant impact on fungibilty.

jtgrassie: not really, just draws them out. On-chain jpeg inscriptions wouldn't practically fit on Monero regardless, whether we do A or B3.

unless B3 has a very high size

<jtgrassie> "Alex | LocalMonero | AgoraDesk..." <- Unfortunately due to the 10-block-lock it's a big risk that if you create batches of txs you'll run out of outputs and users will need to wait 20 minutes.

I managed to build morbius, this is what I did:... (full message at <libera.ems.host/_matrix/media/v3/do…c6f2dd7911801a59aa28bf233c8a6a56094>)

Nfts coming asap

Ill let them know about the 256byte limit so that can efficiently spam the network

Them meaning us

If its going to be supported, im not cancelling anybody who wants to use it for whatever they choose within morals and law

If monero is intended to be used to burn outputs for nfts, so be it

you're now clearly arguing emotionally. I keep making the point that removing tx_extra doesn't actually solve anything, but you're pretending that I'm "a monster who supports mordinals"

Im not

You think im joking?

There are other conversations going on as we speak yknow

People arent trying to build the software because they are emotional. They are trying to build it because, afaic its a community project

Or a part of our ecosystem, and the code seems to be available.

Emotional is boycotting them. Were just embracing the fact that we ignored nfts for years because we wanted monero to be pure

<politicalweasel[> "you're now clearly arguing..." <- Why would removing tx extra still not stop NFTs on the chain? I want to understand why was it such a difficult discussion in the first place in 2020

No to technical, but like I’m 5 haha seem like in the other chat it’s a complex discussion with many pov, 3 years worth of consideration

XMR Priest: long story short, they would be put into outputs instead which causes even MORE damage than using tx_extra. Of course I recommend that you read the entire discussion over the past several days but I know it's long and boring and technical so I don't blame you if you don't want to

I see, is there no way to avoid them putting them in the outputs and can’t they do that right now if they really wanted too

there are many complex arguments for and against removal, but I'm against removing

And thank you, yea I was scrolling through and didn’t know where it started haha but I’ll give it a shot

How about limiting to a smaller amount

Of space possible to put in the chain

XMRPriest[m]: no they could do it now, but they currently have tx_extra instead so they don't have to

Makes sense, is there no way to avoid or prevent usage of outputs other then transaction amounts ?

Yes, the pro-tx_extra crowd (including me) most favor restricting to 256 bytes.

no, there's no way around it

* "I see, is there no way to avoid them putting them in the outputs and can’t they do that right now if they really wanted too" Yes, the pro-tx\_extra crowd (including me) most favor restricting to 256 bytes.

* "How about limiting to a smaller amount" Yes, the pro-tx\_extra crowd (including me) most favor restricting to 256 bytes.

politicalweasel[: Why is that ?

Txextra uses outputs. Smh

Guess it seems like picking the least worse situation

because there simply isn't a foolproof way to detect it. It can theoretically mitigated but not actually prevented

Its just ON instead of IN

ofrnxmr[m]: tx_extra is transaction-wide

not tied to a specific output

you cant use Txextra without generating a tx

yes

Is there better privacy if they put them in the output then the tx extra ?

Im frustrated

Since the output would mimic a normal transaction ?

Or would it fuck things up more

XMRPriest[m]: that's part of the argument

Yea I think it comes down to how do both rings look during chain analysis a NFT in tx extra or output and which one maintains privacy

ofrnxmr[m]: we all are. we all want what's best for Monero and the lack of agreement is frustrating to everyone

Im frustrated because of typing

A real meeting this is an easy deal

Bunch of noise and I feel bad for everyone involved

Hard to explain stuff in a format like this

I’m just mad that this is something we can’t prevent or stop but need to deal with

Only trolls and threats want NFTs on monero and we can’t do anything about it

Noooo

Supported feature, EFF off

i know its apples and oranges, but the "stuffing data on-chain is inevitable so we might as well" feels similar to "ASICs are inevitable, so we might as well". again, there are obvious, *obvious* differences, but it just makes me ponder if something clever just hasn't been imagined yet

<BawdyAnarchist[m> "We have Kaya here telling us..." <- What happens in a scenario where Kaya uses his abilities to build Serai and use steg. We can't stop Kaya from doing this unless we remove both tx-extra and the ability to peform steg by smart people like Kaya, which seems difficult to remove both of these in practice. But then no-one uses Serai. The ouput set will suffer minimal damage. I can see a world where even

if Kaya builds Serai, people don't use it because they avoid UTXO's of any chain like the plague and only transact with physical objects or encrypted blobs (Monero outputs). All UTXO chains gradually fall to zero as the market finds out the value of privacy. This hasn't happened yet and empirically UTXO chains have done well because many individuals don't understand the cost of giving up their privacy assuming that they

are compliant with all rules and regulations and thus have nothing to hide. I think the days of people enjoying their material and financial resources as they see fit while they are known to a variety of indebted adversarial thiefs are numbered, and so are the days of high market caps for UTXO chains

<ofrnxmr[m]> "Just because we arent being..." <- This is the root of the issue.

<Alex|LocalMonero> "Monero is here for one reason..." <- Agree. That's why I wonder in a future environment where all banks accs and UTXO coins are captured (taxed into oblivion) why there would need to be a liquid market for either of these things. Now if the gov is somehow able to remove green pieces of paper from circulation and physical cash is no longer the most marketable currency, then perhaps Serai will have a use

for moving from UTXO currencies to Monero. Having liquidity for bank dollars to xmr will become moot as banks will just begin seizing assets if they think you are suspicious, aka you interact with Monero

<BawdyAnarchist[m> "The group of people who aren't..." <- Who would use Serai? Nobody currently needs a UTXO chain currency or bank dollars in our current society. If you can readily convert back in forth between green pieces of paper (these can even be deposited at banks for utilities) and Monero (you can transact with anyone online in a private, anonymous, cheap, censorship resistant, fast manner), then you don't need

any other currency - or liqudity for them. If green pieces of paper are somehow recalled by the gubermint, then the need for people to flow from taxed compliant currencies to Monero and back becomes real and maybe then Serai would have users.

<BawdyAnarchist[m> "If you incentivize them to act..." <- Then so be it. The question is whether the service they construct will have utility in the market place. If it does then it will hurt privacy to some extent, but it's better than tx_extra IMO currently. If individuals in the market don't need Serai or use it, then it won't hurt privacy via steg

<ofrnxmr[m]> "That* is essential" <- Good point. All that is essential is people can convert effcevtively from physical fiat to Monero and back. Because my argument is that physical fiat can be used to pay for anything, even if it must be deposited at a bank to pay a utility company who doesn't have an office nearby where you can pay cash.

<kayabanerve[m]> "> <@kayabanerve:matrix.org..." <- How? Monero without tx extra as a stand alone system works perfectly fine without tx extra. Tx_extra doesn't improve Monero's decentralization in any way that I'm aware of.

Enabling another form of decentralized on/off ramp? I said improves, not is necessary.

Just read the rest of your comments and I now realize it probably wasn't meaningful to chime in. I'm going to sleep. Bye.

It would seem to me that kaya and others who are advocating for a fixed-size but prunable tx_extra are actually hurting decentralization, perhaps even to a significant extent, because the majority of node operators won't want to be free decentralized storage/database platform for applications, and hence most will want to set their node into "prune tx_extra" mode, leaving the full node operators (which are necessary for

chain integrity) as a small subset of the total running nodes.

And, of course, you can't have the default node setting to be pruned mode because that would mean that you're pushing software that's centralizing by default. So you'll end up in a situation where for the majority of people the default config is suboptimal and you increase the complexity for the node running person as they have to read the docs and understand that they want to set that option, which, to me, seems like bad

design because sane defaults are defaults that should fit the most amount of people with no extra configuration.

<gingeropolous> "i know its apples and oranges..." <- I get the exact same vibe from this issue.

<Alex|LocalMonero> "It would seem to me that kaya..." <- You are definitely right, we should’nt let a start up project threaten or dictate the full direction of monero development IMHO and threats to use other ways to hurt the network is even less warranted and shouldn’t be tolerated

You guys should take a break from this topic for a while, it’s taking on a toxic atmosphere that does not belong in this channel.

agreed. i think it might not even be a research related thing at this point.

Its multiple choice

I said to plowsof that it seems we all forgot about lounge

#monero-research-lounge:monero.social for those unaware

Alex | LocalMonero | AgoraDesk: dang, wanted to ping u on the lounge thingy instead but u not there :/, anyways, so like, regarding your argument about pruned nodes, i just remember reading a long while ago that technically the network would still be in a healthy state even if ran with only pruned nodes, not sure how accurate that is but that was coming from mrl people so like.. /shrugs

also last month on that mrl meeting, the question that was being voted on was regarding the tx_extra but maybe the right question would have been how to prevent mordinals instead of focusing on that tx_extra which according to the discussion, removing it wouldnt prevent them anyways so maybe just figure other ways instead, idk

Has output scanning being variable time ever been discussed from a privacy standpoint?

Yes.

I remember some changes to mitigate what a remote adversary could learn, but it is mitigation.

I do not remember talk about local attacks.

Seems to be more relevant to hardware wallets, and those might be using constant time ?

Yeah, I'm curious about with regards to remote nodes.

Have a link to any issues/PRs?

I'll look for the one I remember.

d5472bd87b8e93706295d8aa7ff99e5ad594277d, though from the commit message it seems like a weak leak. I'm vaguely certain (quite an interesting wording there) there's more to find, but that's the one I remember.

Maybe googling the name in the commit message will get you more meat.

And well, this was just about human delay, which isn't what you asked. I did not remember this when I first replied :)

kayabanerve: Not in detail, but: libera.monerologs.net/monero-research-lab/20221214#c177149

Rucknium: Yeah, exact same Q

I may add a constant time scanner to my work for the paranoid

Regarding tx chaining, is it reasonable to say the biggest benefits from this are to users who are starting with 1 output, and wish to pay >15 recipients in the same block, assuming we maintain the 16 per-tx output limit? And after all those new outputs are made, they're still locked for the 10 block lock limit? And I assume chaining will create inputs that stand out as a different class of inputs because they have no history?

tevador: UkoeHB ^

sgp: TX chaining has no relevancy to the 10-block lock nor will they appear distinct on chain.

The Seraphis membership proof outputs a key, which then needs a proof of its linking tag's accuracy + ownership.

TX chaining is premised on the ability to decide outputs, and create a spend for a given enote creating those outputs, without having created the membership proof yet.

So a chained TX will later have a membership proof created, and because the membership proof is created after the fact, it can select from the full output pool for its decoys.

(90% sure, get someone else to confirm)

Is the reason the real input doesn't appear as the clear spend because decoys are selected normally that are <10 blocks old? I don't fully follow that part

> Combining these yields ‘transaction chaining by delegation’, where the author of transaction B authorizes the transfer of funds from an e-note that doesn’t exist in the chain, then gives their partial transaction (without a membership proof) to the author of transaction A (which creates that e-note), who can complete transaction B and submit it after they have completed and submitted transaction A.

Whoever creates the membership proof knows the real spend. On-chain, you can't tell a chained TX from a non-chained TX.

*That's from the Seraphis paper and confirm what I'm saying.

Are transaction A and B in different blocks?

Yes. Transaction B is published after transaction A is on a block and after any 10-block lock occurs. Then, B has its membership proof created, and is published on chain.

Okay, thank you. Sorry, I had a very different perception of the benefits of this based on how this was described to me

Seraphis 1.3 and 4.8

the main benefit is atomic swaps and multisig