00:02:18 <kayabanerve[m]> Sent an email. I said thanks for spending their time on monero, yet this isn't applicable, and asked for clarification on their PoC.
00:57:54 <hyc> that's been par for the course IMO
00:58:32 <hyc> college profs aren't advising their students worth a damn
00:59:07 <hyc> IME, not IMO...
01:07:54 <kayabanerve[m]> The reason I tried to drag Ruck in is because of the preprint argument, which would be stupid IMO, yet somewhat understandable.
01:08:23 <kayabanerve[m]> Also, what about TX chaining via transcripting hashes and output indexes instead of global output indexes?
01:09:10 <kayabanerve[m]> It means anyone can create a indistinguishable looking TX which maintains the bandwidth optimization, yet requires increasing outputs on disk by ~51%
01:09:18 <kayabanerve[m]> And a migration accordingly :/
01:09:32 <kayabanerve[m]> * It means anyone can create a indistinguishable looking TX which maintains the bandwidth optimization, yet requires increasing output space on disk by ~51%
01:10:16 <kayabanerve[m]> It's a RCT fix for something Seraphis fixes, yet AFAICT it's a clean af solution which respects the 10 block lock.
01:14:20 <kayabanerve[m]> <kayabanerve[m]> "If it takes me five minutes to..." <- Also, with regards to this message ("improperly defining proofs"), I believe I have a proof which meets their requirement on being one way yet doesn't create a secure system under their constructions. It's one way without the previous witnesses + statements, yet the previous witness is sufficient to reverse it, for as long as you have the previous witness. I believe
01:14:20 <kayabanerve[m]> that makes it meet their one way requirement, as defined, yet be unsuitable for usage.
01:32:30 <Rucknium[m]> kayabanerve: I don't know how things work in computer science, exactly. My impression is that things move faster and with less peer review. Lots of papers never seem to receive formal peer review and stay as working papers or conference papers.
01:34:09 <Rucknium[m]> If we really really wanted to be involved in the process, we would contact editors of computer science journals and say "If a Monero paper is submitted, consider contacting one of X, Y, Z possible reviewers at MRL." The thing is, peer review takes labor hours, so that's the drawback for us.
01:36:52 <Rucknium[m]> Anyway, yes it's fine and appropriate to contact the authors at this stage. If you find and fix the issue, you could collaborate on the paper. If the issue is unfixable, well I suppose they could change the name of the protocol to something else that involves a theoretical Monero.
01:38:11 <Rucknium[m]> But yes overall it has been pretty common for people to write Monero papers without any contact with MRL or Monero developers. I hope that we can bring them "closer", which would avoid things like this and direct their energy in a way that helps Monero practically.
01:40:30 <Rucknium[m]> There are multiple economics papers on cryptocurrency topics that spent 2+ years in the draft stage 😢 . Yes, econ is slow.
05:11:05 <kayabanerve[m]> <kayabanerve[m]> "Also, what about TX chaining via..." <- I'm out of the meta here, and conflating a couple of discussions which are frequently paired. This exact idea about transcript has been proposed before. Not sure how much discussion happened on it though...
05:11:38 <kayabanerve[m]> Thanks for the insight, Rucknium :)
14:27:08 <UkoeHB> Meeting 2.5hr
16:59:53 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/714
16:59:54 <UkoeHB> 1. greetings
16:59:54 <UkoeHB> hello
17:00:19 <kayabanerve[m]> Morning
17:00:21 <rbrunner> Hi
17:00:26 <jberman[m]> howdy
17:00:30 <xmr-ack[m]> hi
17:01:09 <Rucknium[m]> Hi
17:01:32 <ooo123ooo1234567> hello
17:01:58 <jeffro256[m]> hello
17:02:38 <UkoeHB> 2. updates, what is everyone working on?
17:04:51 <UkoeHB> me: still working on seraphis enote scanning workflow (almost ready to start unit testing) + spent a couple days working on monerokon slides
17:05:12 <Rucknium[m]> Did K-S tests on output from mj-xmr 's Python implementation of the wallet2 decoy selection algorithm. I found an apparent off-by-one error, which mj then fixed. New output is passing statistical tests so far, although there may be issues with inappropriate use of integers in the wallet2 code.
17:05:14 <jberman[m]> approved 7760 pending merge conflicts, putting slides together for monerokon, getting back over to 8076
17:05:50 <jberman[m]> > although there may be issues with inappropriate use of integers in the wallet2 code
17:05:51 <jberman[m]> sounds familiar
17:07:42 <jeffro256[m]> I'm working through reviewing #7760, changing to EC SSL certs , and added a PR #8385 which makes presistent SSL an opt-in feature, even if in restricted mode. To that effect, I'm working on a p2p crawler which tries to track monerod nodes on persistent SSL certs 
17:09:04 <jeffro256[m]> > putting slides together for monerokon
17:09:11 <jeffro256[m]> What are you presenting about?
17:10:23 <jberman[m]> hoping to run down the proposed Seraphis/Jamtis features from a higher level user perspective, highlighting pros/cons
17:12:22 <kayabanerve[m]> Still working on my own things, yet recently further discussed FROST with a few parties, including as a slide for MK.
17:12:28 <UkoeHB> yeah there is a huge amount of material to cover so we will see how it goes
17:13:03 <ooo123ooo1234567> jberman[m]: does it include something on top of jamtis gist ?
17:13:04 <kayabanerve[m]> jberman[m]: Do we get to end Reddit discussions about the ovk?
17:14:06 <rbrunner> ovk?
17:14:16 <UkoeHB> 3. we can move to discussion
17:16:25 <Rucknium[m]> jberman:  As you (I think) discovered, MyMonero / lws transactions are fingerprintable on-chain due to how they choose fees (  https://github.com/mymonero/mymonero-core-cpp/pull/36 ). How could we go about getting a list of "suspects" on the mainnet chain?
17:17:44 <jberman[m]> ooo123ooo1234567: no, it's not new information
17:18:10 <kayabanerve[m]> rbrunner: Outgoing view key
17:18:18 <jberman[m]> there's a slide on that, ya
17:18:21 <rbrunner> Ah, ok, thanks
17:18:31 <rbrunner> Ending discussion on Reddit? Dream on :)
17:18:57 <kayabanerve[m]> I did want to ask the current bch code for jamtis. I do believe that should finalize to bech32n
17:19:08 <kayabanerve[m]> Right now, it's written as base32 with *some* bch
17:19:09 <kayabanerve[m]> s/bech32n/bech32m/
17:20:01 <ooo123ooo1234567> kayabanerve[m]: it's minor detail
17:20:04 <UkoeHB> kayabanerve[m]: there is no such code
17:20:09 <UkoeHB> unless tevador has something
17:20:15 <jberman[m]> Rucknium[m]: simplest/quickest way would be to run their fee algorithm at various times to get a range of what fees their txs would be. hardest way would be to definitively calculate the plausible fees it could have chosen for each tx. they can likely be pinpointed with effort
17:20:23 <kayabanerve[m]> Though I'll caveat I believe the Bitcoin bip defining bech32m also defines a version, which I'm not proposing carrying 
17:20:39 <kayabanerve[m]> ooo123ooo1234567: Agreed, yet there was an example cited and it was unknown what it did
17:21:02 <ooo123ooo1234567> <Rucknium[m]> "Did K-S tests on output from mj..." <- Is there any public goal that is supposed to be achieved with this scientific approach of code translation from one lang to another ?
17:21:05 <kayabanerve[m]> UkoeHB: I believe they do, yet it's private at this time, but I just wanted to start noting that specific detail
17:21:30 <Rucknium[m]> jberman: Hardest way as in most computationally expensive? Or also hard on developer time?
17:22:00 <jberman[m]> I don't think it would be computationally impractical, just hard on developer time
17:22:27 <ooo123ooo1234567> * with this (pseudo-)scientific approach
17:23:01 <Rucknium[m]> ooo123ooo1234567: Yes. Two main purposes. We need a mathematical definition of the probability density function that the wallet2 decoy selection algorithm uses. Also we can use this code to check how well other implementations in "third party" wallets are mimicking the wallet2 behavior.
17:24:29 <jeffro256[m]> > > <@rucknium:monero.social> jberman:  As you (I think) discovered, MyMonero / lws transactions are fingerprintable on-chain due to how they choose fees (  https://github.com/mymonero/mymonero-core-cpp/pull/36 ). How could we go about getting a list of "suspects" on the mainnet chain?
17:24:29 <jeffro256[m]> > 
17:24:29 <jeffro256[m]> > simplest/quickest way would be to run their fee algorithm at various times to get a range of what fees their txs would be. hardest way would be to definitively calculate the plausible fees it could have chosen for each tx. they can likely be pinpointed with effort
17:24:29 <jeffro256[m]> A cool project would be to color each transaction based on the fee algorithm, then try to trace senders though tx tree based on that coloring and see how badly that affects linkability 
17:26:54 <Rucknium[m]> I know devs are focused on hard fork issues and multisig right now, but it would be great if someone could take on the project of identifying the MyMonero / lws fingerprintable txs. I could maybe make an attempt with some pointers.
17:27:42 <rbrunner> Any news on PR 8149? Still waiting for the results of the external review I guess?
17:28:03 <UkoeHB> rbrunner: the audit is still in-progress I think
17:28:05 <jeffro256[m]> The review is to be done by inference AG right ?
17:28:33 <ooo123ooo1234567> <jeffro256[m]> "I'm working through reviewing #7..." <- Nothing mentioned here can be qualified as research, there are even open source crawlers for p2p network. Also SSL is mostly useless. And code reading is a bare minimum of development process, it isn't research.
17:29:15 <UkoeHB> jeffro256[m]: yes they are doing the audit
17:29:23 <rbrunner> It's almost cool how we will sail through the planned hardfork release date tomorrow without batting an eye ... at least so far.
17:29:43 <kayabanerve[m]> rbrunner: I did submit my own review with a few notes.
17:30:06 <rbrunner> Nice
17:31:05 <jeffro256[m]> > It's almost cool how we will sail through the planned hardfork release date tomorrow without batting an eye ... at least so far.
17:31:06 <jeffro256[m]> deadlines shmeadlines 
17:31:28 <ooo123ooo1234567> Rucknium[m]: mymonero / lws fingerprintable txs isn't a priority
17:32:08 <Rucknium[m]> ooo123ooo1234567: Yes, it's a priority.
17:32:10 <rbrunner> Whoever fancies to work on that will it make their own personal priority for a certain time ...
17:32:34 <cryptogrampy[m]> is the fingerprint simply that one can say the tx came from LWS?  does self-hosting an LWS server produce the same fingerprint?
17:32:41 <rbrunner> That's open source for you.
17:32:49 <ooo123ooo1234567> UkoeHB: early next week == monday or tuesday, right ?
17:32:59 <cryptogrampy[m]> the same fingerprint as MyMonero*
17:33:15 <ooo123ooo1234567> Rucknium[m]: reference implementation wallet2 is a ppriority, third party services aren't priority; why ?
17:33:30 <ooo123ooo1234567> s/ppriority/priority/
17:34:47 <Rucknium[m]> ooo123ooo1234567: First, on-chain action by some users can harm other users. That's one reason why users can no longer set their own ring size.
17:35:08 <kayabanerve[m]> <rbrunner> "It's almost cool how we will..." <- I have two conflicts here.
17:35:08 <kayabanerve[m]> 1) we moved multisig to the CLI labeling it "experimental". Without 8149, it should be "unsafe"
17:35:08 <kayabanerve[m]> 2) I have a minor PR I was hoping to get included and thought I had the necessary approvals for yet remains sitting there :C
17:35:35 <jeffro256[m]> > is the fingerprint simply that one can say the tx came from LWS?  does self-hosting an LWS server produce the same fingerprint?
17:35:35 <jeffro256[m]> jberman would know best, but it seems that the fingerprint is just a binary yes/no whether or not a wallet uses the MyMonero fee algorithm
17:35:53 <jeffro256[m]> To oversimplify 
17:36:31 <ooo123ooo1234567> Rucknium[m]: There are reasons to write/use ad-hoc implementation instead of wallet2, but it's certainly not due to alternative DSA. There is no point to chase every ad-hoc implementation, fix reference one
17:36:32 <Rucknium[m]> Second, MyMonero / lws has a subtle difference in the decoy selection algorithm compared to wallet2, so identifying those txs help with understanding what is happening with decoy selection on-chain.
17:36:33 <kayabanerve[m]> > <@jeffro256:monero.social> > is the fingerprint simply that one can say the tx came from LWS?  does self-hosting an LWS server produce the same fingerprint?
17:36:33 <kayabanerve[m]> > 
17:36:33 <kayabanerve[m]> > jberman would know best, but it seems that the fingerprint is just a binary yes/no whether or not a wallet uses the MyMonero fee algorithm
17:36:33 <kayabanerve[m]> Which voids their ring sigs and removes entire trees as valid decoys
17:36:39 <rbrunner> kayabanerve[m]: I wasn't accusing anybody, just being amused a bit about the Monero dev community as a whole :)
17:37:25 <jberman[m]> >  is the fingerprint simply that one can say the tx came from LWS?
17:37:25 <jberman[m]> this is the LWS one which is currently fixed in the develop branch, soon to be fixed in other branches
17:37:43 <kayabanerve[m]> rbrunner: I was throwing a tiny bit of shade and wanted to reraise the CLI option discussion :p
17:37:53 <jeffro256[m]> kayabanerve : Isn't 1) just a matter of word choice. Usually users equate "experimental" with "unsafe" .
17:37:55 <cryptogrampy[m]> Is there any way to prevent someone from making an implementation that is more fingerprintable in the first place?
17:37:56 <jberman[m]> the mymonero fingerprint is tied to the mymonero client still until those other PR's are shipped. so even if you self-host, if you're using the mymonero client your txs are fingerprintable as coming from the mymonero client 
17:38:00 <ooo123ooo1234567> Rucknium[m]: It's waste of time and certainly not a priority
17:38:12 <jeffro256[m]> > "Which voids their ring sigs and removes entire trees as valid decoys"
17:38:20 <kayabanerve[m]> jeffro256[m]: 8149 is experimental yet I believe it to be safe, even if I get why we won't endorse it as such
17:38:23 <jeffro256[m]> Yes there's a lot of knockon effects for sure 
17:38:32 <kayabanerve[m]> The current is dead code definitively broken
17:38:43 <kayabanerve[m]> It's not experimental once the experiment fails 
17:38:47 <Rucknium[m]> ooo123ooo1234567: Again, you don't understand the issues involved, so you don't see why it's a priority. Stick to what you know, I guess.
17:39:01 <kayabanerve[m]> I'm mainly worried users will see experimental and believe 8149 was merged when it wasn't
17:39:14 <Rucknium[m]> Or at least don't try to make definitive statements about what you don't know
17:39:50 <ooo123ooo1234567> Rucknium[m]: how to test understanding ? any counterexample ?
17:40:14 <Rucknium[m]> ooo123ooo1234567: Did you read those papers I suggested to you?
17:40:20 <jeffro256[m]> > I'm mainly worried users will see experimental and believe 8149 was merged when it wasn't
17:40:20 <jeffro256[m]> I guess that's a good point, it's not really experimental, it's just wrong 
17:40:40 <jeffro256[m]> * Not 8149 I mean, current code 
17:40:41 <jberman[m]> cryptogrampy[m]: UkoeHB has ideas in seraphis to make it easier to write wallet code where fees are less discernible, basically by rounding to an even higher place + reducing significant digits in the fee
17:40:43 <UkoeHB> hence why I said current code should be completely disabled lol
17:41:06 <ooo123ooo1234567> UkoeHB: it doesn't matter who you said
17:41:08 <ooo123ooo1234567> s/who/what/
17:41:41 <UkoeHB> jberman[m]: more than an idea https://github.com/UkoeHB/monero/blob/seraphis_lib/src/seraphis/tx_discretized_fee.cpp
17:42:08 <jberman[m]> true true :)
17:42:27 <kayabanerve[m]> UkoeHB: Agreed. Could you put up a PR tonight after this? Should we ping mooo?
17:43:11 <kayabanerve[m]> Because at the least, it's experimental -> unsafe for the CLI. Next would be a compile time def, which I'm not wholly against and think is probably optimal due to existing users. Finally would be yeah, ripping it.
17:44:47 <UkoeHB> kayabanerve[m]: tbh I don't think disabling would fly, the HF might just be delayed I guess
17:45:27 <kayabanerve[m]> Right. That's why there's the middle ground and a minimum :p
17:50:35 <ooo123ooo1234567> <Rucknium[m]> "ooo123ooo1234567: Yes. Two..." <- Once isolated ref implementation of DSA is available, what is the next goal ? Is there any public place which lists long term goal (with intermediate steps) that needs this work ?
17:52:52 <ooo123ooo1234567> <kayabanerve[m]> "Because at the least, it's..." <- instead of playing in this game of words, it would be good to have better understanding what is secure or not and why, much more helpful
17:53:48 <UkoeHB> ok we are getting to the end of the hour, any last minute comments/questions?
17:54:11 <kayabanerve[m]> ooo123ooo1234567: ... the current code is definitively insecure. Experimental suggests it may be fine, and it's an unknown. It's not an unknown. There's no experiment
17:54:45 <ooo123ooo1234567> <Rucknium[m]> "Or at least don't try to make..." <- the goal of that work is unknown, is it possible to make it public or not ?
17:54:45 <kayabanerve[m]> Therefore, experimental should at least be changed to unsafe as experimental was chosen with the expectation of 8149 being merged which is experimental, pending further review
17:55:13 <ooo123ooo1234567> kayabanerve[m]: you're continuing to play with words again, unknown things can be cleared out with some amount of work
17:56:02 <kayabanerve[m]> There's no word game here. That was facts on the current code and interpretation. That message didn't make a single comment on 8149
17:56:44 <kayabanerve[m]> My following comment said 8149 is considered experimental pending review, sure, yet didn't discuss why/how, making your comments still irrelevant
17:59:36 <UkoeHB> ok that's the end of the meeting, thanks for attending everyone
18:32:33 <ooo123ooo1234567> <Rucknium[m]> "ooo123ooo1234567: Again, you don..." <- I'd say pretty understand. You're continuing to gather some statistics instead of focusing on how it will be fixed. Even simple code translation is done with huge overhead + statistical test on top. Why is it all needed ?
18:34:20 <ooo123ooo1234567> <Rucknium[m]> "Second, MyMonero / lws has a..." <- exodus: https://github.com/ExodusMovement/mymonero-core-js/tree/master/monero_utils... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/1f429ed5a706ed8052d58fdc3ae673c83ec395c5)
18:42:00 <Rucknium[m]> ooo123ooo1234567: Explain to me in your own words how Moser et al. (2018) influenced the current decoy selection algorithm. Therein is the answer to your question about why gathering statistics is necessary to improve the decoy selection algorithm.
18:42:39 <Rucknium[m]> This is a research channel, so please read the research literature.
18:44:43 <Rucknium[m]> You waste my time if you don't read the research.
18:47:13 <Rucknium[m]> I won't try to answer any more of your questions until you can demonstrate a clear understanding of Moser et al. (2018) at least.
18:53:25 <ooo123ooo1234567> <Rucknium[m]> "Second, MyMonero / lws has a..." <- There are only 2 public implementations so far: wallet2 and mymonero/lws. That's just two implementations that can be learned via code reading. But instead of code reading you're doing translation from c++ into python, why ?
19:17:05 <kayabanerve[m]> Rucknium with a seeded random, you can move beyond simple statistical analysis 👀 Something to consider.
19:17:55 <kayabanerve[m]> <ooo123ooo1234567> "There are only 2 public implemen..." <- There's actually a long list of decoy selection algorithm implementations with 4+ documented distinct algorithms.
19:18:01 <ooo123ooo1234567> kayabanerve[m]: seeded/or not random is low level detail, it's unimportant for users of randomness
19:18:28 <kayabanerve[m]> ooo123ooo1234567: ... it means they can use test vectors instead of statistical analysis to verify implementation accuracy.
19:18:54 <kayabanerve[m]> I was commenting on the conversion to practicality. Now how to optimally handle their analysis of the algorithm itself.
19:19:02 <kayabanerve[m]> Though I will still recommend a seeded random there as it's reproducible which is beneficial.
19:21:32 <kayabanerve[m]> Regarding the 4+ algorithms, it's wallet2, MyMonero/lws, my own simple random over a semi-static range, and one we've observed yet not identified
19:21:54 <ooo123ooo1234567> kayabanerve[m]: https://libera.monerologs.net/monero-research-lab/20220608#c106898, It was explicitly ignored already, it was only 1 week ago
19:21:54 <kayabanerve[m]> Though it's distinct enough to confirm it's a distinct implementation. We just have no clue where it's from/who used it where
19:22:27 <kayabanerve[m]> Thanks for the heads up there
19:23:07 <ooo123ooo1234567> kayabanerve[m]: is it public info ?
19:23:08 <kayabanerve[m]> Not my preference, yet if it's already been discussed...
19:23:23 <kayabanerve[m]> ... I mean, we don't where it's from. It's not even private info lol
19:23:46 <kayabanerve[m]> If you wanted to ask for the exact characteristics, I believe Rucknium has noted them as an outlier on an insignificant amount of TXs
19:24:06 <ooo123ooo1234567> <kayabanerve[m]> "There's actually a long list..." <- link to list ?
19:24:10 <ooo123ooo1234567> > <@kayabanerve:matrix.org> There's actually a long list of decoy selection algorithm implementations with 4+ documented distinct algorithms.
19:24:10 <ooo123ooo1234567>  * link to this list ?
19:24:21 <kayabanerve[m]> Though I'd check with them for the exact aspects they want to disclose, along with the most recent findings as I was solely one person helping him work through it
19:24:29 <kayabanerve[m]> The list is a GH issue. I'll try to find it...
19:24:54 <kayabanerve[m]> https://github.com/monero-project/research-lab/issues/99
19:26:16 <kayabanerve[m]> I remember discussing placing mine there, yet I believe it has at most 2 TXs on mainnet so I asked why bother. My current ecosystem work will be there when it's public, yet I believe it's `monero-lws` rn which would be problematic 🤔I'll want to follow up with jberman on that
19:26:36 <Rucknium[m]> kayabanerve: Identical seeds and transformation of those seeds into random numbers would be ideal, but that takes additional development time. How much? I don't know, since I'm unfamiliar with the process. 
19:26:51 <kayabanerve[m]> And then for the fourth distinct algorithm.... we haven't linked it to a wallet. Maybe `? Characteristic []` as a new row?
19:27:04 <chesterfield[m]> if everyone starts running LWS, won't that mean the regular wallet transactions are the ones that stick out? :) 
19:27:23 <kayabanerve[m]> Yet I'd question what Rucknium would consider the defining characteristic of it, or if they prefer Dave as a name :p
19:27:33 <kayabanerve[m]> chesterfield[m]: More likely we'd end up with two privacy pools :/
19:27:42 <ooo123ooo1234567> Rucknium[m]: indeed, long texts are easier to write than code
19:27:54 <kayabanerve[m]> Which is why the deterministic ring discussion exists
19:28:01 <kayabanerve[m]> Rucknium: It's trivial in Rust <3
19:28:30 <kayabanerve[m]> If you want to remain in Python, if you DON'T use a CSRNG yet rather Python's random, it should be possible to seed it as long as you're only running on a single thread
19:28:51 <kayabanerve[m]> So it should just be something like `random.set_seed(x)` before you run each selection. I'd have to check the exact docs.
19:29:03 <kayabanerve[m]> And not using a CSRNG shouldn't be an issue here
19:29:28 <ooo123ooo1234567> kayabanerve[m]: wow, teaching python in research channel
19:30:07 <selsta> chesterfield[m]: there is a patch for it: https://github.com/vtnerd/monero-lws/pull/22
19:30:11 <kayabanerve[m]> My main comment is that if this is a Python codebase, it's a single line which would potentially simplify research and greatly augment equivalence testing/the changes needed to reach equivalence within the Python structure
19:30:20 <kayabanerve[m]> Though I will note cross-language seeded... probably not feasible.
19:31:55 <kayabanerve[m]> Fun :D I'm standard, not monero-lws, as monero-lws is now standard :D
19:38:53 <Rucknium[m]> kayabanerve: I had thought it was difficult because what is needed is cross-language seed and random number generation. Setting a seed in a single language is straightforward, yes.
19:39:39 <kayabanerve[m]> Got it. Then you're already on the right page, sorry
19:40:48 <Rucknium[m]> Took me a bit to find it: isthmus uncovered a very nonstandard decoy selection "algorithm" occurring on-chain that just selected the same decoys over an over again, 65,000 times. So the real spend was the "unique" ring member: https://libera.monerologs.net/monero-research-lab/20211124#c50834
19:43:45 <endogenic> so the mymonero lws has been identified as having a bad decoy selection algo after all? i wondered about that a year or two ago but couldnt go check
19:45:16 <Rucknium[m]> endogenic: AFAIK, no. It's the fee algorithm that's distinct and leads to fingerprinting. I think the decoy selection algorithm differs from wallet2 is subtle ways...oh jberman is answering
19:45:33 <jberman[m]> nay, it's just a little different from wallet2. likely not in a fingerprintable way imo
19:45:47 <endogenic> when did the difference begin?
19:45:58 <endogenic> bc wallet2 upgraded its selection algo at some point
19:46:04 <endogenic> i thought mymonero had kept up as well
19:48:35 <jberman[m]> well it's always been different since it didn't have the bugs the wallet2 impl had. wallet2 got closer to monero-lws after 7798 + 7821 patched those other bugs. monero-lws still slightly different from wallet2 in the way that PR selsta linked above shows
19:48:51 <endogenic> monero lws and mymonero lws are totally different
19:49:01 <endogenic> that's an issue if theyre not being distinguished
19:49:11 <endogenic> i say totally
19:49:19 <jberman[m]> oh I'm not sure about mymonero
19:49:23 <endogenic> bc they are different codebases and different deploys
19:49:40 <endogenic> ok whoever was arguing before, take note ^
19:49:54 <endogenic> and also work together ya heathens
19:50:43 <jberman[m]> was told they were using the lws impl around last August, but not sure when they started using it
19:52:37 <endogenic> wait seriously?
19:52:54 <endogenic> that wouldnt work at scale
19:53:08 <endogenic> otoh who knows
19:53:11 <jberman[m]> of the decoy selection algo
19:53:17 <endogenic> oh
19:58:23 <ooo123ooo1234567> <Rucknium[m]> "endogenic: AFAIK, no. It's the..." <- "We need a mathematical definition of the probability density function that the wallet2 decoy selection algorithm uses. Also we can use this code to check how well other implementations in "third party" wallets are mimicking the wallet2 behavior." 
19:58:23 <ooo123ooo1234567> wow, for comparison of something that differs only in subtle ways
19:59:01 <ooo123ooo1234567> if it differs only in subtle ways then nothing to compare; if the goal is math def of PDF then read code and write math def; just facepalm
19:59:45 <endogenic> yo what's your deal
20:00:12 <endogenic> are you gonna help or not
20:00:39 <endogenic> just read the algos and write the formulae if you want them
20:01:01 <endogenic> then present them to the room
20:01:07 <endogenic> seems kinda spammy otherwise tbh
20:01:13 <endogenic> maybe i'm missing something?
20:09:48 <ofrnxmr[m]> I assume its possible to reject old decoy algos (?) so im seconding cryptogrampy's question:
20:09:48 <ofrnxmr[m]> Is it possible to stop wallets from using malicious or non-standard decoy selection methods on mainnet? Or to stop nodes from relaying those tx? 
20:09:56 <endogenic> it's not possible
20:10:17 <endogenic> it's like trying to verify info is a random string
20:10:34 <ooo123ooo1234567> <endogenic> "maybe i'm missing something?" <- context
20:10:43 <endogenic> wow so helpful ooo123ooo1234567
20:10:45 <endogenic> not
20:11:21 <endogenic> please reiterate to endogenic what you want clearly
20:11:24 <endogenic> so you can stop spamming
20:12:13 <ofrnxmr[m]> endogenic: If wallets sent a fingerprint of some sort to confirm the algo they are using? 
20:12:59 <endogenic> then how do you verify it?
20:13:06 <endogenic> as a verifier
20:13:30 <UkoeHB> ofrnxmr[m]: you could use a statistical test to reject rings that look probably bad, but it would be really awkward and have all kinds of edge cases
20:15:35 <ooo123ooo1234567> > <@ofrnxmr:monero.social> I assume its possible to reject old decoy algos (?) so im seconding cryptogrampy's question:
20:15:35 <ooo123ooo1234567> > Is it possible to stop wallets from using malicious or non-standard decoy selection methods on mainnet? Or to stop nodes from relaying those tx?
20:15:35 <ooo123ooo1234567> likely possible, but that isn't enough
20:15:46 <Rucknium[m]> ofrnxmr: Statistical tests are _probably_ not the way to go for this. koe's so-called "deterministic" ring selection could be used, as I understand it: https://github.com/monero-project/research-lab/issues/84
20:15:58 <UkoeHB> yeah you could make it fully deterministic ^
20:16:45 <Rucknium[m]> Enforcement at the consensus or node-rebroadcast level is discussed here: https://github.com/monero-project/research-lab/issues/87
20:17:47 <ooo123ooo1234567> <endogenic> "maybe i'm missing something?" <- confirmation from Rucknium about their goal; it makes sense to do something quicker if it's at least what they need, but Rucknium dodge any questions about goals (final /intermediate), at least in public
20:19:11 <Rucknium[m]> I think to improve transaction uniformity, it would be a good idea to do it if we can vet a possible solution. Transaction non-uniformity gets worse as ring size increases, which Seraphis will do. In essence, higher sample size = greater ability to distinguish between nonstandard decoy selection algorithms
20:19:15 <ofrnxmr[m]> Rucknium[m]: Tyty this was my exact question
20:23:04 <UkoeHB> Rucknium[m]: not necessarily with binning, since it's only the bin loci that are selected from the macro distribution (right now I have 16 bins x 8 bin members, for example)
20:24:31 <Rucknium[m]> UkoeHB: I agree.
20:41:56 <kayabanerve[m]> <Rucknium[m]> "Enforcement at the consensus..." <- hello i'm here to say i hate anyone and anything increasing foreign TX checks on ill defined data
20:42:34 <kayabanerve[m]> Deterministic rings? Sounds great.
20:42:34 <kayabanerve[m]> Arbitrary criteria frequently requiring context which will cause infrequent failures? D:
20:42:57 <kayabanerve[m]> Before publishing, without a race condition, I should know if my TX is valid as I create it.
20:43:08 <kayabanerve[m]> Current sanity rules do not hold that condition, and while they're optional, I'm against any expansion of them
20:43:27 <kayabanerve[m]> *race condition as in a double spend
20:43:44 <kayabanerve[m]> It's the fact context is itself a race condition I'm complaining
20:46:20 <ooo123ooo1234567> <Rucknium[m]> "You waste my time if you don't..." <- "Until we can figure that out, we are going to have to use statistics to camouflage user behavior under the ring signature model." Questions were about DSA changes and how to verify it's solution. There may be few solutions, but verification is the same.
20:47:29 <ooo123ooo1234567> * the same. And any unverifiable solution would be placebo or another crackable heuristic
20:48:25 <ooo123ooo1234567> <Rucknium[m]> "I won't try to answer any more..." <- It didn't help that scammer, since in the worst case your solution will be cracked once you made it public, it only postpones problems
20:49:16 <gingeropolous> but wouldn't the "arbitrary criteria" be true for all participants at a given moment in time?
20:51:22 <gingeropolous> i guess an underlying piece of that thought is that there is an inherent time limit between tx creation and broadcast 
20:52:48 <ooo123ooo1234567> <Rucknium[m]> "This is a research channel, so..." <- Is it possible to enforce this rule globally for whole channel ? I'm ready for this requirements, but what's about others ?
20:54:34 <gingeropolous> i wonder if those data are available. the interval between txpool injection and most recent ring member
20:55:22 <gingeropolous> well these days block inclusion and most recent ring member are a close enough proxy
21:18:29 <ooo123ooo1234567> <kayabanerve[m]> "Therefore, experimental should..." <- https://github.com/monero-project/monero/pull/8387, it's literally game of words
21:22:36 <selsta> it's clearer wording at least
21:33:14 <ooo123ooo1234567> "Until @8149 is merged, this would communicate the state of multisig more accurately." or less accurately
21:34:08 <ooo123ooo1234567> texts is even more subjective thing than code
21:34:25 <ooo123ooo1234567> s/texts/text/words/
21:42:48 <hyc> is 8149 not going to be merged any time soon?
21:54:35 <UkoeHB> hyc: probably needs ~1-2weeks minimum
22:19:43 <ooo123ooo1234567> <UkoeHB> "hyc: probably needs ~1-2weeks..." <- probability is somewhere between 0 and 1
22:30:00 <hyc> ooo123ooo1234567: no need to quote everything you reply to
22:30:11 <hyc> just clutters up the session
22:38:13 <UkoeHB> gingeropolous: I was also thinking about that. I wonder how big a delay you need for it to be discernible on-chain with decent probability.
22:41:10 <UkoeHB> Now that we are in tail emission, fees will leak a lot less information, but for older txs they might provide very high granularity timing info