"In a paper published this week in Nature Electronics, researchers from Microsoft and the University of Sydney, Australia, explain how they've developed a chip called Gooseberry that can support thousands of qubits – significantly more than the 65-qubit design touted by IBM last year – though they haven't actually made such a device."

Why are you here? For the tech? Then you should be off at Zcash instead of trying to con newbies into a coin that doesn't work. For the money? If you put your money in BTC or ETH you would have been better off. For the magical crypto friends? Monero leadership laughs from losers like that. Find yourself more healthy realationships that don't laugh at you when they steal your money.

Why are you here? For the tech? Then you should be off at Zcash instead of trying to con newbies into a coin that doesn't work. For the money? If you put your money in BTC or ETH you would have been better off. For the magical crypto friends? Monero leadership laughs from losers like that. Find yourself more healthy realationships that don't laugh at you when they steal your money.

meeting here at 17 utc

I will probably have to skip, but can add thoughts afterwards

did you see the rough timeline? monero-project/meta #547#issuecomment-772600779

.time

75 min

.time

meeting time

1. Greetings

hola

hoi

hey all

I'm actually around for something 😀

Hallo.

ping sarang moneromooo ArticMine knaccc vtnerd

Hi (lurking a bit here for once)

hi

jwinterm midipoet

endogenic

hello everyone

hello

are sarang and moneromooo here?

Hi

hmm, apparently not

let's just start with the first high-level topic

we need to think about which plan we prefer of the two

this has been discussed in prior meetings, but now they are written down

sarang mentioned that the research work for triptych will take approximately 2 months

3 months for moneromooo is an estimate

I just don't see the need to delay a network upgrade for multisig, which is so infrequently used.

So Option 2 seems better to me.

just for clarity:

If we can work on multisig in parallel or fund someone else for that portion, great.

option 1 and option 2 will have some multisig wallet support

option 1 is doing 2 hardforks: 1 for BP+, another for triptych

option 2 is doing 1 hardfork with both

ah

seems like the cautious route is to change one thing at a time

My preference is option 1. I think the timeline for Triptych for option 2 is very optimistic.

Would love to first hear an informed stance from noether or moo before casting a vote, though one at a time is more cautious indeed.

agree with hyc, an hard fork with two big changes is more risky

hyc's point to me that sounds the most scientific way of doing things

fwiw, two hardforks also creates more headaches for the ecosystem than 1

Still I want to hear from sarang on the timelines

note that I can speak for sarang in the 2 months for research. That is what he is telling me

I can't really speak for moo

a 2nd hardfork 10 months after the previous doesn't sound like a big hassle

considering we used to do them every 6 months, why is 10 months a problem?

I don't understand yet the long time of 5 months in option 1 where there is only 1 bar "Support ..." active somehow. What happens there?

I'm just passing along that Cake kinda interrupts their dev process each time

Option 1 is the better option IMO as well -- fewer moving parts in a single HF, faster ring-size increase, still lots of lead time.

<rbrunner "I don't understand yet the long "> I would assume delaying 2nd HF so that it's not too much pain on the ecosystem while focusing on improving musig support.

[takes a seat]

still dreaming needmoney90

Ok

that part didn't bother me too much, presumably there will be other work to justify a hardfork as well

is August the soonest we can have v15? I'd actually rather move forward as much as possible if we want to go with option 1

Are debruyne or selsta around?

I'd rather make it June tbh

Both of them are front line support, and I think their perspectives here would be valuable.

The other item for the HF is issue 70

Lots of small fires to put out every HF, they have to deal with it every time.

dEBRUYNE is not here, but they were the one mostly championing option 2

I still personally prefer option 2, but I also get the arguments behind option 1

Trouble once instead of trouble two times?

There is an advantage to option 2 in that it does simplify the scaling side in that there is only one tx size (weight) to deal with

I think timing will mostly depend when the code gets reviewed, no ?

BP+ is all ready to go, bar review.

Triptych is not plugged at all, and we might need a new way to represent rings, depending on how much we bump ring size.

Hi

Also, fucking multisig users over is not nice. We'd have to allow CLSAG txes in parallel, probably, so they can still spend their coins while multisig is worked out.

^

moneromooo: it's my understanding that they wouldn't be "fucked over" in option 2

but it seems like most people are generally for option 1

If Deb is behind option 2, I'm inclined to lean towards that option.

Both are fine IMO, I just lean towards one for faster ring-size increase, mostly, which is probably not a good enough reason.

didn't realize this would be a breaking change for multisig

so yeah, let's not screw anyone...

When I said review above, I meant audit by a third party. Not PR review.

Both options complicate multisig FWIW

Potential multisig problem would be to not be able to spend coins out of a multisig wallet for a certain period?

