Meeting 2hr

meeting time monero-project/meta #743

1. greetings

hello

hi

Hello

Hi

Hi

Hello

hello

2. updates, what's everyone working on?

Hi

me: PR for background sync mode is incoming right after this meeting, then going to do some stress testing on monerod + @rbrunner's pool PR 8076, then jump into Seraphis

hyc completed his review of my OSPEAD estimator proposal. isthmus gave me partial feedback. So far, no major changes.

me: finished planned unit testing for balance recovery in a legacy-seraphis transition, wrote a serialization proof-of-concept for seraphis txs github.com/UkoeHB/monero/blob/serap…it_tests/seraphis_serialization.cpp , started working on supporting legacy inputs to seraphis multisig txs (right now working on multisig key image recovery for legacy enotes, which could probably be PRd to master at

some point)

I'm working on my understanding of wallet2 and simplewallet and trying to create some logical reasoning of what is going on there.

^ nice. that's some srsly messy code.

One more person understanding wallet2 is certainly a plus ...

:p

3. discussion

I have been working on fess and following the ZCash attack. There are some changes that can be implemented as part of comprehensive fee and scaling updates.

I am moving back to OSPEAD

By the way the ZCash attack is continuing

btw, in case anyone missed it libera.monerologs.net/monero-dev/20221016#c151626 we can probably fit 2-3 more people without it getting too out of hand (7 devs + sgp attending right now)

Thanks for stepping up to schedule this :)

as an aside: it appears the zcash attackers may have followed our discussions of the attack and improved their methods as a result

Hmmm ... Isn't the idea "Just keep attacking" a bit trivial to come up with, even without our help?

UkoeHB: Really nice from you :)

sgp yep, somehow the seraphis lib got pretty big lol

Yeah, such things happen :)

rbrunner: one would think so, but then why didn't they just do that from the very beginning?

It may be the case but I have been discussing this kind of attack for over three years

hyc: Good question

ArticMine[m]: any news about zcash planning mitigations?

Maybe they just want to get Zcash improved with a non-brain-dead fee model, and when they saw that intermittent attacks do not yet inspire enough sense of urgence, they stepped up the attacks

anyway sure it may all be coincidence, but the fact that their observed behavior changed within a couple days of our discussion seems to point that way

They want to stop wallets allowing this stuff but only enforce it on protocol level "later"

I have not been following that. There is very little in the news

The observed behaviour chand around October 10th

Changed

UkoeHB: Yes. They have a ZIP to alter fees. They are going to change the block template RPC to give low-fee txs a lower probability of being added to a block (strange to me) to avoid forcing all wallet users to upgrade

in any case, it's a good reminder that just because an attack vector isn't being exploited right now, it always can be

Rucknium[m]: do they need a wallet upgrade to handle dynamic fees?

In my view they have a host of problems with their fee structure going back to Bitcoin. I simply do not know where to start

Shhh, don't tell too much, they should take you as a highly paid consultant :)

;)

(My understanding of the Monero fee-blocksize relationship is incomplete) Are we sure that the Monero mining infrastructure (pool software, p2pool) will raise block size when fees spike suddenly? Have we seen it in the wild, in the current hardfork era?

I think you have the causal relation backwards

but yes we've seen the dynamic blocksize adjust as designed

We saw the proper behaviour just before the HF

UkoeHB: I am not 100% sure, but I would bet that many "third party" wallets have hard-coded the min fee per tx (of any size), which is one zat IIRC

Also back in 2017

Rucknium[m]: the block size constraints change automatically based on past block sizes; block sizes are pushed up if fees exceed the block reward penalty (and there are enough txs to exceed the median block size constraint)

Ok. Don't XMR miners have to "decide" to forgo some of the 0.6 XMR block reward to add the excess-size txs? It's not completely automatic, right?

The kind of massive super low fe tx would not get past node relay

Do starters

Fot

Rucknium[m] p2pool goes above block size limit if there are enough transactions

