01:58:17 <gingeropolous> but, funnily enough, the viewtag thing rollin out is perhaps a bit like this trimmed blocks thing. well, not like it, but achieves same thing
10:59:24 <garth> Perhaps unnecessary, but does this PR require cryptographic changes? https://github.com/monero-project/monero/pull/8262
10:59:50 <garth> And if so, do we need to fund external audits like TrailofBits to help?
11:59:11 <hyc> why would it require crypto changes?
11:59:21 <hyc> it is still the same hash function
11:59:31 <hyc> same inputs generate same outputs as before
12:02:23 <moneromooo> I think the idea is that if the code is buggy but not obviously so, it could be exploited somehow. Like, I dunno, crashes for inputs over 16 kB, that kind of thing. Seems unlikely enough to me.
12:04:50 <hyc> it just unrolled some internal loops
12:05:39 <hyc> any input larger than 32 bytes would have been fed in by an external loop, which hasn't changed
12:16:15 <hyc> I'm just curious about the origin of the changes. the current code is a vanilla reference implementation. the proposed changes are straightforward, so presumably they're also well known?
12:16:18 <moneromooo> OK, I looked at the source. I assumed it was swapping for an asm lib for that speed gain.
12:16:39 <moneromooo> I'm really surprised the compiler did not do this better.
12:17:15 <moneromooo> Maybe adding -funroll-loops to that file only would give us all that...
12:18:17 <moneromooo> Should be in -Ofast though. Hmm.
12:20:42 <hyc> The Rho and Chi loops are a bit more different. avoids a move thru a tempvar in rho
12:21:23 <hyc> similar in chi. these are probably the main speedups
12:23:24 <hyc> I'm guessing the loop unroll is less of a speedup on older chips with hardware parallelism
12:23:37 <hyc> with less hardware parallelism
12:31:27 <hyc> should get some benchmark numbers on an ARM cortex-A53
14:22:42 <sech1> moneromooo hyc it's the same optimized implementation that's used in p2pool and xmrig
14:23:39 <sech1> monero/tests/hash/tests-fast.txt has 321 test cases for this function withh all different input lengths, all passed
14:29:11 <sech1> loop unrolling allows for direct addressing (using compile-time indices) instead of using relative addressing using keccakf_rotc and keccakf_piln tables, this is the main contribution the 5x speedup
14:32:21 <moneromooo> Ah, yes, table lookups would have been hard to elide. Well done :)
16:07:47 <selsta> I won't be available for the meeting, if there are any questions directly for me I'll be able to answer them a couple hours later
16:14:37 <ErCiccione> Selsta: do you have preferences about dates? We should set them today
16:28:43 <selsta> I don't have any preferences, just keep in mind that Ledger and Trezor both need to be updated for BP+
17:00:35 <ErCiccione> Hey folks, it's meeting time. The agenda is here:  https://github.com/monero-project/meta/issues/684
17:01:03 <ErCiccione> today we are going to see the status of the PRs that are going to go in for the network upgrade and especially the multisig PRs,
17:01:13 <ErCiccione> but first, a round of greetings to see who is here
17:01:15 <ErCiccione> Hello everyone!
17:01:45 <rbrunner> Hi there
17:02:16 <arnuschky> Hello there! RINO representative here. Just observing the proceedings ;)
17:02:28 <ErCiccione> We should set the date of the network upgrade today. I do hope there are more people around 🙂
17:02:48 <ErCiccione> hi arnuschky, thanks for being here
17:02:51 <jberman[m]> Hello
17:03:03 <xmrscott[m]> 'ello
17:03:30 <Rucknium[m]> Hi
17:05:16 <binaryFate> hello
17:05:19 <arnuschky> binaryFate should be floating around too, afaik
17:05:22 <arnuschky> ahah
17:05:41 <ErCiccione> ok, let's go on, hopefully more people will join later
17:05:48 <sech1> hello
17:06:03 <ErCiccione> so, the list of PRs are here: https://github.com/monero-project/meta/issues/680#issuecomment-1079924577
17:06:05 <rbrunner> A ping for UkoeHB ... maybe deep into programming, forgetting time :)
17:06:31 <ErCiccione> Bulletproof+ has been merged, so one it's done
17:07:05 <ErCiccione> View tags are approved, but need to be rebased and a final approval before they get merged: https://github.com/monero-project/monero/pull/8061
17:07:31 <ErCiccione> so i guess there isn't much to say about it. Correct?
17:07:37 <jberman[m]> On it
17:08:44 <kayabanerve[m]> Few minutes late, happy to be here :)
17:09:52 <ErCiccione> alright, then there are articmine's fee changes. We have one approval from https://github.com/monero-project/monero/pull/7819. This has been ready for quite a while and only needs to be merged i guess.
17:10:34 <ErCiccione> Could use another approval or two btw, then we only need to merge it. Any comments on #7819?
17:10:49 <selsta> 7819 is already in the merge list
17:12:14 <ErCiccione> perfect!, then the only real stuff left is multisig. Two PRs:  https://github.com/monero-project/monero/pull/8220 and https://github.com/monero-project/monero/pull/8149, but an intermediate PR is needed IIRC.
17:12:27 <rbrunner> Some more details are here: https://github.com/monero-project/monero/issues/8237
17:12:54 <ErCiccione> great link, thanks rbrunner
17:13:06 <arnuschky> Basically there is a mandatory one: https://github.com/monero-project/monero/pull/8149
17:13:25 <arnuschky> Ukoe rebased it already to BP+ but it's still missing view tags
17:14:01 <arnuschky> There are 4 "good to have ones": #8220, #????, #8203, #7852
17:14:36 <arnuschky> From what Ukoe said, #8149 is the only one with crypto changes, all the rest relates to the KEX protocol changes and cleanup
17:15:16 <arnuschky> (just repeating here what I gathered from Ukoe, since he's absent) He wrote  https://github.com/monero-project/monero/issues/8237
17:15:18 <rbrunner> And optimization, in the case of #8203
17:15:25 <ErCiccione> We still need to find somebody willing to review 8149's crypto
17:15:43 <ErCiccione> that's the main roadblocker that we haven't fixed yet
17:15:50 <kayabanerve[m]> I volunteered to review those and do intend to, probably around the 20th. I've been talking with koe a lot recently around multisig and so on as I recently implemented it in Rust (using FROST as the backend instead of DH).
17:16:23 <ErCiccione> kayabanerve: Sounds good. Would you implement the crypto part?
17:16:34 <ErCiccione> s/implement/review
17:16:55 <ErCiccione> well, "will you". I'm tired today 🙂
17:17:20 <UkoeHB> Hi sorry I’m late
17:17:27 <kayabanerve[m]> It's my plan. I also want to work towards versioning so we can ship upgrades outside of hardforks.
17:18:12 <UkoeHB> 8149 is going to need another review after rebasing, is vtnerd around and able to do it?
17:18:22 <UkoeHB> Just to check the rebase
17:18:34 <kayabanerve[m]> UkoeHB did version it IIRC using magic bytes, yet I'd optimally like that moved into an actual field where the protocol version used is the lowest of all participants (and then at hardfork we can ban old versions). That's for furthering development beyond this next set of changes though.
17:18:55 <ErCiccione> ok, good. So we have reviews planned for the key PRs. After those are done we can focus on the "good to have ones", i would say
17:18:57 <binaryFate> UkoeHB: currently I don't think he is available, I'm not sure when he'll be back
17:19:04 <ErCiccione> UkoeHB: As far as i understood, i don't think so
17:19:49 <ErCiccione> but kayabanerve is going to review, so at least we know someone is reviewing it
17:20:53 <ErCiccione> Does anyone have anything to talk about multisig?
17:21:04 <selsta> binaryFate: I think vtnerd said he is a bit available now, a couple hours per week
17:21:18 <binaryFate> nice
17:21:25 <ErCiccione> that's good news
17:21:57 <binaryFate> what about a review from Sarang? Provided he is willing and available
17:22:12 <ErCiccione> can somebody take care of contacting him and ask vtnerd if he is willing to do some reviews? Haven't seen him around these rooms lately
17:22:16 <UkoeHB> I don’t think that will happen
17:22:35 <ErCiccione> i find it unlikely too
17:23:07 <binaryFate> I will check with him 
17:23:25 <binaryFate> selsta: you contact vtnerd?
17:24:23 <ErCiccione> Anything to add? Otherwise the summary seems to be: everything mostly ready except multisig, which needs to be reviewed (+ review of the crypto)
17:24:33 <ErCiccione> I would say makes sense to set tentative dates?
17:25:03 <rbrunner> Any news already about the hardware wallet stuff?
17:25:40 <rbrunner> As I remember from the last meeting that can be a big unknown regarding dates ...
17:26:14 <selsta> vtnerd wrote in this channel a couple days ago
17:26:58 <ErCiccione> rbrunner: They need to have enough time to upgrade, for sure
17:27:46 <selsta> I still think that we might have to integrate it ourselves
17:28:17 <ErCiccione> IMO the important is to set dates, so that hw providers know there is a deadline
17:29:19 <rbrunner> And we also have a deadline for the other PRs that are still on their way
17:29:29 <rbrunner> The non-consensus / non-critical ones
17:29:49 <rbrunner> A little bit of pressure can work :)
17:30:11 <ErCiccione> yeah, i would say everything is ready to set dates. Anyone?
17:31:19 <rbrunner> Testnet in 1 month, Mainnet in 2?
17:32:54 <ErCiccione> This is how it was planned before we suspended it:
17:32:55 <ErCiccione> Branch/feature complete: Jan 15th, 2022... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/9ee5a03ef329016da905873556f130bcd510f83c)
17:33:47 <ErCiccione> branch in a month from now, Release in two, Testnet in 3 and mainnet in 4?
17:33:55 <moneromooo> Previously, about one month (at least) was needed between release and fork. So a month between testnet and fork is not possible if you want the testnet to be useful.
17:34:37 <moneromooo> (useful being defined as, if something borked is seen on testnet, you can fix it before release)
17:35:41 <rbrunner> So Testnet hardfork before release, do I get this right?
17:36:35 <moneromooo> Yes, unless the idea is to assume nothing will break, and if something does, re-release and mainnet fork gets pushed back.
17:36:57 <moneromooo> Which, in fairness, it's unlikely to happen.
17:37:24 <rbrunner> We have for certain a number of breaking changes for sure, where other software needs to catch up
17:37:35 <rbrunner> Beside bugs we produced ourselves, I mean
17:38:05 <rbrunner> E.g. blockchain explorers, because of viewtags
17:38:07 <moneromooo> I'd fork testnet a few days after the last consensus PR is merged.
17:38:39 <moneromooo> Then once you've checked nothing breaks, you can set a fork date.
17:39:07 <moneromooo> Which you could have set before with a "assuming nothing goes boom" beforehand of course.
17:39:35 <ErCiccione> i see your point, but we do need to set the date of the hard fork as soon as possible. A couple of months before (which i assume would be the timeline) is not enough
17:39:42 <moneromooo> Then again, you need testers for testnet to be useful.
17:39:47 <sech1> testnet should be switched to v0.18 as soon as branch is created and PRs merged to it
17:40:05 <sech1> I actually need testnet to test p2pool with view tags
17:40:55 <ErCiccione> sounds good, i would still set a date for the mainneft hard fork the moment we set one for testnet
17:41:08 <ErCiccione> in case it can be pushed back, but people can start to get ready
17:41:33 <rbrunner> So maybe we can try to branch in 1 month, with Testnet fork, then release (hopefully) in 2 months, and fork mainnet in 3 months?
17:43:14 <moneromooo> I don't really have a horse in this, but you don't have to branch to fork testnet.
17:43:42 <sech1> yes, but all consensus changing PRs need to be merged before testnet
17:43:43 <ErCiccione> so, practically speaking. What about:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/860e1f71107836fea38759ee5403a4216dfc5316)
17:43:48 <moneromooo> The branch has to come at/after the release, since its point is to avoid all the new changes to master, to have its own stable-plus-fixes history.
17:44:42 <rbrunner> Sound reasonable, yes.
17:44:56 <ErCiccione> we also need selsta's opinion on how to proceed. I assumed we were going to use the same process of past hard forks
17:45:31 <selsta> I didn't fully follow now
17:46:33 <rbrunner> Anyway, we will surely get that right with the order of things. I think we need to be comfortable and careful with the dates.
17:46:55 <selsta> moneromooo was involved in the most HFs so it's probably best to fork testnet first
17:47:14 <rbrunner> And man, if we don't manage to fork Mainnet in 3 months ... :)
17:48:05 <ErCiccione> Branch: May 16th
17:48:09 <ErCiccione> testnet fork: right after
17:48:14 <ErCiccione> release: June 16th
17:48:19 <ErCiccione> Mainnet for: July 16th
17:48:20 <ErCiccione> ?
17:48:47 <selsta> why not just fork testnet once we have everything consensus merged to master? we don't need a date for it
17:49:14 <sech1> yes, testnet fork can be done "when it's ready"
17:49:21 <sech1> even before 16th May
17:49:49 <ErCiccione> We could keep may 16th as the latest date? I do think we need to put a bit of pressure and a deadline helps a lot in making sure things don't get delayed
17:49:57 <rbrunner> But well, that may be our guestimate when everything is reviewed, rebased, and merged :)
17:50:15 <jberman[m]> AFAICT the last 3 consensus changing PR's are view tags + ring size bump + fee changes. Fee changes are in the merge queue. I'll rebase view tags + ring size bump today
17:50:27 <ErCiccione> yeah, more like "let's get everything done before may 16th"?
17:50:46 <ErCiccione> we could also say end of the month 🙂
17:51:32 <ErCiccione> if we are confident we can get everything merged within 2 weeks?
17:51:42 <ErCiccione> s
17:51:53 <ErCiccione> seems like it at least
17:52:22 <rbrunner> The multisig PR might take a bit longer, and although not "consensus" should be in IMHO
17:52:27 <sech1> Block 2668888 - 8:13:20 pm CEST | Saturday, July 16, 2022
17:52:29 <sech1> nice number
17:52:38 <sech1> and fork on Saturday like it used to be before
17:53:22 <rbrunner> That's a pretty convincing argument. 8's are lucky, after all.
17:54:57 <ErCiccione> Ok so to wrap up: Branch as soon as possible, but not later than May 16th. testnet fork right after branching, release June 16th and mainnet network upgrade July 16th?
17:55:33 <ErCiccione> a round of opinion on this and if we all agree we can set it
17:55:53 <binaryFate> sounds good
17:57:08 <sech1> yes
17:57:25 <UkoeHB> Btw I’m thinking we should aim for a seraphis hf on the 10yr anniversary, who’s with me?
17:57:46 <sech1> a bit too early to discuss it :D
17:57:49 <rbrunner> lol
17:57:52 <UkoeHB> Lol :p
17:57:53 <ErCiccione> selsta moneromooo? You ok with those dates?
17:57:58 <ErCiccione> lol one fork at the time 😛
17:58:03 <xmrscott[m]> A noble goal to be sure
17:58:46 <UkoeHB> Almost exactly 2yrs from today
17:58:48 <rbrunner> And not altogether impossible, I hope
17:59:20 <ErCiccione> Any last comments about the dates? Otherwise we can close here
17:59:57 <w[m]> And objections? 
18:00:07 <w[m]> * Any objections? 
18:00:52 <SerHack> It seems fine 
18:02:26 <ErCiccione> ok, let's close with these dates. Hopefully people will comment if they disagree or have better options
18:02:53 <ErCiccione> thanks everybody for being here today. The dates are:
18:03:10 <ErCiccione> Branch with all the needed PRs for the hard fork: May 16th
18:03:39 <ErCiccione> Network upgrade (hard fork) on testnet: right after
18:03:55 <ErCiccione> 0.18 release: June 16th
18:04:33 <ErCiccione> Network upgrade (hard fork on mainnet): 16th July, Block 2668888
18:05:10 <moneromooo> It seems weird to branch before the testnet fork, but it's not really a problem, so sure.
18:05:48 <rbrunner> Yeah, the dates are important, we will manage to fit that branch in somehow where it makes best sense
18:06:17 <ErCiccione> Alright. Meeting is over, we should set a date for another one soon. Thanks everyone for coming, have a nice weekend
18:06:46 <moneromooo> What you want is to fork the first time you merge something in master which you do not want in the release.
18:07:08 <moneromooo> So you really want to postpone the branch till the latest to avoid double PRs.
18:07:18 <moneromooo> But it's not a huge headache really, so.... fine.
18:07:25 <sech1> this is why testnet fork is not dependent on branch
18:07:35 <sech1> testnet can be fork when all consensus PRs are merged
18:09:43 <ErCiccione> I don't think that's the important date in any case. The important IMO is to have clear when to branch, when to release and when to hard fork mainnet. Everything esle can be more flexible IMHO
18:11:14 <moneromooo> When to branch is a technical detail really.
18:11:30 <jberman[m]> moo is saying we want the branch to == release to avoid making changes after branching. So target branch date at or right before release date?
18:11:53 <binaryFate> thanks ErCiccione for running meeting
18:12:18 <moneromooo> As long as the testnet fork is a couple weeks before release, I'm happy :D
18:14:26 <sech1> it is a month before release in current schedule
18:15:00 <moneromooo> Sorry, I meant >=. A month is fine.
22:53:55 <escapethe3ra[m]> <erciccione[m]> "Network upgrade (hard fork on..." <- is this final? want to post a short report
23:37:26 <escapethe3ra[m]> edits/feedback welcome: https://www.monero.observer/monero-consensus-hard-fork-16-july-2022/