00:48:48 the idea is that you would use the primary and carry the secondary along. once the secondary is accepted, you drop the primary 00:49:14 thus, you have the ability to decrease sync times and blockchain size after the fact 00:49:31 so you don't expose the chain to flaws in B+ 03:49:11 or if B+ is flawed, then you drop that half and keep the primary 14:56:48 Looks like Ledger support should be available for the network upgrade due to an updated development/testing timeline from their team! 14:56:50 Great news 15:00:25 Thanks for kicking some sleeping butts :) 15:00:40 Seriously, thanks so much for driving that sarang 15:02:23 Thanks should go to cslashm for reaching out to their team lead 15:02:41 which helped to encourage internal discussion about the development/testing timeline 15:03:46 sarang: what date? can we push it earlier? :p 15:04:26 Their goal is to finish up testing of their Monero app by the August 17 code freeze, but they requested up to 2 weeks of flexibility if any fixes are needed for the Monero codebase 15:04:43 that's perfect 15:04:45 Even if this is needed, that's still 2 weeks until the release date on September 17 15:04:46 super awesome 15:04:50 and then the upgrade happens October 17 15:05:13 can we push the upgrade to Oct 1? Is that realistic? 15:05:24 Flexibility for fixes after the freeze seems entirely reasonable; there could easily be fixes for other issues that arise during testing for non-Ledger functionality 15:06:02 sgp_: probably; it sounded like the freeze deadline was the most important factor for the Ledger timeline, but I'd need to verify this 15:06:14 amazing 15:06:33 I'm on their developer Slack workspace now, so there should be more real-time communication available 15:06:46 also amazing 15:07:01 imagine if we had this level of access with exchanges 15:14:21 How do other projects handle communication of updates to exchanges? 15:14:36 Do the bigger exchanges have some kind of communication channel for these things? 15:23:09 well, btc doesn't really have consensus critical updates that often. 15:23:39 and I'd hazard a guess that with ethereum, you know about updates because the goram cryptosphere can't stfu about whatever ethereums doing 15:26:20 but it would be great to establish liaisons with at least kraken, bitfinex, binance, bittrex, polo 15:26:25 Yeah 15:26:34 -community might know whats up 15:27:03 Surely it would be easier for them to receive direct notification of updates that affect their service, rather than have to follow blog posts and developer channels 15:27:16 There is a mailing list for this. 15:27:20 well, there's the mai ^^ 15:27:30 Is it known/suspected if they follow it? 15:27:59 I suppose nowadays people might expect twatter instead. 15:28:22 sgp_: do you think only 2 weeks between release and upgrade is sufficient for bigger ecosystem players? 15:28:23 afaik, its been reserved for hyper critical info, such that recipients don't ever consider that an email from monero can be ignored 15:28:42 Network upgrade schedule sounds critical :) 15:28:57 sarang: I would prefer 1 month 15:29:10 well, yeah a pending one. but an email saying "hey, you don't have to do anything now, but in a couple months watch out!" 15:29:10 though people will do it last minute again 15:29:31 maybe a 2 tier email system 15:30:11 like a monthly newsletter that distills down any actual consensus critical changes coming down the pipeline 15:30:25 and then another service thats ermagerd wtf level 15:31:19 "Read now" and "read soon" 15:31:31 If monthly, most mails will be empty :) 15:31:34 monero-announce and monero-omg 15:31:48 "Monero announces no announcements" 15:32:04 "You'll get the surprise" 15:33:07 "Semi quarterly soonish" and "emergency only" 15:33:18 An "everything's ok" alarm: https://www.youtube.com/watch?v=7vIjBtdEQRE (note: loud clip) 15:33:18 [ Everything's OK - YouTube ] - www.youtube.com 15:33:35 ^ sorry, off topic :/ 15:33:46 could function as a canary as well mayhaps 15:35:23 well, i have no control over these things anyway so i'm just singing to the birds i guess 15:39:20 sarang: I'd also prefer one month at least 15:39:33 Two weeks is definitely pushing it and we'll scramble to get everyone properly updated 15:40:01 Yep, I confirmed the original schedule, and said flexibility between the freeze and the release for fixes is fine 15:40:59 Better come up with a name 15:41:13 that's probably a -dev or -community topic though 15:47:03 Got the thumbs-up from the Ledger team lead; they'll still target August 17 15:52:56 sarang: I would like 1 month 15:53:26 But if they can be done with their integration by Sept 1, an Oct 1 hardfork date would be preferable imo 15:53:37 Yes, I told them the original one-month time between release (September 17) and upgrade (October 17) still holds 15:54:00 why is the release Sept 17? Am I missing something? 15:54:10 That was the original schedule from the dev meeting 15:54:22 Freeze August 17, release September 17, upgrade October 17 15:54:23 It might be a bit shit to go back and say since you adapted to our date, let's move it further. 15:54:53 They still need to release their new firmware/apps to their users, so having a known time for this will be helpful 15:55:16 Whatever we set would probably be ok, but they need to know in advance; changing it based on their testing might not work 16:07:53 moneromooo: possibly yes, just throwing out options in an "it's free real estate" sort of way 16:08:16 I wouldn't be upset if we stayed with Oct 17 16:09:38 Even if not required for hardware device release timelines, having a set date in advance gives bigger players like exchanges ample time to upgrade according to their development schedules 16:11:02 yeah I get that 16:11:21 point is this is our last change to move forward if we want to, if we think it's okay to do so 18:01:28 sgp_: Your change would basically change the schedule to freeze August 17, release September 17, upgrade October 1 right? 18:02:01 only Oct 1 if the release could be put out by Sept 1, since a month upgrade timeline is more important imo 18:02:39 Ah 18:02:59 Two weeks for testing + a release seems a bit optimistic, especially if Ledger stated that they would like to test extensively 18:03:05 We also have to factor in external third-party wallets 18:04:51 I think advance notification and consistency are more important than upgrading two weeks earlier 19:02:41 h4sh3d[m]: you here? 19:03:53 Yes 19:04:12 For small changes to your swap paper, would you prefer notes here, or PR to your repo? 19:05:12 Both are fine for me, so do what you prefer 19:05:32 OK! 19:06:31 At the top of page 6 in the definition of the DLEQ process, it might be worth noting that $k_i^s$ isn't technically a scalar in both finite fields 19:06:56 but rather two scalars with an equivalent bit representation, according to the projection map equivalence described in the technical note 19:07:25 The notation still makes sense IMO as long as there's no confusion about what field/group you're operating in 19:07:47 Also: on page 6, I assume "OP_ESLE" is intended to be "OP_ELSE" 19:08:18 I'm also thinking more about the lack of commit-reveal and its consequences 19:08:30 (you mention it on page 7) 19:12:04 Ok, I’ll make sure to get de DLEQ correctly and adjust the terminology 19:12:57 Yeah it's pretty trivial TBH 19:13:22 Yes, OP_ELSE 19:13:31 but could be useful so it's clear to the reader that the use of multiplicative notation in both groups with that "scalar" does in fact make sense if considered under the equivalence 19:16:16 IMO commit-reveal might be needed for k_i^s because one can chose K^s for a known k^s, but in that case he would not know k_i^s and not be able to produce z_i 19:16:53 So commit-reveal is not needed 19:21:36 Yeah, key cancellation would fail in that case 19:22:08 For the view key it would seem not to matter 19:22:28 In fact, couldn't one player simply generate the entire view key? 19:24:01 Yes, might work. But by default I thought distributing might be better 19:25:50 It doesn't change the communication complexity really 19:25:54 in terms of rounds 19:26:32 But one player could fix the secret view key without commit-reveal anyway 19:28:08 I’m not sure what impacts reusing the same view key for all swaps are? 19:28:41 In terms of anonymity 19:31:33 Well, splitting the view key still allows a malicious (or just bored) player to do this 19:31:49 I means, with the current protocol a (bad) implementation might fix the private view key 19:31:52 Yes 19:32:19 At least by having one player generate it, there's no misinterpretation about the guarantees you get 19:32:21 which are, none 19:32:54 Agree 19:33:32 I agree that thinking about the consequences of such a malicious player is important 19:33:58 and, if needed, you could add commit-reveal to fix this, so as long as one player is honest the view key can be unique on each execution of the protocol 19:34:14 But that obviously increases communication complexity with another round 19:36:18 Yes, but I think it’s not a big deal 19:36:50 Which? A malicious player, or adding a commit-reveal round? 19:37:05 Adding a commit-reveal 19:37:09 ah ok 19:37:29 If you added that, then any doubts about shenanigans with the spend key would also go away 19:37:36 since you could include that in the commitment too 19:39:50 RE @sarang “If there are any active vulnerabilities, please use HackerOne to report.” LOL pretty much everything is vulnerable (except maybe RandomX). But seeing as the adversaries probably don’t exist right now we’ll skip the HackerOne disclosures and just drop results on the merge req. 19:39:50 Catching up on the backlog about new contributors, I hope it’s OK if I share a little bit of my experience managing crypto R & D teams. 19:39:50 I’ve got a sarang on my team - one of those unicorns who can build anything, production quality, in 80% of the time that it takes anybody else. And that makes it easy to fall into a trap… 19:39:51 For a few months I kept thinking, “why should I hire somebody new to do this in 15 weeks when [sarang of Insight] could do it in 12 weeks?” 19:39:52 I thought I was being efficient and keeping costs down, but I was actually just overloading my best contributor, who turned out to be working 70-80 hour weeks and precariously close to burning out. 19:39:53 So I hired an apprentice, and the two of them have absolutely prolific output with a sustainable workload. And the fact that the two of them can riff off each other is an entire extra layer of win. 19:39:54 Anyways, I almost learned the hard way that just because one person can do anything doesn’t mean they should do everything :- P 19:39:55 It’s also risky in general to not have a few contributors and mentorship structures in place. You never know when somebody will get sick, or in a bike accident, get an offer for their dream job, or need to take care of family. 19:39:56 I had a project once with all of the eggs in one basket, and that person almost had to leave due to external circumstances. They’d never trained a successor, and even though I could hire a replacement, there would be nobody to onboard them. It would have set us back months… /*gulp*/ 19:39:57 Anyways, I’m excited that there’s interest from new researchers about contributing to Monero. Not saying that we should accept any project in particular, just noting that it can be valuable to have a culture that encourages a healthy and robust set of contributors. 19:39:58 Okay, enough rambles about team building. I’ll now return to my usual content of unexpected histograms and scatter plots with weird structures. 19:41:08 Yes, the question is now: is a fixed view key a problem in terms of privacy or not 19:41:16 Isthmus: for HackerOne I meant anything that should be considered problematic with our current understanding of computing :) 19:41:40 :- P 19:42:14 Very good point about encouraging new contributors and researchers 19:43:03 The nature of an audit is also an important consideration in this case, since there seem to be very few people who are likely to have the expertise for an audit (the proposers certainly have the expertise) 19:43:56 Isthmus: of course feel free to post results elsewhere besides the merge request; this is probably useful for redundancy and portability 19:44:21 AFAIK there isn't a good way to export MR comments 19:47:10 Oh the MR comment is just for keeping track of the project progress and getting the milestone marked off. The actual writeups will be more visible and widely distributed. 19:48:37 Got it! Yeah, linking from the MR will be useful for status updates, for sure 19:54:06 Thanks sarang for the feedback, I’ll do a first batch of improvements based on what we discussed so far tomorrow