15:47:06 <UkoeHB> meeting 1.25hr https://github.com/monero-project/meta/issues/643
16:24:39 <jetsteel[m]> Likely wont be here for meeting but wanted to weigh in on address schemes.
16:25:40 <jetsteel[m]> IMO view tags are a must to allow light wallets that dont impact anonymity.
16:27:11 <jetsteel[m]> And view keys should show spends and receives to calc full balances without back and forth with offline wallet. Makes the most ux sense to me.
16:31:03 <tevador> ^both of these features are already in the proposal
16:40:40 <theblackdog001[m> I will I have some questions 
16:53:44 <jetsteel[m]> <tevador> "^both of these features are..." <- So, IMO plain D or Janus E aligns users desires for ease with anonymity
16:55:45 <tevador> the current proposal "Jamtis" is a kind of hybrid between "Janus B" and "Janus E"
16:57:07 <jetsteel[m]> Link?
16:58:03 <tevador> I'm in the process of rewriting the proposal, but here is an older version: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024
17:00:33 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/643
17:00:34 <UkoeHB> 1. greetings
17:00:34 <UkoeHB> hello
17:00:48 <tevador> hi
17:00:55 <rbrunner> hi
17:00:55 <Rucknium[m]> Hi
17:01:03 <UkoeHB> tevador: are you planning to change the proposal?
17:02:54 <tevador> I'm rewriting it mostly for better readability, but there are also some minor changes
17:03:15 <tevador> e.g. the one-time change addresses we discussed earlier
17:03:37 <UkoeHB> sounds good
17:04:08 <tevador> also added an "xmr" prefix to base58 addresses as per fluffypony's suggestion
17:04:29 <tevador> I've also coded a library that will be used for human-readable representation of wallets and addresses: https://github.com/tevador/id32 
17:06:18 <UkoeHB> ah interesting
17:07:19 <UkoeHB> 2. discussion, does anyone have anything they want to discuss (e.g. from the agenda, or otherwise)? This was Christmas week so it might be a short meeting.
17:08:04 <UkoeHB> I have been thinking a little about wallet/account architecture, and made a little progress but still not completely nailed down.
17:08:34 <Rucknium[m]> Last meeting we discussed reaching out to merchants and crypto services about the preferences regarding the address schemes. We haven't done anything on that yet, AFAIK.
17:09:04 <jberman[m]> I tried gauging the benefit of binning in protecting a user who spends multiple inputs that are close in age in a tx (e.g. collect change outputs over the course of a day, then spend them >2 months later in the same tx), and found that users seem decently well protected in this scenario already, and that binning wouldn't necessarily be of huge help (https://github.com/monero-project/research-lab/issues/86#issuecomment-1001091949)
17:09:12 <Rucknium[m]> This would be a good way to have non-devs and non-researchers contribute -- send them forward to query merchants.
17:09:47 <jberman[m]> Unless people have objections and want to see the wallet-side binning proposal I shared implemented (https://github.com/monero-project/research-lab/issues/88), I also am leaning toward setting it aside and moving on. It seems like it would be challenging to get everyone on board with it, and the benefits of binning at this stage I don't think are critical
17:11:03 <tevador> I think this discussion is being watched by some merchants: https://github.com/monero-project/monero/issues/7889
17:11:15 <Rucknium[m]> I think that binning makes more sense once we have a greater number of decoys to work with, which will (hopefully) happen later on with Seraphis. We also need more statistical analysis of the benefits and costs of binning before putting it into production, I think.
17:12:12 <rbrunner> " and that binning wouldn't necessarily be of huge help " Was that a surprise to you?
17:12:18 <Rucknium[m]> What I am saying is that I would agree with returning binning to the back burner, to pick up later.
17:12:26 <rbrunner> Or kind of a disappointment?
17:14:17 <jberman[m]> Haha not a disappointment, I think that finding was definitely a good thing. But I did think binning would be of more help in that particular scenario, considering the gamma isn't specifically designed to protect from it
17:14:57 <rbrunner> Interesting
17:15:36 <Rucknium[m]> This is only relevant to a specific threat model, correct, jberman?
17:15:46 <Rucknium[m]> Your most recent findings, that is.
17:15:48 <jberman[m]> Yes
17:17:50 <UkoeHB> theblackdog001[m: did you have a question?
17:18:37 <Rucknium[m]> Are we on target for March 15 hard fork? What more needs to be done?
17:19:42 <Rucknium[m]> I guess that's a -dev question, but can MRL help at all?
17:20:34 <rbrunner> Maybe multisig is the critical path?
17:20:38 <UkoeHB> I think the multisig PRs are close to merge-able, which is good news.
17:21:14 <UkoeHB> I will try to get the last review comments from vtnerd wrapped up by this weekend.
17:21:18 <rbrunner> Hmm, https://github.com/monero-project/monero/pull/8114 has quite some unaddressed review issues, last time I checked
17:21:38 <rbrunner> I wanted to do functional tests, but decided to wait
17:22:19 <rbrunner> However don't understand half of the mentioned points :)
17:23:08 <UkoeHB> I think most of that is just discussion that doesn't require new diffs
17:23:44 <Rucknium[m]> I will ask folks at #monero-ux:monero.social if they can do some outreach to merchants, payment processors, etc regarding their preferences on address schemes.
17:23:59 <UkoeHB> thanks Rucknium[m] 
17:24:43 <rbrunner> Sounds like a good idea
17:36:47 <UkoeHB> Seems like we can close out the meeting. Thanks for attending everyone, and merry christmas :)
17:36:57 <isthmus> Cheers
17:37:02 <isthmus> Btw I conducted some personal research into a 50%+1 attack on a proof-of-work privacy coin, and just posted the results at https://mitchellpkt.medium.com 
17:37:23 <isthmus> (yea I know I should self-host instead of using medum, but I’m too absentminded to be a competent sysadmin lol)
17:37:30 <Rucknium[m]> isthmus: Nice! Any word on the cconference?
17:37:35 <isthmus> Postponed until May
17:37:54 <isthmus> (The school is closed, so they can't use the facilities during the originally scheduled window)
17:38:27 <Rucknium[m]> Oh. Did they give a thumbs up or down on our paper?
17:39:08 <isthmus> No response either way. I suspect that they're going to wait a few months to confirm the presenters to avoid churn from people saying yes now but not showing 5 months later
17:39:48 <Rucknium[m]> Makes sense. Maybe we will have new findings by then.
17:47:23 <isthmus> Oh yea I have a ton of ideas for conducting the transaction tree analysis on branches related to the attack
17:47:42 <isthmus> The fast spend time (<15 blocks) will make it pretty easy to deanonymize most of the ring signatures
17:47:56 <isthmus> Especially since right off the bat we can filter out every ring member that doesn't match the known signature
17:50:57 <Rucknium[m]> isthmus: Do you know of any introductory resources to chain analysis, for transparent UTXO chains? I am starting to get into it.
18:13:32 <rbrunner> isthmus: Very interesting article
18:16:20 <selsta> 18:18 <Rucknium[m]> Are we on target for March 15 hard fork? What more needs to be done? <-- I feel like we lost some time with reviews still being focused on multisig vulnerabilities
18:17:25 <selsta> at least vtnerd focused on multisig so he wasn't able to approve the BP+ changed yet
18:18:03 <selsta> also I need some info how much work it will be for hardware wallets to implement BP+
18:18:32 <selsta> I remember sarang or someone else saying it's less work than CLSAG
18:19:25 <selsta> but still it's something we have to consider, time availability for ledger / trezor devs is kinda out of our control
19:17:30 <tevador> UkoeHB: have you already defined the Seraphis base points X and U? I need them to make test vectors for Polyseed + Jamtis.
19:44:26 <sgp_> Final call to be a MAGIC Monero Fund voter or committee member: https://github.com/MAGICGrants/Monero-Fund/
19:45:55 <UkoeHB> tevador: https://github.com/UkoeHB/monero/blob/1dafb6272dd4e7fddcfe776ccfff48715288578d/src/seraphis/sp_crypto_utils.cpp#L101
19:48:38 <UkoeHB> I wouldn't say this is 100% set in stone, since none of the code has been reviewed
19:55:21 <tevador> Updated Jamtis: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024
19:56:25 <tevador> UkoeHB: thanks, could please copy paste the points X/U in hex? I will use them in my python script
20:56:50 <UkoeHB> Ok, maybe tonight I can
22:46:57 <escapethe3ra[m]> <isthmus> "(yea I know I should self-host..." <- you don't need advanced sysadmin skills and you can even start by hosting on Github for free if you're not ready for a vps
22:47:09 <escapethe3ra[m]> let me know if you need a hand