15:03:35 MRL meeting in this room in two hours. 17:00:44 Meeting time! https://github.com/monero-project/meta/issues/913 17:00:52 1) Greetings 17:01:24 Hi 17:01:55 Hello 17:03:20 2) Updates. What is everyone working on? 17:03:23 hello 17:04:08 hi 17:04:26 still on subaddresses in lws :/ getting to the testing phase though; the upsert algorithm is a pain 17:04:27 me: Translating jeffro256's explanation of the wallet2 decoy selection algorithm ( https://github.com/jeffro256/monero/blob/decoy_selection_md/docs/DECOY_SELECTION.md ) into a mathematical formula. 17:05:11 My draft is here. It might have an off-by-one error, but It's close to done: https://www.overleaf.com/read/ndbtkwrbrdjq 17:06:41 me: hardening the Seraphis wallet lib scanner for legacy wallet scanning + some work on fcmp integration getting the rust code running from the monero repo in c++ 17:07:19 3) Discussion. What do we want to discuss? 17:08:20 I wrote up a comment yesterday regarding Seraphis migration txs including {pre-RingCT, post-RingCT, coinbase} outputs as members of the same ring signature here: https://github.com/monero-project/research-lab/issues/59#issuecomment-1778565614 17:08:45 I believe it's been discussed in the past in MRL, but since then, there's been a solid push to separate coinbase outputs when spending, which is at odds with that design decision for Seraphis, so wanted to bring it back up for discussion 17:09:34 tagging UkoeHB in case they're around too 17:11:27 Do you have a link to that discussion about separating? 17:11:40 Also already quite a while back, I think 17:12:05 And maybe a bit less pressing due to changes in p2pool, if I remember correctly 17:12:19 Would it be possible to combine current RingCT and Seraphis enotes in the same ring? I thought the answer was "no", but I want to check. 17:13:49 you mean a discussion about combining? here's a link about separating coinbase from non-coinbase: https://github.com/monero-project/research-lab/issues/109 17:13:52 Users producing transactions today cannot create a non-RingCT enote, right? I can't remember the non-mixable rules exactly. 17:14:32 jberman: Yup, that one, thanks 17:14:33 it's not possible to combine current RingCT and Seraphis enotes in the same ring, no 17:15:22 users producing txs today *can* create non-RingCT enotes 17:16:19 Hi sorry Im late 17:16:29 Combining RingCT and non-RingCT enotes in the same ring would be a new feature under the Seraphis proposal, right? Cannot do that today. 17:16:32 IIRC double checking 17:16:55 correct, combining ringCT and non-RingCT in the same ring would be a new feature 17:17:05 and cannot do that today 17:18:15 What would be the benefit of that? To me, that seems like you would be reducing your anon set OR revealing your amount 17:18:49 the benefit would be providing greater anonymity for very old pre-RingCT outputs 17:19:33 So would everyone include a couple very old pre-RingCT outputs in their rings? 17:20:27 no they would just be included in the set of all enotes from which the wallet would select decoys 17:20:31 I dont see how this works given that those outputs had public amounts. Could you have multiple pre-ringct outputs in a ring? I guess it would work because only the ZKP would "know" which amount was the real one 17:20:59 it works the same way you can include coinbase outputs in rings today 17:21:23 as per this issue: https://github.com/monero-project/research-lab/issues/59 17:22:19 Rucknium: here's a comment I wrote in the past explaining how it's possible to create pre-RingCT outputs today: https://github.com/monero-project/monero/pull/8178#issuecomment-1081307990 17:22:28 ah right. This is separate from seraphis then, but still requires a hard-fork iirc 17:22:45 right 17:24:23 From your comment, what would be needed: "A database migration that stores total output counts not keyed by amount" People would probably cry out in joy ... 17:25:42 And maybe hordes of people running into the problem that they don't have enough harddisk / SSD space for something like that 17:25:45 I think there's a small privacy benefit to allowing pre-RingCT and RingCT enotes in the same ring. Is it worth the engineering effort? You have to change how the RPC responds when wallets ask it for the output age distribution, too. 17:27:02 FWIW, I support requiring coinbase and non-coinbase enotes to be in separate rings. 17:27:31 8 bytes per output + 8 bytes per block I think would be the extra data stored, so nothing crazy 17:28:13 So if a pre-RingCT output were to be spent, they would not do decoy selection from outputs with their amount, but instead everything? I think this has a couple trade offs. Since in the future, those outputs will be so so old. If we naively make a heuristic that says "if an old pre-RingCT output is in a ring, it's the true spend", we might actually be correct more often than not 17:29:07 yes to your question 17:29:52 If the decoy selection distribution is set up correctly, then that heuristic shouldn't work. Setting it up correctly would require more work and thought. 17:30:09 that's probably a fair point. especially if you have a single tx with >1 rings with a pre-RingCT output in it 17:30:55 Right now I'm ignoring non-RingCT outputs in the new proposed decoy selection algorithm distribution. 17:31:28 and spending pre-RingCT outputs a user probably has multiple which would be spent in a single tx 17:32:00 If you have a big consolidation (lots of inputs) of very old outputs, then it's easier to guess the real spend even if they are RingCT enotes. 17:32:55 that's true, but it's even easier with pre-RingCT 17:33:19 and we're talking about a change to enhance privacy specifcally for spending very old outputs 17:34:29 Seems like a hard sell to me, without understanding all the details yet however 17:34:37 i.e. we're talking about a likely situation where the user isn't getting much benefit anyway from constructing a ring sig that includes both ringCT and pre-RingCT 17:35:21 Maybe for a true privacy gain one would have to build a ring only out of pre-RingCT txs? 17:35:43 Party like it's 2017 :) 17:35:54 The best thing for users with pre-RingCT outputs to do is to self-spend so their outputs are RingCT. How many of those users know that? 17:36:17 We could put in a wallet rule that if you're spending old outputs, you should churn to yourself once first so that the amount is definitely hidden during the next tx 17:36:27 Haha you read my mind 17:38:07 I can come back next week with data on how many recent rings have pre-RingCT enotes. Or in a couple of days. 17:38:14 And the CLI wallet would most probably the only one that would really bother to properly implement that including informing the user in a sensible way ... 17:39:29 Because some output amount anon sets are genuinely tiny (i.e. they're "unmixable"). There's a lot of edge cases to consider with spending pre-RingCT outputs, but basically all of them can be fixed if you churn to yourself first, then reap the benefit of the large anon set and hidden amounts of all RingCT outputs. 17:39:44 "Maybe for a true privacy gain one would have to build a ring only out of pre-RingCT txs?" -> this is already the case, except when spending a pre-RingCT amount that doesn't have enough amounts to mix with. Today wallets mix pre-RingCT with other pre-RingCT outputs of the same amount. Technically this could be changed with a hard fork to allow spending pre-RingCT of any amount in 17:39:44 a single ring, and create RingCT outputs (or Seraphis enotes) 17:40:01 jeffro256: Good summary 17:40:22 Ah, I see 17:40:52 Already a lot of complexity built in for something that now must be quite rare 17:41:13 There are probably more txs created with nonstandard fees in a week than txs using non-RingCT enotes in a year. 17:41:27 Just the old pre-RingCT tx construction code left standing then, I guess 17:42:14 agree this is added complexity for something rare, I'm generally for a warning in wallets and moving forward, bu the Seraphis wallet lib would need to be modified to match this behavior from wallet2 too 17:42:14 And pre-RingCT spends get rarer and rarer each month, I don't know if its worth adding consensus rules to accommodate that when you can get the same benefits if you exert a little bit extra tx fees 17:42:31 I like jeffro's idea of producing an error or required confirmation in wallet2 if you don't self-spend non-RingCT enotes first. 17:43:11 But that would be only up to the Seraphis hardfork? 17:43:38 no, for after too, since pre-ringct outputs need to always be spendable using the Seraphis wallet lib 17:44:31 Do I understand correctly that this would mean to swap out the library's current solution to that pre-RingCT spending case, and program a new one? 17:45:07 The small downside of a strongly suggested self-spend is that it is likely that the real spend will happen a short time after that spend. But with 128+ ring size, that is less of a concern. 17:45:54 correct rbrunner . I think that would still be simpler than the alternative which is: consensus changes to support pre-RingCT + post-RingCT in the same ring, database migration, and RPC changes 17:46:42 And again, if we wanted to really be authoritative about the privacy in this case, we could force (or at least warn) users not to spend these outputs immediately after they're unlocked. But that's honestly a concern for every single user with the 10-block-lock 17:49:48 With a DSA that matches the real spend age distribution, that shouldn't really be a concern to every user. 17:50:47 Since a quick re-spend would be just as likely to be a decoy. 17:51:06 True 17:53:13 I am a bit confused now, frankly. That problem with those coinbase enotes, doesn't that get a lot less problematic with those large Seraphis rings? 17:53:47 Yes, but why waste ring member slots? 17:54:38 Well, because maybe the added complexity is not worth the presumably little privacy gain, with 128-member rings? 17:55:18 one thing I wanna make clear: even after the Seraphis hard fork, users would still need to construct 16 member rings *sometimes* when spending older outputs 17:55:39 where older outputs = any output pre-Seraphis 17:56:13 Sometimes? What would be the condition then? 17:56:19 users have to migrate their older outputs into Seraphis enotes, in order to construct Seraphis membership proofs 17:57:04 that migration happens in a tx. any time you spend a pre-Seraphis output that existed in the chain before the Seraphis fork 17:57:47 jeffro256 has already written code to not spend coinbase outputs in rings IIRC. He can say how high the complexity is. 17:57:56 Ok. Here we have a tangle of so many things all influencing each other that my poor brain is overloaded right now. 17:58:10 I mean, in rings that spend non-coinbase enotes. 17:58:58 How do you migrate outputs which you don't know the private key of ? 17:59:07 I think interesting is the complexity past-Seraphis-hardfork, and the new, additional work needed to get there, and what we win with all this 17:59:42 Huh? You don't, I assume. 17:59:44 you migrate your own outputs in a migration tx. maybe "migration tx" is a poor term 18:01:40 Arrange a wishlist of privacy features. Measure their privacy benefit and engineering effort. Then do a cost-benefit analysis to choose which ones to include :) 18:01:57 I receive a 0.5 Monero RingCT output today. Let's assume the Seraphis hard fork is 1 year from now. After the Seraphis hard fork, when I spend this 0.5 Monero RingCT output, my wallet would need to construct a CLSAG 16 member ring composed of pre-Seraphis outputs. That is the "input" side of the tx. On the "output" side of the tx, my wallet would create Seraphis enotes, which can 18:01:58 then in future txs be included in Seraphis-style membership proofs 18:01:58 Can I not construct a Seraphis tx with normal CLSAG inputs on RingCT ring members which creates new Seraphis enotes? 18:02:45 Oh okay that's how I assumed it worked 18:03:24 It sounded like you were saying that you migrate the outputs in the transaction then immiedately use them in Seraphis membership proofs in the same tx 18:03:48 ah 18:03:56 does it all make sense now rbrunner ? 18:04:00 The 16 ring size for CLSAG could be raised when the Seraphis hard fork goes into effect AFAIK. That would increase the tx size of those tx a lot. 18:07:06 We are past the hour. Discussion on this can continue here and on the GitHub issue. 18:08:24 jberman: Yes, but now you still have to add pre-RingCT txs into the picture, seems to me 18:08:52 Yeah the complexity was sort of high but honestly not too bad. My solution used a database migration just because it was miles faster. I simply created a table which was exactly like the RingCT distribution but only for coinbase outputs. You then download those two distributions over RPC, then according to which output you're spending, you pick from the corresponding distribution 18:12:03 rbrunner: right. either those CLSAG rings could be composed of the set of {pre-RingCT, RingCT, coinbase} outputs, or pre-RingCT rings can be kept separate from RingCT the same as wallet2 (and consensus) implements today 18:13:27 i.e. either those CLSAG rings could potentially include {pre-ringCT, ringCT, coinbase} outputs all in the same ring, or the latter 18:15:29 Sometimes I wish we could just emulate the nonsense and borderline scams of other coins and force all users through a non-trustless coin swap here. Problems solved :) 18:16:53 It's so exhausting to be, and to stay, a real and trustworthy cryptocurrency 18:19:26 Fr 18:19:33 honestly the Seraphis hard fork isn't particularly relevant to the decision of whether or not to include pre-RingCT and RingCT outputs in the same ring, like vtnerd was saying. I mentioned it because the Seraphis wallet lib does that 18:20:10 So the seraphis wallet lib already mixes pre-RingCT and RingCT ? 18:20:16 yes 18:21:02 it constructs txs like that, but there is still a lot of work that needs to be done to actually make it work in a wallet 18:22:05 (consensus changes, database migration, RPC changes) 18:23:06 interesting... I would prefer it to not be able to mix (at consensus) unless there's evidence that points to it being a net positive for privacy. So I would (personally, but I can't tell anyone what to do) hold off on that work