.merge+ 8145

Added

hello, my monero gui wont close, it is constantly checking local node status. I dont understand why?

which OS? also did you close it while the wallet was still syncing?

selsta: windows. possibly, what effect would would it have? can i just restart?

also do you use Ledger?

never heard of that, no

ok, you can kill it with task manager

ah, thanks. its been steaming my computer for 3 hours

Meeting here in ~2 hours: monero-project/meta #652

s/652/655/

hi

meeting time :)

It's meeting time!

Hello folks! This is an important meeting focused on the next network upgrade (hard fork). Code freeze supposed to be on January 15th, but the changes needed haven't been merged yet. During this meeting we'll explore the status of these PRs, so that after we can decided new dates.

After that, we will take a look at other features/changes waiting to be merged that would be cool to have in the next network upgrade, but that do not strictly require a hard fork. The full agenda is here: monero-project/meta #655

for reference, the logs of the last meeting are here : monero-project/meta #633

See also this excellent overview of the v15 hard fork: monero-project/meta #630

So let's start with a round of greetings to see who is here today.

Hey everyone, thanks for joining.

Hi

Hello

Hello

:waves:

Hello

Hi

hi

Ok, let's proceed to the second point of the agenda:

Howdy

hi

2. Ringsize 16. There were still some doubts during the last dev meeting. Do we want to confirm 16 as the next ringsize or more discussion is needed?

I say confirm

+1

+1

Such a nice number :)

we also have to talk about multisig which currently isn't in the agenda as far as I can see

ok with me, would have comparable verification costs to a likely seraphis implementation

+1

selsta: It's in 5.

But sure a candidate for 3.

IMO it should be something we want to release before the hardfork

yeah multisig doesn't require a hard fork, so we can discuss it later. Very important topic indeed

I support increase of ring size to 16.

but yes lets talk about it later

16 ring size it is then, no?

everyone present agrees on 16. That was easy. We can make it official at this point

16 it is

now let's talk about the r PRs that require a hard fork that still need to be merged:

3a. view tags (monero-project/monero #8061).

The review of the PR seems to be still ongoing. @jberman could you give us an update of where things stand at the moment?

We got some feedback about Siphash, from the Siphash author, on the view tag PR: monero-project/monero #8061#issuecomment-1024939341

jtgrassie and vtnerd_ were the ones expressing skepticism about it originally

Commit coming today in response to rbrunner 's comments related to making sure there is a smooth transition at the fork (users who update wallets before the fork will have their tx's processed without view tags for a grace period, to allow smooth transition, and will include a way to not cause a breaking change on one of the internal structs)

Eagerly awaiting this!

+ addressing their other comments

there will also be merge conflicts between this PR and bulletproofs+, happy to take care of them

Sounds good. Will it only need final reviews + merge after or are there other blockers?

I have the code of this PR running at my MoneroTech web wallet as "TechNet" as a functional test. Works beautifully.

regarding the re-opening of Siphash versus Keccak discussion, whatever is decided there is super simple to change in the code. I already have the code using Siphash written

Without knowing the background, switching to a custom hash for only 1% or 2% speedup seems odd.

To resolve that question, hopefully jtgrassie and/or vtnerd_ can respond to Mr. Aumasson

Personally I would like to forego that re-opening ...

> Will it only need final reviews + merge after or are there other blockers?