Research areas for this still include: cross-transaction batching, multisig algorithms and analysis, anonymity set binning

There are ecosystem-wide repurcussions every HF. We should be leaning towards more consistency in our releases if at all possible. I think two HFs (when we know what will be included in both ahead of time) is less ideal due to this

rbrunner: I don't believe that would happen

sgp_: do you have a summary of the multisig effects of both?

Just wondering what would be the "fuckery" ...

clsag multisig wallet users need to "convert" their wallet to a non-multisig wallet before they can spend triptych funds received in this same wallet

<needmoney90 "There are ecosystem-wide repurcu"> If we go this route and combine BP+ and Triptych, I'd vote for a long and pushed testnet/stagenet testing time.

With lots of pushes to get people running nodes, maybe even simple scripts for stress-testing scenarios

maybe I need to document this all clearly since there is a ton of confusion it seems

That would cause much less strain on time, resources, and our surrounding ecosystem.

Could do no harm :)

okay, so how about this

We generally don't do a ton of public test/stagenet testing before forks and its just a few of us involved. I'd like to see us actively try and rope in more users and define more test-cases.

I'll open a github issue for these two options with all the details I know of

<sgp_ "maybe I need to document this al"> Its very confusing lol

then everyone will have a week to comment

longer if needed

A pushed back timeline would be a great chance for us to do a push for testing.

before I do that, why v15 in option 1 in August?

BP+ isn't a huge advance over BP so I'd be fine pushing it till later tbh.

I'd vote for 1-2mo after audits complete.

It doesn't hurt as it did for 12 kB -> 2.5 kB.

ArticMine: is really pushing for their fee change being included soon

so we can have bp+ audit finished in 2 months, pretty easy

For sure.

so that's sooner than August

I would only advocate a HF for it with other improvements like MRL70 and ring-size increase.

<sgp_ "so we can have bp+ audit finishe"> June sounds viable then.

is anyone here against late June?

because if no one is against late June, I can adjust option 1

I would prefer to hear from our front line support before making a call here

So BP+ audit by April HF in June. That makes sense

This should be in -dev anyway. Research isn't concerned with fork timing.

okay, looks like I have some work to do then

I'll put out a github issue tomorrow AM at the latest with a summary

ArticMine: can you talk about the fees then?

I'm a little concerned with the increase in the scaling limit from 1.4 to 2

it seems aggressive to me

if Monero adoption grows faster than whatever limit we set, the network doesn't break; transactions just get more expensive temporarily

does anyone have thoughts here?

While I agree that under many circumstances something like 1.6 or 1.8 might be enough. There would be very little margin for error

p.s. I have not looked at fees yet... no head space at the moment

2 would allow for a 32x increase in block size per year

In 2016 we saw a rate over several months in excess of 2 and there was no increase in adoption during the 2014 - 2015 bear market

1.4 allows for ~5.4x

in 2019 - 2020 we saw an increase in adoption during a bear market

well, maybe we should make the upper limit in growth per year to whatever brings us up to Bitcoin's current transaction throughput

since the BTC network does work today with a limited size

is that unreasonable?

add to this the recent regulatory changes and a repeat of what happened in 2016 and we will will be over 2

Bitcoin is dysfunctional because of its limits to growth

So following Bitcoin is unreasonable

there's still provision for growth however

it's a capped growth rate not a capped static siz

Just because we have 2 it does not mean that that it will be maxed out

we need to prepare for spammers to try and cap it out however

That is why the we introduce the LT median

The attack that happened was the reverse

I mean just a month ago

yeah I get that, capping the decrease rate

if it was maxed out under the two scenario: 1) how much would the blockchain grow in one year, and 2) how much in XMR fees would be paid in total over the year?

if you happen to know

jwinterm: with this proposal, it would allow blocks to be max 32x larger than they were at the start of the year

If we allow the short term median to remain above the long term median for an extended period of time then the type of attack we just has would be chap and disruptive

cheap

I think 32x/year is excessive, and gives us little time to react to an attack. We should be considering lead times in years at this point, not months.

There is plenty of time

to respont

There is a flurry of support/ecosystem issues that pop up every HF.

The is only just over 2 hour on the other side

Those must be considered in this equation

That is ho long the short term median can fall drastically

Bitcoin has a little over 10x as many tx/day as Monero right now

June is stressy and unrealistic

Ah, welcome selsta

You should. Please catch up, your opinion here is greatly appreciated

Since you deal with the support fallout from HFs

So we are talking under 2 hours vs over 2 months to respond to an attack

ArticMine: let's separate these two things

there's 1) the maximum decline rate. We seem in agreement here

What two things

then there's 2) the maximum increase rate

is this correct?