... and the proper fee is paid

even if it's the lowest fee level, it can go up to 300k + 1000 bytes or so

as I've seen in practice

Then the scaling begins with the rate depending on the fee paid

On this topic, I'd like to recapitulate my idea for upgrading how wallets select fees. Basically, wallets should estimate the confirmation delay for different incremental fee/weight ratios and present them to users in form fee/weight * tx weight (e.g. fee 0.002 = delay 5 blocks, fee 0.01 = delay 0 blocks), then users select which fee they want to pay.

sech1: But you had to program this yourself after all, a dumb version of p2pool would not take part in pushing up the blocksize, if I understand correctly?

no, any sane tx selection algorithm will push above block limit

it will keep adding transactions as long as additional fee overweights the penalty

and start from best fee/byte transactions

Yes, that "tx selection algorithm" is inside your own code, and you could have built a very primitive version with hardcoded blocksize?

why hardcode blocksize? monerod tells it

p2pool does have the limit though

it's 1000 tx per block currently

I try to get a grasp on Rucknium's question: "It's not completely automatic, right?" Seems to me indeed it isn't all automatic.

rbrunner: This is the point I was making. Anyway, not a huge concern for spamming since a miner hardcode would limit chain bloat. But would also possibly frustrate users trying to get their txs confirmed

It is a very serious concern for scaling

Rucknium[m]: yes there is a block reward penalty when you exceed the median block size, which increases non-linearly as you go farther into the penalty zone; you only add a tx into the penalty zone if the new tx exceeds the penalty and removing any other other tx from the block won't improve the block reward

If this is true

If different miners all have their own logic how they fill txs into blocks, and how many, *in theory* block growth could fail because of too-stupid such algorithms.

A mining pool can refuse to increase the blocksize but they would loose money doing this

This particular mechanism requires rational behavior on the part of miners. But maybe it was rational to take a coding shortcut :/ . Just raising the issue. Probably it is OK.

in general, miners don't do any selection themselves. they let monerod select for them.

ArticMine[m]: if enough pools do it, they could force a fee market to arise which would increase rewards

Ah yes, there is a call for that after all.

There is already a fee market

UkoeHB: You mean the Bitcoin scenario

Well, a fee market with fixed supply (i.e. if miners cap block size at the median

UkoeHB: Very good point. In the future it could be a nice idea to examine the incentives of miners to check whether they align with what was intended. There are various papers about PoW miners subverting the intention, even for fixed-blocksize chains

We need to understand first if this is happening and where. It is a very valid point

a competing pool could easily break that cartel by offering higher block rewards to miners though

er miner shares I guess

... and the hashers would move there

This sounds a lot like an economics question :)

Industrial Organization, even.

It does

ArticMine[m]: yeah, and the supply of hash power might increase which would increase the marginal cost and might push the cartel miners into unprofitability (even though block rewards are nominally higher)

I think I found the RPC version: COMMAND_RPC_GETBLOCKTEMPLATE

yes

there is probably a certain percentage of tx volume that a cartel could block without the cartel being broken, but it's probably pretty small since switching pools is fairly simple for miners

Speaking of economics, last year Zcash hired some economists to develop their fee model for Zcash Shielded Assets, which do not exist yet. They didn't think to hire them to look at the fee model of ZEC itself

lol

If renting hashpower somehow somewhere is cheaper than the income you get from blackmailing tx submitters into high fees by artificially small blocks, you win :)

Few miners switched when minexmr raised their fee though

Needs pretty serious hashpower to work however ...

an example of 'small enough'

It would be a money loosing proposition for the cartel except if the bigger blocks increased by orphan rate

There was a paper way back by Peter Rizun on this

He is a BCH community member

anyway we are closing in on the end of the meeting, any last-minute questions/topics?

So there is an edge case where this can make senses

I will put this on the open research questions list.

I will look for it

ok seems like we are done, thanks for attending everyone

Thanks for

Hosting