I want serai to work but not mordinals

ceetee[m]: both subaddresses and payment IDs are more-than-reasonable current uses of the tx_extra

Don't those things now have their own fields?

No

They will have specific fields in seraphis, but look a bit different than they do now thanks to a lot of refinement.

so removing tx_extra now would break both subadresses and payment ids?

yes

well, it would break all balance recovery since the tx pubkey for normal addresses is also stored there

Break > change

ofrnxmr[m]: only if new fields are added

Right

If we change the tx_extra field (either A or B3), we could add new fields

Removing without adding properly used fields for the data currently contained there isnt an option id ever imagine

ceetee[m]: the tx_extra debate is about how it will look in seraphis, there hasn't been much enthusiasm for updating the current protocol

Well then its even less of a question

my point is, without the tx_extra it's not a guarantee we'd have subaddresses right now

I don't question the historic relevance at all

but think the current state of XMR is advance enough that we know much better where we are going

Compared to a few years ago

that is very optimistic

If the question were what is more likely: we desperate need txextra for a feature or txextra will be abused for some bs, I'd bet on the second option

I think some people in this conversation are forgetting what exactly tx_extra is. We're not talking about smart contracts or even bitcoin-style scripting, instead just some arbitrary bytes. There is no additional functionality added to Monero by it, except for things like subaddresses which... (full message at <libera.ems.host/_matrix/media/v3/do…62e7b153e7e53e8ef4f560dd5650e46cf3e>)

<ceetee[m]> "If the question were what is..." <- And even if it *just* isn't abused for some BS, for example, even if there are developers making actually useful wallets that give additional features to their users assuming other users also use the same wallets, all this creates a plethora of mutually incompatible subecosystems, with the complexity and incompatibility only increasing over time.

This is the current state of the Bitcoin ecosystem.

But does removing tx_extra actually solve this? They'd just stuff outputs instead, which is way more harmful to us than a dedicated field

