the idea is that you would use the primary and carry the secondary along. once the secondary is accepted, you drop the primary

thus, you have the ability to decrease sync times and blockchain size after the fact

so you don't expose the chain to flaws in B+

or if B+ is flawed, then you drop that half and keep the primary

Looks like Ledger support should be available for the network upgrade due to an updated development/testing timeline from their team!

Great news

Thanks for kicking some sleeping butts :)

Seriously, thanks so much for driving that sarang

Thanks should go to cslashm for reaching out to their team lead

which helped to encourage internal discussion about the development/testing timeline

sarang: what date? can we push it earlier? :p

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

that's perfect

Even if this is needed, that's still 2 weeks until the release date on September 17

super awesome

and then the upgrade happens October 17

can we push the upgrade to Oct 1? Is that realistic?

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

sgp_: probably; it sounded like the freeze deadline was the most important factor for the Ledger timeline, but I'd need to verify this

amazing

I'm on their developer Slack workspace now, so there should be more real-time communication available

also amazing

imagine if we had this level of access with exchanges

How do other projects handle communication of updates to exchanges?

Do the bigger exchanges have some kind of communication channel for these things?

well, btc doesn't really have consensus critical updates that often.

and I'd hazard a guess that with ethereum, you know about updates because the goram cryptosphere can't stfu about whatever ethereums doing

but it would be great to establish liaisons with at least kraken, bitfinex, binance, bittrex, polo

Yeah

-community might know whats up

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

There is a mailing list for this.

well, there's the mai ^^

Is it known/suspected if they follow it?

I suppose nowadays people might expect twatter instead.

sgp_: do you think only 2 weeks between release and upgrade is sufficient for bigger ecosystem players?

afaik, its been reserved for hyper critical info, such that recipients don't ever consider that an email from monero can be ignored

Network upgrade schedule sounds critical :)

sarang: I would prefer 1 month

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!"

though people will do it last minute again

maybe a 2 tier email system

like a monthly newsletter that distills down any actual consensus critical changes coming down the pipeline

and then another service thats ermagerd wtf level

"Read now" and "read soon"

If monthly, most mails will be empty :)

monero-announce and monero-omg

"Monero announces no announcements"

"You'll get the surprise"

"Semi quarterly soonish" and "emergency only"

An "everything's ok" alarm: youtube.com/watch?v=7vIjBtdEQRE (note: loud clip)

^ sorry, off topic :/

could function as a canary as well mayhaps

well, i have no control over these things anyway so i'm just singing to the birds i guess

sarang: I'd also prefer one month at least

Two weeks is definitely pushing it and we'll scramble to get everyone properly updated

Yep, I confirmed the original schedule, and said flexibility between the freeze and the release for fixes is fine

Better come up with a name

that's probably a -dev or -community topic though

Got the thumbs-up from the Ledger team lead; they'll still target August 17

sarang: I would like 1 month

But if they can be done with their integration by Sept 1, an Oct 1 hardfork date would be preferable imo

Yes, I told them the original one-month time between release (September 17) and upgrade (October 17) still holds

why is the release Sept 17? Am I missing something?

That was the original schedule from the dev meeting

Freeze August 17, release September 17, upgrade October 17

It might be a bit shit to go back and say since you adapted to our date, let's move it further.

They still need to release their new firmware/apps to their users, so having a known time for this will be helpful

Whatever we set would probably be ok, but they need to know in advance; changing it based on their testing might not work

moneromooo: possibly yes, just throwing out options in an "it's free real estate" sort of way

I wouldn't be upset if we stayed with Oct 17

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

yeah I get that

point is this is our last change to move forward if we want to, if we think it's okay to do so

sgp_: Your change would basically change the schedule to freeze August 17, release September 17, upgrade October 1 right?

only Oct 1 if the release could be put out by Sept 1, since a month upgrade timeline is more important imo

Ah

Two weeks for testing + a release seems a bit optimistic, especially if Ledger stated that they would like to test extensively

We also have to factor in external third-party wallets

I think advance notification and consistency are more important than upgrading two weeks earlier

h4sh3d[m]: you here?

Yes

For small changes to your swap paper, would you prefer notes here, or PR to your repo?

Both are fine for me, so do what you prefer

OK!

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

but rather two scalars with an equivalent bit representation, according to the projection map equivalence described in the technical note

The notation still makes sense IMO as long as there's no confusion about what field/group you're operating in

Also: on page 6, I assume "OP_ESLE" is intended to be "OP_ELSE"

I'm also thinking more about the lack of commit-reveal and its consequences

(you mention it on page 7)

Ok, I’ll make sure to get de DLEQ correctly and adjust the terminology

Yeah it's pretty trivial TBH

Yes, OP_ELSE

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

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

So commit-reveal is not needed

Yeah, key cancellation would fail in that case

For the view key it would seem not to matter

In fact, couldn't one player simply generate the entire view key?

Yes, might work. But by default I thought distributing might be better

It doesn't change the communication complexity really

in terms of rounds

But one player could fix the secret view key without commit-reveal anyway

I’m not sure what impacts reusing the same view key for all swaps are?

In terms of anonymity

Well, splitting the view key still allows a malicious (or just bored) player to do this

I means, with the current protocol a (bad) implementation might fix the private view key

Yes

At least by having one player generate it, there's no misinterpretation about the guarantees you get

which are, none

Agree

I agree that thinking about the consequences of such a malicious player is important

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

But that obviously increases communication complexity with another round

Yes, but I think it’s not a big deal

Which? A malicious player, or adding a commit-reveal round?

Adding a commit-reveal

ah ok

If you added that, then any doubts about shenanigans with the spend key would also go away

since you could include that in the commitment too

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.

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.

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…

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?”

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.

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.

Anyways, I almost learned the hard way that just because one person can do anything doesn’t mean they should do everything :- P

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.

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*/

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.

Okay, enough rambles about team building. I’ll now return to my usual content of unexpected histograms and scatter plots with weird structures.

Yes, the question is now: is a fixed view key a problem in terms of privacy or not

Isthmus: for HackerOne I meant anything that should be considered problematic with our current understanding of computing :)

:- P

Very good point about encouraging new contributors and researchers

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)

Isthmus: of course feel free to post results elsewhere besides the merge request; this is probably useful for redundancy and portability

AFAIK there isn't a good way to export MR comments

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.

Got it! Yeah, linking from the MR will be useful for status updates, for sure

Thanks sarang for the feedback, I’ll do a first batch of improvements based on what we discussed so far tomorrow