07:42:35 <ghostway[m]> <merope> "Last I checked, the i2p-hosted..." <- Question, why was it moved? 
09:11:55 <merope> No idea 🤷‍♂️
13:27:54 <mnrrn[m]> <moneromooo> ""Stealth address ?"" <- I was under the impression that stealth addresses are derived from the subaddresses that senders and receivers actually exchange, and that outputs publicly go to the stealth addresses.
13:29:04 <mnrrn[m]> <moneromooo> "If you mean you want to find..." <- Thanks, but I'm trying to do this for others' outputs, just to see what the public can figure out.
13:29:25 <Rucknium[m]> ghostway: Like I said, pokkst wants people to use i2p: https://reddit.com/r/Monero/comments/yzgoh2/comment/iwzz47i?context=3
13:29:53 <Rucknium[m]> "I like I2P, and want to encourage people to learn how to use I2P. I ditched GitHub almost entirely (it's not just the MyNero repo that's been migrated over), and have been meaning to again since my GitLab account was wrongly terminated like 2 years ago (long story of them fucking up their verified-email requirement)."
13:34:02 <mnrrn[m]> <Rucknium[m]> "It is fine as an educational..." <- I read the thread. I still don't see why users *should not* modify their behavior based on a decoy scanner. Either way, I think it's valuable information to know.
13:35:32 <mnrrn[m]> <Rucknium[m]> "mnrrn: pokkst's scanner probably..." <- Alright, I'll give it a shot. Thanks.
13:36:54 <Rucknium[m]> mnrrn: Let's say you always spend an output after that output is included in 2 other rings. Then an adversary knows that the third tx that used the output is the real spend, i.e. your transaction would be traced. The adversary would have had to target you and know you are using that strategy of course.
13:39:33 <mnrrn[m]> But the adversary would have to know that you always spend after the first 2 rings, and you yourself would have to always spend after the first 2 rings consistently. How would he get that information? I might be spending after the first 2, you might be spending after the first 10, so the adversary wouldn't be able to target both of us at the same time. I might just be spending after at least 2 so I could be spending anywhere from
13:39:33 <mnrrn[m]> the 3rd, 4th, 5th, and so on.
13:41:54 <Rucknium[m]> Tell me a privacy-increasing user strategy that uses the decoy scanning information.
13:43:37 <Rucknium[m]> I don't think it's a big deal if a user tried to follow a strategy. But do we need more Monero user folk knowledge with poor theoretical foundations?
13:45:09 <someoneelse49549> Rucknium[m]: 300 years ago there was only thousands of people that knew how to do derivatives. Now it's a common knowledge. We clearly don't need more monero user folk with poor theoritical foundations
13:45:32 <someoneelse49549> s/theoritical/theoretical/
13:49:53 <mnrrn[m]> <Rucknium[m]> "Tell me a privacy-increasing..." <- Here's a simple one: avoid spending an output immediately after receiving it. Wait a while before spending it, at least until it's been used as a decoy at least once.
13:50:59 <Rucknium[m]> How does that increase a user's privacy?
13:52:10 <mnrrn[m]> Some newer Monero users familiar with Bitcoin tumblers think that they can achieve greater privacy by moving XMR around from address to address, making the first transaction an output appears in be the real transaction. It's not obvious to them that that decreases privacy rather than increases it.
13:52:10 <mnrrn[m]> If we're telling people how many confirmations they've gotten in order to give them an idea of how irreversible a transaction is, why doesn't it make sense to tell them how many times their output has been used as a decoy?
13:52:21 <Rucknium[m]> You've just removed the first use of the output in a ring as being part of the possible anonymity set.
13:53:17 <Rucknium[m]> Number of confirmation and number of times an output has been used in a ring are completely different.
13:53:22 <mnrrn[m]> Agreed. But some people will spend their output in the first transaction, because either they have no choice (they need to move the money fast for some reason), or they follow a different strategy.
13:58:22 <Rucknium[m]> There is a piece of truth in what you're saying. Without a deep analysis of churning (yet), I think that a good churning strategy could be to follow the decoy selection algorithm. The realized values of the decoy selection algorithm isn't the same thing as the theoretical distribution that could be followed. That's why I said a scanner like that could be useful as an educational tool.
13:58:55 <Rucknium[m]> Churning has not been rigorously analyzed and my hypothesis above is just that: a hypothesis.
13:59:26 <Rucknium[m]> And the user would have to use a random number generator and stick with the RNG's decision.
13:59:54 <moneromooo> Stealth addresses are not a monero building block. People have talked of these to mean at least two different things in monero. We don't need that noise.
14:00:41 <moneromooo> I suspect you're talking about output public keys. At least that's the most straightforward way to use to identify an output.
14:00:55 <mnrrn[m]> moneromooo: Yes.
14:02:42 <moneromooo> If people start never using their output before it's been referenced once or more, then, probabilistically, the first ring member will more and more become less likely, decreasing privacy. You want about 1/16th of rings to spend the first ring member, ideally.
14:03:16 <moneromooo> If you need to spend a new output quick once, just let it be the first use of that output.
14:03:49 <moneromooo> Now if you're *always* in that case, then it might suck but waiting cannot be a solution if your problem is you need to always not wait.
14:04:07 <Rucknium[m]> mnrrn: The first 5 pages of my PDF here may be helpful: https://github.com/monero-project/research-lab/issues/93
14:06:40 <mnrrn[m]> moneromooo: I think I see what you're saying: "Let those who do not need to be the first spend protect those who always need to be the first spend." Something like that, correct? If so, then yeah, maybe leaving users blind to how many times they've been a decoy would be better than worse.
14:07:09 <mnrrn[m]> Rucknium[m]: Thanks. I'll read it.
14:08:42 <moneromooo> I guess it's a nice way to put it. Or at least an implied point.
16:01:02 <UkoeHB> Meeting 1hr
17:01:47 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/790
17:01:47 <UkoeHB> 1. greetings
17:01:47 <UkoeHB> hello
17:01:59 <UkoeHB> sorry got distracted by that ordinal nonsense
17:02:26 <rbrunner> Hello
17:02:32 <ArticMine[m]> Hi
17:02:32 <Rucknium[m]> Hi
17:02:42 <isthmus> Heya
17:02:55 <plowsof11> hi
17:02:55 <dangerousfreedom> Hello
17:03:47 <UkoeHB> 2. updates, what's everyone working on?
17:05:07 <Rucknium[m]> Doing some initial Monte Carlo simulations for OSPEAD. Checking computational bottlenecks and performance in estimating parameters.
17:05:07 <isthmus> Chatting with Rucknium about ways that my team at Geometry Labs can support OSPEAD parameterization. We have some extra bandwidth on the engineering team and plenty of computational resources to throw at it :)
17:05:07 <isthmus> Still in early stages of discussing Ruck’s dev wish list, haven’t formalized anything yet but planning to draft up a CCS in the next week or two to share here for feedback.
17:09:09 <UkoeHB> me: doing a lot of thinking about how to architect the core wallet engine for the seraphis migration project, focusing on coordinating async processes (mainly around balance recovery right now) with the ambitious goal that the engine should be able to work as an enterprise backed with support for 10s or 100s of concurrent wallets
17:11:32 <isthmus> "enterprise backed with support for 10s or 100s of concurrent wallets" This would be awesome
17:11:40 <Rucknium[m]> UkoeHB: Does that mean that monero-wallet-rpc could have more than one wallet open at a time?
17:12:12 <UkoeHB> Rucknium[m]: that's what I'm thinking yeah, it's been a pain-point for a long time I think
17:12:15 <rbrunner> You mean whatever will come after monero-wallet-rpc ...
17:12:57 <Rucknium[m]> That would be very nice :)
17:13:40 <UkoeHB> 3. discussion, anything to talk about today?
17:15:10 <dangerousfreedom> I'm trying to understand the pros/cons of different wallet designs and one thing that scared me was the fact that we didnt talk much about the daemon/rpc communication yet for seraphis. Is it part of the no-wallet-left-behind efforts?
17:15:11 <dangerousfreedom> For the moment I believe we could use a fake ledger to simulate transactions and create the necessary wallet functions (I'm making a prototype in this direction). But it may have a big impact on some wallet decisions too.
17:15:11 <dangerousfreedom> How do you guys see this part advancing?
17:16:27 <rbrunner> Well, if we have you thinking on this, I think that's already a good way.
17:16:34 <Rucknium[m]> I think communication between monero-wallet-rpc and remote nodes is one of the less reliable parts of the Monero ecosystem.
17:17:30 <rbrunner> That's why I still advertise a bottom-up approach: Start with something small, see how it turns out, work your way up
17:17:46 <rbrunner> The greater shapes of the whole architecture will reveal themselves over time
17:19:02 <rbrunner> Needs a bit of confidence that we won't chase down too many dead ends of course,
17:19:09 <rbrunner> and don't have to backtrack too often.
17:19:59 <rbrunner> But take only such little question like this one: More than 1 wallet open at any given time over RPC is nice, but how does that influence the RPC interface?
17:20:30 <rbrunner> How will that best look if you introduce state like "the set of currently open wallets"
17:21:09 <rbrunner> And these even update like crazy with UkoeHB's enterprise grade scan engine :)
17:22:17 <UkoeHB> well not that crazy unless you have a lot of threads
17:22:18 <blankpage[m]> What is "that ordinal nonsense"?
17:22:30 <UkoeHB> blankpage[m]: check -lounge
17:23:22 <rbrunner> Who knows, maybe we will even move away from RPC towards ZMQ because it turns out things are better to handle through that by an order of magnitude
17:23:31 <rbrunner> after we granted all possible wishes
17:24:39 <blankpage[m]> Will do thanks
17:24:41 <Rucknium[m]> IMHO, RPC should keep working for legacy systems and legacy coders :)
17:25:27 <rbrunner> It should, agree. Just don't know where we land after we will have walked the full way.
17:27:24 <UkoeHB> rbrunner: for a public interface you'd probably issue wallet ids for each wallet activated, then forward requests based on id. Layers of forwarding isn't that exciting, but idk what other options there are.
17:28:16 <rbrunner> Yeah, the familiar "handle" pattern that OSs use for files, for example.
17:29:29 <rbrunner> With all the problems you will get if clients do not correctly handle those on their side and forget to close wallets until you have 1000 open :)
17:29:57 <rbrunner> Or the same wallet a thousand times.
17:30:20 <rbrunner> Ever the pessimist :)
17:30:25 <Rucknium[m]> I thinking about giving a text-to-speech presentation at Monerotopia: "A Statistical Research Agenda for Monero." An overview of questions including decoy selection of course, but also post-Seraphis fee estimation, possible remote node timing attacks, transaction churning, tx flood detection, dynamic block size, etc. How does that sound, or does anyone have a better idea?
17:31:06 <UkoeHB> easy enough to enforce open wallets are unique
17:31:41 <UkoeHB> Rucknium[m]: that sounds good to me
17:31:48 <rbrunner> Are these one-hour presentations? If yes, you might really have to limit yourself to an overview
17:32:01 <rbrunner> with some many possible points
17:32:19 <rbrunner> But sounds interesting, yes
17:32:55 <UkoeHB> more like 25-35 minutes I think
17:32:59 <Rucknium[m]> For Monerotopia, an overview is appropriate. MoneroKon is the more technical conference.
17:34:28 <dangerousfreedom> Rucknium[m]: Sounds really cool :)
17:35:24 <rbrunner> Did you ever do already such a "text-to-speech" presentation? Does that work well=
17:37:04 <Rucknium[m]> No. I have been experimenting with some tools. I hope it works OK.
17:46:10 <blankpage[m]> If it is janky you could give someone a copy of your script to act as your physical avatar. Even better if they understand enough to answer basic questions.
17:46:29 <UkoeHB> Hmm I don't have anything to say so maybe we can wrap it up early. Fortunately or unfortunately, it seems I will be spending a lot more time on seraphis migration than I originally planned, since it looks like there is a lot of advanced architectural work that A) interests me, B) probably needs my help. Not sure how much actual wallet-level code I'll write, but we'll see how it goes.
17:49:44 <UkoeHB> thanks for attending everyone
17:49:53 <blankpage[m]> I hope to eventually have caught up enough with saraphis/jamtis and the rationale spread through various github issues to be able to make informed contributions to these discussion
17:50:10 <blankpage[m]> Thanks again for hosting the meeting
17:50:10 <dangerousfreedom> UkoeHB: Thanks Koe
18:24:27 <rbrunner> blankpage[m]: Do you intend to contribute code to Seraphis and Jamtis over the medium term? If yes, you might be somebody with this intention that I have missed so far :)
18:24:50 <rbrunner> See also Mondays meeting ...
18:25:52 <blankpage[m]> I am not much of a dev to be honest, but I'm trying to wrap my head around things in case there is something I can contribute regardless
18:26:10 <blankpage[m]> I have been reading the Monday meetings yes
18:27:56 <rbrunner> Alright, thanks :) People with informed opinions and being able to act as "sparring partners" for discussion will certainly be very valuable as well.
18:56:01 <ghostway[m]> <Rucknium[m]> "I thinking about giving a text-..." <- That sounds interesting!