politicalweasel[: It doesn't solve this but it closes one of the doors that allows this.

And the outputs door is much less efficient to use, which naturally disincentivizes it.

A lot of use cases would only need 32 bytes anyway, as a commitment. And you're underestimating how much people will pay to do useless shit - loot at ordinals

look*

And also it worsens the senders privacy, if I understood correctly, so users are disincentivised to uses services that need bit stuffing

ceetee[m]: Correct, unless there's full range proofs, as per kayabanerve

People don't care. And it worsens privacy for everyone, ie those using the bloat outputs as decoys, not just the sender.

*membership proofs, not range proofs.

politicalweasel[: You're right but having tx_extra doesn't eliminate this issue.

It merely diverts most of the honest actors not to exploit it.

and how is that not a good thing? and what's the disadvantage of keeping it?

If you enable easy arbitrary data storage you enable not just use but abuse, as ceetee🇧🇪 alluded to. We have no way to predict how an arbitrary data field will be used, what sort of subchains and subecosystems will develop. Look at Bitcoin right now with hundreds of BIPs, incompatible wallets, multisigs, addresses, someone's stuffing NFTs, someone's mixing, others are rejecting those who are mixing etc etc.

I feel like Monero should be as narrowly-defined as possible, the protocol as strict and efficient as possible, for one purpose: decentralized, electronic, fungible (private) digital cash.

Bitcoin's situation is a product of refusal to do a proper (hard fork) update to clean itself up. And again, data storage is still possible without tx_extra. They'll just choose to do it in a way which is much more expensive to the network as a whole.

tx_extra doesn't expand Monero's functionality. It only makes it more extendable. Both for spam and legitimate uses which we don't know of yet. In both cases removal will either result in output spam or holding Monero back from its potential. Relying on Core to hard fork every possible use case into Monero is not a desirable future

To make an analogy, if you have two leaks in your boat you wouldn't make an argument that closing one leak is pointless because there's another leak, right? I understand that there doesn't exist a solution for the outputs exploit at the moment, but I haven't seen proof one way or the other that this is a solvable/unsolvable issue.

Point is, you're making an argument from is, not from ought. I'm making an argument from ought.

Tx_extra is a big but easily pluggable leak of arbitrary data. The outputs exploit is a much smaller leak, but more difficult to plug as well.

<politicalweasel[> "Bitcoin's situation is a product..." <- WE are also refusing to clean up. I was surprised that the data for sub addresses and payment ides don't have their own fields yet, and are still in the tx extra. We should sort that out

ceetee[m]: I believe that this is implied in the seraphis upgrade assuming tx_extra is removed. Right UkoeHB ?

I could use the boat analogy back on you. Attackers can still spam regardless (a leak), but honest users would be forced to spam w/o tx_extra (a leak). You've been arguing that patching the latter doesn't have merit.

We can't force users to use Monero in the way we strictly define. Regardless that's arguably not even a good idea in the first place. Arbitrary data storage will always be possible. And I still don't understand why tx_extra is anywhere near as bad as output spam.

ceetee[m]: fair enough, those should have been given their own fields long ago

They dont, because of Txextra. Its like a junk drawer. Allows laziness

if Monero's dev team is lazy to the extent that it's legitimately causing harm to Monero, then that's not something which will be fixed by removal. besides it's not that "lazy", there just isn't a real reason to "fix" that which would frankly be a waste of dev power which coud've been used elsewhere. Doing it when we overhaul the tx format is a reasonable time

it's preferable to have dedicated fields, but not really a big deal

Im not calling ANYONE lazy. Lets make that clear first.

Leaving it in Txextra is lazy. Leaving depreciated addresses alive is lazy.

oh yes I agree

i guess i misinterpreted

as a user, i am against nfts on monero. yet im still currently spinning up a morbinal node just for the novelty of it. i shouldnt be able to do that.

mordinals would instead just exist by spamming outputs. Then we'd have the same problem at an even higher cost. yay?

> <@politicalweasel:matrix.org> I could use the boat analogy back on you. Attackers can still spam regardless (a leak), but honest users would be forced to spam w/o tx_extra (a leak). You've been arguing that patching the latter doesn't have merit.

>

> We can't force users to use Monero in the way we strictly define. Regardless that's arguably not even a good idea in the first place. Arbitrary data storage will always be possible. And I still don't understand why tx_extra is anywhere near as bad as output spam.

Yes but again, you're arguing is rather than ought. Do you believe that arbitrary data storage is desirable?

in some cases, yes, but in the case of ordinals and similar, no

No. Mordinals would be harder to develop and wouldnt be public on chain.

politicalweasel[: How would you police the cases absent a hard fork?

we don't live in a perfect world

you dont. only mitigate damage

Precisely.

you can't police use cases

its impossible

Its not policing.

ofrnxmr[m]: "harder" to what extent? And why wouldn't they>

?*

can morbs be pruned out? should be easy to do righ

s/righ/right/

Pruning takes io

tx_extra can (?) be pruned. outputs cannot, without manual blacklisting

if we have to have morbs id like them to be as pruneable as possible

politicalweasel: it's one thing to say "let's extend the Monero protocol because feature X is useful", it's another thing to say "let's make a dedicated field for anyone to be able to morph the protocol into whatever they like", which will lead to the same state as Bitcoin is at right now. It's true that if you want to write arbitrary data on the chain then it will become harder and more costly, but that's also kinda the

point of having a hyper-focused project: any usage of XMR outside of its primary usage is to be as inefficient as possible to maximize the efficiency of the primary usage. This is especially important given Monero's need to be fungible (hence, homogeneous)

^^^

Anyway.... (full message at <libera.ems.host/_matrix/media/v3/do…5ddba302cca0d146abb3344ff42ed48324a>)

Like, it's true that I can encode the entire bee movie by registering a long-enough chain of twitter accounts. Doesn't mean Twitter should cater to being a file sharing service.

You can't have the first thing without the second*, that's the nature of flexibility. And you still haven't addressed the fact that removal doesn't stop spam, only makes it more harmful to the network.

*it's not really "whatever they want". Again, we're not talking about smart contracts.

^^^

It doesnt make it more harmful.

> <@politicalweasel:matrix.org> You can't have the first thing without the second*, that's the nature of flexibility. And you still haven't addressed the fact that removal doesn't stop spam, only makes it more harmful to the network.

>

> *it's not really "whatever they want". Again, we're not talking about smart contracts.

Removal doesn't stop spam, but neither does keeping it. I don't need to fix the outputs issue to argue against tx_extra.

Thats absolute fear mongering. (Or an accusation that good actors ate actually bad)

> <@ofrnxmr:monero.social> Anyway.... (full message at <libera.ems.host/_matrix/media/v3/do…fe19ed25643a09e0c34e198e9d4547e10e6>)

If steg+output spam is worse than a small tx_extra field, and neither option stops abuse, then it's logically better to have a small tx_extra field

One incentives spam by making it a tool. The other ruins the blockchain.

Spam outputs harms everyone's privacy and bloat the enote set. Way more harmful than a few arbitrary bytes which can be ignored or even pruned

ofrnxmr[m]: Exactly. Tx_extra is a systemic issue while outputs are a rather minor exploit that's only feasible for some use-cases.

Alex|LocalMonero: But removal doesn't actually solve anything. It's not "patching" any "hole", just forcing water into the other one. Legit users would be forced to spam.

The damage to ring privacy is not "minor"

politicalweasel: those arent orbot users

By minor I meant arbitrary data storage.

Keeping it DOES patch a hole, that being legit users not having to spam

Keeping it doesnt patch anything.

It just names people use more tx to write their script

I just explained what it patches

politicalweasel[: That can be done without removal of tx_extra

And anyone who would, is, by definition, an attacker.

nikg83[m]: yes but why force honest usecases to do it? Would you rather 100 people die or 50?

ofrnxmr[m]: But that comes at a higher cost, which is an active incentive against it. System working as intended

politicalweasel[: Legit users doing tx need to spam ?

Not a good actor that is being forced to mixer babies

Murder*

merope: Steg does too

politicalweasel: but I believe that once you zoom out to the bigger picture, you'll see that keeping it will lead to the bitcoinization of Monero (by bitcoinization I mean that the ecosystem will be splintered, mutually incompatible in a lot of ways, many different address types and multisig and wallet setups and NFTs and so on like the Bitcoin ecosystem is now, where the harm for Monero is much worse because unlike

Bitcoin Monero has a goal of being fungible)

nikg83[m]: legit usecases for arbitary data, I mean. Or even non-legit ones, ie ordinals which don't explicity want to attack the network but also aren't really "legit"

politicalweasel[: Who is using tx_extra rn ?

Exchanges

nikg83[m]: see my earlier reply

And bad actors

I don't really buy the argument that removing tx_extra will cause people to spam useless outputs.

I'm sure there's the occasional motivated spammer who really wants their favorite meme on the blockchain no matter that it takes, but I'd bet most will just think "oh, there's nowhere to put it" and give up.

So yes politicalweasel I would rather that kaya uses outputs for his DEX than open the door for the bitcoinization of Monero

politicalweasel[: Is monero a currency or data storage network ?

Its ipfs

Alex | LocalMonero | AgoraDesk: agreed. But he wont.

Alex|LocalMonero: tx_extra doesn't do this though, that's a strawman. Nor does it harm fungibility, at least not any more than output spam.

nikg83[m]: A transaction data storage network. We are now arguing what types of data constitute "valid" transaction data, which includes an optional field

Yes sir

merope: A option field which can bloat the chain ?

nikg83[m]: currecy, but do you think people actually care and will respect that? And regardless, some data storage isn't mutually exclusive to a currency... if that were the case then we'd have to remove subaddresses, etc

politicalweasel[: Why do you think that it doesn't do that when we already have mordinals?

No we wouldnt have to remove subaddresses !

Let that be clear

Thats nonsense.

Alex|LocalMonero: they can and will spam outputs instead, if it's actually a serious project that has serious intentions of doing what it's designed to

ofrnxmr[m]: that's my point

Its like "putting the dishes away", who would suggest just tossing them in the trash. .?

nikg83[m]: It can also be used to add features without requiring a hardfork every time someone wants to implement a new service thay requires it. And since chain bloat can be acheived even without tx_extra, the chain bloat argument loses value

politicalweasel[: That may be true, but you're, again, arguing how things *are* rather than how they *should* be. You're arguing that arbitrary data is desirable, but only when it's not mordinals.

I do t agree endor00: the arguement doesnt lose value. Quite the opposite

merope: If output exploits happen with or without tx_extra then the discussion should be focused purely on whether we want tx_extra or not.

Not really... I'm saying data storage is inevitable, though desirable in some cases. tx_extra just defines a way to do that while causing the least harm

A. Bad actors do bad actor things

B,3. A+ good actors think they are doing a good thing and will push more a d more

> <@ofrnxmr:monero.social> A. Bad actors do bad actor things

> B,3. A+ good actors think they are doing a good thing and will push more a d more

B3 bad actors have a "lower hanging fruit" way of doing bad things that actually reduces their harm, and good actors are not forced to act like bad actors to do the things they want

again, i'm not convinced that there's any real argument in favor of removal, aside from "following" vague principles according to one's own interpretation. There's not actual harm caused.

politicalweasel[: Would you also be against removing tx_extra if the outputs exploit didn't exist?

A. Legit users AND illegit users AND attackers all "attack" the network

B. Legit users AND illegit users don't attack, attackers still do

<merope> "It can also be used to add..." <- New service ? A 3rd party tool? Should monero blockchain be even used for that , for new core features I am sure we can always hf

Now that hf are so slow that most of these features would be well planned in advanced and won’t need such experimental fields

Alex|LocalMonero: If chain bloat happens with or without tx_extra, but its harm can be minimized *with* tx_extra, then tx_extra is the least harmful option

politicalweasel: what insane world do you live in where legit users to illegit things ?

merope: Chain bloat isn't the only variable when it comes to keeping/removing tx_extra. You're forgetting about the bitcoinization argument that I described.

Alex|LocalMonero: maybe. there's an argument to be made that data storage in general should not be outright banned in the first place

Thats what you call greed

ofrnxmr[m]: depends on how you define that

ofrnxmr[m]: That would be the case of Serai using output steg to encode their data

nikg83: 2 hard forks coming over the next 2-3 years

merope: Are you in the opinion we keep tx_extra but cap the size?

> <@busyboredom:monero.social> I don't really buy the argument that removing tx_extra will cause people to spam useless outputs.

>

> I'm sure there's the occasional motivated spammer who really wants their favorite meme on the blockchain no matter that it takes, but I'd bet most will just think "oh, there's nowhere to put it" and give up.

i think this way

And after seraphis we should be good for a while

nikg83[m]: No, I'm very much in the "remove" camp.

nikg83[m]: Yes, option B3

Oh, he was addressing you.

> That would be the case of Serai using output steg to encode their data+

endor00: precisely.

That is a bad actor by definition

Alex|LocalMonero: Yah I know your stance already 👍

Alex|LocalMonero: Like politicalweasel said, it's a strawman argument

> <@ofrnxmr:monero.social> > That would be the case of Serai using output steg to encode their data+... (full message at <libera.ems.host/_matrix/media/v3/do…8fac0d50c0b334789eecac81712156064df>)

You cannot claim to support privacy, while intentionally harming it for profit, to the determent of tour customers

ofrnxmr[m]: forcing output spam IS harming privacy

Forcing spam?

ofrnxmr[m]: And here's an easy solution: relegate your harmful data in this nice optional tx_extra field! :D

(spam which could've otherwise been innocous tx_extra)

Why would someone develop something that is BROKEN BY DWSIGN

politicalweasel[: Nobody is forcing 😂

endor00: politicalweasel please answer the question: if output exploits weren't a thing would you be for tx_extra removal?

You cant force someone to write broken software on purpose

nikg83[m]: If there is no alternative to implement a needed feature, then you are effectively forcing people to break the system to get what they want

Endor: what they want being impossible by breaking it

merope: You don’t harm others privacy to achieve your goal, that’s called a bad actor

Alex|LocalMonero: Right now, no, but I wouldn't be nearly as hardline. Also keep in mind that I'm assuming there's no other harmful data storage method is available. Meaning could possibly be convinced otherwise.

<monerobull[m]> "> <@busyboredom:monero.social> I..." <- i will bloat the chain with monerochans just because it is so simple to do -.-

politicalweasel[: That's important because it demonstrates that there's a difference in values. You don't value Monero's hyper-specialization factor as much as I do, so I feel like this isn't something we can ever reach consensus on.

Wen ccs to attack mainnet

Forcing Kaya to do it, forcing me to do it, whats the differencio.

Bad actors are going to act bad.

Either I have 2 routes, or 1

<Alex|LocalMonero> "endor00: politicalweasel..." <- No: like I said, leaving *some* room to implement features that can connect Monero to other ecosystems and implement advanced features. The risk of spam can be reasonably mitigated by designing tx_extra with some forethought (eg. size limits and/or fee cost).

But the real answer is that until someone figures out how to actually prevent output exploits, the question remains a pure thought experiment - and can therefore have no bearing on real-world decisions *today*

endor00: my full stance was remove in next hard fork, then possibly add back in a new /improved / studied form for Seraphis

Oops, cut off part of the message: * I believe leaving some room is a good idea

That's fair. I understand your point, but my argument is one of being flexible and reducing damage caused by certain use cases, even at the cost of comprising a strict code of principles. Of course, I do still value fungibility, privacy, etc.

Alex | LocalMonero | AgoraDesk:

(forgot to quote)

monerobull[m]: im gonna do it guys. ill abuse tx_extra just because its so easy

Its not removing any use cases aside from the ability to soft fork

Dooooooo it

its morbin time

Make em max size and dont stop for 6 months plz

Rip

You have to holes for arbitrary data. One gaping and easily-pluggable hole and one smaller hole. You have people who want to shove their arbitrary stuff through those holes. A bigger and free-to-access hole is much easier to shove stuff through, therefore it will be used extensively with massive amounts of stuff shoved through it. If that hole is closed the smaller hole will remain. Only the most determined hole-stuffers,

malicious or not, will utilize it, therefore less stuff will be stuffed.

If you believe arbitrary data is desirable then this argument won't convince you, but I would argue that if you believe that arbitrary data is desirable then perhaps Monero is not the best project for you.

two holes*

ofrnxmr[m]: how much would that even cost

I would thumbs up but only some people have that power in here #emojigate

monerobull[m]: 0.01c per tx, 2160tx/day

Send to yourself. Ie, almost nothing

wait what

> massive amounts of stuff shoved through it

Hence the proposal for a tight size restriction

no way arb data is that cheap

> <@alex:agoradesk.com> You have to holes for arbitrary data. One gaping and easily-pluggable hole and one smaller hole. You have people who want to shove their arbitrary stuff through those holes. A bigger and free-to-access hole is much easier to shove stuff through, therefore it will be used... (full message at <libera.ems.host/_matrix/media/v3/do…22edef9f88846396f74d97d6204c573eb95>)

Yes cheaper than read data

Real

Also, if plugging one hole causes the other hole to explode and break stuff around it, then having two small but controlled holes is better

wtf im gona use monero as cloudstorage from now on /s

Arbitrary data of literally any kind is harmful to fungibility. And if reducing or eliminating arbitrary data means we don't get to "interact with other ecosystems" then so be it. Monero does its job just fine on its own without other ecosystems.

DiegoSalazar[m]: output spam is way more harmful though, which is the alternative

do morbs even harm fungibility

they use preset outputs no?

yes

* yes they harm fungibility

It only precludes interacting with other systems that absolutely necessitate data to be written into the Monero chain Diego Salazar . The overwhelming majority of other systems don't require that.

monerobull[m]: for ring members

DiegoSalazar[m]: But that's the point: removing tx_extra would not eliminate harmful data. Rather, it would force people to put it in an even more harmful place, causing bigger damage overall

It doesnt force people to.

politicalweasel[: Malicious actors can spam outputs regardless of tx_extra, we need to fix that issue as well. Sorry for repeating myself but I'm exhausted that the two holes get merged.

ofrnxmr[m]: you know what we mean :/

Bad actors arent going to spam using Txextra, they are going to do both.

And good actors will unintentionally do more than bad actors simply by using the protocol the way it was designed

ofrnxmr[m]: explain.

Example

Kaya with 5000tx/day and view keys posted

If I have two bugs, one is easy to fix and one is hard to fix, I won't refrain from fixing the easier-to-fix bug just because the harder-to-fx bug exists politicalweasel .

ofrnxmr[m]: If they want to put it somewhere, they *will* put it there, because they can. So giving them a less harmful alternative is the preferable option

endor00: if an xmr based exchange wants to put it there, it wants to die fast

And kill monero with it

It's like giving clean needles to drug addicts: they still have a drug problem, but at least they avoid giving hepatitis to eachother en masse

So, its not even a realistic assumption

Alex|LocalMonero: but my point is that the easier-to-fix "bug" will just lends its "vulnerabilities" to the much more dangerous and harmful "bug"

Security through obscurity

Lets hope bad actors are nice and only use Txextra, and lets hope good actors are nice and dont steg

Both of those thought involve drugs

ofrnxmr[m]: You don't know that, and can't assume that

Dont know what?

ofrnxmr[m]: most arbitrary-data-users don't wish harm to Monero. only explicit attackers.

That it would die fast

That it wants to die? Or that it wants to put view keys up?

politicalweasel[: Yes but by leaving the easier-to-fix bug open you divert merely a subset of the damage away from the main damage-generating-bug. You just hope that the diversion of the good guys is enough to keep the damage by the bad guys below an acceptability threshold, which there is no reason to assume

merope: If you ran an exchange and poisened 60% of outputs via steg. Are you really going to use xmr to secure your liquidity?

Cmon now

Thats like opening a vegan steakhouse

Lets put aside those who want to do harm for a minute. I'd think leaving it in signifies to a lot of people, even well meaning ones, that it's OK to build a lot of things that would harm fungibility further.

DiegoSalazar[m]: Exactly!

ofrnxmr[m]: Users gonna use services without knowing how things work under the hood. If that service gets popular, it will do so regardless

Diego Salazar: I know it sounds like in poking at kaya but im not 😂.

Just the best metaphor I can use

Alex|LocalMonero: again, the existence of bad guys isn't an argument against mitigating damage caused by good guys

i'll be gone for 10-15 minutes

...... good...guys.... dont

... premedite... bad...behavior...

Diego Salazar: hence the proposal to keep the field but restrict its size to something like 128 or 256 bytes

politicalweasel[: Yes, but neither is ignoring the existence of bad guys

Unless you're arguing that the good guys are what will carry the output poisoning issue over the acceptability threshold, which I don't think you are.

You're only acknowledging that this is an issue that needs to be fixed.

> <@ofrnxmr:monero.social> ...... good...guys.... dont

> ... premedite... bad...behavior...

ofrn can you help me get morb running

The dynamic size limits are never more than 11 hours away from allowing ~30MB blocks, so long as the fees are paid to make it happen.

I suppose it is not impossible for something like this to make that happen.

My takeaway is to have a high performance node and mining rig ready.

s/to make it happen//

<Alex|LocalMonero> "Unless you're arguing that the..." <- the "acceptability thresehold" is 0. But 1 is better than 2. And 2 is better than 3. And so on.

> <@spackle_xmr:matrix.org> The dynamic size limits are never more than 11 hours away from allowing ~30MB blocks, so long as the fees are paid.

> I suppose it is not impossible for something like this to make that happen.

> My takeaway is to have a high performance node and mining rig ready.

isn't there a long-term dynamic blocksize cap which prevents taht

<merope> "Diego Salazar: hence the..." <- 128, but enforced on all tx should be fine to keep uniformity & removal/further reduction to be studied till seraphis/w.e next big hf comes

* isn't there a long-term dynamic blocksize cap which prevents that

nikg83[m]: I was kind of thinking all tx extra should be padded then, yeah.

I'm not a fan of enforcing on all txn's. Needlessly increasing tx sizes

Fungibility above all else.

DiegoSalazar[m]: That option was also considered, but most people seemed against it

DiegoSalazar[m]: Security? Censorship resistance? Reliability? Sustainability?

not that tx_extra directly impacts all of those, but still

32 bytes max. Anything they want to say can be said in that space. :P

politicalweasel[: Yes.

We already have "secure" blockchains (for some definition of secure)

We already have "reliable" blockchains.

We have no other fungible blockchains.

so then we should just remove the blockchain and have Monero operate on "I send you 1 XMR"? Completely fungible.

<politicalweasel[> "> <@spackle_xmr:matrix.org..." <- That is the long-term cap taking effect.... (full message at <libera.ems.host/_matrix/media/v3/do…7b92926b97f26a0b5618f269c0d1430d8c1>)

Here's a simulation I wrote off that document, if you feel like checking my work: github.com/spackle-xmr/Dynamic_Bloc…/blob/main/Dynamic_Blocksize_v16.py

politicalweasel[: Lol. Then it wouldn't be a blockchain. It must be a fungible blockchain. Not just a fungible.

spackle_xmr: wait so the long term cap is 50x? Am I reading that correctly?

Diego Salazar: fine, then we'll have a blockchain consisting of "XXX sends user XXX 'XXX' XMR"

politicalweasel[: Once the penalty median M_N is no longer restricted by the short term median, it is restricted by 50 * M_L.

Then the maximum possible block size is 2 * M_N, assuming that enough fees are paid.

Note that the amount of fees required for this is absolutely massive.

* Diego Salazar: fine, then we'll have a blockchain consisting of "Unknown user sends unknown amount to unknown user"

politicalweasel[: This isn't the gotcha you think it is, as the goal is indeed to make it as close to this as possible to an outside observer who is not either party in the transaction.

DiegoSalazar[m]: Then let's do it. Hard fork next month to remove all this "cryptography" crap

I understand your hyperbole extends even to the parties in the tx, because then it is completely 100% fungible. But the concessions to let it be used as a currency mean the parties themselves must see what's going on.

Beyond the necessary concessions that let it be used as a currency, nothing else should be considered that would weaken fungibility.

Tx extra is not needed for currency functionality.

that's not the point. it's that a "currency" who's only property is fungibility is not really a currency

DiegoSalazar[m]: Again, output spam DOES weaken fungibility, which is the alternative to tx_extra.

"Fungibility above all else" doesn't mean we have nothing else in there. :P it means that when we come to a crossroads, and one path harms fungibility, we prefer the alternate path.

Okay that's at least a more reasonable statement

Ye. Sorry for my desire to be "twitter brief and punchy" robbed me of the nuance I needed to get the point across well.

> that's not the point. it's that a "currency" who's only property is fungibility is not really a currency

What properties must a currency have ?

Currency is a service to be exchanged for goods and services.

Currency as a service is fungible transfer of value.

well for one, security. currency is pointless if it is insecure, ie if it can be duplicated or trivially stolen. A fungible coin is worthless if I can magically steal it from you or magically turn it into 10.

So turn up the hashrate

<politicalweasel[> "the "acceptability thresehold..." <- 1 is better than 2 but 2 with no tx_extra that closes the biggest door on bitcoinization is better than 1 that swings the bitcoinization door wide open, would you grant me that? :)

You still haven't really solidly explained why tx_extra will result in "bitcoinization". There are 2 main "branches" of bitcoinization, as I see it.... (full message at <libera.ems.host/_matrix/media/v3/do…e719f5a30e9e13ec32ca8829f2fc5eb7ce3>)

oops didnt finish #1: ...like I said, Monero should be simple and standard but extenable

s/extenable/extendable and flexible/

When you say extendable and flexible, you mean on-chain, right? But you can't have a simple and standard and extendable chain at the same time, or am I misunderstanding something? It would seem to me that if you allow anyone to soft fork with tx_extra you inevitably reduce simplicity, do you not?

Monero's baseline format should be simple, but also flexible to be built upon and extended by external users

I guess that's a slightly better way to say it

Right, but if you're talking about that capability being on-chain then I don't see how you won't end up in the same place that Bitcoin did. The xkcd about standards comes to mind: xkcd.com/927 which is projected in the BIP library :) github.com/bitcoin/bips

So if a protocol can/will be used/abused to its maximum extent, it would seem to me that that abuse needs to be limited/discouraged/disincenticized to the greatest possible extent, by closing any potential doors. And while one may say that you can never really close all the doors that feels to me like making the perfect the enemy of the good.

I'm not really talking about standards though. There should be one standard address format, and one standard transaction format, with very little or no exception. Simple. I'm talking about things like DEX's or atomic swaps and so forth, where Monero itself isn't being changed but built upon to create something with it. Users generally shouldn't have to deal with non-standard "stuff" unless they explicitly seek it out.

(unlike bitcoin, with its several address/transaction formats)

* its several standard address/transaction formats)

But if you allow tx_extra then you necessarily allow a similar address fragmentation to develop. Recall that integrated addresses are just base address + tx_extra.

It would seem to me that you're not advocating for tx_extra (arbitrary data field) specifically but for a field that can be dedicated for, say, DEX interfacing.

Also, recall that Haveno, a DEX, does not require tx_extra. And IIRC atomic swaps don't need it either.

Fair point, but I think subaddresses should have been made standard long ago, and integrated addresses disabled. It's probably not worth it at this point with Seraphis approaching, but whatever. That's something we need to do as a community, not something that should be preemptively blocked by strictly solidifying the tx protcol. Allowing subaddresses to be phased in via tx_extra wasn't the worst thing in the world, but

it should have been temporary.

You can't predict use cases, though. Just because what exists now doesn't require tx_extra, doesn't mean it can't be useful. But again, either way, there's an argument to be made that discouraging output spam alone is enough to justify tx_extra as a "put your crap here instead of outputs" thing.

in fact come to think of it, this situation has a parallel with OP_RETURN. Core tried limiting it to 80 bytes, so ordinal spammers just used the segwit loophole instead. Luckily for Bitcoiners, it isn't too harmful besides the raw blockspace, but that's not the case for us. On-chain ordinals won't fit on Monero either way, but smaller 32 or 64 commitments definitely could

people will find a way around restrictions if they want to

* in fact come to think of it, this situation has a parallel with OP_RETURN. Core tried limiting it to 80 bytes, so ordinal spammers just used the segwit loophole instead. Luckily for Bitcoiners, it isn't too harmful besides the raw blockspace, but that's not the case for us. On-chain ordinals won't fit on Monero either way, but smaller 32 or 64 byte\ commitments definitely could

* in fact come to think of it, this situation has a parallel with OP_RETURN. Core tried limiting it to 80 bytes, so ordinal spammers just used the segwit loophole instead. Luckily for Bitcoiners, it isn't too harmful besides the raw blockspace, but that's not the case for us. On-chain ordinals won't fit on Monero either way, but smaller 32 or 64 byte commitments definitely could

Would you agree that defining the Monero protocol as strictly and simply as possible with maximizing transaction efficiency (in the sense of monetary transactions: medium of exchange, store of value, global monetary base) while maintaining decentralization and fungibility (which necessitates confidentiality and homogeneity) should be the prime directive?

I mean I don't think a flag to include either 0 or 256 bytes of tx_extra is a massive complication. We aren't talking about smart contracts here. I value simplicity, but also see value in the extensibility I was talking about earlier

(or 128 bytes, or however many)

that part doesn't really matter

Well, as mentioned previously even 16 bytes is enough to have address fragmentation (IIRC integrated addresses use just 16 bytes of tx_extra).

well in theory you could do it with just 4 if you're ok with "only" having ~4 billion addresses to choose from. That kind of misses the point though

So you can't have tx_extra, especially not one as large as 256 bytes, and not have the potential (or, perhaps more accurately, have the guarantee) for address fragmentation.

The *potential* yes. Though if we were really desperate for some reason then a new address format could also use spam outputs, but that's not my point.

Integrated addresses were hastily strapped onto CryptoNote, and it shows. We, as a community, are responsible for maintaining a clean protocol. If we can't do that then we're screwed anyway, tx_extra or not. The legacy system of CryptoNote and integrated addresses and wishy-washy tx_extra and so on wasn't kept clean, and Seraphis is a new start. We've cleanly solved the fundamental problem that integrated addresses poorly

solved, so that issue isn't likely to arise again.

After all Monero started out as another low-effort fork of ByteCoin. Even in post-RingCT Monero there are remnants of that. Seraphis will basically not have any

s/post-/current /

politicalweasel: are there any chains that eliminated the vulnerability of output spamming?

no, because it's impossible

well, not without just banning all transactions lol

So, this issue is separate to having tx_extra or don't. If someone seriously wants to attack Monero will do it no matter the cost

this was discussed already

there's more to it than that

Ok, I just wanted to be clear

By the way politicalweasel , spamming outputs is only a privacy issue while we don't have full membership proofs, which may change soon. We're left with it being costly to stuff arbitrary data into the chain as opposed to arbitrary data costing the same as any other data in the case of tx_extra.

s/We/Without the privacy issue, we/, s/tx_extra/tx\_extra/

Which, to me, is a desirable outcome.

So, if you have tx_extra then address fragmentation is not disincentivized. If in order to have a wallet app with address fragmentation you need to generate more outputs you'll have to pay a disproportionally higher cost than wallets that are using the standard Monero protocol, hence, your wallet is outcompeted by the standard implementation.

Do full membership proofs require accessing the enote set at all, or only a constant-sized "root" of some sort? If so, then that's still worse than tx_extra. If not then I'd probably be okay with removal, but we'll cross that bridge when we come to it. There is still a higher cost due to verifying rangeproofs, but that's not the end of the world.

Using tx_extra should be more expensive than not, so there's not really a significant change there. But again, that's a community responsibility.

"if so" as in still having to access the enote set

I dont like that political weasel is making arguements based on feelings and mixing in alot of assumptions or "what ifs"

Where there are real answers to some of said assumptions

like what? what's a "what if" I've used which isn't reasonable?

Example

Why are you voting "its ok because Seraphis is coming"

When is Seraphis coming?

Exavtly. Its not ok to just wait around

I didn't mean it's something to not care about, but that since Seraphis is approaching anyway it's likely not worth the effort to change anything unless we have a hard fork in-between anyway (ie for BP++)

Exactly = you dont know.

It could be 2 years, it could be 6, it could have been a year ago

"Likely" not worth the effort. You're just speaking your opinion.

Opinions are nice, but everybody has them. Most of your arguements for keeping it are because you have an opinion

Doing a full hard fork to restrict one singular field is absurd IMO. We could soft fork, because that change wouldn't affect any average user, but I'm not sure if the community would go with that.

Not because you how anymore this works.

tx_extra should have been cleaned years ago, but we're in an akward position where Seraphis is "close"

Arguing with, what I assume to be, the largest monero adopter outside of cex

politicalweasel[: Should have? Never

ok, your point?

ofrnxmr[m]: wdym?

It was a junk drawer and stuff gotnput in there and left there

so... you're saying it shouldn't have been cleaned up?

because that's what I'm saying

It should have never been filled with junk!

oh sure, agreed

Subaddresses made it in because if a sift fork. A hard firm would have added them properly.

I don't think subaddresses were a soft fork? Only a wallet-level adoption protocol, no consensus change

Yes,soft fork

> Alex | LocalMonero | AgoraDesk: subaddresses are in the tx_extra, and are not enforced by consensus afaik.

^ koe

<kayabanerve[m]> "Ordinals does not use OP_RET and..." <- ^ politicalweasel:

"Doing a full HF to ...." - there are more (necessary) reasons to HF pre seraphis than Txextra. Txextra is just extra. Far from the main reason.

> Integrated addresses were hastily strapped onto CryptoNote, and it shows. We, as a community, are responsible for maintaining a clean protocol.

If we can't do that then we're screwed anyway, tx_extra or not.

The legacy system of CryptoNote and integrated addresses and wishy-washy tx_extra and so on wasn't kept clean, and Seraphis is a new start.

Txextra leans toward an excuse not to hard fork. We will have hard firms until we get it right.

And I understand your and others perspective. I really do. It just isnt a business minded decision you guys are making. You're trying to appease everyone instead of trying to push towards progress

After reading the backlog I would like to explain something to the non-devs here:

I have seen repeated mentions of the following: "Stego and tx_extra are like 2 different holes on a boat, a small one and a big one"

Or, in other words, it gets claimed that writing something into tx_extra is easy, and stego is hard

This is misleading. Making stego, like creating fake outputs and putting bytes in there, is only one library away from becoming very easy

Somebody has to write that library, agreed, and it's not trivial, but once it exists, putting arbitrary bytes into

a Monero transaction using stego once again becomes as easy as using tx_extra

In your code you just call a very simple method: tx.add_with_stego("this is rubbish and only bloats the chain"

And that "add_with_stego" method will care about all the complexity of creating fake outputs, and so on

stego by its nature is less space-efficient, so the tx fee will be larger

which will reduce spam

Yes, correct, but that wasn't the argument that was used in the discussion

It was used at least once and disregarded as "but we never know what we might need within the next year"

also, output count is limited to 16 per transaction

Again, a good point, but on the other hand proposal B3 comes with a pretty strict length limit as well. 256 bytes is one proposal.

<plowsof11> Cant transfer ownership of an 'ordinal' on monero >> sure you can. just publish the true output in the tx_extra, right?

gingeropolous @gingeropolous:libera.chat: There's also the input side I don't care to comment the solution for.

gingeropolous the opinion i blindly parroted seems to be misinformed, please forgive

<Alex|LocalMonero> "We're left with it being costly to stuff arbitrary data into the chain as opposed to arbitrary data costing the same as any other data in the case of tx_extra."

reading most of the back log and thinking, maybe the issue is that fees, especially for tx_extra, are way too low

we're talking about storing data on every node forever, I feel like if it's appropriately priced, spam discourages itself. isn't that like, a significant portion of the reason we have fees at all, to deal with spam issues?

like Ik it doesn't solve the problem but it feels like everyone is talking around how CHEAP this data storage actually is and how much that incentivizes people to stuff data to begin with

<Lyza> "reading most of the back log and..." <- I thought about this too. If tx_extra is worth more per byte then a normal transaction, miners are incentivized to preferably include these transactions

not a problem right now, but it affects the economics of dynamic scaling

ceetee[m]: a miner adds a tx to a block if the fee exceeds the marginal block reward penalty from adding that tx. Block reward penalty is a function of tx weight, not tx size. To increase the fee cost of tx_extra, we would increase the 'weight' of tx_extra bytes.

So, whether or not a tx has a tx_extra would not be a factor miners care about

oh okey, that's is actually very good design

My mental concept had the normal size based tx fee + an extra fee for the extra data. Glad I was wrong

<rbrunner> "Yes, correct, but that wasn't..." <- It was exactly that argument..

<sech1> "also, output count is limited to..." <- Also, with tx chaining we can limit the number of outputs to 2 for each transaction, which, and correct me if I'm wrong, seems to almost completely close the "spam output" steg angle.

Increasing tx_extra fee might not be that effective, unless it's something like a 200x increase: Monero's fee per byte is very low

Rucknium: What would you think about the potential of using relays to enforce statistical tests rather than being hardcoded consensus?

<xfedex[m]> kinda feel like the overall fees could be higher too, we're also talking about people using output spam for steg afterall

I'm not super sure how things scale as XMR price increases since fees are priced in XMR without respect to dollar price but like, rn a standard TX is like 0.007 USD

which if you compare the size of a Monero transaction to a bitcoin transaction, about 10x larger, that's on some level the same as if bitcoin had fees that were 7 hundredths of a cent

it's ludicrously low imo

it's very low because tx volume is still in the minimum-size buffer zone, which exists to ameliorate wide volume swings when adoption is low

BawdyAnarchist: IIRC the loose proposal being discussed would do the statistical checks at the node tx relay level, not consensus. Just like min fee is now. So you are "on the right track" :)

Thanks for fielding my pleb questions

<UkoeHB> my understanding is that even when we get above minimum block size, the system is designed for fees to stabilize approximately where they are now, and for higher fees to be mostly during sudden TX volume increases. is that wrong

that's correct

ok I'm not sure what you were trying to say about the minimum-size buffer zone then

There's plenty of space for everyone, and the max block size gets no shrinking pressure.

It would if it were above 300000.

true. so fees would average higher than now for that reason?

If there were pressure and people tried to pay more to get in first.

During block size expansion fees are higher. The fees at a high and stable tx volume will be significantly lower than they are now.

The fee per byte is proportional to 1/M_F, with M_F being the median for minimum fees calculated as min(M_N, M_L).

For example: At a stable 10M block size I believe the fee per byte would be approx. 2.27e-9, compared to the approx. 1.9e-8 it is now.

If there's pressure and everyone's fine waiting some, fees don't go up.

im having a hard time getting my head around "it's OK if we don't have tx uniformity"

* During block size expansion fees are higher. The fees at a high and stable tx volume will be significantly lower than they are now.

The fee per byte is proportional to 1/M_F, with M_F being the median for minimum fees calculated as min(M_N, M_L).

I think the situation is more like, we can't entirely prevent it, so should we keep the field for it to keep it from potentially poisoning outputs? also, less adaptable protocol

<spackle_xmr[m]> when you edit in matrix it reposts the whole comment on the IRC side

Ahh, got it.

but thx for the explanation

sure, but that would lean toward a mandatory tx_extra... if we can't prevent it.

random thought, I don't entirely understand how steg works in XMR, but would some sort of deterministic decoy selection close that hole

<gingeropolous> ok that's a fair take

and the "keep it as it is because it is the way it is" seems.... silly. That's not how you make protocol improvements. If that logic were true, we would've kept variable ringsizes

I don't think that will happen as long as consensus can happen for something else

You don't think what will happen?

and presumably, if steg (i.e., data stuffing) is still possible even without tx_extra, theoretically the protocol would still be adaptable. you could mod the relay rules to allow some payload as long as its linked to some stegged hook in the tx

LyzaL: steganography is basically impossible to prevent

While the subject of the dynamic block size algorithm is being discussed... if anyone is interested in creating animations to help explain it, I've been working on that with the end goal of creating a interactive graphical simulation.... (full message at <libera.ems.host/_matrix/media/v3/do…5560ca3d98954cc3406075cdbac3dcd7995>)

<UkoeHB> "LyzaL: steganography is basicall..." <- But it's possible to limit its scope and increase its cost, right?

I guess? it's pretty low priority from a protocol design standpoint

and you aren't going to get more than like 2-3x higher cost no matter what, which is pretty insignificant

UkoeHB: 2x-3x higher cost is already more than enough for the standard Monero implementation to outcompete anyone that wants to soft-fork through steg.

this whole social engineering game does not excite me

any decision we make regarding tx extra, fees, etc potentially affects user behavior so I don't see how it would be avoided, or maybe exactly what you mean by it

I know this sounds crazy ... could statistical checks be implemented by relays to check that outputs meet some very low threshold which all but ensures you'll avoid type I errors?

So, remove tx_extra; and then relays basically prevent the propagation of transactions with outputs that are clearly non-random

Monegro: Checking for what?

Some of the statistical checks you mentioned

Uniformity checks. Legit outputs should have a uniform distribution, no?

(also, full disclosure, I'm Bawdy. I just decided to use IRC instead of Matrix rn)

So the threshold would be set such that it's nearly guaranteed that there will be no false positives. But anyone trying to build extensibility via steg, wouldn't be able to reliably get their transactions through, because even tho some might get through, too many of them will be caught to be reliable.

It's a can of worms, to start. And if the steg was encrypted or even XOR'ed with some other random parts of the tx like jberman suggested in the long tx_extra Github issue, then a statistical check wouldn't work at all.

It's probably more robust to limit the outputs to two, which will also help with tx uniformity as per tevador

This can't be done now, however, as tx chaining is only possible post-seraphis.

Seraphis doesn't directly fix the 10 block lock by the way. Alex, I think you implied that above in arguing for limited to two outputs.

Rucknium: tx chaining doesn't necessarily require fixing the 10-block-lock, those are distinct issues AFAIK.

UkoeHB: would you comment? ^

so with a post-ringsig proof (full membership), do the fungibility implications of tx_extra go away?

gingeropolous: Only if tx_extra is mandatory and fixed size and somehow uniform.

but when you go to make a tx in post-ringsig monero, you don't reference a specific set of enotes

But if people using steg for extensiblity are now required to encrypt their outputs, doesn't that remove one of the primary negatives regarding output poisoning?

gingeropolous: IMHO, not entirely because you can accidentally or purposely fingerprint yourself in tx_extra. Global membership or not, a unique user-level fingerprint would destroy privacy.

sure, in the generation of txs, but in a global membership, you don't reference specific enotes ... (?)

But yes if a user is using a standard not-fingerprinting wallet w/global membership proofs then they are not impacted much from the fingerprinting txs. There is not the output poisoning externality

roight

Or how about implementing a uniformity check when constructing rings? As a simple means of avoiding poisoned outputs?

At the wallet level

yeah i seem to be more concerned with tx linkability than fingerprinting in my thoughts on tx_extra

or traceability. being able to tell which enote is the real one

Monegro: You mean "avoid suspicious outputs"? Maybe there is already a spent outputs database builder in the code that could be extended. But recently I think tobtoht suggested it be removed.

It's complicated since right now the daemon only tells the wallet basic info about the available outputs. Would require some engineering effort

gingeropolous: Both of those measurements are intertwined: bad fingerprintability makes for bad linkability

to do the picking on the wallet side

right. which is why the thought "tx nonuniformity is fine" still makes my head hurt.

(continuing to go out on a limb) with the statistical check of outputs, there would need to be a large enough sample of bytes/bits in the output public key(s). Are there enough? Probably not.

Let's suppose for a moment that people using steg are more likely to use multiple outputs. It's starting to run into complexity, but supposing that such a uniformity check was applied only to transactions with say ... 4 or more outputs, and renders the check on the concatenated set of outputs.

Now you're x4 on the number of bits.

Again, only at the wallet level. A user-level mitigation against poisoned outputs, in the case that tx_extra is removed.

One problem with pushing people who want to work-around a size constraint or

removal of tx_extra (e.g. steganography in fake outputs), is that we

may end up having to ensure all outputs are actually on the curve so as to

avoid fingerprinting. That would be more problematic in terms of verification

cost. Enforcing a uniform distribution of a constrained size tx_extra I posit

would be preferable.

jtgrassie: What is "the curve"?

outputs are curve points

Thus I now lean toward the various B (2,3,4) options.

(e.g. encrypted tx_extra, though I have no strong preference to fixed size / optional)

<jtgrassie> "avoid fingerprinting. That would..." <- In that case you should be in favor of limiting outputs to 2, not tx_extra.

If we go with A (removal), I think we'll end up having to make steganography

harder, which will mean more verification overhead at relay.

And yes, restricting output count is one way to make steg harder.

(harder / more costly)

How would limiting outputs to 2 increase the verification overhead?

It wouldn't. When I mentioned verification cost I was refering to checking outputs are actually valid curve points.

Limiting to 2 outs makes doing steg harder, but removes the ability to perform batched transactions.

(batched txs are commonplace for exchanges and pools)

if the number of outputs is limited to 2, sweeping/churning will require a lot more txn

hbs[m]: no it wouldn't, a sweep takes any number of inputs but creates 1 output.

(1 and a dummy)

sweep_all can be instructed to produce a specified number of outputs, very handy to split a large output into 16 smaller ones

sweep_single sorry

That's true, yes.

I forgot!

So, 2-outs restriction has 2 issues:

1) no more batched txs

2) no more ability to split a large output into multiple small outs

it will also significantly increase the spent fees

which is a consequence of the two points you mentioned

yes, and for the honest user (e.g. someone using Monero as p2p cash)

Hence why I now prefer keeping tx_extra, but encrypted + size constrained.

We have to close the gap of (ab)use of the blockchain for non-financial txs, but not at the expense of honest users.

By keeping the field but size constrained and encrypted, people can still ab(use), but not at the expense of privacy or cost to honest users.

that would still allow to go the stego way and poison outputs right?

yes, but it allows a safer way to experiment

Preventing steg is impossible. IIRC valid curve points aren't actually that rare to find in random 32 bytes (50/50 I think?), so ensuring that outputs are valid curve points doesn't help anything. And enforcing 2 outputs just delays the problem... people could still spam chained transactions. So you quite notably damage user experience while simultaneously increasing the load on the network due to having multiple

transactions which could have been batched as 1.

politicalweasel[: indeed, steg would still be possible

but an encrypted size constrained tx_extra provides a safer way to experiment

yes, I am strongly in favor of option B3 (optional, fixed-size tx_extra)

my only hesitance with a fixed size (vs optional or 0-CAP) is it dictates growth where none may be required

Yeah I mean optional

transactions would either have 0 or 256 bytes

(or whatever arbitrary number is chosen)

gotcha, yes, I still prefer even B4 to A, but B2 or B3 over B4

B3 was optional fixed length encrypted by default, from the current discussion it seems it is rather mandatory encryption that has the greatest consensus, or at least with a satisfactory result to a yet to define statistical test

Encryption should be done by default and yes maybe we should even have some statistical check, but that won't actually stop anyone who really wants to put public data there. In practice it would be more of a "strong recommendation" rather than something which can be actually enforced.

a statistical test shouldn't be that difficult or costly to enforce

ordinals allowed custom tokens on btc right

yeah but a simple XOR and that all goes down the toilet

monerobull[m]: can the same be done with the currend morbs

politicalweasel[: true, but an enforced statistical randomness test certainly helps

XOR maybe a weak form of encryption, but it's better than nothing

point being, from a uniformity perspective, an enforced statistical test should suffice

I'm not opposed to a statistical test as long as it doesn't notably impact verification time. My point was just that it's not bulletproof.

monerobull[m]: morbs would still be possible, yes, but at least they wouldn't harm privacy of others

im talking about "fungible" morbs like how there are tokens based on ordinals on btc now

politicalweasel[: exactly and agreed. a statistical test over a small field (256 or 1024 bytes) is going to be fast

XOR with a one time pad is the über form of encryption, which as a matter of fact can ne used extensively for plausible deniability, i.e. any tx_extra can be proven to be the encrypted form pf anything with the correct one time pad

very true

a statistical test of randomness will suffice our needs

(for passing a sniff test of encryption that is)

<jtgrassie> "Limiting to 2 outs makes doing..." <- Which is why I only suggest limiting to 2 outputs after we have chained transactions, which is possible in Seraphis as per UkoeHB