17:00:28 meeting time now 17:00:32 yep, hi 17:00:36 Was the burning bug mentioned in the audit report or did it slip past them? 17:00:47 hello 17:00:48 hey 17:00:49 jeffro256[m]: (read audit report) 17:00:56 hello 17:00:58 howdy 17:01:15 hi 17:01:40 i don't really have a meeting template, should we start with multisig? 17:01:54 heyo 17:01:56 Hi 17:02:00 Hello 17:02:06 Hi 17:02:09 Hello 17:02:16 seems reasonable to start with multisig :) 17:02:36 selsta: before starting, can you recap the items we should cover? Besides multisig 17:02:56 multisig, and we should set a final fork date, as 2 weeks from now is too early 17:03:13 we now have a definite date from trezor so that should be possible 17:04:15 let's start with multisig, what would your recommendation be UkoeHB? 17:04:26 multisig: I am fine with squashing 8149 whenever. vtnerd__ said he is working on a follow-up review, but his last message was a couple weeks ago so idk what to think about that (in the past he has always followed through despite sparse irc activity). 17:04:41 selsta: It was 17:05:09 *sorry, meant to reply to the question about the burning bug 17:05:13 as soon as 8149 is merged I want to expedite this branch (the 'burning bug'): https://github.com/UkoeHB/monero/tree/multisig_signfixes_deterministic_secrets 17:05:25 it's a 150 diff commit on top of 8149 17:06:39 last update from vtnerd__ 3 weeks ago* 17:06:58 Hi 17:07:32 hey there 17:07:34 UkoeHB: what would "expedite" entail? What level of review is needed? It's "just" code and doesn't touch crypto right? 17:08:02 "code doesn't touch crypto" interesting statement 17:08:07 binaryFate: it changes how tx private keys are computed, so there is some crypto involved 17:08:28 expedite as in, let's not take 6 months to merge it... 17:09:00 seems fine 17:09:06 > binaryFate: it changes how tx private keys are computed, so there is some crypto involved 17:09:06 Does it utilize something similar to "guaranteed addresses" like kayabaNerve proposed? 17:09:53 yes, you generate the keys from a hash chain starting with entropy provided by the tx initiator + the input key images 17:10:54 the burning bug PR used to be part of 8149, and is pretty self-contained 17:10:54 it's essentially this commit: https://github.com/UkoeHB/monero/commit/ee28a2207f9b6929b270d2741354b3ad6e695f4c 17:11:10 for miner txs, it would just be the previous block hash right? (or whatever block hash) 17:11:11 Kayaba spoke about it in his talk at Monerokon 17:11:32 it changes the serialization of the pending_tx struct or whatever it's called, so it's a breaking change (but could be released in a post-fork update if necessary I suppose) 17:11:43 "multisig: I am fine with..." <- not fine with 8149, not fine with multisig_signfixes_deterministic_secrets 17:11:52 jeffro256[m]: multisig does not make coinbase txs 17:13:05 kayabanerve[m]:'s proposal requires a change to view scanning, this just changes the tx author's ephemeral key 17:13:36 ooo123ooo1234567: can you cleanly elaborate what it is about both you are not fine with 17:13:53 what's the final goal regarding multisig features ? 17:14:09 unsafe implementation with experimental flag ? 17:14:25 if yes, then it doesn't matter whether 8149 will be merged or not 17:14:35 if the goal is to have working multisig then there is a need for additional changes 17:16:12 can you give an example of what you thought was incorrect in the audit? 17:16:59 I feel we'd be more productive by taking this one at a time. So before moving onto the burning bug discussion or other discussions, can we agree that 8149 is ready to be merged? 17:17:06 why does it matter if it doesn't cover multisig completely ? 17:17:13 It's the same uniqueness principle, yet it moves generated from the shared secret to r specifically 17:17:39 8149 has been thoroughly reviewed, audited, and Koe already implemented everyone's remarks 17:17:40 Sorry, few minutes behind 17:18:30 once 8149 is merged, we can use this as a new basis of discussion for further improvments 17:18:41 arnuschky: thorough review of C++ isn't for cryptography, audit is poor, minor remars are not important 17:18:48 ooo123ooo1234567: No one is saying we don't want formal review. We're saying the existing is definitively broken, and no one has come forth saying this is broken. Therefore, regarding the code alone, it's a definitive benefit. 17:19:07 Regardless, yes, obviously, it would be a major issue if this was also broken. 17:19:25 arnuschky: no, it isn't a basis; cryptography shouldn't be implemented with partial changes without having overall design; it's a way to add more vulnerabilities 17:19:32 That's why we've gotten it reviewed by multiple people who contribute regarding cryptography, and multiple people regarding C++ 17:20:05 May I recommend instead of shutting down progress, forcing people to use known insecure code, you instead work to be the progress you want? 17:20:26 ooo123ooo1234567 Are you saying that the scope of the audit should have been expanded? 17:20:50 I believe they want formal security proofs comparable to bulletproofs/clsags 17:21:01 kayabanerve[m]: I'm saying that 8149 isn't enough for safe multisig; if the goal is to have unsafe + experimental then it doesn't matter whether 8149 is merged or not 17:21:20 It's a formal theoretical spec and tens of pages of documentation, combined with more months of review 17:21:21 Even if repeated, that's a strange opinion to have IMHO 17:21:44 You're welcome to that opinion. We can keep the experimental label accordingly, to make it clear this isn't safe. But it DOES matter if it's merged 17:21:46 "bad or worse does not matter, if nothing perfect is available". Really 17:21:55 If ooo123ooo1234567 can't convince anyone that 8149 should be stalled further by the end of the meeting, I would like to squash and merge 8149 this week. 17:22:02 kayabanerve[m]: it's needed to catch all details in one place 17:22:27 I won't completely disagree, yet I will disagree it's required 17:22:27 kayabanerve[m]: it's a necessity whether it's moths or not 17:22:32 UkoeHB: ACK 17:22:32 ooo123ooo1234567: are you aware of additional vulnerabilities in multisig that require more code changes to patch? Or is your position that it isn't "enough" to reach the bar of "safe"? 17:22:34 s/moths/months/ 17:23:08 I'd close my "unsafe" PR in that case, giving precedence to the experimental one 17:23:11 > If ooo123ooo1234567 can't convince anyone that 8149 should be stalled further by the end of the meeting, I would like to squash and merge 8149 this week. 17:23:11 It would be a different matter if ooo123ooo1234567 had a specific gripe, but it seems that ooo123ooo1234567 wants 8149 to be the be all, end all PR for multisig and *only* then merge it 17:23:24 Assuming the burning bug addition is successfully merged 17:23:45 UkoeHB: in this meeting nobody cares about cryptography security analysis, so technical defeat ? 17:24:11 Who or what is defeated? 17:24:32 I think if things are agreed as they are in that meeting, and as it generally goes with community decision, we'll all take collective responsibility for the good and the bad 17:24:34 I think merging iterative improvements to software doesn't conflict with analysis of the system as a whole 17:24:49 sorry wrong window 17:25:05 Still true? 17:25:09 jberman[m]: yes, but it was already said 17:25:18 > <@jeffro256:monero.social> > If ooo123ooo1234567 can't convince anyone that 8149 should be stalled further by the end of the meeting, I would like to squash and merge 8149 this week. 17:25:19 > 17:25:19 > It would be a different matter if ooo123ooo1234567 had a specific gripe, but it seems that ooo123ooo1234567 wants 8149 to be the be all, end all PR for multisig and *only* then merge it 17:25:19 While leaving the community in a known critically vulnerable state in the meantime 17:25:44 Friendly reminder they submitted their own PR, which they've yelled wasn't merged, without these specs 17:25:57 binaryFate: collective responsibility means no one will be responsible 17:26:12 I truly believe they're just a pissed off obstructionist, not that I believe there's anyone else left to convince 17:26:37 kayabanerve[m]: not leaving, I was busy with security proof since it's the most important port 17:26:38 s/port/part/ 17:27:01 ooo123ooo1234567: So they've claimed this, there's been no evidence, no one else has found them, and it's obvious they don't actually want to help. I won't say there isn't. I will say we can't trust them 17:27:19 And while formal spec would certainly help... It doesn't guarantee 17:27:55 can someone explicitly say what is supposed to be placed into hardfork release ? unsafe multisig + experimental / safe multisig without experimental ? 17:27:57 ooo123ooo1234567: Great. I don't believe you've ever shared that that's why you ghosted the PR. Would you like to contribute now? We'd appreciate it 17:28:23 I think the only way forward is to do this how any collective open software project is driven forward. Agree on set of changes, merge them, invite people to suggest further improvements. 17:28:42 merge 8149 -> merge burning bug -> keep experimental -> try to get more formal security proofs before removing experimental flag 17:28:56 So I think we got all reviews and changes we gonna get for 8149. Let's merge it, as monero will be in a better state afterwards. 17:29:05 > merge 8149 -> merge burning bug -> keep experimental -> try to get more formal security proofs before removing experimental flag 17:29:06 +1 17:29:11 selsta: ok, I want add additional changes to my own PRs -> merge it -> remove experimental 17:29:21 ooo is then invited to propose a new PR on top of it if he wants to prove that there's more to fix 17:29:36 arnuschky: why on top ? 17:29:40 ooo123ooo1234567: so no formal security proof then? 17:29:51 If ooo actually wants security, and actually knows of issues, they're welcome to contribute them 17:30:09 ooo123ooo1234567: Code style/myriad of other edits towards form and function? 17:30:17 tobtoht[m]: including security proof 17:30:40 And about the time frame, in a first rough estimate? 17:30:49 kayabanerve[m]: there are controversial style/myriad changes, not important 17:30:50 8149 can be rebased on top my prs with all that style changes 17:30:54 Controversial to you. Not to the project 17:31:11 @ooo123ooo1234567: because that's how you develop incrementally using git, in a group of people 17:31:12 kayabanerve[m]: No, controversial objectively, do you want to discuss ? 17:31:48 arnuschky: yes, that's why 8149 can be rebased on top my PR one more time and submit all miner changes 17:32:01 s/miner/minor/ 17:32:19 I think we have community consensus 8149 is the proper PR for the fundamental set of changes both PRs contain. Therefore, it's the one not controversial to the community. If yours was fine, it would've been merged without requested edits 17:32:35 And how is this better than merging, and then continue to develop from that point onward? 17:32:52 ooo123ooo1234567: wouldn't it be faster to explain publicly what the remaining issues to be fixed are, in plain english? 17:33:03 kayabanerve[m]: community consensus ? 17:33:05 Fuck it. If it gets ooo to shut up, if they want to edit their PR to have the same HEAD as 8149, fine. Let's merge theirs 17:33:08 Then you can either do it on your own or get help 17:33:22 ooo123ooo1234567: I would argue for keeping 8149 unmerged, we proceed with multisig disabled until we reach the bar of safe, if you prove you're aware of additional vulnerabilities 17:33:23 But no one will step up to maintain your PR. 17:33:24 binaryFate: it's vulnerabilities, can't publicly 17:33:35 Lol 17:33:53 you can always talk to me or hacker one team privately 17:33:56 if it's your worry 17:34:05 vulnerabilities in unmerged code 17:34:17 binaryFate: no, there are no competent people behind hackerone, not ok 17:34:41 whoever you would give your updated PR to review, then why not tell these people now what the issues are? 17:34:41 It seems it's always only black and white ... 17:35:33 let's move onto discussing how to move forward with a release. I see two open PRs for multisig: 17:35:33 - 8149 (consensus to be merged) 17:35:33 - burning bug (small PR, but needs review) 17:35:37 what else should go into that release? 17:35:38 Are we doing to have a closed source ooo monero daemon? 17:35:50 Like that seems to be the only path they'll accept at this point 17:35:58 kayabanerve[m]: PRs are public, why closed source ? 17:36:07 Once the new release is out, ooo (or anyone else) is invited to report vulnerabilities using the usual channels. 17:36:31 I don't find it productive to turn in circles on hypotheticals. 17:36:32 Because that'd disclose the vulnerabilities because we're all incompetent and can't be trusted, apparently 17:36:40 ooo123ooo1234567: why not DM vulns to koe? 17:36:46 arnuschky[m]: Exactly 17:37:22 arnuschky[m]: no circles yet 17:37:35 jberman[m]: sure, he'll need a new account though 17:37:44 The ironic thing is responding to that would be yet another iteration of the circle 17:37:57 ๐Ÿ˜ 17:38:00 :) 17:38:16 8149. Burning bug. "Experimental". It seems like everyone except ooo agrees on that. 17:38:33 yes 17:38:39 mark it as experimental 17:38:45 From maintainers, to the acknowledged cryptographer of the project, to people who are willing to bet their business on multisig 17:38:46 Does anyone else have objections ? 17:38:58 I don't see it being super actionable to not merge something because it's experimental and could have flaws, without person who says it's flawed being able to articulate them 17:39:25 Not to mention that everything always can have more flaws 17:39:45 by all means be cautious, but I think in this case the community's caution is just being taken advantage of to stall. or at least that's the side effect 17:40:12 word 17:40:15 "Fuck it. If it gets ooo to..." <- it isn't just edit, there are important changes 17:40:38 jeffro256[m]: no one understands what is it about, not clear what's the purpose of such voting 17:40:40 if the current code has reviews from competent people and we don't know of any vulnerabilities, then ok to merge as experimental. my 2c 17:41:03 sgp_: agree 17:41:04 Purpose of voting? Reaching a decision, maybe 17:41:16 sgp_: those competent people removed their names and failed 1st time 17:41:36 it's like strong sign that we don't want to participate in it from side of auditors 17:42:13 If ooo123ooo1234567 discloses a single vuln to koe that was previously unknown, I would argue for keeping multisig disabled and we give them time to continue work on their patch 17:42:27 can't we just put out as experimental and commission audits as necessary later? I don't see what's the big deal 17:42:38 ooo123ooo1234567: I believe the competency referred to koe and others, not just the auditors who are grey 17:42:41 sgp_: we would ideally need formal security proof, not audit 17:43:03 okay, so just say formal security proof doesn't exist then 17:43:05 Keyword is probably "ideally" 17:43:20 work on this can continue outside of the hardfork and release 17:43:23 UkoeHB: what was your opinion on how in depth the audit was compared to your knowledge? 17:43:28 jberman[m]: If it lead to any loss of funds/denial of service of fund access that isn't just the rpc routes being manual, sure 17:44:04 playing devil's advocate but where do we draw the line between "experimental" or not? There is surely more to Monero crypto and code that isn't as security proved as ooo123ooo1234567 would wish for to deserve being non-experimental 17:44:08 do the multisig changes in question even require a hard fork? 17:44:29 r4v3r23: no 17:44:34 rbrunner: Fuck it, I'll add a 10 XMR bounty on 8149. If any loss of funds are submitted, outside of the rpc routes being manual, and UkoeHB: confirms... Stands until the hf 17:44:43 binaryFate: MuSig2 paper - not experimental, no paper - experimental 17:45:02 Sorry, did not mean to reply to rbrunner. My client is acting up 17:45:07 jeffro256[m]: then why is a feature that can be hased out later holding up an entire network upgrade? 17:45:25 r4v3r23[m]: it's not holding up the network upgrade 17:45:32 ooo123ooo1234567: Tell koe one new loss of keys/funds. Prove you're superior and help monero. I'll pay you 10 xmr 17:45:37 binaryFate: previous researchers were writing security proofs since it's necessary in cryptography and done everywhere 17:45:38 Or yes, we go back to ignoring you 17:45:41 selsta: I'd say it wasn't as thorough as my own review, but at the same time the auditor(s) brought a different set of expertise/experience to the table, which always improves the venn-diagram of concept coverage (e.g. hightlighting the bias issue in hash_to_scalar(), which prompted me to update my seraphis lib). 17:45:50 kayabanerve[m]: 1000xmr ? 17:46:08 hey that's enough of this please 17:46:41 meh. mercenaries have no place here. 17:46:56 help improve things or go away.\ 17:47:00 people need these upgrades for better wallets and privacy. move past this discussion or else monero won't ever improve 17:47:19 ooo123ooo1234567: are you going to disclose a vuln or not? 17:47:26 selsta: some people here are under the impression that it is 17:47:33 hyc: Based. I just want to iterate I don't believe they have anything 17:47:45 We're going in circles again. Let's take it one at a time. Merge 8149, merge the burning bug fix, reevaluate 17:47:46 if not, giving some clarity to the community on the path forward to this network upgrade would be great 17:47:59 ok, let's do like I said before 17:48:01 19:28 <+selsta> merge 8149 -> merge burning bug -> keep experimental -> try to get more formal security proofs before removing experimental flag 17:48:05 48 minutes into the meeting and nothing has been decided yet. What's the date of v15 network upgrade? 17:48:09 jberman[m]: yes I can 17:48:09 I'll happily badger ooo to prove to us that he indeed knows of more vulnerabilities 17:48:15 selsta: seems perfect 17:48:19 ooo123ooo1234567: if you want to change that you have to disclose your patch or your vulnerabilities to _someone_ 17:48:34 otherwise we don't get anywhere 17:48:54 indeed. 17:48:55 selsta: besides ooo, does anyone else oppose this 17:48:58 sech1: apparently we're now actually blocked waiting for trezor? 17:49:02 yes, the only thing worse than hearsay is 'Isay' 17:49:13 Trezor said they'd be ready on the 20 17:49:18 I agree with selsta's plan for 8149 17:49:28 I +1 selsta plan 17:49:33 +1 17:49:34 +1 17:49:37 +1 17:49:39 +1 17:49:42 +1 17:49:47 Can we just be done with disussing 8149 now (in this meeting)? 17:49:51 if everyone agreees 17:49:57 yes, so fork date next 17:49:59 so how about July 23, 1 week delay 17:49:59 +1 for selsta 17:50:02 sgp_: In this meeting only UkoeHB has some knowledge, not sure what's the purpose to ask others 17:50:08 +1, as obvious 17:50:20 hyc: Bit tight to trezor release but I'm not against it 17:50:33 I'd like to delay the hardfork 2 weeks, so that we hardfork around August 1st 17:50:34 Should be longer 17:50:38 +1 17:50:40 ok 17:50:43 so that we gave people at least 1 month to update 17:50:50 Oh longer than one week 17:50:51 give* 17:50:53 yes, +1 on July 30th release 17:51:08 +1 give at least 1 month to update 17:51:17 1month to update for august first means release tomorrow? 17:51:44 luigi1111: what would you suggest? 17:51:45 there's no release branch yet 17:51:49 August 7th? 17:51:56 which PRs need to be merged before release? 17:51:59 when tag? 17:52:09 first thing to consider before fork date 17:52:16 1month after tag is my preference 17:52:22 .merges 17:52:22 -xmr-pr- 7774 8296 8356 8357 8358 8384 17:52:32 Tag being moving target so just best guess 17:52:33 we need a new fork height first before tag 17:52:46 if it's 2 weeks delay, just add 10000 blocks 17:52:54 We also need the Ledger code in the repo 17:53:08 jberman[m]: we gave ledger everything 17:53:10 height 2678888? 17:53:22 i will update them on the new fork height, if they aren't ready until then it's not our fault 17:53:27 last hardfork they also were 1 week late 17:53:47 sounds fine then 17:53:54 ok, makes sense 17:54:02 So we are proposing merging this stuff today and branching like tomorrow? 17:54:13 sech1: can you do August 3rd or so? we need a couple days to merge and tag 17:54:18 and releasde 17:54:38 So the final date for HF? 17:54:49 Tag after 8149, Ms burning bug, and I have a PR I'd insist is critical :p 17:55:02 *and then other people's submissions, ofc 17:55:04 That's just my list 17:55:12 August 3rd is 4 more days, so 2681720 17:55:19 what else needs to go into this release? Is all the rest ready? 17:55:29 arnuschky[m]: there are a couple unreviewed patches 17:55:40 but we will have a second release before the hardfork anyway 17:55:55 to include hardware wallet support 17:55:56 I have a PR unmerged yet reviewed by moneromoooo: and I think selsta: :/ 17:56:19 I badly want the DNS leak fix in (8408) 17:56:23 kayabanerve[m]: wow, crowd based voting on whether to merge cryptography changes or not 17:56:39 july 16 was a Saturday, push 4 weeks would be August 13. 17:57:23 Selsta, Jberman is ok w 7760.. can we rebase and merge without ooo? Or ๐Ÿ˜… 17:57:35 4 weeks would basically be adding 20k blocks, also an option I suppose 17:57:40 Would put the fork date around the 13th of August 17:57:48 sounds good 17:58:27 I'll add reviews to those 2 kayabanerve and tobtoht today 17:58:36 tobtoht[m]: I didn't add things to the merge queue yet, 8408 will be included 17:58:55 ok, great 17:59:11 In case of having a date in the middle of August, we should release binaries in 1-2 weeks 17:59:15 ofrnxmr[m]: not sure if a rebase is even needed, no actual merge conflicts have to be solved 17:59:36 it's just git being confused, you have to tell it to take the patch side, have to look up the exact command 18:00:22 "we should release binaries in 1-2 weeks" sounds realistic, no? 18:00:27 should i leave now or wait for release ? 18:00:41 @selsta that wonโ€™t work because some macros included in 7760 were removed in one of my PRs 18:01:00 Do i get it right that you will release 8149 + experimental flag in hardfork ? 18:01:09 and this decision can't be changed 18:01:14 correct ? 18:01:17 ooo123ooo1234567: it can be changed if you point out any remaining issues 18:01:21 ooo123ooo1234567: Wrong 18:01:48 ooo123ooo1234567: Not unless we're provided with a literal reason why not 18:02:13 so this meeting has run over an hour now. congrats ooo on successfully DOSing development 18:02:19 ^ 18:02:27 there is unresolved conflict with UkoeHB (maybe will resolve later via pm) but he is the most competent in current meeting, how to solve this issue ? 18:02:43 hyc: meething is for discussion, not development 18:02:45 s/meething/meeting/ 18:02:56 work is done silenly when someone is thinking and reading/writing code 18:03:02 s/silenly/silently/ 18:03:08 ooo123ooo1234567: pm him with new account if you want to resolve things with him 18:03:36 hyc: excuse me, but merge of incorrect code is a regress, not progress 18:03:50 It's not incorrect, just not perfect 18:04:01 if it's exploitable then it's incorrect 18:04:05 Show 18:04:05 anyway let's not waste even more time please 18:04:08 is there anything else 18:04:19 no, we will add 20k blocks to the fork height 18:04:33 great 18:05:01 for the blog post announcing the delay, 1) who will write it, and 2) what is the stated reason for the delay 18:05:13 delay for trezor 18:05:36 sgp_: https://github.com/monero-project/monero/pull/8299#issuecomment-1171167355 18:05:37 lol perfect 18:06:23 If we are moving on to less pertinent issues, has anyone looked at https://github.com/monero-project/monero/pull/8385? 18:06:40 It just gives better control over whether persistent SSL keys are used 18:06:46 jeffro256[m]: we need 7760 first 18:06:48 sgp_ why do you think a blog post is necessary? We didn't have one to announce temptative date 18:06:51 ideally 18:07:26 Ideally , yes but 7760 is unrelated to the SSL files 18:07:33 binaryFate: we announced here: https://www.getmonero.org/2022/04/20/network-upgrade-july-2022.html 18:07:37 selstaso tag+release in next few days? 18:07:38 "Not unless we're provided with a..." <- I don't like that crowd of incompetent people say me what to do 18:07:51 sgp_: I'd say the delay is caused by having to wait for the Trezor firmware update + mulsitig audit results 18:08:17 binaryFate I'm not sure where and how it was announced, but many picked up: https://www.nicehash.com/countdown/xmr-forking-2022-07-16-12-00 18:08:35 sgp_ ah right, forgot about that. We should add adendum to this post then (regardless of new post or not), in case people just land on it via direct link 18:08:36 sgp_: We announced it via a post 18:08:37 And on Twitter 18:08:38 And on Reddit 18:08:53 I will edit the post, what's the new height? 18:08:55 "Not unless we're provided with a..." <- and expected scenario is the following: I point out issues, you all are grabing them and merging instantly skipping long discussion and kick me after, correct ? 18:09:00 I can get a PR submitted in a few minutes 18:09:12 ooo123ooo1234567: Kick you????? What? 18:09:19 ooo123ooo1234567: please leave this alone, your comments are entirely unproductive 18:09:22 sethforprivacy " we will add 20k blocks to the fork height" 18:09:55 sech1: Thanks, sorry, missed most of the meeting due to work 18:10:08 20k blocks is approx. 4 weeks 18:10:12 * kick me out after, correct 18:10:30 any other topics? 18:11:10 looks like we're done 18:11:11 sgp_: Wallet2 dns issue? 18:11:12 Are we prioritizing this? The PR is done 18:11:30 jeffro256[m]: hahahah, you're suggesting to remove something from PR; facepalm 18:11:48 doh... I'm done, gotta go. ttyl 18:11:53 > <@ofrnxmr:monero.social> Wallet2 dns issue? 18:11:54 > Are we prioritizing this? The PR is done 18:11:54 Iโ€™m all for removing that DNS code, good find tobtoht 18:12:13 "tobtoht: I didn't add things..." <- this is the DNS leak, will be included 18:12:16 ooo123ooo1234567: No Iโ€™m not 18:12:23 I only wanted to discuss multisig and fork date 18:12:24 * DNS leak, patch will be 18:12:26 jeffro256[m]: what's the value in stupid parroting of already said statements ? facepalm 18:12:56 ooo123ooo1234567: I asked. Missed it earlier. 18:12:57 Ooo, chill. 18:13:06 seems like there's nothing else 18:13:59 New tag date? 18:14:00 selsta and SGP, thanks for hosting 18:14:07 Fork is approx August 13th 18:14:16 tag/binary release/etc. 18:14:21 I encourage a certain someone to wise up and learn to have a productive conversation with a group, and encourage everyone else to be more aggressive at changing discussions to get back on topic when someone is clearly trying to derail. Thank you. 18:14:41 sethforprivacy: release 1 month before, so tag before that 18:15:20 Would like an estimate date for the blog post but can leave it out if we don't want to commit to one 18:15:28 selsta: thanks for the meeting. I will squash 8149 in 2hr unless I get a solid pm justifying more delays. 18:15:38 Err, nvm, can just roll with release date estimate of July 13th 18:15:52 we also have to delay the stagenet fork date 18:17:12 thanks selsta and everyone for the meeting [post-meeting discussions: https://libera.monerologs.net/monero-dev/20220630#c114478]