In theory, when constructing a tx, a wallet could also include the entire contents of each ring member's associated tx, and a pruned node could theoretically verify this tx only using stored tx hashes from across the chain and key images that it has previously verified? Not that this is necessarily a good idea, but just curious

a pruned node has to store all outputs, so it just needs to verify all outputs referenced by a tx are in their partial ledger

adding in the tx hash of referenced outputs doesn't add much afaik

When you say outputs you mean output ID's, pub keys, and commitments?

yes

Ah and unlock times. Got it. The thing the hash idea would save is just needing to store the stuff that is included as part of the tx hash

MRL Meeting at 17 UTC today here. Agenda: monero-project/meta #657

meeting 0.5hrs

meeting time: monero-project/meta #657

1. greetings

hello

Hi

hi

Hi there

hi

hello

Hi

Salutations

Buenos

días.

Today we should focus on fee changes for the upcoming hardfork (and also look into the future). I summarized two concerns here: monero-project/research-lab #70#issuecomment-1024964432

It sounds like ArticMine agreed to reduce the long term scaling factor from 1.4x -> 2x to 1.4x -> 1.7x (this is maximum growth over 69 days).

Yes that is correct monero-project/research-lab #70#issuecomment-1025334284

reduce the upcoming change*

sgp value of 1.7 as a compromise

Then we can find consensus for the subsequent HF

Yes I think that is fine.

Overall I think 1.7 is a decent compromise for the growth rate, but I think the sanity check hardcap on blocksize should be lowered to something with a basis in reality (like jberman calculated)

Also fees should be higher in general

<carrington[m]> Overall I think 1.7 is a decent compromise for the growth rate, but I think the sanity check hardcap on blocksize should be lowered to something with a basis in reality (like jberman calculated) <--- there are ways of dealing with this without hard coding obsolescence into consensus

ArticMine: what is your response to the stability concern I raised?

There are many way to deal with this including effectivly pricing the upload bandwidth of nodes. This doe not require consensus

There is a point at which you can't retroactively solve for a chain that has grown too large to verify and sync on commodity hardware, that imo is the only way to lead to obsolescence

Do we still lack an estimate for the cost of a deliberate maximal blockchain-bloating spam incident?

Yeah long term nodes "catching up" wouldn't be a problem if we had some kind of disposable history, but for now considering there is already a hardcoded sanity check I think tweaking it isn't a permanent problem

yes it is lacking (I could do it, but I am busy with seraphis... any takers?)

I can take it on if there are no other takers, seems to be priority #1 for the fork at this point + I'm looking deeper into the fee changes at this point now anyway

Spam costing is something I am prepared to do but not in a rust before the next HF

This is the point of the compromise

ArticMine: yes, there are ways to improve the performance of nodes. However, those methods aren't a 'solution', they are only a 'bandaid' to the basic problem. The basic problem is unbounded block size growth _cannot_ be supported by casual users (at some point only server centers can handle the load).

What do you mean by "pricing the upload speed of nodes"?

Prioritizing transactions for relay based upon the fee

Aka fee market?

while keeping the number of broadcast nodes constant

For low bandwidth nodes this effectivly created a fee market

What does a low bandwidth node do if it gets a huge valid block from a mining pool?

It just falls behind and oh well?

Keep in mind that many internet connections can ahve a 30x difference in upload and download bandwith

and a Monero node needs easily 12x as more upload than download bandwith

Bandwidth isn't the issue in my calculations: monero-project/research-lab #70#issuecomment-1027806393

even if you assume 0 cost bandwidth (aka infinite mb/s upload and download), the time to verify + storage requirements to run a pruned node that verifies the chain would eventually get too large

^ I have serious doubts with that. Batch verification is something that can be run in parallel

time for blocks to propogate increases orhphans no? 5-10 sec block upload time seems not great even if other hardware reqs are there - how long does it take a block to fully propogate in that situation?

I think verification is the issue more than bandwidth?

ArticMine: this is as much a theoretical problem as it is a numerical one.

the time to verify is divided by 8, the number of threads on my machine. parallelism is accounted for

There mare solutioon here that de not involve hard caps

I can review jberman 's work and/or work with him on spam cost estimation.

LyzaL: that's a good point, since dandelion++ increases propagation time

I just do not see the argument to run verification on a single thread if there are many txs

I wonder how high we would like to see fees for extreme scenarious to feel save. Even with 10s of thousands of USD you could still fear a dedicated enemy with deep pockets.

If the orphan rate increase then mines will require higher fee. There is exisitng reserach on the fpor Bitcoin / Bitcoin cash

