<liamswenson[m]> "Can the utility of tx_extra..." <- No, as I detailed in my response on its issue.

It's the first segment of this post monero-project/monero #6668#issuecomment-1196312004

There's dramatically more utility in the L1 you're operating over carrying the data that using linkable solutions

And then the other aspect is removing TX extra doesn't remove arbitrary data. It just forces less efficient, yet also potentially uniform, encoding of data.

So the options are:... (full message at libera.ems.host/_matrix/media/r0/do…e8deaee1cf5f791168118d2d24fd09a3715)

We can actually do any of these without a hard fork AFAICT, so long as it's purely done on relay. I'm fine with either steg or 2x + 255b (of arb data, we still have to consider the existing wallet data), personally.

Isnt't there, at least in theory, a way to make it possible to add arbitrary data to bulletproof data, sort of encrypted tx_extra alternative?

Bulletproofs do not provide a chance for steg

So do I confuse this with something else?

I will note I'm mainly interested in seeing what ArticMine's addition to 6668 will be, as they said they will comment there

It is possible, but leaks some data (I forget what exactly) to the recipient.

rbrunner: CLSAGs do, and then outputs do

Ah, ok

Oh. I might be confusing with CLSAGs.

moneromooo: ... I don't believe it is. BPs don't have any scalars, except for a few Schnorr-signature equivalents at the end. You can't steg those without changing the nonce, which changes the challenge, which changes the signature

And then points can't be stegged if you're ever expected to know the discrete log

So with CLSAGs, the recipient knows the decoys used for steg are decoys.

It's a privacy reduction. With TX outs, there is no privacy reduction (other than non-2-outs), yet you have to do range proofs and it's inefficient.

It was BP+. Dunno about BP.

Double checking, turns out my comment was about +. BP has a different set of scalars yet still none are usable

It sounds like at a minimum, we're discussing a mult such as 2 (will need to double check against steg). I believe such a multiplier should be our immediate discussion accordingly, since it isn't as controversial as a limit

This thing "steg" and "stegged" comes up a lot, and no bells are ringing. I missed something. Where could I look to understand what that means?

I assume steganography.

TrasherDK[m]: it's kayabanerve[m]'s abbreviation for steganography

steganography is a long word not in my phone's dictionary for some reason :(

Okay. Got it.

I wanted to do that for player to player messages in Townforge, until I realized the amount of data I could stuff into a normal seeming tx was less than I thought :(

32 bytes for BP gone, 32 bytes for a dummy outpub pub key gone...

What is the computational cost for the device decoding the steganography ?

150 bytes in CLSAG, ~500 english characters wasn't enough?

*key word being English. I had a very limited charset proposed.

TrasherDK: Not the worst. Just some stream cipher

Are you saying you can stuff 150 bytes in CLSAG which the recipient can recover, not others, and the tx looks like one without such data in ?

yeah

Thanks.

I must have missed that :o

The recipient will know instead of 16 decoys, you only have 11 though.

But yes, you can forfeit any decoy you want to the decoder in exchange for 252 bits each.

I was left with a couple bits off ring members, and 8 bytes off the amount (which I'd know) :D

Any competent encryption algorithm will give you uniform appearing data. You'd abuse the encrypted amount to say which decoys where actually messages

(plus a few bits here and there by brute forcing some values by the sender)

In my case the recipient know the amount is 0, so I can stuff any encrypted data in it.

Because yes, if the first 5 decoys are always messages... not good. You can maintain distribution by not selecting the first 5, yet a specific 5, and then saying which 5 those are in the enc message

Oh, your 150 bytes come from stuff *all* in the offsets ?

Right. I'm just commenting you need +2 bytes from elsewhere to signal which decoys were stegged. My recommendation is the enc amount with a real amount of 0 ;)

stuffing

No, from the `s` vector

The `s` vector is completely random except for the true signature

Oh really. Very nice. I shall reuse your system :D

So you can put non-random data there without issue. If it's encrypted, and appears random accordingly, there's no impact.

Oh I'm not building this lol

I hate blockchain messengers :p

aw...

I just enjoy steg lol

*I may do a PoC in Rust ;)

Well, I had given up due to the dearth of available bits, so I might code it up then.

But I'm planning on using extra for my work

I'd be up for collab'ing on the design if you want something a bit more formal than code present in Townforge ;)

Are you sure ? I mean, I'd started coding this for BP+, which gave (IIRC) 32 bytes only. 150 bytes seem crazy large for sarang not to jave mentioned it instead.

Well, I'd make it more generic for monero ofc.

... I don't even know where you got 32 bytes in BP+ 🤔

But there should be absolutely no issue with using `s` other than the reversion in privacy. It cancels out the upcoming ring size increase

Can you read python ? I can point you to sarang's python PoC if so.

"reversion in privacy" ?

I'll also note, for your messages to have a `from`, you need 64-bytes there for the signatures (and then you can check against known senders for a sufficiently short potential list)

moneromooo: Any decoys used for messages are obvious as decoys to whoever knows they're a message (the recipient)

Therefore, they're not valid as decoys. Decoys should be indistinguishable from the real spend

moneromooo: And yes

Yes, for the from I had an issue. Best I found was a two step system, where a first message uses a 64 bit sig, and then subsequent ones can use a lot less.