some downstream ecosystem folks will likely need new code to to handle view tags (wallets will need to use new code to construct/scan for tx's with view tags)

- I don't know the extent of what changes will need to be made to accommodate them it will vary by software (not sure how much is re-used from the core repo)

- these changes can likely need to be done alongside changes to support bulletproofs+ I would think

got it. Usually we give enough time to members of the ecosystem to adapt to the post-hard fork changes, so that shouldn't be an issue.

So good we publish the software 1 month before hardfork, right?

yes

if there are no further comments let's proceed to the next PR:

View scanning is a central UX bottleneck, so I think it would be unwise to leave any inch on the table, for no compelling reason.

3b. Fee changes from Articmine (monero-project/monero #7819)

The PR seems to be mostly ready and reviewed. Only some minor conflicts that need to be fixed. moneromooo could you give us a quick update?

UkoeHB suggested a second review

AFAIK this is ready. Let me go see the last comments...

"second review" as in "more eyes"?

Yes, nothing since, so nothing to add.

IMO all big PRs need at least 2 reviewers.

I can review this

Are the growth numbers from Justins comment here accurate? If so, I have grave concerns about chain growth attacks

Especially in light of the flood attack last year

My estimate is Monero won't be able to realistically exceed Bitcoin volume: monero-project/research-lab #91#issuecomment-1018641072

I'll review 7819

Might be worth contemplating an upper limit on block size

No

To avoid stability problems around verification costs

This has caused very serious problems for bitcooin

thanks jberman 🙂

Thanks jberman

ArticMine: bitcoin doesn't have a verification bottleneck

The combination of allowing 14x growth in block size per year with the very low fees could lead to a disaster

Verification can be addressed

How?

With the use of graphic processors and multithreding

That only kicks the can, it doesn't solve it

Actually it does

once we take a hard look ant the numbers

your next project...?

The overall limit is bandwidth by the way

I have been looking hard at this

In any case, answering this question is the same as 'contemplating the need for a block size limit'. Let's not answer it in this meeting.

However, does it need to be answered before the fee PR can be merged? carrington[m] 's concerns

Limiting verification to GPU owners is a TERRIBLE tradeoff IMO. Dynamic block size is fantastic up to a point, but there are other ways to scale transactions.

Well, what's allowed *now* as a yearly blocksize growth?

hello i'm sorta here

Most consumer device have intergrated graphics that can be used

most servers don't

by default

And drivers can make you crazy.

No with current tools such as Open CL

Also agree limiting to GPUs is a bad idea especially given current shortage of them

rbrunner: I think the longterm median can rise 5x per year with current growth rate

Reminder that last year someone added 700MB to the block chain for $1000 in fees

Yes but no on a sustained basis this is the reason for the long term median

The cosst of the kind of span adds up

spam

The short-term can rise up to 50x the long term. So you could have 75MB blocks after one year of maximal growth.

I mean in that example the LT median dod not even move at all

seems like there are some heavy skepticisms about this. Maybe it needs more focused discussion before we include it in a network upgrade?

or a separate MRL meeting for this?

It has been hashed over and over agan

The fee PR is necessary, the question is about growth rate.

100%

The growth rate of the LT median is necessasry over the short term

2 - 3 months

Any dynamic blocksize can be scaled to insane limites given enoght time

insane limits

think the fee PR has been discussed for months since artic first came up with it. similar to beating a dead horse. beyond deliberating further, why not run a quick poll for yes or no and move forward depending on the outcome? akin to how we reached final consensus re: ring size bump 16.

just sayin.

Clearly more discussion is needed, let's have this discussion in a dedicated MRL meeting, let's move on to the next point

I agree a cap of 14x/yr seems high, and I agree it would be ideal to target CPU's to allow syncing on any commodity device, raspberry pi or server included. I'm for another MRL meeting to discuss

commodity devices have graphics

As Justin pointed out, hitting a growth ceiling doesn't break the network. It just causes a temporary fee market. We don't have to rely on a fee market to exist like BTC, but avoiding it completely in exchange for huge chain bloat is nonsensical to me.

please set a date for a focused discussion on this, we need consensus on such important change and until that's reached, there is no point in discussing it here. Moving on:

Sorry, JustinE to be clear

Actually it can trigger the issue 70

There is a point where normal node operators have to shut down, since they can't verify new blocks fast enough. And also a point that happens way earlier than that, where normal node operators can't verify the chain, since it takes too long to catch up. These breakpoints are stability issues for the network, and they have NOT been discussed.

If we allow the st median boe be above the lt median for an extend pereiod of time

Would it be advisable to implement a slightly more complicated blocksize limit function to permit short-term spikes (to accommodate sudden adoption), but not allow huge cumulative growth over long periods?

That is what the LT median does

Ok ErCiccione we will address it in the next MRL meeting.

yes please, let's move on

This seems like a good problem for that guy who was looking into the difficulty adjustment recently, control theory and all that

3c. Bulletproofs+ (monero-project/monero #7170)

Not much action on the PR lately. Are we waiting for more reviews moneromooo?

Why ? Come on, they're discussing something importand and on topoc.

At least wait till they're both done.

ErCiccione: vtnerd is working on the review

moneromooo: we have a lot of point in the agenda and this is a discussion that has been going on for a long time. If we want to use this meeting to discuss this sure, but i think the hard fork is more importna, especially because we are already postponing it

moneromooo: could you amend the PR comment for 7170 with a link to the audit report on BP+?

Gah, november, ping me if you comment on a PR from me :S

there is always time at the end of the meeting to discuss whatever, but at least let's try to organise this HF first

I dio not have the audit report. No idea where it is.

moneromooo: suyash67.github.io/homepage/assets/…etproofs_plus_audit_report_v1.1.pdf

ty

ok, so waiting for vtnerds final review and then can be merged i guess

yes

so, the situation is: 2 of the 3 PRs that require a hard fork are mostly ready to go. The issue is with the fee changes, since there seems to be some disagreements.

Do we feel comfortable in already talking about dates or we want the discussion about the fee changes to be completed first?

To clarify, the theory AND implementation of BP+ have been audited, yes?

yes

The fee changes are predicated on the LT median scaling

I think it makes sense to wait until the fee change discussion is completed so we don't end up putting out more conflicting dates

discussion re: fee changes is to occur wednesday next week. there are three other potential PRs that could be included before hf as per agenda

So we need to dealt with fee change dicussin before we proceed with the dates

for the HF

it would be good to have bp+ merged soon so that we can contact hardware wallets for integration

jberman: my feeling too

A dedicated MRL meeting sounds good, I'll be there

<selsta> it would be good to have bp+ merged soon so that we can contact hardware wallets for integration <= +1

let's freeze the hard fork until the fee discussion is completed then

We need to be aware that third-party wallets may also require code changes

So they need to be properly informed of the changes (view tags and BP+)

yeah we will do the usual code freeze

+ let everyone know.

*plus let everyone know

I'm happy to assist any ecosystem participants with needed changes too

Right, but want to point out that we may have to allot a bit more time

Or we need some people dedicated to reaching out and assisting (thanks jberman[m] for offering already)

To confirm, if wallets haven't implemented viewtags at the hardfork will their slower previous method continue to work?

yes

dEBRUYNE: I think we are in a good spot, we have more people that could help compared to the past hard fork. ANd things went always fine in past

most normal wallets use wallet2 so it should be a non issue for them

That explains why it's a candidate for a fork so fast. Nice :)

UkoeHB: wallet scanning could still work in theory, but parsing/serializing will probably cause issues. Plus, if we require view tags as the PR does, then they won't be able to construct tx's

true

the PR as is has a grace period, which I think moneromooo you were intended for BP+ as well?

ErCiccione: True, but still would like it to go as orderly as possible and not cause any users to not be able to properly use their wallets

sorry, willl have a grace period

dEBRUYNE: of course. 100% agree

any comments re: multisig PR? monero-project/monero #7877 UkoeHB vtnerd_

I don't remember whether I added a placeholder fork. A double fork is probably best.

yeah double fork is what we did in past no? 1 fork adds the changes the other one enforces them?

I believe vtnerd_ needs final approval, and h4sh3d also said he is reviewing the changes I made.

Reviewing it, probably a ship it soon

When needed, yes.

Scalability: will talk about that in a bit

I have a commit for view tags will submit today that also implements double fork

thanks vtnerd_ UkoeHB.

what do we want the spacing in between forks to be?

ErCiccione: Yes

Oh, that reminds me there was a bug with txes being checked when added to the pool before a fork, and not checked again at the fork.

Did that get merged ? I had a patch for this IIRC.

yes

it got merged

Thanks

that was merged: monero-project/monero #7169

Your lookup speed is commendable :o

hehe, I have these links from discussion with rbrunner in the view tag PR, who pointed out my view tag PR should also implement the double fork thing

luigi1111w: regarding the multisig crypto changes monero-project/monero #8149, any news regarding extra review? you added the important label :D

that's cuz it's important :D

I hear someone is reviewing it, need to figure out their schedule though yet

Would be really nice to get the whole multisig stuff into the hardfork as well, for organizational reasons: Everybody will have to update.

jberman[m] we should already double fork for ring size/bp I think, so it's ok

rbrunner agreed, would really like to see all the ms fixes we have included

rbrunner: yeah absolutely, we will need them for Haveno too, so the faster is in, the better

I made a lot of functional tests with them, up to 3/5 multisig, which all worked

(the consensus rules I initially included for view tags didn't follow the double fork pattern is what I meant)

Does not replace reviews, of course, but still

ok, there are other PRs that are marked as nice to have for the HF:

meeting time is almost over, so if anyone has anything to say about any of these, please go ahead

Re: multisig, In the past I said I'd review, but I don't have the crypto knowledge to spot significant issues. h4sh3d I think is currently re-reviewing changes and does

jberman[m]: can you give an update on binning?

I think it's not planned for this HF

if I remember correctly

The algorithm in the linked issue is in a state where it is review-able. Personally I don't feel I have compelling enough evidence to push it further i.e. it is not a critically necessary update in my opinion, and needing to find agreement on its parameter choices + getting the implementation into the code seems a tall task considering

so yes, I would remove it from the HF list

It's probably much too late to even try to get 7760 in, no?

monero-project/monero #7760 fixes so many existing bugs with the daemon it would be really nice to include it but I don't know yet how we will get it reviewed

but it's not something that requires a HF

It's stuff that can be done regardless of the HF afaik, so it's ok

Maybe in a .1 right after the release ? That way it can get long term testing by people who update to it, but most merchants etc won't.

Though I guess it'd interfere with the usual brown bag fixes.

Jberman[m]: ukoeHB: I’m on it, I think I can complete the re-review by the end of next week

So the fork release becomes something like an LTS release :)

I have been running it on my nodes for half a year now

awesome, thanks h4sh3d

^that sounds good to me

it's stable :D

Nice! Anything else hard fork related? Otherwise we can end the meeting, as we are past the hour

For the fee issue, could the people who see a problem make a sample case (ideally worst case with ArticMine's current patch and worst case they'd be grudgingly OK with), then ArticMine can see whether he'd be happy with a parameter change that'd prevent those cases while still allowing enough growth ?

view tags and bp+ almost ready to be shipped. fee pr to be discussed during mrl meeting next week. binning post-poned for now. it's looking good as far as i can tell...

ErCiccione: i guess it would be wise to decide if we will have a follow up dev meeting next week, or in two weeks, to hopefully pick dates for hf?

multisig is also ready, just getting some extra reviews

No need for a follow up meeting until the situation of the fee changes is clarified and consensus is reached IMO

that is what the MRL meeting on wednesday is there for...

there will be consensus because that is an hour long meeting run by UkoeHB.

We will see

if you want to be conservative, why not schedule the next dev meeting for dates in two weeks instead of one?

either way there has to be another dev meeting. dates are to be decided still

this is a discussion that has been ongoing for months, don't assume it will be clarified in one meeting

<moneromooo> For the fee issue, could the people who see a problem make a sample case (ideally worst case with ArticMine's current patch and worst case they'd be grudgingly OK with), then ArticMine can see whether he'd be happy with a parameter change that'd prevent those cases while still allowing enough growth ? Could this be posted to MRL issue 70

I don't think there are the basis to schedule another HF dedicated meeting at the moment

not assuming. it's been discussed for months. decisions have to be taken.

OK.

and cross referenced to pull 7819

I'll reread all the relevant threads etc. so I can have an informed opinion on Wednesday

Ok the meeting is over folks. Thanks a lot for joining, next appointment is at the next MRL meeting, where fee changes will be discussed, but feel free to continue the conversation here now!

thanks ErCiccione

Thank you ErCiccione , high quality meeting

+1

Thanks for hosting/leading the meeting ErCiccione!

+1

thanks 🙂

+1

I'll post the logs

<moneromooo> "Maybe in a .1 right after the..." <- This is a good idea IMO

That's what we did for... something, some... time ago. Can't remember what or when, but pretty sure we did :D

Ah ya, I remember that was discussed in this vid: youtube.com/watch?v=dQw4w9WgXcQ

:P. jberman matrix preview ruins it 🙂

couldn't help it

for the IRC people :D

.-.

mitchellpkt.medium.com/fingerprinti…ero-transaction-volume-a19cbf41ce60 <---- Blocksize remained well below the minimum penalty free zone of 300,000 bytes during the anomaly. bitinfocharts.com/comparison/size-xmr.html#log&1y Going into the penalty zone above 300,000 means a 5x increase in fee just to get started. Then there is the requirement to maintain

the ST median for over 2 months just to move the LT median

It is not that simple

In any case the "attacker" stayed well away from the penalty.

Sadly missed the meeting, but thanks ErCiccione for hosting it! Will have to read through the logs and catch up.

carrington[m]: Would you mind posting them on r/Monero as well?

(the logs that is)

Yes I'll make a post shortly

ArticMine @ArticMine:libera.chat: my point with that article was more broadly "low fees are already a problem". Extrapolating, it seems that someone could grow the blockchain by 1TB for roughly $1.5 million without activating dynamic blocksize at all. If dynamic blocksize "organically" results in x14 blocksize over a year, that attack could be performed x14 times faster with a linear cost increase. These costs seem unacceptably low to

trash the network completely. Please correct me if I've misunderstood.

But then again I'm not sure what the cost of a 51% attack is at the moment, which is what it should be compared to

I.e. the attack over the course of a few weeks becomes possible over a few days, leaving not enough time to upgrade hardware and knocking many nodes offline

Let us start with the current minimum fee. In order to have reliable scaling one needs an increase of 5x

Now if there is organic scaling to say 32x. or ~100x the current tx rate. What is the impact of price in terms of constant USD?

I did an analysis of this back in 2020 for a talk I gave on line. For Monero the value increase exponent is about 1.6 This is between 1 (linear) and 2 quadratic Metcalfe's lwa

so we are talking about 1600x for the value of 1 XMR

So one needs to estimate the cost of doubling the block size via spam from say a base of 10 MB

vs the current situation

So the premise is that the base fee would be higher in fiat terms, increasing the cost of such an attack? I will watch your talk before Wednesday

i wonder if we could harvest difficulty / time to get a sense of the verification capability of the network. ... somehow tie the dynamic blocksize to difficulty...

The total cost of increasing the blocksize by 2x not the base fee

The base fee per byte is actually less in terms of XMR

and can even fall in terms of USD at the expense of lowering the rate of growth

gingeropolous @gingeropolous:libera.chat: isn't difficulty related to hashrate which is not necessarily verifying transactions?

For a constant rate of growth the base fee falls be a 32 for the same rate of growth

in my example

carrington[m], yeah. my point isn't to tie it directly to difficulty, but to use those data as an "oracle", almost, to get a sense of what silicon can do

for an increase of 32X in blocksize

like if we see a 32x increase in blocksize, but not an X increase in difficulty...thats different than seeing a 32x increase in blocksize and a Y increase in difficulty.

At the bare minimum rate the fee in terms of XMR falls by a factor of 1024 in terms of XMR

So in my scenario of 10 MB blocks with a 1600x in crease in price we have

Cost of HAM (single tx) at minimum fee the increase in constant USD 5x1600/1024 7.8x The SPAM cost increase by an additional factor of 32

so 250x

The current rate

The bottom line organic growth makes it way more expensive to spam the network once we factor in a reasonable increase in price.

There is a lot to think about here. It definitely seems like an area that would benefit from gaming out various attacks and comparing their cost to a 51% attack. I'm not sure I'm convinced by the "fiat spam price will increase under organic growth" argument (just looks at organic growth over the last year and overlay the fiat price, the correlation is not easy to see).

UkoeHB's comment on issue 70 is a good summary

In fact, Moneroans often like to contrast the price charts with the txn increase charts

It is unsustainable over an extended period of time

Even if one just consider the equation of exchange

en.wikipedia.org/wiki/Equation_of_exchange One cannot simple keep increasing economic activity, have an effectively constant money supply and not have serious deflation

Is there a good link where I can read up on what the issues are regarding the fee that are being discussed here?

wernervasquez: monero-project/research-lab #70

please define "a reasonable increase in price" :-)