.merges

.merges

Should update in a bit, a fair few of what's left needs second reviews by qualified persons. :)

I opened an issue on the Tails repo asking to include Monero. They don't use third party repos, so they won't use whonix' repo. They seem to be willing to add it

but reproducible builds aside i doubt the GUI will ever make it to Debian stable (now, buster)

^ that's the issue

i don't see a quick solution. Feel free to post on that issue, obviously

if we get reproducible builds for the GUI, why wouldn't debian take it?

hyc: monero needs updates faster than their release cycle can take

i think that was the reason given for why monero cli is still stuck in experimental or sid

makes sense

which ultimately tells me we shouldn't bother getting into distro repos

and only provide our own 3rd party repos that users can add if they want package management

... which I think is a waste of time, especially since we have auto-updaters for our binaries now

I think debian is the exception in this case. I'm not aware of other distros with such tight release process.

In general i agree we shouldn't bother, but debian is a bade for many distros and having the GUI on debian stable would open a lot of doors, but yeah, not really doable at the moment.

Btw even bitcoin is not in stable iirc.

.merges

hyc ErCiccione[m]: is there a good advantage to maintaining a third-party repo separately for debian, rather than the updater?

Consistent process, clean uninstall, etc.?

Sarang: beside the fact that debian stable users would be able to install the GUI simply using "apt install monero", would make easier for all debian-based OS to integrate the wallet.

Whonix uses third party repos maintained by them, Tail relys on packages already in stable

Not too much a big deal, but i would really like to have monero integrated by default in tails

Meeting here in 10 minutes

Ok everybody let's start this meeting. This is an important one since we should decide the date for the upcoming network upgrade and what consensus changes should be included. The agenda is here: monero-project/meta #485

Let's have a round of greetings to get an idea of who is here

Hi

Hello

Hi everybody

Hello

Good morning.

Hi all :)

Grüezi

So the main point is to decide what are we going to include in the next release, but before that, would be great to have an overview of the status of CLSAG and related audits.

Sarang, go ahead please

:)

Sure

JP and Antony (the reviewers) have completed their audit of the preprint and code

They're finalizing the report for public release

The preprint has already been updated, and the code does not require any security updates

moneromooo is in the process of rebasing the code

I've been in contact with folks on the Ledger and Trezor teams throughout the process, since they have their own development and release timelines

in the process of preparing to get ready to start rebasing the code

:)

What's the ETA for having it PRd and ready for final reviews?

Trezor is pretty much ready to go; they'll need the fork height and can then update firmware, but the Monero-specific development is done

Ledger has done most of the work already and has code ready for integration on their side, but it hasn't been completed yet

The person I've been working with (Francois) said the team that does the firmware integrations does _not_ have this on their 2-month timeline for some reason

and that Francois would not be able to do the integration until after September 21 due to scheduling

They're check to see if the Ledger integration team can prioritize this if needed

Further, they want a couple of weeks to test after the integration is complete

and then can set the fork height and release on whatever timeline they choose

Is there a general opinion of when the upgrade should be, ideally?

Personally I don't see much more argument than "Why wait with improvements" ...

It seems like Ledger is the biggest unknown right now

Annoying that Ledger can't do any work for 2 months

I'm all for pushing this ASAP once code is ready to go, but if Ledger is #soon we could wait for that.

Francois asked for 4 weeks between release and the upgrade height, presumably for prioritizing testing

I guess ledger will have to adapt their schedule.

<sgp_ "Annoying that Ledger can't do an"> Yeah no kidding...

"on whatever timeline they choose" sounds a little, well, harsh

but they are unavailable until September 21 to do the rebase and integration

Sarang: that's a good idea reguardless and we usually do it afaik

rbrunner: I didn't mean that to sound harsh

Do we have a "release checklist" for this including these items?

I just meant that I don't know what's required for their releases

Alright :)

sethsimmons: the checklist is something good to have. We can discuss that once we have a date :)

Ok, I'll start capturing some items for it to circle back to later.

So we are looking realistically at the end of October?

If the Ledger timeline works as I understand it from Francois, it sounds like end of October would be the soonest they could support

but it's unclear if that's guaranteed to work for the Ledger team

What can we do to get a clearer timeline for them?

We all on ourselves could do this probably a month earlier, right?

3 months of notice is extremely generous time

sethsimmons: I'm not sure

Francois is reaching out to the coin integration team to get a better sense of their prioritization

I haven't heard back about this yet

It is extremely generous. I wouldn't go beyond three months

But part of this seems to be that Francois is not available to do the necessary rebase until after Sep 21 for other reasons

And there isn't anyone else at Ledger that can do it?

I do not know

Someone else previously worked on Monero support with Ledger, but recently passed this on to Francoid

*Francois

Ah, yes, forgot about that.

