10:19:44 <kayabanerve[m]> <liamswenson[m]> "Can the utility of tx_extra..." <- No, as I detailed in my response on its issue.
10:21:36 <kayabanerve[m]> It's the first segment of this post https://github.com/monero-project/monero/issues/6668#issuecomment-1196312004
10:21:59 <kayabanerve[m]> There's dramatically more utility in the L1 you're operating over carrying the data that using linkable solutions
10:22:41 <kayabanerve[m]> 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.
10:25:18 <kayabanerve[m]> So the options are:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d8d64e8deaee1cf5f791168118d2d24fd09a3715)
10:31:14 <kayabanerve[m]> 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.
10:32:07 <rbrunner> 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?
10:32:43 <kayabanerve[m]> Bulletproofs do not provide a chance for steg
10:33:04 <rbrunner> So do I confuse this with something else?
10:33:19 <kayabanerve[m]> I will note I'm mainly interested in seeing what ArticMine's addition to 6668 will be, as they said they will comment there
10:33:21 <moneromooo> It is possible, but leaks some data (I forget what exactly) to the recipient.
10:33:31 <kayabanerve[m]> rbrunner: CLSAGs do, and then outputs do
10:33:52 <rbrunner> Ah, ok
10:33:55 <moneromooo> Oh. I might be confusing with CLSAGs.
10:34:11 <kayabanerve[m]> 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
10:34:25 <kayabanerve[m]> And then points can't be stegged if you're ever expected to know the discrete log
10:34:38 <kayabanerve[m]> So with CLSAGs, the recipient knows the decoys used for steg are decoys.
10:35:17 <kayabanerve[m]> 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.
10:35:34 <moneromooo> It was BP+. Dunno about BP.
10:38:12 <kayabanerve[m]> Double checking, turns out my comment was about +. BP has a different set of scalars yet still none are usable
10:43:58 <kayabanerve[m]> 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 
13:57:05 <TrasherDK[m]> 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?
14:01:45 <moneromooo> I assume steganography.
14:01:50 <UkoeHB> TrasherDK[m]: it's kayabanerve[m]'s abbreviation for steganography
14:02:21 <kayabanerve[m]> steganography is a long word not in my phone's dictionary for some reason :(
14:02:28 <TrasherDK[m]> Okay. Got it.
14:03:09 <moneromooo> 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 :(
14:03:42 <moneromooo> 32 bytes for BP gone, 32 bytes for a dummy outpub pub key gone... 
14:03:45 <TrasherDK[m]> What is the computational cost for the device decoding the steganography ?
14:03:46 <kayabanerve[m]> 150 bytes in CLSAG, ~500 english characters wasn't enough?
14:04:05 <kayabanerve[m]> *key word being English. I had a very limited charset proposed.
14:04:28 <kayabanerve[m]> TrasherDK: Not the worst. Just some stream cipher
14:04:29 <moneromooo> 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 ?
14:04:44 <kayabanerve[m]> yeah
14:04:54 <TrasherDK[m]> Thanks.
14:04:56 <moneromooo> I must have missed that :o
14:05:05 <kayabanerve[m]> The recipient will know instead of 16 decoys, you only have 11 though.
14:05:23 <kayabanerve[m]> But yes, you can forfeit any decoy you want to the decoder in exchange for 252 bits each.
14:05:28 <moneromooo> I was left with a couple bits off ring members, and 8 bytes off the amount (which I'd know) :D
14:05:56 <kayabanerve[m]> Any competent encryption algorithm will give you uniform appearing data. You'd abuse the encrypted amount to say which decoys where actually messages
14:05:59 <moneromooo> (plus a few bits here and there by brute forcing some values by the sender)
14:06:41 <moneromooo> In my case the recipient know the amount is 0, so I can stuff any encrypted data in it.
14:06:46 <kayabanerve[m]> 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
14:07:23 <moneromooo> Oh, your 150 bytes come from stuff *all* in the offsets ?
14:07:27 <kayabanerve[m]> 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 ;)
14:07:31 <moneromooo> stuffing
14:07:38 <kayabanerve[m]> No, from the `s` vector
14:07:50 <kayabanerve[m]> The `s` vector is completely random except for the true signature
14:08:06 <moneromooo> Oh really. Very nice. I shall reuse your system :D
14:08:10 <kayabanerve[m]> So you can put non-random data there without issue. If it's encrypted, and appears random accordingly, there's no impact.
14:08:21 <kayabanerve[m]> Oh I'm not building this lol
14:08:27 <kayabanerve[m]> I hate blockchain messengers :p
14:08:29 <moneromooo> aw...
14:08:33 <kayabanerve[m]> I just enjoy steg lol
14:08:46 <kayabanerve[m]> *I may do a PoC in Rust ;)
14:09:08 <moneromooo> Well, I had given up due to the dearth of available bits, so I might code it up then.
14:09:20 <kayabanerve[m]> But I'm planning on using extra for my work
14:09:52 <kayabanerve[m]> I'd be up for collab'ing on the design if you want something a bit more formal than code present in Townforge ;)
14:10:00 <moneromooo> 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.
14:10:25 <moneromooo> Well, I'd make it more generic for monero ofc.
14:10:33 <kayabanerve[m]> ... I don't even know where you got 32 bytes in BP+ 🤔
14:10:56 <kayabanerve[m]> But there should be absolutely no issue with using `s` other than the reversion in privacy. It cancels out the upcoming ring size increase
14:11:08 <moneromooo> Can you read python ? I can point you to sarang's python PoC if so.
14:11:19 <moneromooo> "reversion in privacy" ?
14:11:31 <kayabanerve[m]> 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)
14:11:53 <kayabanerve[m]> moneromooo: Any decoys used for messages are obvious as decoys to whoever knows they're a message (the recipient)
14:12:10 <kayabanerve[m]> Therefore, they're not valid as decoys. Decoys should be indistinguishable from the real spend
14:12:13 <kayabanerve[m]> moneromooo: And yes
14:12:23 <moneromooo> 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.
14:12:46 <kayabanerve[m]> You can just send a 16-byte ID
14:12:59 <moneromooo> Ah, so that's the same issue as the BP+ one then :/
14:13:27 <kayabanerve[m]> As in, you establish a channel, and then have a 16-byte ID identify the channel for all future communications
14:13:48 <kayabanerve[m]> (or a 32-byte ID or a 252 bit ID)
14:14:05 <kayabanerve[m]> Did the BP+ solution reveal amounts?
14:14:17 <kayabanerve[m]> To be clear, this doesn't reveal the real spend. It just decreases the amount of decoys hiding it
14:14:31 <kayabanerve[m]> With the ring size increase, it maintains the existing amount of decoys.
14:14:53 <moneromooo> Oh, I looked up what I thought of doing for auth'd sender:
14:15:10 <kayabanerve[m]> 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
14:15:28 <moneromooo> 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).
14:15:48 <kayabanerve[m]> 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.
14:15:50 <moneromooo> Alice wants to send a PM to Bob, she sends a full sig, plus a 1 gold fee or whatever.
14:16:21 <moneromooo> 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.
14:16:58 <moneromooo> And sends ffff,fffd to Carol, etc. So know the sender without further data.
14:17:18 <moneromooo> I was really hyped about this system :D
14:17:48 <moneromooo> Hiding stuff in BP+ did not reveal amounts, just which ring member was thre real spend IIRC.
14:17:58 <moneromooo> I'll find the python code from sarang, it'll probably have comments.
14:19:08 <kayabanerve[m]> 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.
14:19:54 <kayabanerve[m]> 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
14:20:27 <moneromooo> Right. Just the fact the semder knows the destination.
14:20:57 <kayabanerve[m]> *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.
14:21:52 <kayabanerve[m]> Right. So you use 16 magic bytes to check validity/origin. You specifically have 5 * 252 bits. 141.5 bytes after -16.
14:22:22 <moneromooo> https://github.com/SarangNoether/skunkworks/blob/pybullet-plus/pybullet/pybullet.py, grep for aux
14:22:23 <kayabanerve[m]> If you can specify an alphanumeric character set, which isn't inclusive and a bad idea for this, you can get hundreds of characters.
14:22:45 <moneromooo> I use a text compression algorithm (unishox2).
14:23:01 <moneromooo> Then it gets encrypted with a shared secret (IIRC).
14:23:02 <kayabanerve[m]> Interesting
14:23:33 <moneromooo> Though I didn't code it, since too little space, so maybe there are obstacles I did not see.
14:23:45 <moneromooo> But yes, 150 bytes is wheeee here I come :D
14:24:21 * moneromooo adds to the TODO list again
14:24:23 <kayabanerve[m]> 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 ;)
14:24:38 <kayabanerve[m]> And then use the encrypted amount to signal which decoys were replaced with messages
14:25:00 <moneromooo> Got it. Thanks.
14:25:23 <kayabanerve[m]> and if possible (you hit the scalar modulus, potentially), flip a coin to set the 253rd bit as well
14:25:31 <kayabanerve[m]> and when decrypting, clear that bit
14:26:24 <kayabanerve[m]> 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.
14:26:24 <moneromooo> Oh, subtle.
14:27:08 <kayabanerve[m]> 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
14:27:39 <moneromooo> 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.
14:28:05 <kayabanerve[m]> Yep. Even two-out TXs have some degree of steg possible :/
14:28:12 <kayabanerve[m]> Or you just add a bunch more outs lol
14:28:16 <moneromooo> 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.
14:28:23 <kayabanerve[m]> I believe I was looking at adding 2
14:28:40 <moneromooo> Do you think it's feasible (beyond brute forcing) ?
14:29:14 <kayabanerve[m]> wdym
14:29:31 <kayabanerve[m]> With points, you have to brute force the top bits until it lines up. With scalars, you don't have that risk
14:30:01 <moneromooo> Yes, that's fine, the number of inc/dec can be stored elsewhere to recover. That's not a problem.
14:30:22 <moneromooo> IIRC the number is an exponentual distribution, so few bits needed.
14:30:26 <kayabanerve[m]> You don't even have to here. Those 252 bits are guaranteed as usable.
14:31:04 <moneromooo> Yes, but not in a contiguous domain.
14:31:09 <kayabanerve[m]> 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.
14:31:14 <moneromooo> So you still need to adjust.
14:31:33 <kayabanerve[m]> ... no? Unless I'm misunderstanding you
14:31:40 <kayabanerve[m]> Any scalar value of 252 bits is valid.
14:32:00 <moneromooo> Hmm. We may be tlakng about differnet things. I was on about stuffing 31.5 bytes in a curve point.
14:32:10 <kayabanerve[m]> So since we're discussing replacing scalars, any thing you put there, as long it's 252-bit chunked, is valid.
14:32:11 <moneromooo> Scalars is contiguous, yes.
14:32:12 <kayabanerve[m]> Right lol
14:32:15 <kayabanerve[m]> These aren't points
14:32:17 <kayabanerve[m]> So not an issue
14:32:36 <moneromooo> OK. I was still on about stuffing data in a dummy output pubkey :D
14:32:53 <moneromooo> Which I think I can't do anymore, but... 31.5 bytes...
14:50:52 <moneromooo> 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++...
14:51:00 <moneromooo> It's not as bad, sure...
15:45:09 <kayabanerve[m]> 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 :/
15:45:38 <kayabanerve[m]> 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.
15:45:44 <kayabanerve[m]> But yeah, this is why TX extra/outputs makes sense.
15:46:07 <kayabanerve[m]> Oh. It's also 157.5 bytes per input, not just per TX 👀