13:59:01 <UkoeHB> Meeting 3hr
17:00:02 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/709
17:00:02 <UkoeHB> 1. greetings
17:00:02 <UkoeHB> hello
17:00:19 <jberman[m]> hello
17:00:23 <rbrunner> Hi there
17:00:34 <xmr-ack[m]> Hi
17:00:47 <gingeropolous> o/
17:01:35 <Rucknium[m]> Hi
17:02:16 <dangerousfreedom> Hello
17:02:41 <merope> Hello
17:02:54 <UkoeHB> 2. updates; what is everyone working on?
17:04:04 <dspringer71[m]> hello
17:04:19 <UkoeHB> me: working on seraphis enote scanning workflow, and in the middle of a detour to rework the tx building workflows for this https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4176179#gistcomment-4176179
17:05:05 <xmr-ack[m]> Me: lots of travel this last week, but continuing to work on feature engineering. Neptune is helping me out with setting up a database with all references to decoy occurrences on chain.
17:06:08 <jberman[m]> mainly been working through understanding the changes to the server code in 7760, stepping through old and new code with provided tests + setting up my own mini boost asio test env to figure it out. taking me quite a bit to get up to speed with boost asio but making progress
17:06:14 <dangerousfreedom> I will hand my first delivery for the first part of my ccs next week. I believe I understand MLSAG and the first rangeproofs. I will be working on CLSAG and Bulletproofs next month. Meanwhile, I have been scanning the blockchain looking for some leaks or strange things that could lead to inflation. I have to thank gingeropolous because now my work is much faster as I have access to some computing resources :)
17:06:53 <Rucknium[m]> Doing some statistical analysis of personal characteristics that are associated with using cryptocurrency as a means of payment, based on the U.S. Federal Reserve's recently-released Survey of Household Economics and Decisionmaking 2021 microdata. Preliminary results suggest that financial marginalization is positively correlated with use of cryptocurrency as a means of payment in the U.S., somewhat to my surprise. I think I can
17:06:53 <Rucknium[m]> push something out by tomorrow.
17:09:21 <UkoeHB> thanks for the updates
17:09:28 <UkoeHB> 3. discussion, anything to discuss?
17:09:32 <mj-xmr[m]> I've been busy preparing the 1st milestone of SolOptXMR with endor00 . After this, I'll return to my decoy task.
17:10:55 <rbrunner> Do you expect any more changes to #8149, or do you think it's complete now? Was somewhat surprised to see how much changed 2 days ago.
17:10:59 <UkoeHB> For seraphis, I want to emphasize that the update I mentioned basically kills collaborative funding and isolated enotes. Those were both mostly 'nice-to-haves', so while unfortunate I'm not that sad. My multisig verification code is a lot easier with this.
17:11:43 <UkoeHB> rbrunner: no more changes. I rolled back some stuff I shoved in their since it was out of scope.
17:11:48 <UkoeHB> there*
17:12:16 <rbrunner> Ok, thanks
17:12:52 <Rucknium[m]> dangerousfreedom: Thanks. Any non-uniformities in the transactions that are in the cryptography (like you have already found) can be beneficial for identifying nonstandard wallet implementations. So keep collecting them :) 
17:13:24 <UkoeHB> does anyone have more opinions about https://github.com/monero-project/monero/issues/8351 ?
17:14:21 <jberman[m]> UkoeHB: can you give a refresher description of isolated enotes/what functionality would be lost as a result? 
17:14:27 <dangerousfreedom> Thanks, so far I have some issues with these stealth addressess being outside the prime group. They can be members of ring signatures later and then compromise fungibility... yeah give your thoughts
17:14:28 <Rucknium[m]> UkoeHB: Is collaborative funding something that the underlying cryptography would still support, i.e. is this just a wallet implementation simplification?
17:15:55 <UkoeHB> jberman[m]: 'isolated enote' means creating an enote without any surrounding context (no other tx outputs, no tx inputs). There are no known tx engineering protocols that could use that. Now you need to know the full input set when defining your enotes (or block height for coinbase txs).
17:17:47 <UkoeHB> Rucknium[m]: previously, collaborative funding could have an easy interface (so it could be supported by the core wallet API), but now you need an interactive protocol between all tx participants (which won't be supported by my PoC, and shouldn't be supported by the core wallet).
17:18:22 <UkoeHB> so yes, it can still be done, but it's harder and more constrained
17:18:46 <moneromooo> Collaborative funding being... Alice and Bob both sign a ring in the same tx ?
17:18:53 <UkoeHB> moneromooo: yes
17:22:35 <rbrunner> From what I can grasp right now, I agree with that trade-off: Robust core protocol trumps nice-to-have features as this one
17:22:45 <jberman[m]> wouldn't collaborative funding be interactive by definition either way? little confused on that
17:25:12 <UkoeHB> jberman[m]: old version: define outputs, publish output set proposal, anyone can send in partial inputs funding the output set; new version: define destination set, define input set, finish defining outputs as function of inputs, make partial inputs, complete tx (so you need to interact with other input contributors + the output set definer in order to make input sigs)
17:25:37 <moneromooo> Does Seraphis use bulletproofs ? 
17:25:43 <UkoeHB> moneromooo: yes
17:26:32 <moneromooo> When I coded collaborative inputs, it turned out it was impossible (as far as Sarang found) to create the BPs without leaking the real spends to other funders.
17:27:43 <UkoeHB> not sure why that would be
17:27:59 <moneromooo> I couldn't tell you, sorry. I'm just a code monkey :)
17:28:04 <UkoeHB> but yeah it does take some careful thought to prevent info leaks
17:29:04 <UkoeHB> moneromooo: was it MoJoin?
17:29:25 <moneromooo> Oh I think it might have taken that name at some point...
17:29:48 <moneromooo> I don't remmeber the timeline tbh.
17:30:11 <UkoeHB> the TxTangle protocol in ZtM2 is an evolution on MoJoin, you'd probably need something like that to get collaborative funding with seraphis (maybe a bit simpler though)
17:31:22 <moneromooo> Anyway, the reason I mentioned this is (1) it'd be nice to get it and (2) if we use BP anyway, it's already DoA due to the leak anyway so no big loss.
17:31:33 <moneromooo> Unless someone found a way to avoid the leak since then.
17:32:21 <UkoeHB> it would need to be a third-party solution like atomic swaps
17:33:57 <jberman[m]> Losing that collaborative funding flow does seem a bit of an unfortunate loss. sounds like the old could enable a nicer crowdfunding model (something Rucknium has brought up in the past about an approach to CCS that doesn't involve trusted parties e.g.)
17:34:20 <UkoeHB> yeah it was originally inspired by Rucknium[m]'s comments
17:37:39 <Rucknium[m]> FWIW, BCH's Flipstarter is basically a third-party implementation. The first generation version of Flipstarter needed some software running on a VPS for the Flipstarter "host" and a plugin on the Electron Cash wallet for donors.
17:40:09 <UkoeHB> Any other topics people want to discuss?
17:42:21 <UkoeHB> ok I think we can close it out here; thanks for attending everyone
17:42:36 <Rucknium[m]> Does anyone have any ideas on "sanity checks" I can run on this Federal Reserve Household Economics data? Basically, what characteristics might we assume be correlated with use of cryptocurrency as a means of payment? I have checked education degree (computer science is the only statistically significant degree associated with use of cryptocurrency as a means of payment) and willingness to take risks (yes, it's positively
17:42:37 <Rucknium[m]> correlated).
17:42:50 <UkoeHB> nvm meeting continues lol
17:42:58 <Rucknium[m]> I want to make sure that the data is not just random responses. So far, the data seems legit.
17:43:34 <Rucknium[m]> Also, use of cryptocurrency as a means of payment is associated with lower life satisfaction. That's consistent with everyone's personal experience, right? :P
17:43:41 <merope> Usage in DNMs/association with crime, maybe? But I don't know if/how that could be measured
17:44:10 <UkoeHB> I'd expect predominantly men age ~18-35
17:44:28 <merope> Would be nice to be able to compare fiat usage in criminal activity (as a means of payment) vs crypto criminal activity
17:46:31 <Rucknium[m]> UkoeHB: Yes, youth and male are associated with use as a means of payment. In fact, I'm using age in most of my regressions since financial marginalization and age are also likely correlated, so I don't want to introduce omitted variable bias.
17:46:31 <merope> Maybe crypto usage vs "tech skills" (not as a degree, but general tech savyness)
17:47:38 <dspringer71[m]> <Rucknium[m]> "Does anyone have any ideas on "..." <- How it can be used for cryptocurrency development in the best case ?
17:48:38 <Rucknium[m]> endor00: There is a question on device type that was used to complete the survey. So I can look at that. On DNM: I didn't see anything relevant in the data dictionary on that.
17:50:04 <Rucknium[m]> dspringer71: Adoption is arguably as difficult as protocol development. We don't understand adoption well. Once it is understood, maybe we can figure out ways to promote it.
17:50:49 <Rucknium[m]> Wider adoption improves the anonymity set, enhancing privacy.
17:51:02 <UkoeHB> I'd predict that adoption is anti-correlated with promotion lol
17:51:22 <dspringer71[m]> Rucknium[m]: Goals of project aren't compatible with wider adoption
17:51:47 <merope> Why wouldn't they be?
17:52:05 <Rucknium[m]> UkoeHB: Maybe we can eventually test that hypothesis!
17:52:24 <UkoeHB> Rucknium[m]: that would really be something to see
17:54:01 <UkoeHB> I guess 'grassroots' promotion would be forward-correlated, and any 'centralized' promotion would be anti-correlated.
17:54:03 <merope> Oooh, what about usage in large urban areas vs rural areas?
17:54:25 <dspringer71[m]> UkoeHB: are there any link to the most comprehensive benchmark for view tag available somewhere ?
17:54:56 <UkoeHB> although the causal order between adoption and grassroots promotion is worth pondering
17:55:18 <moneromooo> Rucknium[m]: "likes privacy and uses cryptocurrency to give it hard to visa/mastercard spying ops"
17:55:39 <moneromooo> (about "what characteristics might we assume be correlated...")
17:55:57 <Rucknium[m]> endor00: Yes there is a question on if the survey respondent is in a metropolitan statistical area or not. I'm not sure that would be a data quality check per se, but it would be interesting.
17:55:59 <UkoeHB> and the failure of centralized promotion may be as much as, or more than, a symptom of deeper issues
17:56:09 <moneromooo> I have low life satisfaction because I realize the world spies on me, indeed.
17:57:08 <UkoeHB> wow word salad: as much a symptom as a cause*
17:57:31 <moneromooo> There's the good old "works in a sector that's legal but frowned upon".
17:57:45 <moneromooo> Like gambling, sex, weapons.
17:57:52 <moneromooo> (depending on your jurisdiction
17:58:08 <Rucknium[m]> moneromooo: Interesting idea. There are some questions in the survey that may capture how much trust survey respondents have in government and business institutions.
17:59:34 <Rucknium[m]> There are some questions on occupation and industry. Sort of broad categories, though, so it may not have "frowned upon" activities isolated well.
17:59:36 <moneromooo> An also commonly mention characteristics is "works in a rich country, but family is in a poor country, and money transfer services charge loads (except hawala)).
17:59:58 * moneromooo cringes at the grammar in the previous sentence
18:00:25 <moneromooo> Might not be "payments" though, depending on how you look at it.
18:00:29 <merope> Is there any data about usage of the "frowned upon" services?
18:00:42 <moneromooo> Oh, cannabis is a good one probably.
18:00:53 <sech1> "works in a rich country, but family is in a poor country" <- but family is in Russia, and money transfer services don't work at all
18:01:07 <Rucknium[m]> Respondents that did not have U.S. citizenship were more likely to use cryptocurrency as a means of exchange, according to preliminary results.
18:01:17 <moneromooo> Can you sell crypto for roubles in russia nowadays ?
18:03:18 <Rucknium[m]> I also have number of years the respondent has lived in the U.S. and language spoken at home, but I have not analyzed them yet.
18:03:32 <UkoeHB> ok we are past the hour now; thanks for attending everyone
18:04:17 <moneromooo> "is an immigrant" might be, since those people often have difficulties opening a bank account in the new country.
18:04:27 <dspringer71[m]> Rucknium[m]: I don't believe that usage of surveillance data can be used for the sake of cryptocurrency promotion. Centralized money has huge advantage in access to any surveillance data.
18:05:03 <dspringer71[m]> The goal of this project is to prevent surveillance.
18:05:38 <UkoeHB> github is ded ^.^
18:05:53 <moneromooo> Embrace, extend, extinguish ? ^_^
18:06:21 <dspringer71[m]> UkoeHB: how to check ?
18:06:32 <UkoeHB> seems like a good operating model
18:07:05 <jberman[m]> <dspringer71[m]> "UkoeHB: are there any link to..." <- poc benchmarks: https://github.com/UkoeHB/monero/blob/86b253ebb9a6e47d621cc38e162b252c50b6fd46/tests/performance_tests/view_scan.h    +   https://github.com/SarangNoether/monero/blob/c710f1bc1dfda9d838aa89f31fb0645e4cf94235/tests/performance_tests/view_tag.h
18:07:49 <jberman[m]> I don't have a good link to share on my mainnet benchmarking that arrived at 30-40%, but my methodology was:
18:07:54 <sech1> "Can you sell crypto for roubles in russia nowadays ?" yes, lots of instant exchanges in Russia
18:08:03 <jberman[m]> - disconnect my node from the rest of the network
18:08:03 <jberman[m]> - create new wallet using old and new code, with consistent restore heights (10k, 100k, whole chain) and measure time it takes to scan
18:08:03 <jberman[m]> - to test view tags, I tested for equality to a static 0x00 right here: https://github.com/monero-project/monero/blob/8349cfe4a63cfc63d50ce3818886b67a05e240a4/src/cryptonote_basic/cryptonote_format_utils.cpp#L1006
18:08:39 <moneromooo> Also "self employed in a tech sector".
18:10:56 <Rucknium[m]> moneromooo: Thanks for the suggestions. I will see what the data can do.
18:12:09 <moneromooo> Oh. Has a criminal record for drug usage ^_^
18:15:05 <dspringer71[m]> jberman: In my performance test for upper boundary ratio is: --max-concurrency=0 + just view tags <= 75%, --max-concurrency=0 + view tags + thread pool modification <= 71%;
18:15:59 <kayabanerve[m]> Sorry for missing the meeting. I just wanted to chime in, regarding Bulletproofs, dalek's impl has collaboration and sarang has acked it IIRC. 
18:16:42 <dspringer71[m]> What to add for potential -40% ?
18:16:56 <jberman[m]> as in you modified the thread pool with your own code?
18:17:08 <dspringer71[m]> offline, 2000k, the rest as you did
18:17:37 <dspringer71[m]> s/2000k/2000 blocks/
18:18:30 <kayabanerve[m]> Regarding that subgroup discussion, I do endorse Ristretto, as I've stated in the past, just to simplify things and end these discussions while guaranteeing security there.
18:19:22 <dspringer71[m]> jberman[m]: I mean, do you remember what was important for so big fluctuation of performance 30%, 40% ?
18:20:56 <jberman[m]> various block ranges produced different results. closer to 30% was more common from what I remember
18:21:11 <jberman[m]> why not test with concurrency?
18:21:11 <dspringer71[m]> The only way I see to get ~40% drop, is to use --max-concurrency=1; after that performance ratio is --max-concurrency=1 + just view tags <= 62%, --max-concurrency=1 + view tags + thread pool modification <= 62%;
18:21:33 <dspringer71[m]> did you do something like this or it was just fluctuation due to different ranges of scanning ?
18:22:30 <jberman[m]> I did test with concurrency enabled/disabled as I was working on it, but the 30-40% was with concurrency enabled with my machine's max (8 threads)
18:22:53 <dspringer71[m]> jberman[m]: Did you disable turbo boost on that machine ?
18:22:55 <jberman[m]> the fluctuation between 30-40% was just over different block ranges
18:23:14 <jberman[m]> nope
18:23:39 <dspringer71[m]> jberman[m]: probably this then
18:24:41 <dspringer71[m]> I also added isolated test for txs with different number of destinations: std / subaddr
18:25:27 <dspringer71[m]> and it shows the same ratio 75% as in wallet2 without thread pool test, so everything in accordance with theory
18:28:33 <jberman[m]> when you say ratio 75%, you mean 10s -> 7.5s, right?
18:29:38 <dspringer71[m]> yes, fastest / slowest
18:30:30 <dspringer71[m]> "https://github.com/monero-project/research-lab/issues/73#issuecomment-634961245", this 60% is for tx with 2 outputs including change or not including change ?
18:32:59 <dspringer71[m]> In isolated test I get 75% (124ms / 144ms) for 2 outputs including change, 66% (124ms / 188ms) for 2 outputs excluding change (so it's 3 outputs in reality)
18:39:45 <dspringer71[m]> No questions regarding performance savings except for enabled concurrency and 40% with different block ranges 10k, 100k, whole chain (maybe will test too, but I doubt that I will reproduce it)
18:40:57 <dspringer71[m]> In theory it's possible if older outputs have only std addresses in destinations, since this is case of the most performance benefit
18:41:15 <dspringer71[m]> But it isn't applicable to fresh data (2000 fresh blocks shows ~71% ratio)
18:41:43 <dangerousfreedom> <kayabanerve[m]> "Regarding that subgroup discussi..." <- Maybe Ristretto would be overkill. I am not an specialist (yet :p) but if we ensure that only Points of our subgroup are stored in the blockchain we don't need to make big modifications and would play safe. What do you think?
18:42:10 <kayabanerve[m]> I think you don't know what Ristretto is :p
18:42:35 <kayabanerve[m]> But you may and simply believe the series of ed25519consensus rules is sufficient
18:42:41 <dangerousfreedom> kayabanerve[m]: Not much :p
18:42:47 <kayabanerve[m]> dangerousfreedom: It's solely a point encoding
18:43:13 <kayabanerve[m]> It's the same exact curve and scalar field.
18:43:26 <kayabanerve[m]> But all points are encoded canonically and decoded canonically.
18:43:58 <UkoeHB> dangerousfreedom: check out the Ristretto section in mechanics of mobilecoin
18:44:13 <kayabanerve[m]> There is edcon, which is a series of rules, no torsion, not above curve order, etc, and I believe they end up slower than ristretto as they're ecc ops themselves
18:44:28 <dangerousfreedom> Yeah, the thing is the speed. Thats what I meant. We don't need to touch the cryptography schemes if we ensure that the recorded points are in this subgroup.
18:44:38 <kayabanerve[m]> And ristretto does have a slight performance penalty but it ends this discussion .-.
18:45:14 <kayabanerve[m]> dangerousfreedom: I mean, it's much more than that, and I wouldn't be surprised if a torsion check is slower than ristretto with the rest of the rules
18:45:27 <kayabanerve[m]> UkoeHB: do you happen to know?
18:45:48 <kayabanerve[m]> I think Ristretto is quoted at 5% or so and I'm unsure how the scalar mul compares
18:46:41 <kayabanerve[m]> Oh. It's also faster to test equality
18:47:02 <jberman[m]> dspringer71: try block height 2484065, restore height 2459065
18:48:08 <UkoeHB> kayabanerve[m] don't know
18:48:48 <kayabanerve[m]> I'll write a snippet now
18:55:08 <kayabanerve[m]> 13ms R encode... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/73422fc22b1e2148999828f54b140743b7ae6863)
18:55:12 <kayabanerve[m]> UkoeHB: 
18:55:47 <dangerousfreedom> > <@kayabanerve:matrix.org> 13ms R encode... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c3810a1d970fc56f783ca1843733f0075fd9340a)
18:56:15 <kayabanerve[m]> 1000 runs per op. Two runs each with the same results for all except inv 8, 8 was 288ms on its first. Rust dalek debug.
18:56:33 <UkoeHB> kayabanerve[m]: would be interesting to know the proportion of tx verification cost used by encoding/decoding
18:56:41 <UkoeHB> hard to get that data though
18:56:47 <dangerousfreedom> Or what is R and E? 
18:56:54 <kayabanerve[m]> dangerousfreedom: That should be theoretical numbers capable of comparison. Subgroup checks, as monero does them, increases decode 24x
18:57:27 <UkoeHB> kayabanerve[m]: monero's subgroup check is to mul l
18:57:32 <kayabanerve[m]> So it's ~50% slower encode with 25% slower decode but it's 20x faster in subgroup decode 
18:57:42 <kayabanerve[m]> UkoeHB: Yeah but we don't actually do that .-.
18:57:53 <kayabanerve[m]> Like BP data is inv 8 8
18:58:01 <UkoeHB> for key images it's mul l
18:58:14 <kayabanerve[m]> Though tbf, if sender inv 8, this is just a series of doubling which should be performant
18:58:15 <UkoeHB> BP points are pre-multiplied by inv 8
18:58:26 <kayabanerve[m]> UkoeHB: Fair. I'll get numbers simply 8 and l
19:00:02 <kayabanerve[m]> dangerousfreedom: 18ms with 8. Still slower.
19:00:02 <kayabanerve[m]> Considering this is constant time, the 286 - 18 should be the scalar mul speed. That means by l would be 268ms per 1000. 
19:00:14 <kayabanerve[m]> > <@kayabanerve:matrix.org> 13ms R encode... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/b5d44f1f7dfee51559ed5487b99f0b51b01b7575)
19:01:25 <kayabanerve[m]> So dalek places Ristretto as more performant than cofactor mul and far more performant than any scalar mul, as done by senders and for key images
19:03:20 <kayabanerve[m]> Monero also constantly encodes/decodes, which is idiotic, yet we can do Ristretto over the wire and Ed25519 internally so we get the benefits of Ristretto without decreasing performance. Proper scalar/point type usage would speed both up equally after that
19:04:20 <kayabanerve[m]> So no matter what the subgroup guarantee is, Ristretto is always more performant, and I assume it'll be more comprehensive in a lot of ways. We no longer have to add additional checks for points. We just have it. The end.
19:04:40 <kayabanerve[m]> There's also libs from C++ to Rust to Python to JS to Zig
19:05:43 <kayabanerve[m]> So when everyone just uses wallet2, and then people who do rebuild wallet2 still have the necessary options... I don't see this as unsupported, bleeding edge crypto. It's established, with an IETF draft, accepted, and supported
19:06:55 <kayabanerve[m]> jberman: would also speed up wallet scanning time 👀 The ECDH are 8Ra. This would make it *just* Ra with a smaller penalty to extra parsing
19:07:53 <kayabanerve[m]> Anyways. I said I'll take a stab at adding Ristretto to koe's work when I had a chance, and have been busy with a few things. I'll try to re-prio time for that...
19:15:12 <dangerousfreedom> kayabanerve: Nice comments. I read some stuff that there are some possible attacks when you multiply stuff outside the subgroup. I didnt go deep into the details but do you believe it is safer also or only faster?
19:39:29 <kayabanerve[m]> <dangerousfreedom> "kayabanerve: Nice comments. I..." <- Ristretto's safety is faster than our current safety. Globally using safety means we can never forget about it or have oversights.
19:41:07 <kayabanerve[m]> Right now, Bulletproofs are doing mul by cofactor to correct for out of subgroup. Key images aren't corrected yet are verified to be in subgroup. Then we have > order checks when decoding and a -0 check. Output keys used to not even be checked to be points and I think they're now solely required to be decodable points.
19:42:08 <kayabanerve[m]> Which presumably would be < order, not negative zero, yet in any subgroup 
19:43:11 <kayabanerve[m]> It's an uber sporadic series of checks creating a ton of edge cases which now that I think about it, probably break my code as currently written .-. 
19:43:34 <kayabanerve[m]> Ristretto would be a uniform set of rules applied to all points removing these questions and concerns though.
19:45:36 <kayabanerve[m]> Oh. I think ristretto also has batch decoding... I'd have to check if ed25519 does before claiming that as an advantage though
19:50:25 <kayabanerve[m]> *that is not distinct to ristretto