You can just send a 16-byte ID

Ah, so that's the same issue as the BP+ one then :/

As in, you establish a channel, and then have a 16-byte ID identify the channel for all future communications

(or a 32-byte ID or a 252 bit ID)

Did the BP+ solution reveal amounts?

To be clear, this doesn't reveal the real spend. It just decreases the amount of decoys hiding it

With the ring size increase, it maintains the existing amount of decoys.

Oh, I looked up what I thought of doing for auth'd sender:

I'd also note for short messages, such as just 10 bytes, you only need to forfeit 2 decoys (ID and message). I'm solely proposing a max of ~150 bytes per TX so it never goes lower than a ring length of 11

Every player publishes subaddress ffff,ffff, that's the base PM address (you receive something on that one, it's a message, nobody else knows).

But if you limit the char set to lower alphanumeric + space, and run a zstd dictionary tailored for common english words... could prob get ~500 chars.

Alice wants to send a PM to Bob, she sends a full sig, plus a 1 gold fee or whatever.

If it's spam, Bob keeps the fee and does nothing more. If it's not spam, Bob sends back a message with his ffff,fffe subaddress, to which Alice can send without fee.

And sends ffff,fffd to Carol, etc. So know the sender without further data.

I was really hyped about this system :D

Hiding stuff in BP+ did not reveal amounts, just which ring member was thre real spend IIRC.

I'll find the python code from sarang, it'll probably have comments.

So it uses each subaddress to identify a channel. The sender sends their subaddress for replies, along with the spam fee. You can do an ECDH of spend keys and only have 64b to open the channel then.

And then all messages are encrypted. Combined with a 16b magic header on all further messages, you don't need further signatures to guarantee message origin and validity

Right. Just the fact the semder knows the destination.

*the 64b is just the subaddress for replies. You can also always use ffff to open channels by having the person who accepts their channel initially reply with the gold in return + the specific subaddress on their end, which it sounds like you were already thinking.

Right. So you use 16 magic bytes to check validity/origin. You specifically have 5 * 252 bits. 141.5 bytes after -16.

github.com/SarangNoether/skunkworks…/pybullet-plus/pybullet/pybullet.py, grep for aux

If you can specify an alphanumeric character set, which isn't inclusive and a bad idea for this, you can get hundreds of characters.

I use a text compression algorithm (unishox2).

Then it gets encrypted with a shared secret (IIRC).

Interesting

Though I didn't code it, since too little space, so maybe there are obstacles I did not see.

But yes, 150 bytes is wheeee here I come :D

moneromooo: Right. Just pipe that into `clsag.s`, for whatever decoys you don't care about (<= 5). Make sure you prefix with 16 magic bytes pre-encryption, post-compression ;)

And then use the encrypted amount to signal which decoys were replaced with messages

Got it. Thanks.

and if possible (you hit the scalar modulus, potentially), flip a coin to set the 253rd bit as well

and when decrypting, clear that bit

Because 5 decoys past the standard chance on if the 253rd bit is set may be minorly notable. Accordingly, if it can be set... I'm sure there's some odds to best restore natural chance.

Oh, subtle.

But not a statistician, just a developer, ping Rucknium for which 5 to replace and to be proper, run math to get the odds of that bit being set in order to best replicate it :p

Since it's arguably on topic... I originally intended to have 31.5 bytes come from the non-change output, when it's a dummy (0 amount) one.

Yep. Even two-out TXs have some degree of steg possible :/

Or you just add a bunch more outs lol

However, even if we don't need it to be spendable, it still must be well formed to pass is_out_to_acc. So I don't think I can stuff much in it.

I believe I was looking at adding 2

Do you think it's feasible (beyond brute forcing) ?

wdym

With points, you have to brute force the top bits until it lines up. With scalars, you don't have that risk

Yes, that's fine, the number of inc/dec can be stored elsewhere to recover. That's not a problem.

IIRC the number is an exponentual distribution, so few bits needed.

You don't even have to here. Those 252 bits are guaranteed as usable.

Yes, but not in a contiguous domain.

And then there probably is some statistical attacks. 16 fitting the distribution on the surface may not have an 11 which also fit, once you cancel out 5.

So you still need to adjust.

... no? Unless I'm misunderstanding you

Any scalar value of 252 bits is valid.

Hmm. We may be tlakng about differnet things. I was on about stuffing 31.5 bytes in a curve point.

So since we're discussing replacing scalars, any thing you put there, as long it's 252-bit chunked, is valid.

Scalars is contiguous, yes.

Right lol

These aren't points

So not an issue

OK. I was still on about stuffing data in a dummy output pubkey :D

Which I think I can't do anymore, but... 31.5 bytes...

Though for monero use, the privacy drop is a bit unfortnuate, since that's why I stopped working on porting sarang's PoC to C++...

It's not as bad, sure...

I prefer outputs, which will also survive Seraphis, to `clsag.s`. For your desire, which is TXs without distinction and not increasing load, `clsag.s` makes sense. I don't appreciate asking users for a privacy reduction though in my use case :/

And tbc, no, I'm not saying you appreciate it either :p With the increase in ring size, we actually don't 'lose' privacy from our current reference point so it's fine.

But yeah, this is why TX extra/outputs makes sense.

Oh. It's also 157.5 bytes per input, not just per TX 👀