14:59:01 <Rucknium> MRL meeting in this room in two hours
17:00:41 <Rucknium> Meeting time! https://github.com/monero-project/meta/issues/905
17:00:47 <Rucknium> 1) Greetings
17:01:09 <tevador> Hi
17:01:12 <m-relay> <j​effro256:monero.social> Howdy
17:01:15 <rbrunner> Hello
17:02:47 <Rucknium> 2) Updates. What is everyone working on?
17:04:30 <m-relay> <j​effro256:monero.social> discussing and implementing Jamtis changes, trying to formalize wallet2 decoy selection algo
17:04:32 <Rucknium> me: Working with jeffro256 on interpreting wallet2's decoy selection algorithm. Second, excluding the set of txs with nonstandard fees from analysis of on-chain ring member age.
17:05:55 <Rucknium> 3) Discussion. What do we want to discuss?
17:06:40 <tevador> Has a decision been made to go forward with the Jamtis changes?
17:07:31 <m-relay> <j​effro256:monero.social> I brought up an issue on the Jamtis gist, but I wanted to hopefully dive deeper into it here in this meeting. Simply put, the issue is this: multiple self-send enotes within a transaction creates a significant statistical fingerprint for finding outgoing enotes for anyone with knowledge of the find-received/assist-filter/filter-involved key (whatever we're calling it in the new or old scheme)
17:08:46 <Rucknium> Can you post the gist URL again for the meeting log?
17:08:47 <m-relay> <j​effro256:monero.social> I think most people (correct me if wrong) are in agreement about using the extra public key to guard against third-parties knowing the nominal address tags
17:09:32 <tevador> I generally agree with the change regarding self-send enotes, although it has a potential to increase the required wallet traffic 2.5x or more.
17:10:12 <m-relay> <j​effro256:monero.social> Yes, you can find my original comment here: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4706509#gistcomment-4706509
17:11:22 <tevador> There was a pushback against dynamic view tags and I expressed my opinion that the proposed Jamtis changes might not be worth it without them: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4708830#gistcomment-4708830
17:11:46 <m-relay> <j​effro256:monero.social> Yes, which is unfortunate, but luckily only affects light wallets, and it's limited a certain constant. And *if* we have a decent flexible view tag scheme, hopefully we can mitigate performance issues down the line
17:12:17 <rbrunner> Don't understand half of that stuff, frankly, I just get the impression that things are still pretty much in flux, not yet "converging" to a solution
17:12:34 <m-relay> <j​effro256:monero.social> I highly disagree that the extra public key is useless without the view tag changes
17:13:08 <tevador> I didn't say "useless".
17:13:39 <tevador> "potentially wasteful" would be the right expression
17:14:41 <rbrunner> At the end that Reddit poll "Do you support variable size viewtags?" only had around 40 voters in total.
17:15:06 <tevador> One advantage of the original 3-key design is that it doesn't cater to remote scanners, yet still improves them significantly with lower costs.
17:17:05 <m-relay> <j​effro256:monero.social> Okay fine, but still I disagree with this sentiment: "The static 8-bit view tag works well with a "medium" transaction volume, which is a range from mid tens of thousands to mid hundreds of thousands of enotes per day.". A static 8-bit view would work well for *any* transaction volume, assuming that light wallet users always can handle ~0.5% of the traffic as full wallets
17:17:35 <m-relay> <j​effro256:monero.social> We might not be able to assume that for all users, but it's not a terrible assumption
17:18:55 <m-relay> <j​effro256:monero.social> If we assume constant load handling capacity, then yes static view tags are bad for high volume (and low volume for privacy)
17:20:05 <Rucknium> What kind of use cases do pre-signed transactions, signed days+ in advance, fill? There's an atomic swap protocol that needs them, but I don't know if you would really need pre-signing for that more than 24 hours in advance.
17:20:26 <Rucknium> Hoenisch et al. (2022) "Lightswap: An atomic swap does not require timeouts at both blockchains"
17:20:35 <m-relay> <j​effro256:monero.social> Yeah this is true, it's nice that it's effectively 0-cost. Although I think believe that light wallets will take a bigger part in the ecosystem from Jamtis onwards, especially with mobile wallets
17:20:52 <tevador> "assuming that light wallet users always can handle ~0.5% of the traffic" -> do we have something to base this assumption on?
17:23:44 <rbrunner> I would claim that with actually tens of thousands of enotes *per day* all kinds of bottlenecks would spring up, with 1-byte viewtags only one among many.
17:24:51 <m-relay> <j​effro256:monero.social> One use case I can think of is if you wanted a dead man switch to pass on your funds to your next of kin. But more generally, delegating membership proofs lets you make transaction cermemonies that can take a while to complete but don't necessarily make fingerprintable decoy selections
17:24:52 <tevador> We currently have about 50 000 per day.
17:25:33 <m-relay> <j​effro256:monero.social> Yeah this is true, it's nice that it's effectively 0-cost. Although I believe that light wallets will take a bigger part in the ecosystem from Jamtis onwards, especially with mobile wallets
17:25:38 <rbrunner> Yeah, just saw that, I have to switch my argument to the "hundreds of thousands" then :)
17:27:06 <rbrunner> Multisig transactions can also take a while until everybody signed, right?
17:28:32 <tevador> We could hardfork in the future to adjust the view tag, but we'll be stuck with the address format forever. something to bear in mind.
17:28:37 <m-relay> <j​effro256:monero.social> There is an argument to be made that if light wallet users can't handle 0.5% of transaction prefix traffic, then our full nodes will have to handle far too much traffic for the network to be as decentralized as it should be
17:29:19 <m-relay> <j​effro256:monero.social> Exactly
17:29:47 <rbrunner> So the decision how many keys to have there is much more important than the decision whether fixed size viewtag or flexble ones?
17:29:55 <tevador> Yes.
17:31:27 <rbrunner> And well, where do we stand regarding opinions to introduce, or not, another key in the address? I lost overview a bit.
17:32:45 <tevador> There are pros and cons of both.
17:33:21 <rbrunner> Reminds me of the unlucky tx_extra story ...
17:34:01 <rbrunner> In regard of difficult decision processes, I mean
17:37:20 <m-relay> <j​effro256:monero.social> I thinks the pros of the extra public key in the address far outweigh the downsides, but I admit a lot of that is because of my predisposition for imagining what actually decent light wallets could give us
17:39:37 <rbrunner> My focus is more on what I consider something like a "hole" in Jamtis that doesn't belong there in anotherwise so beautiful and powerful construct
17:39:55 <rbrunner> that story with the dangers of repeated use of an address
17:40:09 <m-relay> <j​effro256:monero.social> what would you think about flexible sized view tags by hard consensus rules, but which the relay rules enforce a constant size
17:40:11 <rbrunner> with remote scanning services in the picture
17:40:53 <tevador> The 3rd key gives Janus attack protection and a separate key to view amounts, which is generally useful to everyone. The 4th key is only for light wallets. Users running their own nodes won't see much benefit.
17:41:11 <m-relay> <j​effro256:monero.social> And the bad thing is that it is out of your control whether someone sends to your public address more than once. Trying to mitigate it as a light wallet user is basically impossible
17:42:11 <UkoeHB> Have the proposed jamtis design changes stabilized? I have not been following the discussion.
17:42:35 <rbrunner> So it's a bit also a discussion whether we accept light wallets as "first class citizens", as integral part of the system
17:43:19 <rbrunner> UkoeHB: From what I can see, no ...
17:44:10 <m-relay> <j​effro256:monero.social> tevador and I have agreed upon a key derivation tree, public address layout, and sender-receiver secret derivation scheme *if* we choose to add the extra pubkey to the address. The main point on contention is how to do the view tags
17:45:00 <tevador> A soft-rule for view tags would probably work.
17:45:45 <tevador> But I would not see the 3-key/4-key debate as settled yet regardless of the view tag decision.
17:45:46 <rbrunner> But those new problems / points that you mentioned could force some re-considerations there, worst-case?
17:47:18 <rbrunner> "multiple self-send enotes within a transaction creates a significant statistical ..."
17:47:20 <m-relay> <j​effro256:monero.social> With a soft-rule flexible view tag,  if we later wanted to switch to your dynamic `trunclog2(3 * num_output_100k / 200000)` view tag method, we could do so without a consensus change
17:47:44 <tevador> good point
17:48:37 <tevador> If a large portion of users start using 3rd party scanners, then the 4th key is most likely worth it. I'm not sure if we have any data on this.
17:49:48 <rbrunner> I am not sure current data is very valuable if we switch to a third-party scanning system with significantly less privacy problems
17:50:45 <rbrunner> And one that could also technically be simpler to implement, as an add-on to normal wallets instead of fully different wallets to connect to light-wallet servers
17:50:48 <m-relay> <j​effro256:monero.social> Yeah, it's impossible to tell for sure. However, could we agree that the usage for Jamtis light wallets would likely be even higher than usage of MyMonero, monero-lws, etc considering that the privacy is orders of magnitude better in many ways?
17:51:43 <rbrunner> For me it's telling how already today pretty much *every* multi-coin wallet uses MyMonero technology for their XMR support
17:51:49 <rbrunner> privacy be damned
17:52:32 <rbrunner> I think light-wallet use under Jamtis has the potential to become a stampede.
17:53:09 <tevador> More users will probably choose some kind of light wallet setup with Jamtis, but it's not clear if it's +5% or +50% of users. Running a local node will always be more private.
17:53:10 <rbrunner> Just think about all the third-world countries where you still buy your mobile data traffic in megabytes
17:54:13 <Rucknium> MyMonero had a slightly nonstandrad fee calculation for a while. If we knew how to identify them on chain, we could look back at the data. The fundraiser to have mj do that nonstandard fee investigation was unsuccessful.
17:54:50 <rbrunner> Was that on Magic?
17:55:11 <Rucknium> I think MyMonero's decoy selection algorithm is slightly different, too, but it's harder to see through the statistical noise of just 15 decoys per ring
17:55:17 <Rucknium> rbrunner: Yes
17:55:28 <rbrunner> Hmm, didn't even hear about that.
17:55:51 <tevador> fluffypony could just say how many users they have...
17:56:15 <rbrunner> Maybe they are not allowed to by some contracts
17:56:43 <Rucknium> IIRC fluffypony stated somewhere on IRC that MyMonero has low single digits in percent of txs. But that probably does not include the other wallets like Guarda that use MyMonero.
17:56:44 <tevador> or just the % of matched outputs
17:57:15 <rbrunner> But, well, yeah we don't know the number of probable light wallet users on Jamtis, but on the other hand, couldn't even 5% percent lead to problems without a 4th public key?
17:58:29 <tevador> Someone could do the math and figure that out. However, 3-key Jamtis is still way more private than cryptonote.
18:01:12 <m-relay> <j​effro256:monero.social> This is true, but I want to reiterate again that the scenarios in which you lose privacy are basically impossible to plan for
18:02:31 <Rucknium> No. It was Reddit, not IRC. https://www.reddit.com/r/Monero/comments/uth0un/comment/i9bk0sf/
18:02:50 <Rucknium> "Whilst we don't disclose user numbers, I can assure you that the number of viewkeys we have is not even double-digit percentages."
18:05:00 <Rucknium> We can end the meeting. Discussions about dynamic view tag length and the 4th public key will continue :)
18:05:07 <rbrunner> Lol
18:05:53 <rbrunner> Quite a tangle of many different considerations and trade-offs
18:07:29 <m-relay> <j​effro256:monero.social> You know what they say: "trust, don't verify"
18:11:41 <rbrunner> Ah, now, looking on Matrix, I understand this. On pure IRC this comes out of the blue, too cryptic :)
18:14:37 <rbrunner> I wonder what Rucknium the statistics magician could all do merely holding a few percent of all viewkeys :)
18:20:35 <tevador> some of us are still using old-fashioned IRC...
18:20:39 <endogenic> i'm pretty late to the party but as I said, i have new client code for lws that every lws client will want to switch to which solves the issue of txs being distinguishable from other clients
18:22:26 <m-relay> <j​effro256:monero.social> How does that work?
18:35:11 <endogenic> i factored wallet2
18:36:58 <endogenic> i'm the one who wrote the code that all lws clients use as it is - it was initially ported from js to c++ - and i massively upgraded that even beyond wallet2's capabilities in some parts but eventually opted to converge the code for reasons including what you're discussing
18:37:22 <endogenic> i will be publishing a writeup on it soon
18:37:58 <endogenic> i'm so late due to having no help, .. etc
18:38:05 <m-relay> <j​effro256:monero.social> Are you talking about on-chain indistinguishability for any external observer?
18:38:10 <endogenic> yes
18:38:18 <m-relay> <j​effro256:monero.social> Ah okay sweet
18:38:34 <m-relay> <j​effro256:monero.social> Let us know if/when you publish that write-up
18:38:41 <endogenic> granted the decoy selection algo sits on server still but even that is something my factorization etc now brings to the client if we want
18:38:59 <endogenic> but it comes with a tradeoff that isnt acceptable for most lws UX
18:39:37 <m-relay> <j​effro256:monero.social> That trade-off being that the user needs to download the RCT output distribution?
19:00:03 <endogenic> yep.. takes a while. still a cool hybrid mode tho i guess. i think what would be better is a proposal i'll make where the lws from vtnerd can be stripped down into a decoy outs terminal and easily deployed without need for server side storage - and clients can simply ping whatever decoy outs oracle they want
19:00:44 <endogenic> this is something i'm also working on.. i built it already but.. it should be rolled out
19:00:59 <endogenic> i have a *lot* of good stuff to share
19:01:19 <endogenic> been keeping it under wraps due to having no help and not knowing when i'd be ready
19:42:39 <endogenic> (and when i say stripped down i just mean a PR to his repo to include ifndefs etc)