MRL meeting in this room in two hours.

Meeting time! monero-project/meta #913

1) Greetings

<v​tnerd:monero.social> Hi

Hello

2) Updates. What is everyone working on?

<j​berman:matrix.org> hello

<h​into.janaiyo:matrix.org> hi

<v​tnerd:monero.social> still on subaddresses in lws :/ getting to the testing phase though; the upsert algorithm is a pain

me: Translating jeffro256's explanation of the wallet2 decoy selection algorithm ( github.com/jeffro256/monero/blob/de…election_md/docs/DECOY_SELECTION.md ) into a mathematical formula.

My draft is here. It might have an off-by-one error, but It's close to done: overleaf.com/read/ndbtkwrbrdjq

<j​berman:matrix.org> 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++

3) Discussion. What do we want to discuss?

<j​berman:matrix.org> 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: monero-project/research-lab #59#issuecomment-1778565614

<j​berman:matrix.org> 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

<j​berman:matrix.org> tagging UkoeHB in case they're around too

Do you have a link to that discussion about separating?

Also already quite a while back, I think

And maybe a bit less pressing due to changes in p2pool, if I remember correctly

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.

<j​berman:matrix.org> you mean a discussion about combining? here's a link about separating coinbase from non-coinbase: monero-project/research-lab #109

Users producing transactions today cannot create a non-RingCT enote, right? I can't remember the non-mixable rules exactly.

jberman: Yup, that one, thanks

<j​berman:matrix.org> it's not possible to combine current RingCT and Seraphis enotes in the same ring, no

<j​berman:matrix.org> users producing txs today *can* create non-RingCT enotes

<j​effro256:monero.social> Hi sorry Im late

Combining RingCT and non-RingCT enotes in the same ring would be a new feature under the Seraphis proposal, right? Cannot do that today.

<j​berman:matrix.org> IIRC double checking

<j​berman:matrix.org> correct, combining ringCT and non-RingCT in the same ring would be a new feature

<j​berman:matrix.org> and cannot do that today

<j​effro256:monero.social> What would be the benefit of that? To me, that seems like you would be reducing your anon set OR revealing your amount

<j​berman:matrix.org> the benefit would be providing greater anonymity for very old pre-RingCT outputs

<j​effro256:monero.social> So would everyone include a couple very old pre-RingCT outputs in their rings?

<j​berman:matrix.org> no they would just be included in the set of all enotes from which the wallet would select decoys

<v​tnerd:monero.social> 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

<j​berman:matrix.org> it works the same way you can include coinbase outputs in rings today

<j​berman:matrix.org> as per this issue: monero-project/research-lab #59

<j​berman:matrix.org> Rucknium: here's a comment I wrote in the past explaining how it's possible to create pre-RingCT outputs today: monero-project/monero #8178#issuecomment-1081307990

<v​tnerd:monero.social> ah right. This is separate from seraphis then, but still requires a hard-fork iirc

<j​berman:matrix.org> right

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 ...

And maybe hordes of people running into the problem that they don't have enough harddisk / SSD space for something like that

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.

FWIW, I support requiring coinbase and non-coinbase enotes to be in separate rings.

<j​berman:matrix.org> 8 bytes per output + 8 bytes per block I think would be the extra data stored, so nothing crazy

<j​effro256:monero.social> 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

<j​berman:matrix.org> yes to your question

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.

<j​berman:matrix.org> that's probably a fair point. especially if you have a single tx with >1 rings with a pre-RingCT output in it

Right now I'm ignoring non-RingCT outputs in the new proposed decoy selection algorithm distribution.

<j​berman:matrix.org> and spending pre-RingCT outputs a user probably has multiple which would be spent in a single tx

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.

<j​berman:matrix.org> that's true, but it's even easier with pre-RingCT

<j​berman:matrix.org> and we're talking about a change to enhance privacy specifcally for spending very old outputs