the numbers don't assume verification is running on a single thread

^ It is critcal to clarifit this

clarify

On one hand, solutions against a big bang attack in issue 70 already depend on the ability of the community to react within the timeframe of the long term window

UkoeHB was very clear in the simulation on this

it is only critical when you are defining a hard-coded number... it is irrelevant for my theoretical objections which are being ignored

orphan rates would increase as a consequence of larger blocks

So in some sense we are choosing between baking in obsolescence and baking in centralized upgrades

what do you mean react? iirc those comments did not factor into ArticMine and my analyses

Isn't "obsolence" a bit hard for a hard upper limit on the number of transaction?

personally I favor a conservative growth rate, having a fee market for a few months during a period of big growth isn't the end of the world, but mass centralization is

rbrunner: my opinion is that spam attacks should cost the same as 51% attacks for equivalent security guarantees

also L2 seems possible at some point

It is not. Bitcoin is a prime example

Bandwith has increased 200x in the Bitcoin gensis block

while people keep up the debate on the blocksize

So why not have limits that go up more or less together with technology improving?

Bitcoin does not have huge expensive blocks...

I posted on the orginat BCT thread that was started in 2010 on increasing the blocksize

<rbrunner> So why not have limits that go up more or less together with technology improving? <--- Bingo That is what I want to work on for the next HF

Which is why 1.7 is a reasonable compromise

For my comment about "reacting" look at Artic's comments in 70 about "recent network attacks"

to my eyes even 1.4 looks like a massive growth rate

Over nthe long term yes over a 2 - 5 month period no

If we are relying on the fact that we can adapt and react and change the protocol in the event of unforeseen circumstances, why not err on the side of keeping it at the more conservative growth rate it is at now and react in the direction of allowing for more growth, on the chance that we do not find agreement and the long term gets away from us?

Because maybe that feels a little like defeat :)

Because one can control growth in many ways

if there is an issue

More a psychological than a technical problem ...

^ I agree and Bitcoin is the prime example

makes sense to me jberman , a conservative growth rate is nothing like locking things at fixed caps for a decade

We have a compromise. I am not going back to ask for 2 but I will not support less that 1.7 1.7 has been on the table for over a year

This is the critical psycological promlem

Perhaps a dumb question: why does the growth have to be exponential? Why not linear?

or logarithmic

pretty sure adoption change is proportional to existing adoption

in the intial stages yes

"will not support less that 1.7" How could that look in the light of a possible result of surprisingly low costs - still, after fee rising - for spam attacks?

Just hypothetically, we don't know yet after all

becasue this has been hased to death

I think it is a good idea to read a few messages in the thread of the first suggestion to increase the bitcoin block size.

"If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow."

merope: That's sort of my thinking as well. The functional forms that are being chosen are sort of forcing us into a space that maybe we don't want to be. But if we changed the functional forms, then we would have to re-work many things.

My views in that thread are still valid

It is the reason I gave up on Bitcoin in 2015

and the rest is history

Yeah, but come on, even with 1.1 instead of 1.7 or whatever we are much better than Bitcoin. Is that even a fair comparison?

Yes it is

look at the hisotory of Bitcoin

history

1.7 was on the tale for a year

table

It is not a fair comparison, especially seeing as Monero is in general still being upgraded regularly

So is Bitcoin

I feel you, but how can this help us now to come to a "loose consensus" and go forward with the HF?

I though we had consisus at 1.7 untill this morning

We seem to sit at something like a stalemate now, if you want to be brutally honest

Don't we have to do 2 hard forks anyway? Maybe better be conservative for this one and in case increase in the next one? Does that make sense?

No

Well, 7 hours ago jberman found out even 1.4 can go to 4.5 TB per year, worst case ...

i mean the second hard for for seraphis

There was critical work that was done over a two year period

but if it doesn't makes sense it'll just shut up 🙂

ErCiccione: seraphis may be 3 hardforks in the future, if it takes long enough. The next hardfork after this one is likely to be very small (if we have one).

ArticMine: it might help if you publish your numerical research for us to examine. Your presentation of 'we need 2x' was only backed up by a couple paragraphs.

I am not convicend it will do any help

I o zero response to my comments on 70 untill the very las minute

'las

last

Take a look at the date of the post on issue 70

There was ample time to ask questions etc

The maximally bloated scenario is unlikely IMO because of the way the penalty works. A "medium speed" growth rate will probably provide more useful numbers for a given "maximum annual growth"

