meeting 1.5hr

meeting time monero-project/meta #740

1. greetings

hello

hi

Hello

Hi

Hello.

Hi

2. updates, what's everyone working on?

Hello. I'm still going on through all the math equations in Seraphis and working on the audits framework.

s/on//

Modifying OpenSats to make a fundraising campaign system for MAGIC (despite not knowing web dev 😶): github.com/MAGICGrants/opensatswebsite . I am also happy to report that current MAGIC Monero Fund reserves are at 57,000 USD equivalent. That gives us a good buffer for grants so we don't get wiped out from a single grant. Thanks donors, whoever you are.

me: I got distracted learning about thread pools and concurrent program design for most of the last week (slightly related to monero at least, since I want to figure out the best way to do balance recovery in the background using the current seraphis balance recovery model). In the middle of unit testing balance recovery for the legacy-seraphis transition. Full-featured robust legacy balance recovery has a lot of

annoying edge cases...

Looking at the code I had a feeling it's possible you are more robust there than `wallet2` itself ...

I have been looking at the cost of the ZCash spam attack in Monero

Well a lot of the edge cases don't show up in practice, because real-world reorgs are pretty benign.

ArticMine: Is that ongoing, or do you have estimates already?

It is ongoing but I do have some estimates.

3. we can move to discussion

Hi! :)

ArticMine[m]: any you'd care to share, or want to hold off until you have a conclusion?

IMHO, a good medium-term goal would be to perform a scaling stress test on a private testnet. I don't think it has been done recently. If it had been done a year ago or more, it would have caught the integer truncation bug that jberman found by code inspection.

BCH did one recently: bitcoincashresearch.org/t/assessing…egories-of-bch-network-software/754

so we need an automated wallet to generate txns as fast as possible?

Yes. And/or spoof system time. xmrack has a tx spammer

jberman told me that he wants to do something at least in the general direction of that shortly

we would also need testnet nodes over some distantly connected networks. these tests are easy to boost on a single high end server

E.g. building up a very large mempool and see how management code will react to that, to find bottlenecks

This should then also be able to show that my PR #8076 is indeed an improvement and does not get victim of one of those bottlenecks - if they exist

xmrack 's stagenet spamming already found a small bug in RPC calls when the mempool was very large

I just have a gut feeling that good and realistic stress tests won't come cheap.

Those probably mean work :)

Ramping up the short term median to the equivalent of the ZCash max blocksize can be around 50-70 K USD . If the attack is stopped for more than 100 min then the median resets, and the spammer has to start again.

So the start and stop approach of the ZCash spammer gets very expensive.

This was the bug: monero-project/monero #8388

rbrunner: there's only a few dimensions of potential bottleneck. the main point is using realistic test hardware, and the time required to run a test

Wouldn't 4 or 5 decent computers, spread around the U.S. and Europe, running day and night for a month do a good stress test?

they can be load generators, sure. you also need some simulated users who can actually see the impact, e.g. if it slows down their UX

The ZCash approach is far from optimal to attack Monero.

I am more concerned with a maintenance attack where the short term median is maintained rather than grown. This is tricky because if the attack is stopping for over 100 min the median resets.

So I am looking at ways to further harden against a maintenance attack.

raises the question of why the zcash spammer pauses instead of running continuously

As far as I know the biggest impact of the Zcash attack is rendering some wallets pretty much non-functional because they are not up to the task to process those "monster" transactions

and not in the numbers they occur

I think blockchain bloat is not their main problem, by far

but whatever, assume someone attacking monero will know about the median time constraints

maybe the zcash guy needs to take breaks to rearrange funds

Very good point. There is no reason for the ZCash spammer to do this

... but it is a very strong defense for Monero

I have read as a short-time bandaid some wallets have stopped to even look at transactions with more than 20 or 50 outputs ...

hyc: Of course which is why I am looking at maintenance

rbrunner: Jup. Their most popular wallets use the official SDK though, which i think hasn't been updated yet

The 10 block lock also makes things more difficult for a spammer, but that's something that can be overcome.

Yes, where Zcash is more or less begging to get spammed, Monero already has several defenses in place, and altogether certainly does not look like an easy victim

monerobull[m]: In Monero the limit is 16 outputs except for coinbase

Of course we still should try to improve, no doubt

ArticMine[m]: Does that mean i could have coins i don't know about