What about tentatively saying Oct 1?

Sounds good to me

I don't think that works

Maybe depends on Ledger's reaction to that.

Seems too early

We also have to account for other wallet providers such as MyMonero

I would suggest October 31

Spooky

If Francois can start the integration right away on Sep 21 and Ledger prioritizes it on their timeline, they'd still want a couple of weeks to test their release with updated Monero code before releasing firmware with the block height

I wouldn't base the timeline on ledger's needs. We are giving them planty of time to adapt

I agree that at some point the release needs to happen, but I hope there can be as much support as is possible in a reasonable timeline

I am all for allotting time for third-party wallets etc., but due to Ledger we're basically frozen for 2 months

They are a company that makes money on Monero. They ahould adapt on us, not the other way round

*should

I tend to agree. If some entity cannot live with 3 months of advance warning, well, tough.

Giving plenty of time is fine. Adapting to their priorities is not

That's half of our "old" hardfork schedule, after all

There have also been months of advance warning. The code was written a while ago

Well, they were also presumably waiting to know of any changes

Thanks for the thumbs up on matrix but those don't show up on IRC, please write what's in your mind :)

I know that Francois was unavailable to join this meeting today (but said they would read the logs later), but I can present the October 31 and get their thoughts

I still would rather present Oct 1

As much as leaving Ledger users out to dry sucks (that includes me), if we give 3m and thats not enough with a lot of extra runway before now I'm not sure thats something we can wait even longer for.

Perhaps someone else can do the necessary rebase

Oct 31 is the absolute latest and is very non-ideal

Yeah I'd love to hear if anyone else at Ledger can step in

They made it sound like rebase and working with Ledger integration team was all that was left to do

2mo without a way to rebase is.. odd

I tend to agree woth sgp

I would make October 31 firm, or maybe something like Oct 20

but make it firm

OK, so working backward from there

October 1 is the ideal _fork height_?

Not release

Coffee Chat planned on Oct 17. We can make another update edition

Oct 17 sounds like a good compromise.

Yes that seems reasonable

That gives them 3+ weeks to rebase/test after their 9/21 date

Hopefully that is plenty.

So I'd like to know what the proposed dates would be for (a) setting the block height, (b) releasing code, (c) the upgrade height occurring

b) Sept 17

Of course, once the Monero code is rebased, they can build and test on a private testnet as they wish

Block height 17 oct release one month before?

sethsimmons: We need a release at least a few weeks in advance of the height

There will need to be another release for Ledger but that's only impactful to Ledger users, not consensus

Preferably a month or so

For sure

Note that there's already Ledger-specific code in the current Monero CLSAG branch

Yes, that would speak for a September 17 release, right?

Release 17 sept, hard fork 17 october?

Are people ok with that?

does monero have a list of commandments? 11. thou shalt not hold releases for outside entities.

That makes sense

amen

And maybe merged our changes into master on August 17? With time to play around on Testnet

OK, so when would the height be finalized?

Since that needs to go into their dev cycle

(this is where a release checklist would be _very_ helpful...)

I guess even now if we have a date for the hf.

<sarang "(this is where a release checkli"> I'm compiling a starter as we speak :)

Seems so, the hardfork height should the be least problem if we have a date :)

rbrunner: right, but it needs to happen :D

It could vary slightly in timing depending on HR changes, but we could set it now

sethsimmons: block times are pretty consistent overall

Generally, yes, I wouldn't expect much variance.

Why not pick the exact height shortly before the Sept ~17 release

We did the important part of choosing the date today

Does anybody have anything against 17 september release, 17 october hard fork? Otherwise we can officialize it as decided

Sounds good to me.

OK, so to recap... the intent is to merge all changes by August 17 for testnet, release on September 17, and fork on October 17?

The release need to have the fork hard coded?

I think it better has it, yes

Yeah

moneromooo: since you're getting all the CLSAG stuff rebased and updated, does that sound reasonable?

I can do it in time yes.

I'll reach out to Francois again with this timeline and see what the Ledger team can prioritize

and will reach out to the Trezor team too

Trezor basically said "let us know when your code is done and the height is set, and we're good"

Nice. Let's keep going then

Trezor sounds awesome haha

What other consensus changes do we want in?

Are there any waiting?

Only potential one is BP+, correct?

There were a few more things included in the logs I posted in the meeting issue

and issue 70 in MRL

Coinbase rings is one I'm pushing for

I want to straightn out some unlock time stuff, technically a consensus change, but no functional change.

I've been meaning to do that for a long while.

If the freeze deadline is mid-August, I doubt BP+ could safely make it in

moneromooo: sounds good to me :)

<sgp_ "Coinbase rings is one I'm pushin"> What is needed for that?

but TBH the size savings aren't so significant as to make that a huge loss