ok sure, but we are talking about it now... better late than never

In order to kii the entire proposal

I don't personally have a big stake in the number chosen, but it would be nice from an engineering PoV to understand the argument with more precision. Right now there feels a lot of vagueness

Seems to me that's almost a given, because you can easily work with quite different assumptions about growth, behaviour of market, of miners, of users ...

Which then may lead to a different "best" growth rate

One can argue against any number by taking edge cases

Realistically, if we go now with 1.7 and something bad comes upon us, we can probably emergency-HF in a month or even less. With this in sight, we should not allow a stalemate ruin our nice HF. IMHO.

I would go with 1.7, we will still have enough time to do further research on fees in the future

^ I agree

This is the point of the compromise

Ok

also mooo already updated to PR so we have to go with it now :D

lol

lol

Best argument today :)

^ Convinced

Solid engineering

lol

So maybe this time it's not our famous "loose consensus" but only a very loose one, but the comprimise can go through - barely?

If we are at "roughly consensus" on the 1.7 number, does anyone have any insight into this concern of mine:

 do we know for sure that miner implementations are actually set up to behave "rationally" once we are in the dynamic blocksize regime? i.e. does software like XMRig account for the penalty that will be applied correctly and allow itself to build blocks larger than 300kb under optimal fee environments, or does it naively just keep adding highest-fee transactions beyond the 300kb limit? It seems to me that if the mining

software is not set up to actually figure this stuff out, the whole dynamic blocksize system will not kick in smoothly.

The dynamic blocksize has kied in before

kicked in

after the RingCT fork in 2017

Don't know, can't imagine miners would put up with this for longtime before they revolt

xmrig doesn't have to care about this.

Ok we are at the end of the meeting. There seems general consensus to allow 1.7 into the fork. I hope/expect by summer there is a stronger and more precise understanding about scaling, stability, and spam costs around block sizes and block growth. This way we can have compelling arguments about scaling factors and the presence/absence of a hard upper limit.

Xmrig does not know anything about transactions nor fees, only hashing block templates

Well spoken, UkoeHB.

Fees and txes are the responsibility of nodes (or whoever generates the block template to be mined)

OK I guess I mean pool operators (or whatever algorithms they use)

thanks for attending everyone

Thanks

+1

carrington[m]: I think if there is a bug, it would get fixed realll fast when miners notice their profit margin fall.

bug or failure to take the dynamic size into account*

I suppose if that's the worst case scenario it is not something to worry about. Unless miners are taken offline in huge numbers while they patch their transaction selection algoritms

It's not the miners that would have to do the patching, but pool ops

And it wouldn't take very long (individually)

but pool would be offline I guess? And miners would still stop mining?

Also, I'm pretty sure the pool software (as well as monerod?) already take penalties into account when generating the block template

merope: ^

If that is the case then all is well

The average blocksize went over 300000 bytes in 2017 and over the 60000 byte limit in early 2017

UkoeHB: do you think we've sufficiently explored the curve25519 idea for view tags aka does it seem ready to you?

tevador's results suggest we need to record the tx pubkey (output/enote pubkey) as a curve25519 point. I'm leaning toward pushing that kind of thing to Seraphis, and leaving your PR as-is.

Adding curve25519 as a dependency for the upcoming hardfork is a big ask I think.

Seems reasonable to me. knaccc might have thoughts there, think they will be happy to know it's looking like it'll be part of a future upgrade

yeah it does look like a big ask for the small performance gain

it also may affect our ability to use txpubkeys in clever ways in the future, outside of the output pubkey ecdh

so an active imagination would be required to determine if it could be useful to have ed25519 txpubkeys

we do have another clever use in jamtis, but it relies on another ecdh exchange

so there is no penalty from curve25519

i remember thinking of schemes where it would be useful to reveal sG, where s is the tx private key

since sD is declared as the txpubkey, and since we know d, we can calculate d^-1 * sD to get sG

and then sG acts as a shared secret between sender and receiver

for which only the sender knows the private key

yep we use the secret `sG` (as you call it) in jamtis

oh nice

We bake it into the amount blinding factor and encoding factor, to add an extra permission tier to the wallet key structure.

So, with current subadresses, what information is needed to decode the amount recieved? And what information is needed to check that it matches the commitment?

Just the view key

Oh yeah, baking in `sG` also solves the Janus problem without any extra tx bytes.

UkoeHB: what, precisely, is XORed against the amount? And what is hashed into the blinding factor?

web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf check ch5

Thanks, I had misread something in there earlier. But a fresh read fixed it.