Rucknium[m]: Doesn't the 10 block lock only apply to a single wallet? A spammer could use the network to tx many wallets, one right after the other, couldn't he?

but coinbase can have unlimited outputs, so a dedicated spammer can solo mine blocks with ~7700 outputs per block

and then use these outputs

one-horse-wagon[: You also need to fill those wallets first

300k / 39 ~ 7700 (one output is 39 bytes on average)

hmm, with the advent of p2pool it might be worthwhile for scanning to have an 'ignore coinbase' toggle

I think wallet2 has this? Not sure.

wallet2 already has this toggle

oh

set refresh-type = ...

in CLI wallet

Right, that was it

TIL

set refresh-type = no-coinbase

one-horse-wagon: Yes. No "too" difficult. But it bumps the difficulty up a bit for a weekend warrior hacker

A big percentage of Lightning went down this week to a 998/999 multisig transaction. Our multisig is limited to like 100, right?

monerobull[m]: 16, and it is all off-chain

<sech1> "300k / 39 ~ 7700 (one output is..." <- Interesting but then the spammer is not able to sustain the attack. So we are back to resetting the median

Would this fall under scriptless script?

I think you can get to 30-60 group members with FROST-style key gen (kayabaNerve ?)

As I saw with my TechWallet, if you constantly send transactions with many outputs to yourself, in a few hours you can rack up hundreds of outputs easily

monerobull: I think that was basically due to an outdated configuration on an "alternative" BTC node implementation. It wasn't a computational bottleneck. But it does once again point to risks with multiple node implementations.

But you will spend then all in a burst attack of sorts, and then it's back to square 1

was reported here decrypt.co/111642/enormous-multi-si…-crashes-bitcoins-lightning-network

ArticMine[m] why would the spammer be unable to sustain it? If he has enough hashrate to mine blocks, he can mine any size block containing only coinbase outputs, and use them for blocks that he doesn't mine.

actually, 0.6 XMR is enough only for ~3600 1in/2out transactions with current fees...

Escapethe3r, since you're reading this for your writeup anyways: the write-ups are great, keep em coming :) also agree with retiring TA reports in favor of other content

It comes down to the rate of tx generating vs percentage of total hashrate under the spammer's control

On can estimate this

my math was wrong, it's enough for ~19500 transactions

Per mined block

So a stockpiling attack?

what's that?

I can imagine an attacker mining a block and submitting 7.7k transactions to mempool right after that. And again and again

The attacker first builds up a supply of outputs

Then uses the stockpile to attack

oh btw, coinbase outputs are locked for 60 blocks

so if such attacks ever happens, there's 2 hours advance notice

Lol. Cutting it close :)

sech1: would be nice to remove that for seraphis monero-project/research-lab #104

sech1: Isn't this whole PoW thing an incentive mechanism to... Not do that

sech1: Emergency hardfork every time

This is a good reason to leave the coinbase lock time alone or even increase it

yes, solely because coinbase can have unlimited number of outputs

I don't the coinbase lock time helps at all with this

Also coinbase is not private. So good old censorship becomes a defense

All it does is shifting the attack 2 hours into the future *once*?

if the attacker is periodically making blocks, it doesn't matter whether their coinbase outputs are 10 blocks old or 1000 blocks old, either way once the setup period is over the rate they can spend outputs is the same

Not if you increase lock time to infinity 😅

true, so for this it is irrelevant. but a the lock time is a good defense against spending outputs that disappear due to a reorg

Yes there is advance notice of attack and which outputs are going to be used

Hmm, sure, but will this knowledge give you advantages as a defender?

if outputs are used in 1in/2out, it's hard to filter them out because of decoys

In any case the attacker has to build up an arsenal of outputs that are not private and is therefore a target for the defense

so no, scrap this

feels like this discussion is getting lost in the weeds

if anything, there should be a bonus weight on coinbase outputs to account for the network costs, if they are considered problematic

Yes

although that would work at cross-purposes to p2pool, a hard design balance

anyway, we are at the end of the hour I so I think we can close out the meeting; thanks for attending everyone

thanks UkoeHB for facilitating

saw this on reddit reddit.com/r/Monero/comments/y0rz1p…_activists_use_xmr_today_if_quantum

the latest updates to jamtis I expect to mitigate this to a great extent (perfect forward secrecy for enotes owned by any non-public address, and public addresses can't be linked together) gist.github.com/tevador/50160d160d2…ment_id=4289801#gistcomment-4289801