AKA could coinbase rings easily make it in in time?

BP+ would also need more review/audit right?

<sarang "but TBH the size savings aren't "> Yeah no need to rush that at all.

sgp_: I personally think so, but part of it depends on what the actual diffs from the current code end up being

So no BP+ then

When I brought up BP+ earlier (when the preprint came out), the reaction seemed quite "meh"

and only now seems to have come up again with the new CCS

But no, I would not plan on BP+ for the fall upgrade

and certainly don't block for it

How big are the savings?

Something like 90 bytes per single proof

Not massive, but not trivial either

Ok, so seems that consensus is to keep bp+ out for now.

What abut coinbase rings? Do we need more discussion about that?

For coinbase-only rings, luigi supports reducing the coinbase ringsize to only 1

I'm still not sure whats still needed for that/how feasible it is to make it into the HF

sgp_: can you speak to that?

I'm for the change overall, just not sure on details

I can't speak to moo and others' ability to code it in time

moneromooo: any idea on timelines for that/is anyone else helping with coding that?

Nobody is doing this AFAIK. I won't unless MRL clearly says it should be done.

In which case it's an easy change I think.

Yeah, reading the IRC notes on the meta issue I was wondering whether there is already our famous "loose consensus" about this, or quite diverging opinions

sarang: any feedback on that overall?

I've seen back and forth but no clear decision.

After all it's again some step up in protocol complexity.

rbrunner: my feeling too

I see the question being consensus rather than coding time

Appears so :)

I marginally support such a change, but it would require pretty hefty testing

Since it would affect how outputs are selected in the distribution

This doesn't require a consensus change, but it's related to monero-project/monero #5222

coinbase rings requires consensus change, correct?

Yeah

Yes, if you want nodes to reject those that don't behave.

Figured, just wanted to make sure.

The main reason I'd like to see it in this upgrade (if we can reach rough consensus) is because its not worth its own HF so would have to wait for another down the line

Which could be a while.

Would it be worthwhile to separate out a meeting for that discussion?

sethsimmons: for which proposal exactly?

(too many things flying back and forth)

coinbase ring changes

SOrry :)

I would say let's wait for clear consensus before deciding about coinbase rings in the october hard fork. It's not super urgent anyway and we don't have to decide now.

Rushing output selection changes seems unwise

but that's not a reason not to do them if desired, of course

Well, if we want to be able to play with the release on Testnet in 1 month, that's not much time left.

True, especially since it seems to need a good bit of testing/verification even after code release

you can always setup private testnets

The CLSAG changes are significant enough that I think delaying for smaller changes is not worth it

Having plenty of time to test CLSAG will be important

Definitely agree.

I don't think this would cause a delay; rather no one else seems enthusiastic about it

I'm enthusiastic about it :P But there certainly doesn't seem to be strong consensus

I would rather wait a little and wait for 50+ rings, with Triptych, making some such problems marginal as I see it

no clear benefit, nobody knows what the risks actually are. sounds like a bad idea

Hmm, hadn't thought about what effect increased ringsizes would have on it in future.

The problem stays and scales, but the convincing ringsize is still larger

Alright. I think the general feeling is to not include coinbase rings in the upcoming release. Let's not go in depth about it now, it can be discussed in another meeting :)

Sure, no one else really cares so pass

Anything else that we want in? Or any blockers that should be resolved?

Well, not care sounds harsh, just different weighting of trade-offs maybe

sgp_: I do care, and would support a change if implemented and tested carefully

I think it's somewhat marginal for heuristics, as I've said elsewhere

As far as i understood there shouldn't be blockers, right? The biggest issue right now seems to be ledger that cpuld be late

Right, it's not clear when the Ledger release would be available

Let's see what they come up if a little gentle pressure

Yeah, now that there's a date in mind, I'll let them know and see what could be done

Of an October 17 hardfork

Perhaps they hadn't prioritized because no date was known

which is understandable

And if there are useful coinbase changes and/or BP+, that would make for a nice subsequent release at some point

Good point on the subsequent release :)

So we won't run out of hardforks anytime soon :)

Gotta keep the FUD alive :D

Alright. So, let's start talking about splitting duties. Wpuld be good to have a checklist of stuff that needs to be done and people willing to take care of it

Yeah, a while back I brought up the idea of a checklist

We don't necessarely have to decide everything now, but wpuld be good to start

Where assignments can be made for who is responsible, and when, etc.

<ErCiccione[m] "Alright. So, let's start talking"> I have a WIP checklist I can share if you'd like.

and hopefully avoid a lot of the small errors and problems that happen from time to time

e.g. "the hashes don't match" etc.

And I'm happy to own some of the administrative tasks (contacting entities, etc.)

Didn't fluffypony hand over something a while ago?

