Huh I didn't expect it to `/me` all 3 lines

Unrelated... (I can't remember if I've asked this before) // Suppose we look at each output and ask "_how many times has this been referenced in a ring signature?_" ... how many times do you think the most-referenced output has been referenced?

We can answer this question from the NRL database, but wanted to give people a chance to place their bets before we spoil the answer :- P

Oooh, I was actually wondering about this a while back...

Most-referenced output? Either it's a weirdly high outlier (like 100+), or a pretty low number. I say 10

8

Anybody else? I'll wait for ~12h so people on the other side of the globe get a chance to guess :)

~10000

42

287

~10000

500

~10001

~10002

69

80085

Meeting in 2hrs 13mins ( monero-project/meta #632 ).

21

rbrunner: You doing alright today?

Yeah, why?

30

Just being polite.

:)

meeting time ( monero-project/meta #632 )

1. greetings

Hello.

hello; this week is a holiday in the states, so attendance may be lower

Hi

hello :)

Salutations

Hi

2. let's start with updates

Submitted the view tag PR (monero-project/monero #8061), and have since been investigating multithreaded performance in the wallet to try to realize its maximal performance gain and to potentially help continue the discussion in that PR on which hash algo to use. I've found some more optimization tweaks, some of which seem to potentially be low hanging fruit that have nothing to do with view tags and can

make it into the next point release

Hoping to finish that investigation up today, then moving back over to decoy selection work

I was reading through Document A as written by Rucknium about statistical attacks. Would like to know has anyone here ever come up with a Monero data sample with known inputs on which a statistical attack would be performed?

Meant to say could be performed.

me: I updated the Seraphis paper with an efficiency section (and other miscellaneous improvements) github.com/UkoeHB/Seraphis . I also investigated the limits of BP+ batching, which is significant for Seraphis-Squashed since inputs require range proofs. I basically found that an aggregate proof with many range proofs (e.g. a BP+ for a tx with many inputs/outputs) doesn't benefit much from batching with aggregate

proofs that have few range proofs (but benefits a lot from batching with proofs of similar size). In practice... 1) txs added to the txpool are singularly-validated (although they could be batch-verified if tx volume were high enough, e.g. high enough to batch-verify every 5 seconds), 2) new blocks are validated on a block-wise basis (any more than that would be pointless), 3) synching an old chain can benefit from

cross-block batching (e.g. cache 100 blocks worth of range proofs before validating them) which would have significant benefits. The (1) case is the main performance bottleneck since it determines whether a machine can or can't participate in solo mining competitively (there is an optimization problem: tx flow rate vs batching vs CPU power in the worst-case of maximally-sized txs). Also, since (3) can be faster than

(1), a machine that can do (1) can always 'catch up' with (3) to the main chain (although if the rate difference isn't one or two orders of magnitude, then it might take a year+... in which case maybe (3) is the true bottleneck).

My BP+ investigation did not find any disadvantages to Seraphis-Squashed, just complications for analyzing the upper bound of tx throughput.

one-horse-wagon[: not that I am aware of

3. discussion; anything anyone wants to say/discuss?

It would be nice to make progress on Seraphis address schemes: monero-project/research-lab #92. Has anyone had any new thoughts about that?

Perhaps it can also be a subject in the upcoming dev meeting

Sounds like a good idea

We also need to discuss requirements to get the multisig PR merged, in that meeting.

If no one has anything else to say, we can wrap things up. I'll give it a few more minutes.

I don't see how we can get the sample as you say one-horse-wagon

Unless we copy BTC spend data (shaky ground to begin with) and then implement that in a ring sig simulation

I think Isthmus is looking at some efficient data structure to follow ring sigs through the chain

UkoeHB: question on BP+ optimization investigation, sounds like that benefit of cross-block batched verifying could be realized in the next HF introducing BP+?

But any simulation would have to account for the changing decoy selection algorithm over time

jberman[m]: I think only in-block batch verification is used right now.

Correct.

I don't think I have a PoC for inter block batching. I do have one for txpool batching though (which was rejected for adding latency).

carrington[m]: That would complicate coming up with decent sample. If you assume no one is interested in the past but only the present (which then turns into the future), you would not need to consider past changes in the algorithm.

The big problem I see is making sure the sample is not skewed in some manner.

Taking BTC spend distributions and sticking them into XMR is a big assumption. I don't see how else it would be done though.

I'm a little confused, why invent a dataset whole cloth instead of, Idk, using the real blockchain data, then assuming certain inputs are 'known' ?

I guess they have to actually be known nm picking wrong ones would skew things

<UkoeHB> "proofs that have few range..." <- "High enough to batch verify every 5 seconds" does this correspond to some volume of common-sized transactions?

I'm reading what you said as "for batch verifying to be worth it the volume has to be high enough to batch verify every seconds" which I'm not understanding

I guess it would be 'volume high enough that if you don't batch verify then there is a noticeable perf hit on mining'. Right now there is a lot of down-time between verifying each new tx.

OK that makes more sense to me, thank you

So we would ideally want mempool batch verification to automagically kick in at some calculated volume. Batch verification across blocks would benefit all synchronization of post-BP+ blocks and so it is worth doing for an upcoming release (not necessarily a network upgrade)

^ is this correct?

Sounds right

You can also batch-verify BP blocks.

But not BP & BP+ together.

Hey sorry I'm late, between phone calls

So there could be an upgrade to wallets in the future which would speed up the verification of the whole BP "epoch". Any sort of percentage speedup estimate?

On the other hand, there are diminishing returns to batch-verification. If blocks are really big, you may not gain much from batching. The main benefits are batching of 'rare' large-aggregate proofs.

carrington[m]: I doubt it would be better than 5-10% overall.

Sorry to interrupt, have a few quick updates, but I need to bounce in a minute

@LyzaL you were the closest guess! These 6 cached outputs have been referenced in 65,000 ring signatures

(Brace yourself, these transactions are painful to look at... That's 65k ring sigs with effective ring size = 1...)

... and it's always the same 6 cached decoys in all 65k of them

Also, officially submitted our flood analysis for SBC 22 conference last night :)

Fingers crossed the organizers are enticed 🤞

There's actually > 100k rings with similar issues and consequently effective ring size = 1 but that cluster is the most dramatic

isthmus: ooooooooof size 100

h/t @Neptune for surfacing the answer from our DB

isthmus: interesting... is this Hyrum's law (learned it recently)?

oh nice :D

Maybe "new block" batch verification would be worth it for re-orgs?

<isthmus> "there's actually > 100k rings with similar issues..." 100k out of how many?

might be worth investigating... just requires some dev hours lol (maybe a lot of hours)

there was an exchange that sent withdrawals with the same 6 ring members and the customers

= 7

gross

was happening in mid 2018, not sure how much before and after that

Anyway, I think we can call the meeting. Thanks for attending everyone.

perhaps those outputs should be ignored when crafting txs?

blacklisting outputs from ring signature construction in the official wallet sets a weird precedent I feel like

they are super old and will be selected very rarely now, no?

And are probably detected by the blackball tool, which is used by pretty much 0% of monero users.

I used the blackball tool once