needmoney90: I think Sybil resistance on the network layer is important regardless

there are things like segmentation attacks, where your node is surrounded by Sybils who then feed you bad blocks or cut you off from the network

so it's not just about passive traffic analysis

is this not essentially an identity verification issue though?

hi - the MRL meeting today is at 17h UTC correct?

.time

.time

Hey - anybody around today?

I can still share some updates

Someone just pointed out that I had a small typo on page 3 of the atomic swap paper, I wrote y2 = x3+ b x+ a instead of y2 = x3+ a x+ b

(inverted a and b)

I'

*I'll correct that

and for the atomic swap project: we started working on it this week, we'll post some updates on Reddit in the next days

We also settled on a name for the project: Farcaster. We think it's a cool name and we hope you also like it!

You can find the latest info on #monero-swap and the farcaster-project github organization (we just started the RFCs, draft state)

Thanks for the update!

farcaster. Cool!

thanks

Oh, and we are super excited about the project!!!

\o/

.timie

.time

Oops

argh daylight savings

bamboozled yet agani

s/ni/in

Welp, I'll just drop notes here anyways

Jotted down some notes about a generalized framework for tracking and analyzing fungibility defects.

Over the past few years, n3ptune and I have identified and discussed a variety of defects in an ad hoc manner, and only handwaved around how they can be used for blockchain analysis.

For example, non-core use of tx_extra, non-core fees, juvenile spending, 1OTXs, incorrect decoy selection algorithms, unlock times, ring size, etc (several of which have been fixed already)

This paper describes how each of those can be cast into the same framework simply by defining B_f(t) for boolean defects, and V_f(t) for valued defects

cool, what is the fraction of txs that present fingerprinting traits?

Nice to see this all written out Isthmus.

Do you have a formulation for particular spend age behaviour? For example all tx's that consume outputs aged for exactly n blocks.

@zkao varies for each defect. Off the top of my head, the tx_extra defects each have a 5%-20% impact, fees are about 1% with a generous matching function but probably more like 3%-5% if somebody sat down for a week or two to write a more sensitive detector. Decoy selection issues on about 5% of ftransactions

I'll try to get some stats and plots in that paper

Yea @TheCharlatan two actually

B_juv(t) detects spends that occur too early (note, this has been fixed at the protocol level)

Oh, three actually

Juvenile spending (fixed)

Cached ring members (which is an atrocious edge case)

And then transactions that used an egregiously-wrong decoy selection algorithm

I was rather thinking of B_{algo}(t) without the max, but instead some round values.

Or would that catch a constant recurrent payment as well?

Not sure, can you elaborate?

You'd expect the output spend age to follow the distribution, but there might be specific singular outliers, or "popular" discreet spend age values.

Ohhh that's interesting

B_algo(t) as formulated would not capture that, but I think we could build a detector for that

Hmm, there was a phase where monero used a triangle distribution for decoy selection, right?

B_tri(t) would be interesting, to identify wallets that specifically never upgraded that component

awesome, thanks for the details, Isthmus

Isthmus: What does 'cached ring members' entail?

I can't remember if this was during the era of 7 ring members or 11 ring members, I'll just use 11 for the example

There was an exchange that cached 10 ring members, and with each outgoing transaction they would just drop in the 11th ring member and sign the transaction

This means that the same set of 10 outputs showed up in > 1000 transactions

Also makes it blatantly obvious which is the true spend...

Anything that fails B_cache(t) will also fail B_algo(t) since the ring members were very old

Well, I suppose the first 1 - 10 transactions with B_cache(t) might have been plausible with respect to B_algo(t) but within (span of the "recent zone" ~ 2 days) they would start failing B_algo(n)

erm (t)

Ah, I vaguely remember that

So basically 10 decoys were fixed, and then the real spent was added?

Yep

Interesting

Wow. What evil people...

They must have gone though quite some work to do that.

I wonder if they just handed the code to an engineer and said "speed up transaction generation" and failed to take into account the privacy implications

OK, I was thinking it was too much work to be just stupidity, but your suggestion is quite plausible.

that shell script was gorgeous, and so was the cronjob