sethsimmons: yes please we can then integrate it with some that are already around (fluffypony has one)

rbrunner: he had a few things, yes

Having an ongoing list would be great, and any issues that arise can be added to avoid in future releases

Let me post to a pastebin site

Copy paste will end poorly for you IRCers

yeahhhhh

Initial list

Very WIP

hmmm. Can post an instance of the checklist for each release

on gitlab

I'm sure I have some steps out of order etc

and make each point an unresolved thread

<hyc "on gitlab"> Yeah that would be the intent

and then resolve them as they are taken care of

Host it in an issue perhaps with MD checklist

something something gantt chart

*meta issue

Soon we will end up on JIRA

I'm a JIRA admin dont tempt me

JIRA - where software projects go to die

:P

GitHub supports basic kanban boards

I would say a basic kanban on github would do it. We could link issues to it and assign issues to prople

Should I open a meta issue to work through the creation of the checklist?

So we can have discussion/updates/etc.

Sounds good

Ah, a checklist checklist

XD

We've gone too deep

Lol, but i do think would be useful

Any initial feedback on the first stab at the list?

I have a self-hosted Wekan available (Trello clone)

If not I'll open the issue now and we can iterate as needed.

Ledger/Trezor coding is a bit more abstract

Unless you mean "on the Monero codebase"

sgp_: i would keep it simple and just create one on github. Also much more visible

e.g. there's Ledger-specific code in Monero

as a device option

I'll break that into our end and their end

Oof that didn't paste well

paste.centos.org/view/29c74c53 <- Better?

Wallets should be informed as early as possible IMO

As should exchanges

Right after fork height, or tagging?

Seems that exchanges operate at the speed of a glacier as it is

I'd say right at fork height, so they can plan for it

done.

Even if they don't start working right away, then they at least know when to expect the release and the upgrade

Any last updates? Don't wanna derail this meeting too much with the first take on it.

Alright. I would say we can conclude the meeting

The discussion about the checklist can continue after or directly on the meta issue

OK, what are action items on this?

I'm going to contact Trezor and Ledger folks ASAP with these dates

Nope, we are done.

Thanks everybody for participating. You are free to go back to your sundays :)

Thanks all, and thanks for running this ErCiccione!

thanks all

Thanks

Initial upgrade checklist and meta issue: monero-project/meta #489

there is another open discussion about removing the tx_extra field, although it's probably not relevant for the next release (issue #6668)

indeed tevador

Basically tx_extra allows us to augment the tx format without changing the tx version

Isn't that benefit somewhat negated by the use of semiregular network upgrades anyway?

seems like that's a pointless feature to have

Moving transaction elements out of extra means lowering the possibility for fingerprinting transactions based on non-enforced structure

the general consensus was in favor of removing tx_extra

I we want to remove it out we should really make it known soon, to make sure we are not breaking anybody's setup imho.

*If* we want to remove it, we can announce it soon and then actually remove it in the next upgrade I guess (the one after CLSAG)

That should allot plenty of time to make necessary changes

I am somewhat against remove the extra field, but don't have a strong opinion

rbrunner: fwiw my Release Engineering list was focused on getting a release out there

not on hard fork duties

dEBRUYNE used to do a lot of groundwork around hard forks, he might have further thoughts on what to include in RE lists for hard forks

Would you mind sharing your list so I can compare/combine?

Or do you think we should keep them separate?

fluffypony: ^^

oh

sorry I thought someone had shared it

one sec

sethsimmons: paste.centos.org/view/raw/0f0e3b00

Thanks!

I'll probably leave the specifics around code updates out of this, but have added the specifics on updating downloads/hashes

Hmm, they should probably be captured somewhere, though... I'll give it some thought.

yeah everything's kinda intertwined

also FYI web.getmonero.org is the CDN, the source is just getmonero.org

no wait other way around

lol

so leave it as is

😅 glad I’m not the only one that confuses

Wouldn't necessarily need to _remove_ extra (but it's probably optimal for fingerprint reduction)

but at least moving known tx elements out would help

note this proposal also has an implementation guideline that includes removing things from extra monero-project/monero #6456

yes, removing everything non-optional from tx_extra would be a good first step

fluffypony: The gist of it was basically to spam information about the upcoming HF as wide and as much as possible

And trying to contact exchanges etc.

I guess most of it is condensed now on the mailing list (the contacts)

So a few emails on that + wide social media coverage should suffice

tks dEBRUYNE

With a less tight schedule and no PoW changes it also becomes easier

Last time we tagged 5 weeks before the HF iirc and there was plenty of time for services to upgrade

A new software version is mostly a drop-in (barring some testing of course)

except for wallets

they're the ones that struggle the most

but for exchanges and services year

*yaeh

*yeah

Yep

We should accomodate plenty of time for wallets with this CLSAG upgrade