09:59:20 <Snipa> .merges
09:59:20 <xmr-pr> Merge queue empty
15:26:07 <sarang> Are there any other major changes planned for the next network upgrade?
15:26:19 <sarang> No CLSAG code changes are needed as a result of the security audit
15:31:50 <moneromooo> I want to change the unlock time, I've been meaning to do this for years really.
15:32:14 <moneromooo> But someone's prodded me about it not long ago, so I might get to it :)
15:32:46 <moneromooo> Can't think of anything else atm.
15:33:19 <moneromooo> (just straightening stuff, technically a consensus change, but nothing wil change in practice)
15:33:46 <moneromooo> I think I had something else I wanted for a fork but I can't find anything in my list.
15:34:19 <moneromooo> Ah, there was the "pre-divie key image by 8" thing... :)
15:34:19 <sarang> No CLSAG-related changes from the audit, right?
15:34:35 <sarang> They had only two informational suggestions that are not security-related
15:34:36 <moneromooo> Not that I know of. But you'd know better than me here.
15:34:50 <moneromooo> Right, and nothing consensus related anyway.
15:34:54 <sarang> I didn't think they were necessary, and the type change thing would likely introduce more risk
15:35:50 <sarang> I do like the key image idea, but I understand that it was contentious
15:35:51 <fluffypony> moneromooo: make it shorter or longer?
15:35:56 <fluffypony> (unlock time)
15:36:07 <moneromooo> No functional change.
15:36:17 <moneromooo> Actually.
15:36:55 <moneromooo> It's currently stored as a full 64 bit unsigned IIRC. But coinbase txes check it's exactly 60.
15:37:10 <moneromooo> Might be worth removing it for coinbase, and hardcoding 60.
15:37:14 <moneromooo> Saves... 4 bytes ?
15:37:43 <moneromooo> I was going to say delta for all, but then it depends on when it is mined, which might be unwanted,
15:37:56 <sarang> every byte counts
15:38:06 <moneromooo> Delta also prevents stupid things like an unlock time < current height.
15:38:14 <sarang> I also want a cooler name for CLSAG, but I fear that ship has long sailed
15:38:37 <moneromooo> ZLSAG.
15:38:41 <moneromooo> Everything is better with a Z.
15:38:50 <moneromooo> Almost sounds the same.
15:39:00 <sarang> %s/C/Z/g
15:39:03 <sarang> done
15:39:11 <sarang> what could do wrong
15:39:34 <moneromooo> RingZT.
15:39:40 <dsc_> Nein!
15:40:41 <Isthmus> Delta from height of the youngest ring member perhaps?
15:41:00 <moneromooo> Interesting idea.
15:46:07 <moneromooo> Ah, maybe moving tx key / nonce outside extra and kill extra, since sgp mentioned people were gonna use extra for customer data.
15:46:33 <moneromooo> I'm coming round to the idea that the pros/cons are really not that good.
15:46:57 <sgp_> I believe those plans fell through fwiw, though of course anyone can use it for any reason at any time
15:47:49 <moneromooo> Or replacing with a fixed size (non consensus enforced) encrypted chunk.
15:48:15 <moneromooo> If the fixed size is high enough, we could also calculate entropy and consensus enforce high enough :D
15:48:23 <sgp_> tradeoff between bloat and sticking out
15:48:29 <moneromooo> OK, bad idea probably.
15:49:13 <sgp_> if we want to remove tx_extra, we need to aggressively ask for comment now
15:49:31 <sgp_> we don't know if we would be breaking anything
15:50:39 <moneromooo> Should be simple enough to list all txes that have unknown extra payload. AFAIK only minergate has its own thing.
15:51:19 <moneromooo> Then we get to ponder, if there's unknown stuff, does it add or remove incentive to break it :)
15:51:46 <Isthmus> !RemindMe 1 week
15:51:53 * Isthmus heads to the data mines
15:52:59 <sgp_> I still see this as something we need to super clearly announce ahead of time since we are potentially breaking.... who knows what lol
15:53:21 <Isthmus> Yea, let's set removal for 2022 or something. Better late than never, especially where transaction linkability is involved.
15:53:45 <Isthmus> @mooo replacing with enforced fixed-size encrypted would also get an upvote from me
15:54:18 <sarang> What good real-world use cases would that have, that couldn't be addressed with encrypted pID?
15:54:29 <moneromooo> I have a patch somewhere that does mostly that, but has a quantized set of allowed sizes.
15:54:45 <sarang> downvote for quantization / optional sizes
15:54:54 <moneromooo> Coloured coins maybe. Can that be encrypted ?
15:54:58 <sarang> IMO it should be all or nothing (and I'd prefer nothing, since pID exist)
15:55:05 <moneromooo> One single size is a special case of quantized :)
15:55:10 <sarang> Oh, multiple assets for outputs? Yes
15:55:22 <sarang> There are a couple of ways to do it
15:56:10 <moneromooo> What I wanted to have is encrypted data where you can stuff json for the recipient. Then recipient/sender agree on a set of fields they want to exchnge.
15:56:34 <moneromooo> That said, it's kinda a solution is search of a problem maybe.
15:57:24 <sarang> Even if nothing else makes it besides CLSAG, that's still a huge improvement
15:57:30 <sarang> 25% smaller, 20% faster
15:57:50 <sarang> better security model
15:57:54 <sarang> audited signature code
15:58:09 <sgp_> I'm still pushing for coinbase-only sings but no one else seems interested in those
15:58:13 <sgp_> *rings
15:58:47 <sarang> I marginally like the idea
15:59:25 <moneromooo> I can't help but feel that it's what someone who wanted to deanonymize solo miners would do.
15:59:49 <sarang> sgp_: can you read through the blog post draft I posted to -community about CLSAG?
16:00:00 <sgp_> yeah one sec
16:00:22 <sarang> no rush
16:00:25 <sgp_> I know we love solo miners, but think of all the other users too...
16:00:27 <sarang> can't post it for a while anyway
16:00:53 <moneromooo> Because we don't. Obviously.
16:01:22 <sgp_> it's just one of those things where if we ask the solo miners for a small favor, then everyone else is much better off
16:03:57 <hyc> I really don't see the threat
16:05:05 <sgp_> hyc: which threat?
16:05:11 <hyc> singling out coinbase outputs into separate rings kind of destroys their anonymity set
16:05:23 <luigi1111w> I see benefit of having coinbase inputs not part of normal rings
16:05:36 <luigi1111w> but ~no benefit of having their own rings
16:05:36 <hyc> letting them be randomly selected in normal rings keeps them ... random
16:06:00 <moneromooo> OK, I said I'd trust MRL if they gave the ok to it, I'd also trust luigi1111w.
16:06:04 <sgp_> luigi1111w: how could we enforce that behavior by consensus?
16:06:28 <hyc> luigi1111: I don't understand. if they're not part of normal rings, and don't have their own rings, then how can they be spent at atll?
16:06:34 <luigi1111w> 0 rings
16:06:41 <luigi1111w> why have rings at all if they publish their txs
16:06:45 <hyc> ah
16:06:51 <sgp_> oh so you mean make coinbase spends have no decoys
16:06:54 <luigi1111w> just theater that wastes space
16:07:12 <sgp_> that's the reality really, yeah
16:07:43 <sgp_> I'm mostly in favor of keeping the ringsize 3 for coinbase, since the cost is tiny and the benefits could be larger than the tiny cost
16:08:08 <sarang> From a graph analysis perspective, any removal of coinbase from standard rings moves heuristics effectively one hop
16:08:19 <sarang> Which can be marginally beneficial
16:08:26 <sarang> Hence I marginally support the idea overall
16:08:41 <sgp_> imo those benefits are downplayed
16:09:33 <Isthmus> @sarang good point, RE encrypted memo field = ePID. Probably not necessary to have both, could just expand ePID length to desired data payload size
16:10:05 <hyc> whatever fixed size you choose will always be "not big enough"
16:10:10 <sgp_> luigi1111w: what are your thoughts about c_ringsize 3?
16:10:20 <sarang> Isthmus: I think it really comes down to whether it's optimal to have enough space for arbitrary data, or enough for a reasonable side-channel identifier (like pID is now)
16:10:32 <luigi1111w> seems pointless
16:11:53 <luigi1111w> the chances of not having "poisoned" inputs is pretty small at 3, surely
16:12:02 <luigi1111w> so the size isn't large, but the benefit is ~zero
16:12:07 * Isthmus is just making a technical note and not commenting on whether or not it's something we should do
16:13:04 <sgp_> I think the unpredictability helps reduce the effectiveness of mass surveillance, not really something to be relied upon for individual protection if that makes sense
16:13:46 <sgp_> makes things like associating outputs by timing of spends more difficult, for example
16:14:35 <sgp_> I'm not strongly in favor of this, but I think the benefits are greater than the cost
16:20:59 <UkoeHB_> Isthmus: did you ever submit a PR for fixed coin base amounts?
16:22:23 <Isthmus> Oops, forgot to put that in. Probably have time for that on Saturday.
16:22:51 <sarang> ?
17:19:03 <sgp_> this is not a consensus change, but thoughts on https://github.com/monero-project/monero/issues/5222?
17:19:24 <sgp_> I edited it to show that it applies to all public wallets, not just public mining pools
17:59:25 <sarang> Oh, another CLSAG thing... I've reached out to the Ledger and Trezor folks for a status update, since that will be an important part of the upgrade process that should go smoothly
18:00:04 <sarang> moneromooo: I suppose the `clsag-device` branch should be rebased and tested?
18:00:08 <sarang> See if anything conflicts/breaks?
18:07:15 <moneromooo> Probably. I try to rebase often, less pain this way.
18:07:30 <moneromooo> Are you asking me to do it ?
18:10:37 <sarang> I can do it, provided it doesn't get too awful :D
18:11:02 <sarang> I'm trying to figure out what a good timeline is
18:11:02 <moneromooo> I can do it if you'd rather, and point me to the correct branch.
18:11:20 <sarang> Since I assume the Trezor and Ledger teams would like something relatively final to base their work on
18:11:24 <sarang> and eventually they'll need testnet
18:11:41 <sarang> Here's the audited branch: https://github.com/SarangNoether/monero/tree/clsag-device
18:12:01 <moneromooo> Oh. If I do it, I will just ignore ledger/trezor and leave that to the relevant poeple. I'll just fix conflicts but not test.
18:13:03 <sarang> Right. My understanding (waiting to hear back) is those teams have firmware stuff on their own timeline, but ideally want to know what code/network to test against prior to release
18:13:39 <sarang> That branch already includes some of cslashm's device-specific work