Seems like a hard sell to me, without understanding all the details yet however

<j​berman:matrix.org> 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

Maybe for a true privacy gain one would have to build a ring only out of pre-RingCT txs?

Party like it's 2017 :)

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?

<j​effro256:monero.social> 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

<j​effro256:monero.social> Haha you read my mind

I can come back next week with data on how many recent rings have pre-RingCT enotes. Or in a couple of days.

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 ...

<j​effro256:monero.social> 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.

<j​berman:matrix.org> "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 <clipped message>

<j​berman:matrix.org> a single ring, and create RingCT outputs (or Seraphis enotes)

jeffro256: Good summary

Ah, I see

Already a lot of complexity built in for something that now must be quite rare

There are probably more txs created with nonstandard fees in a week than txs using non-RingCT enotes in a year.

Just the old pre-RingCT tx construction code left standing then, I guess

<j​berman:matrix.org> 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

<j​effro256:monero.social> 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

I like jeffro's idea of producing an error or required confirmation in wallet2 if you don't self-spend non-RingCT enotes first.

But that would be only up to the Seraphis hardfork?

<j​berman:matrix.org> no, for after too, since pre-ringct outputs need to always be spendable using the Seraphis wallet lib

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?

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.

<j​berman:matrix.org> 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

<j​effro256:monero.social> 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

With a DSA that matches the real spend age distribution, that shouldn't really be a concern to every user.

Since a quick re-spend would be just as likely to be a decoy.

<j​effro256:monero.social> True

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?

Yes, but why waste ring member slots?

Well, because maybe the added complexity is not worth the presumably little privacy gain, with 128-member rings?

<j​berman:matrix.org> 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

<j​berman:matrix.org> where older outputs = any output pre-Seraphis

Sometimes? What would be the condition then?

<j​berman:matrix.org> users have to migrate their older outputs into Seraphis enotes, in order to construct Seraphis membership proofs

<j​berman:matrix.org> that migration happens in a tx. any time you spend a pre-Seraphis output that existed in the chain before the Seraphis fork

jeffro256 has already written code to not spend coinbase outputs in rings IIRC. He can say how high the complexity is.

Ok. Here we have a tangle of so many things all influencing each other that my poor brain is overloaded right now.

I mean, in rings that spend non-coinbase enotes.

<j​effro256:monero.social> How do you migrate outputs which you don't know the private key of ?

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

Huh? You don't, I assume.

<j​berman:matrix.org> you migrate your own outputs in a migration tx. maybe "migration tx" is a poor term

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 :)

<j​berman:matrix.org> 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 <clipped message>

<j​berman:matrix.org> then in future txs be included in Seraphis-style membership proofs

<j​effro256:monero.social> Can I not construct a Seraphis tx with normal CLSAG inputs on RingCT ring members which creates new Seraphis enotes?

<j​effro256:monero.social> Oh okay that's how I assumed it worked

<j​effro256:monero.social> 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

<j​berman:matrix.org> ah

<j​berman:matrix.org> does it all make sense now rbrunner ?

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.

We are past the hour. Discussion on this can continue here and on the GitHub issue.

jberman: Yes, but now you still have to add pre-RingCT txs into the picture, seems to me

<j​effro256:monero.social> 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

<j​berman:matrix.org> 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

<j​berman:matrix.org> i.e. either those CLSAG rings could potentially include {pre-ringCT, ringCT, coinbase} outputs all in the same ring, or the latter

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 :)

It's so exhausting to be, and to stay, a real and trustworthy cryptocurrency

<j​effro256:monero.social> Fr

<j​berman:matrix.org> 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

<j​effro256:monero.social> So the seraphis wallet lib already mixes pre-RingCT and RingCT ?

<j​berman:matrix.org> yes

<j​berman:matrix.org> 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

<j​berman:matrix.org> (consensus changes, database migration, RPC changes)

<j​effro256:monero.social> 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