08:05:05 <fluffypony> needmoney90: I think Sybil resistance on the network layer is important regardless
08:05:42 <fluffypony> 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
08:05:53 <fluffypony> so it's not just about passive traffic analysis
08:19:05 <midipoet> is this not essentially an identity verification issue though?
08:52:30 <h4sh3d[m]> hi - the MRL meeting today is at 17h UTC correct?
15:22:15 <zkao> .time
15:22:16 <monerobux> 2020-11-11 - 15:22:15
17:05:05 <h4sh3d[m]> .time
17:05:05 <monerobux> 2020-11-11 - 17:05:05
17:05:43 <h4sh3d[m]> Hey - anybody around today?
17:12:03 <h4sh3d[m]> I can still share some updates
17:13:31 <h4sh3d[m]> 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
17:13:40 <h4sh3d[m]> (inverted a and b)
17:13:42 <h4sh3d[m]> I'
17:13:59 <h4sh3d[m]> *I'll correct that
17:14:51 <h4sh3d[m]> and for the atomic swap project: we started working on it this week, we'll post some updates on Reddit in the next days
17:15:17 <h4sh3d[m]> We also settled on a name for the project: Farcaster. We think it's a cool name and we hope you also like it!
17:16:51 <h4sh3d[m]> You can find the latest info on #monero-swap and the farcaster-project github organization (we just started the RFCs, draft state)
17:17:38 <dEBRUYNE> Thanks for the update!
17:17:45 <donkeydonkey[m]> farcaster. Cool!
17:17:52 <donkeydonkey[m]> thanks
17:18:43 <h4sh3d[m]> Oh, and we are super excited about the project!!!
17:18:58 <h4sh3d[m]> \o/
18:01:40 <Isthmus> .timie
18:01:45 <Isthmus> .time
18:01:45 <monerobux> 2020-11-11 - 18:01:45
18:01:47 <Isthmus> Oops
18:01:53 <Isthmus> argh daylight savings
18:01:59 <Isthmus> bamboozled yet agani
18:02:04 <Isthmus> s/ni/in
18:02:05 <monerobux> Isthmus meant to say: bamboozled yet again
18:02:19 <Isthmus> Welp, I'll just drop notes here anyways
18:02:27 <Isthmus> Jotted down some notes about a generalized framework for tracking and analyzing fungibility defects.
18:02:27 <Isthmus> https://www.overleaf.com/read/bxbpmwxgskjw
18:02:28 <Isthmus> 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.
18:02:28 <Isthmus> 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)
18:02:28 <Isthmus> 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
18:12:42 <zkao> cool, what is the fraction of txs that present fingerprinting traits?
18:12:47 <TheCharlatan> Nice to see this all written out Isthmus.
18:14:40 <TheCharlatan> Do you have a formulation for particular spend age behaviour? For example all tx's that consume outputs aged for exactly n blocks.
18:17:11 <Isthmus> @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
18:17:19 <Isthmus> I'll try to get some stats and plots in that paper
18:17:43 <Isthmus> Yea @TheCharlatan two actually
18:18:06 <Isthmus> B_juv(t) detects spends that occur too early (note, this has been fixed at the protocol level)
18:18:46 <Isthmus> https://usercontent.irccloud-cdn.com/file/9e5d823U/image.png
18:18:48 <Isthmus> Oh, three actually
18:18:55 <Isthmus> Juvenile spending (fixed)
18:19:01 <Isthmus> Cached ring members (which is an atrocious edge case)
18:19:22 <Isthmus> And then transactions that used an egregiously-wrong decoy selection algorithm
18:21:16 <TheCharlatan> I was rather thinking of B_{algo}(t) without the max, but instead some round values.
18:21:55 <TheCharlatan> Or would that catch a constant recurrent payment as well?
18:22:05 <Isthmus> Not sure, can you elaborate?
18:24:21 <TheCharlatan> You'd expect the output spend age to follow the distribution, but there might be specific singular outliers, or "popular" discreet spend age values.
18:25:26 <Isthmus> Ohhh that's interesting
18:25:47 <Isthmus> B_algo(t) as formulated would not capture that, but I think we could build a detector for that
18:26:53 <Isthmus> Hmm, there was a phase where monero used a triangle distribution for decoy selection, right?
18:27:08 <Isthmus> B_tri(t) would be interesting, to identify wallets that specifically never upgraded that component
18:27:40 <zkao> awesome, thanks for the details, Isthmus
18:32:38 <dEBRUYNE> Isthmus: What does 'cached ring members' entail?
18:34:51 <Isthmus> 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
18:34:51 <Isthmus> 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
18:34:51 <Isthmus> This means that the same set of 10 outputs showed up in > 1000 transactions
18:34:51 <Isthmus> Also makes it blatantly obvious which is the true spend...
18:36:23 <Isthmus> Anything that fails B_cache(t) will also fail B_algo(t) since the ring members were very old
18:37:02 <Isthmus> 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)
18:37:07 <Isthmus> erm (t)
18:37:48 <dEBRUYNE> Ah, I vaguely remember that
18:37:58 <dEBRUYNE> So basically 10 decoys were fixed, and then the real spent was added?
18:39:29 <Isthmus> Yep
18:39:53 <dEBRUYNE> Interesting
18:40:43 <moneromooo> Wow. What evil people...
18:41:07 <moneromooo> They must have gone though quite some work to do that.
18:41:43 <Isthmus> 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
18:42:59 <moneromooo> OK, I was thinking it was too much work to be just stupidity, but your suggestion is quite plausible.
19:08:06 <zkao> that shell script was gorgeous, and so was the cronjob