Yes but you are ignoring that the short term median can still be above the long term median for an extended period of time

Setting the stage for an attack

Such as the one that just occurred

The whole point of the long term median is to give the community over 2 months to respond

This does not change

because it's capped at ~2x growth?

The Short term median is capped at 50x over the long term median

To allow for a retain surge over a 1 - 2 month period

This is why VISA has over 20x their average use as a maximum capacity

This was all done when the long term median was introduced in 2019

I still think the bump is ambitious

sorry we are getting close on time

selsta: is August the earliest you support?

what are your thoughts there

It is actually very prudent

base uppon the transaction data

I think we will need to schedule another dedicated discussion on the block caps

I suggest the argument be made first in the issue on GItHub

GitHub

Let selsta catch up and reply to the upcoming github issue, take some time to collect their thoughts

MAke the case for 1.6 or 1.8 vs to there

vs 2

needmoney90: can only catch up later

yes I can comment

have to go again

but I also don't want the default to be an assumed increase to 2

the change to 2 is the proposed change

but yes, last meeting I said I would be for late July / August

okay ty selsta

any final thoughts?

if someone wants to join the 2nd BP+ audit calls with me, please let me know

my takeaways:

Are they going to be published later?

The calls that is

needmoney90: no, I'm not going to record the calls

but the SoWs will be public

OK.

When will that be?

The calls that is.

TBD, ideally within a week

it's on me to schedule

Got it

No further thoughts from me

I really would prefer sarang or someone else knowledgeable there

since I have no idea what this code is LOL

anyway

look for the update summary/timeline github issue

thank you everyone

oh, and I will also comment on the block size issue

Sorry, which code are you asking about? (haven't read scrollback)

sarang: I can take the BP+ call by myself but if they have specific questions I'll be useless

I'm happy to provide insight on that code and any auditor comments/questions

sweet, are you able to join the calls too?

Time permitting, sure

okay I'll DM you some times

I have to leave the meeting. I have a conference call in a few minutes

"Such as the one that just occurred" What attack are you talking about? I'm out of the loop

If an attacker disrupts the nodes. The tx rate can drop over 65%

This happened during the attack in late December

There was no impact on fees or scaling becasue the network was in the penalty free zone all along

The scenario is a similar or greater collapse of the short term median in the penalty zone

... and all it takes is for the attacker to keep up the attack for under 2 hours very cheap

and the blocksize can fall by a factor of say 10x or more

<ArticMine> add to this the recent regulatory changes <= What are you referring to exactly?

<sgp_> dEBRUYNE is not here, but they were the one mostly championing option 2 <= Yes

I'd also adamantly oppose option 1, mostly because the upgrade is fairly minor

dEBRUYNE The regulatory changes by FinCEN and by the US Congress, effectively treating cryptocurrencies as cash

One impact of this is that there can be a significant pressure to move transactions on chain and the need for additional on chain transactions to legally avoid onerous reporting requirements

For example if 1) A merchant uses payment processor to accept Monero who then pays the merchant in USD. The Payment processor has to KYC the customer

but if 2) The merchant first accepts Monero and then sends the Monero to the payment processor, there is no need to KYC the customer

This is actually in the 2019 FinCEN guidance

In case 2) there are 2 transactions on the Monero blockchain. In case 1 there is only one transaction on the Monero blockchain

Also section 70 upgrade is not minor and that would be included in option 1

There is a very real risk with the current situation of severely disrupting the Monero network once Monero is deep into the penalty zone. An attack would only need to be maintained for 100 minutes to cause the short term median to fall drastically and fees to skyrocket

So prudence is that we address MRL issue 70 before the blocksie scales over 300000 bytes. This could happen in 2021 with the recent rate of growth

blocksize

There is no immediate problem. If we wait for Triptych to address issue MRL issue 70 there can be a real problem particularly if Triptych is delayed

The wake up call on MRL issue 70 was the drop in transactions during the attack last December

Is there still discussion about your proposal in the PDF I see linked ?

I have not see a response in the issue

on Github

Let me rephrase then. Do you expect this proposal to stay as is and thus be ready to code in monero ?

ie, is this the synthesis of discussion with people who are interested in the nuts and bolts of that particular issue ?

Yes my latest proposal was a response to UkoeHB and the concerns raised

It did not go far enough

There was also the question of a misunderstanding on Big bang attacks

The attacker has to support the short term median for the period of the long term median to continue the attack

So the scenario where the short term median is below the long term median does not play in Big Bang

By the way I proposed the 2x increase rate for the long term median that sgp has questioned rate back in August of last year

I have not yet assessed to updated proposal

I know

for moneromooo's question ^

Thanks. Ping me when you're happy with it please.

sure