08:14:31 <midipoet> Would it be possible to have a "traceable Monero" protocol that would provide need to know accountability/traceability, that is accountable itself. ie. Some sort of notification/canary type scheme that would alert the user if their privacy has been compromised by regulatory authority? Yes, i know this is antithetical to Monero, but i am just asking generally. 
08:15:10 <midipoet> Because the above would bw helpful in a lot of "blockchain use cases"
08:15:15 <midipoet> *be helpful 
08:53:45 <moneromooo> If the user has to be notified, then the user must give some information.
08:54:27 <moneromooo> And the user presumably has to be forced to give the information somehow to meet the regulatory authority's requirement..
08:54:51 <moneromooo> I don't see how to meet both requirements unless the privacy's out in the first place.
08:55:01 <moneromooo> Oh. I do. Devious.
08:56:21 <moneromooo> Theoretically, the authority could ask every single user for a key. These keys would be magically^Hcryptographically munged in such a way that it gives the RA what it wants, without knowing which key in particular "helped".
08:56:54 <moneromooo> Then all users know the RA was up to something, and the person with the key they wanted can hopefully tell their key was the one to get the data.
08:58:00 <moneromooo> Now I've no idea if this is technically possible, but it is the way such a scheme could meet both "a user cannot choose to withhold information" and "the user has to be notified".
08:58:37 <moneromooo> The scheme would have to prevent the RA from brute forcing small (possibly cardinality of 1) sets one at a time.
08:59:35 <moneromooo> Hmm.The scheme above probably fails the "user is notified THEIR data got pwned", it only says "someone's data got pwned".
09:00:10 <moneromooo> Unless the RA has to make public the tx they want in the first place.
09:01:52 <moneromooo> Probably not helpful, is it :D
13:56:02 <UkoeHB> meeting 3hr
16:56:30 <john_r365[m]> Thanks for that calculation Bawdy
16:56:33 <xfedex[m]> <midipoet> "Would it be possible to have a..." <- Perhaps that could be accomplished by adding a new type of transaction, which is like "hey wallet X, share your view key to me" which must be signed by some sort of authority. User's funds are then locked until he publishes the view key, encrypted so that only the authority can see it, in blockchain; and after a while he doesn't share it, funds are destroyed.
16:57:46 <xfedex[m]> This system would need some sort of system to verify that an encrypted view key is actually valid; or, in alternative, share the view key publicly
16:59:55 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/825
16:59:55 <UkoeHB> 1. greetings
16:59:55 <UkoeHB> hello
17:00:18 <rbrunner> Hello
17:00:36 <Rucknium[m]> Hi
17:02:23 <ArticMine[m]> Hi
17:03:37 <UkoeHB> looking to be a small meeting
17:03:37 <UkoeHB> 2. updates, what's everyone working on?
17:05:07 <UkoeHB> me: working on 'implementing seraphis' companion paper to the seraphis abstraction paper
17:06:10 <ArticMine[m]> I am working on updating the scaling and fee algorithms 
17:06:45 <ArticMine[m]> In advance of my talk at Monerokon 
17:07:10 <Rucknium[m]> Going to post effective ring size analysis for Mordinals and coinbase outputs tomorrow probably. Mordinal minting pretty much ceased on April 2nd. The worst daily effective ring size in the last month (considering Mordinals only) was about 14. As of yesterday, it is already back up to 15.8
17:07:43 <Rucknium[m]> worst mean effective ring size
17:08:43 <UkoeHB> did it stop due to the network-layer tx_extra relay constraint?
17:08:56 <john_r365[m]> @ArticMine - updates, as in, future changes to the fee algorithm? How so?
17:09:28 <plowsof11> v0.18.2.2 officially released , with the tx_extra limit. looking at my peer list i can see who has/not updated by the error messages when trying to send a tx. 'people seem to be updating' which is nice https://paste.debian.net/1277128/ 
17:10:01 <Rucknium[m]> UkoeHB: I don't think so. I will refer to the cession as "without apparent cause"
17:10:06 <Rucknium[m]> The cession happened a week before the official release of 0.18.2.2
17:10:09 <rbrunner> UkoeHB: Mordinals probably stopped because a special fee was introduced
17:10:41 <UkoeHB> Rucknium[m]: cessation?
17:10:45 <Rucknium[m]> Er, cession is the wrong word. Means surrender territory.
17:10:53 <UkoeHB> rbrunner: ah
17:10:55 <Rucknium[m]> yeah lol
17:11:26 <Rucknium[m]> Mordinal minters could just use the old software. I'm not sure that's a complete explanation for it.
17:11:38 <rbrunner> It's almost ironic, as you could get the impression that the Mordinals devs take their NFTs serious, but not the "minters" ...
17:12:29 <vtnerd__> ive focused on LWS stuff again this past week (sadly)
17:12:50 <rbrunner> Rucknium[m]: Did you find more than two after April 2? Because only 2 new ones appear in the viewer web app
17:13:07 <ofrnxmr[m]> they stopped to work on transfers. mordinal devs werent the ones spamming
17:13:51 <ofrnxmr[m]> the spammers probably updated and got confused. the spam was so low quality for spam and as nfts, that it was just a senseless waste of 5xmr
17:13:56 <rbrunner> Yes, "transfers" now work. The Monero punks proudly tweeted about their first one
17:14:03 <UkoeHB> looks like the BP++ CCS is fully funded, so we can look forward to the results of that; plowsof11 what's the timeline look for that work?
17:14:16 <tevador> here is a 6 blocks old mordinal: https://xmrchain.net/search?value=8da183c297425e9e368d422845a9ddce963186b77c448372142cd6ebacbcfc0a
17:14:17 <Rucknium[m]> I think there are only two after April 2. My total count is 43083 now. Slightly above the count on the viewer web app I think.
17:14:56 <ArticMine[m]> 1) Reducing the surge factor for the short term median from 50 to 20 or 16
17:14:56 <ArticMine[m]> 2) Increasing the growth of the long term median from 1.7 to 2
17:14:56 <ArticMine[m]> 3) Considering the introduction of a third sanity median of 1,000,000 blocks to cap the long term median to Nielsen's Law of Bandwidth an initial growth  
17:15:02 <Rucknium[m]> Technically, transfer txs are also black marbles. Do I want to track them? No, but I guess I will have to eventually.
17:15:16 <ArticMine[m]> This is at protocol level
17:15:58 <rbrunner> tevador: Just now appears in the viewer app :)
17:16:11 <ArticMine[m]> Also consider the use of node relay for lower caps than at protocol 
17:16:16 <plowsof11> BP++ CCS: we're still on the hook of the BP++ author : who promises updates for april 14th (no update as of yet)
17:16:52 <UkoeHB> ok
17:18:29 <ArticMine[m]> The idea is to have generous limits at protocol with lower limits at node relay 
17:19:46 <xmrack[m]> Hi
17:20:05 <rbrunner> Is this two-limits system of sorts a new approach?
17:20:52 <john_r365[m]> Thanks for the update ArticMine - RE 2) Wasn't that a point of contention in Issue 70 discussions? With 2 being the original value, and then 1.7 agreed as a compromise when Justin expressed concern?
17:21:17 <john_r365[m]> Link to prior discussion: https://github.com/monero-project/research-lab/issues/70#issuecomment-785193630 - or perhaps I'm misunderstanding
17:21:38 <ArticMine[m]> In reality no because nodes and miners are not obligated to max out scaling
17:22:42 <ArticMine[m]> It does recognize that node relay can provide more flexibility 
17:23:54 <ArticMine[m]> The protocol changes would introduce a third median to limit the growth of the long term median 
17:24:49 <UkoeHB> is there a security concern? it sounds like overkill from what I remember about the fee design
17:25:36 <ArticMine[m]> This allows the long term median to be more flexible over the short to medium term while addressing some community concerns 
17:26:18 <UkoeHB> what concerns?
17:26:31 <ArticMine[m]> UkoeHB: In my view the current situation is good enough, but there is some room for improvement 
17:26:53 <ArticMine[m]> So there is not a security concern 
17:29:09 <UkoeHB> ok, well are there any other topics to discuss today?
17:29:26 <ArticMine[m]> The main advantage is to allow a faster response of the long term median over a 3  month to a year while tightening the pricing of the growth of the short term median 
17:29:33 <Rucknium[m]> I will include possible mitigations for Mordinals' privacy impact in the post. Here is my list. Any others? These are not necessarily "good" mitigations. Just possible ones:
17:29:41 <Rucknium[m]> - Exclude coinbases from decoy selection algorithm (in development)
17:29:41 <Rucknium[m]> - Exclude Mordinals from decoy selection algorithm
17:29:51 <Rucknium[m]> - Stop transfer of Mordinals by enforcing a decoy selection algorithm (could be transferred with cryptography)
17:29:51 <Rucknium[m]> - Alter tx_extra rules to make Mordinals less appealing (0.18.2.2 patch)
17:29:58 <Rucknium[m]> - Raise ring size
17:30:50 <UkoeHB> ArticMine[m]: at the very least it will be interesting to see your research and proposal
17:31:27 <john_r365[m]> Yep, looking forward to reading/hearing more on your research ArticMine
17:31:44 <UkoeHB> Rucknium[m]: seems comprehensive
17:33:06 <ofrnxmr[m]> Rucknium @rucknium:monero.social: i proposed the same to jeffro and jtgrasie
17:33:42 <ofrnxmr[m]> (not point 3), but thats where i ended up as well
17:35:54 <Rucknium[m]> It would be nice for people to try to come up with reasons not to exclude coinbase outputs from the standard decoy selection algorithm. AFAIK, there are no major reasons, but we don't want to overlook anything.
17:37:14 <Rucknium[m]> As of yesterday, if we only consider coinbase outputs to be black marbles, then average effective ring size is about 14.75
17:37:40 <Rucknium[m]> That's with the P2Pool payout efficiency upgrade on March 18
17:37:51 <ofrnxmr[m]> i often, more than id like, have 3-4 coinbase
17:38:13 <UkoeHB> changing the core wallet decoy selection algorithm just makes it even more difficult to replicate in alternate wallets
17:38:53 <UkoeHB> you can pretty much guarantee that all wallet implementations will be using different decoy selection algos
17:39:01 <Rucknium[m]> As of yesterday, the unluckiest 5th percentile is effective ring size 13 (only coinbases as black marbles)
17:39:05 <ofrnxmr[m]> you can do that now
17:39:13 <ofrnxmr[m]> im using a different algo than you
17:39:57 <rbrunner> Yes, but still means that we should increase complexity only after careful deliberation
17:40:09 <Rucknium[m]> Yeah we should be careful about changing the decoy selection algorithm when not at a hard fork. IMHO, that factor needs more study
17:40:10 <rbrunner> And weighing trade-offs
17:41:11 <ofrnxmr[m]> yeah, imo it should be saved for a hf.
17:45:05 <UkoeHB> hmm can we end the meeting here?
17:45:37 <ofrnxmr[m]> yes sir. thanks ukoehb
17:47:10 <UkoeHB> ok thanks for attending everyone
17:47:29 <Rucknium[m]> On quick calculation, as of yesterday about 30% of rings contain no coinbase outputs.
17:50:06 <Rucknium[m]> If you construct a single-input tx without any coinbases deliberately, an observer might say that there is a 30% probability you are just using the standard wallet2 method. I think.
17:50:15 <ofrnxmr[m]> ruck can you check the number of outputs? % of outputs that are 2 out, vs 345 etc.
17:50:22 <Rucknium[m]> If you have multiple inputs, things get more complicated
17:51:03 <Rucknium[m]> Yeah. One moment. research computing server CPU whirs
17:51:12 <ofrnxmr[m]> i imagine the vast majority are 2 or 16. over any period
17:54:31 <Rucknium[m]> Wait did you mean check the number of coinbase outputs in each ring? That's the quantity I just calculated:
17:55:09 <Rucknium[m]> 0: 29%; 1: 34%; 2: 23%; 3: 10%; 4: 3%
17:55:40 <Rucknium[m]> You want the number of outputs in each tx?
17:55:42 <ofrnxmr[m]> whoops. 
17:55:42 <ofrnxmr[m]> i meant the number of outputs in each decoy in a ring
17:57:05 <Rucknium[m]> So look up each output in a ring and see if it came from a tx with 2 outputs or 3 outputs...16 outputs?
17:57:27 <ofrnxmr[m]> yes please and thanks.
17:58:10 <Rucknium[m]> My data isn't set up to do that this moment, but I can probably do it soon
17:58:13 <ofrnxmr[m]> as i believe rings are poisoned by 3-16 out for the vast majority of regular users. im in favor of keeping 16, but would like to know the actual ring distribution of each (2-16)
17:58:47 <ofrnxmr[m]> whenever you are able, greatly appreciated. thanks
18:24:22 <nikg83[m]> <Rucknium[m]> "0: 29%; 1: 34%; 2: 23%; 3: 10%;..." <- After p2pool implementation?
18:32:14 <Rucknium[m]> nikg83: Yes. Those numbers are the daily counts from yesterday. This includes all coinbases, not just P2Pool payouts.
18:34:00 <Rucknium[m]> The P2Pool network upgrade on March 18 reduced the coinbase share of outputs from about 18% to about 9%