Maybe the math is perfect. Can a wallet be created that flags txs? The same as what the iOS xwallet tried to do.

How so?

lh1008[m]: You can leak info to a centralized server OR have the wallet generate a custom extra.

Even an irregularity in what looks to be a normal extra (bit patterns in the R key, single byte would have a 1/255 chance of appearing and therefore offer decent accuracy if your wallet made sure it occurred)

Or you can use an undefined field

If math can't be broken, you will have to break and link something else (code). Something inside a wallet that creates a bit of info that it's a flag to txs. Is that possible? Can the blockchain store something different from what it already stores?

If there's a flag then you just make a request.

Transactions can store arbitrary extra data

Default wallets will not do this

Default as in official monero wallets right?

Yes

There's a lot of discussion about removal of this capability altogether at the protocol level as well

I support such removal

Thank you sarang :)

sarang: Would be interesting, especially given outdated systems such as standard addresses/payment IDs. I would love to hear what you think the value offer is.

Because irregular points can be used as an ID, if you write the code to do so and know what pattern to look for. It'd be even stealthier than an extra field.

Though the removal of MinerGate's field would be pleasant.

if we just have "trusted nodes" make more transactions than the "info gathering" nodes, then we can skew the probabilities back in our favour. Essentially we need more Minko types

midipoet "trusted nodes"? In a trustless network? Just encourage everyone to use their own nodes.

sech1: yeah, maybe the phrasing is incorrect

if we know some nodes are just sitting there churning, for example

you could call them a seed node

nodes don't churn, users churn

right, so perhaps an algorithm that churns that is attached to a node. would that me a more apt description?

we can't know which node sent a transaction

we don't need to know

essentially if some adversary is creating outputs - lets say 10,000 a hour, to "pollute the anonymity set" and reduce the effectiveness of rings, if the network created an additional 500,000, this would mitigate this attack surface, no?

of course, we could try and do that with adoption...

and i know that is the preferred method for a number of reasons

and essentially if CipherTrace have a "known list of tainted outputs", this effects the "taint of rings" regardless. in the interview David kept saying it "historical analysis", and i assume that means known taints.

however. there is a very strong argument for "explicit algorithmic bias" here, due to the aggregation of outputs into rings. essentially the risk assessment techniques that CipherTrace are pushing create a situation where criminality is being passed through the network and the networks users, regardless of their degree of criminality. Also CipherTrace seem implicitly involved in this spread

midipoet: yes, but a restored wallet still has to scan through those outputs

even if it's created by "churn nodes" sitting and re-mixing 1 XMR over and over

awesome line of questioning from 45 mins on. that's the key to this. CipherTrace are explicitly raising the probability risk score in their involvement - especially if they are creating transactions. if they are creating transactions then they are explicitly complicit. i can't see it any other way

i would also argue there is a litigation case waiting to happen, if their explicit involvement led to a prosecution based on a false positive

good reading on similar issues: supremecourt.uk/docs/speech-191112.pdf

the above has specific mention to blockchain and risk

the thing about the above example and judicial note is that an AI algo is creating outcome bias - in the case of CipherTrace it is CipherTrace themselves.

more on this:

all this is coming from Law Researchers in my company btw - not just pulling it out of my arse

sarang, sgp_: Great work on the interview

I do think it would be worthwhile to add a short blog post to the website as well

Some people just want to read something briefly and don't want to spend time (or have time) to watch a lengthy interview

some people just read headlines, so we should make a sensational headline too

like "Ciphertrace were destroyed in the interview, they can't trace shit!"

we're above that! :-D

and then send it to all the "journalists" who published FUD yesterday

dsc_ ok we can omit "shit" from the headline :D

:)

"CipherTrace forgoe their own science and admit arbitrary risk scoring"

how is that?

oh wait

"CipherTrace forgoe their own pseudo-science and admit arbitrary risk scoring"

"CipherTrace forgoe their own pseudo-science and admit Arbitrary Risk Scoring (ARS)"

Arbitrary Risk Scoring Estimate (ARSE)

dEBRUYNE: I don't know if the blog post is a good idea. Right now it's just a glorified press release. if we answer to them, we give them more credits than they actually deserve. I would wait until more concrete details will come out

sech1: that's the one!

blog post would be worth it after the second interview with "the math guys"

yeah

ErCiccione[m]: The issue is that a lot of people currently use the headlines as a given

We need to debunk / refute / clarify that

"We have yet to see conclusive evidence of real-life tracing ability"-ish?

If you think a blog post is beneficial go for it. I think would be better to way for a more technical analysis. Unless the FUD spreads uncontrolled, in that case, yes, better make a clarification. Don't know if that's the case for now though.

i don't really feel like people are taking this seriously

e.g. sarang wrote "This may be a simple merge analysis, where the presence of multiple flagged outputs appear in multiple signatures for the same transaction. If so, this is an analysis technique known for quite some time."

so it's not FUD. it's "an analysis technique known for quite some time"

and no one is disputing that

do we want to fix the problem, or just try and spin it away?

how might it be fixed?

well one way that i have very high confidence in is showing people how to properly churn inputs independently before spending them

that destroys this "analysis technique known for quite some time"

two outputs known to belong to the same person that are later spent in the same transaction is a dead giveaway

maybe we should consider not letting wallets spend owner outputs together unless they have been churned

s/owner/owned

Luck has it that my wallet™© has output control

aha, yes, featherwallet is the answer :)

knaccc: But it also depends on what kind of information you have on the other end

knaccc: was worth a shot :-P

If you merely know to outputs belong to a person, these get 'merged', then analysis from there will be quite difficult

dEBRUYNE if they spend it directly to an exchange, then Ciphertrace can assign a very high threat score to it

and then get the exchange to disclose user information

i assume that's the threat model we're addressing here

i'm very concerned about their quote that there is an "art" to getting information from exchanges that don't normally share it

Obvious problem with mandatory churning is the blockchain bloat and the bad UX and selecting output is good for power users but useless for the normal person. Tricky problem

It has to be either automated by the wallet or mandatory, otherwise it won't happen for 99% of users

yeah, that's why people are trying to kick the can down the road and not address it. because addressing it will not be easy

He also specifically said in the interview it was not just merge analysis, but Idk if we can take his word on that

He also specifically said he didn't choose that example for any reason (he loves to be arbitrary apparently)

it's not hard to assign a probability score to a merge

But -- merge analysis is one of the strongest heuristics and has a known root fix, we just need to find a way to implement it well :)

you just pick 1000 pairs of outputs on the blockchain and see the probabilitiy of them randomly being spent together in the same tx

We are also assuming seriousness from their side. This could be all snakeoil and they actually have no idea of what they are doing. The problem still exists tho

THey certainly sound like they have no idea what they're doing

CLI wallet already tells me when I try to spend more than 1 output, is this not enough?

But that doesn't mean it isn't a good chance to try and fix one of the heuristics they may or may not be using

sech1: yea we should add that to GUI

a warning isn't enough for the GUI if it doesn't clearly say why and what to do next

the merge threat is really not very hard for anyone to understand. it's not math or anything

And single output churning is not easy in the GUI either

People don't want to understand. They want to be able to do something or not knowing about it

right

IMO it would be a nice solution to be able to flag any subaddress in your wallet as one with a higher risk of monitoring (like a subaddress used to receive from an exchange) and have the wallet mix inputs to that subaddress output by output as they come in.

That way you're not "needlessly" churning *all* inputs

sethsimmons: using different accounts makes it easy to not mix outputs

But you have an easy way to say "I want to churn these as I'm concerned about off-chain surveillance

afaik

otherwise we're selling people covid masks that let air through the sides, and are not telling people about how to get a proper seal beacuse we're scared people will then not use them at all because it's too much hassle to do right

sethsimmons: yes, freezing individual txos

anyway isn't this discussion better suited for -dev? Some people who would be very helpful in this discussion (like mooo) are not here

Probably

we can move there :)

we have to decide, are we selling covid protection, or covid protection theatre

yeah

knaccc: How would raising the ring size to, say, 50 help in this regard?

dEBRUYNE ring size bumps help, but not enough to avoid needing churn

with merge analysis, ring size starts to matter when it's 1000's or even more

if you had a wallet that allowed you to manually choose the set of decoys in a ring, could that help in some way?

sounds dangerous

Peoples "randomness" would stand out on-chain, most likely

there's a clear fix to merge analysis -- churning single outputs from untrusted sources

Its just tricky to implement

sethsimmons: sure - but if you were to select all your own outputs in a ring and then churn a few times...

If they knew those outputs you'd fix nothing with the transaction

who is "they"?

As that would be something you'd statistically never see via the normal decoy selection

The attacking party (like CipherTrace)

what do you mean staistically?

Merge analysis is most potent (or maybe only potent) when there are poisoned/known outputs being merged

<midipoet "what do you mean staistically?"> The current decoy selection algo is time-weighted and selects across all outputs

If you only chose your own outputs (or even enough to stand out to the attacker) they would know its a churn and rule it out

sethsimmons: yes, so selecting your own outputs avoids a tainted selection being included in a ring (assuming you have no tainted or blacklisted outputs)

sethsimmons: how do they know its a churn?

oh you mean to avoid false positives in their system?

sethsimmons: how would they know you have selected all your own outputs? (honest question)

<midipoet "sethsimmons: how do they know it"> because its apparent you chose to select all of your own outputs as decoys, it doesn't match the normal spend/decoy pattern

(this whole scenario is in the case of poisoned/known outputs)

sethsimmons: unless i misunderstand the protocol i am pretty sure they cannot distinguish who owns the outputs within a ring, can they?

isn't that the whole idea?

Well I'm addressing what CT supposedly showed us, which was a merge analysis on poisoned outputs

<midipoet "sethsimmons: unless i misunderst"> They can't necessarily distinguish the signer unless they can strip the majority/all of the decoys with other heuristics etc

sethsimmons: yes, but in my example one assumes your own outputs aren't tainted.

But if they know 11 of your outputs due to poisoning, and you select all 11, it stands out

<midipoet "sethsimmons: yes, but in my exam"> Well then yeah

so you automatically create a non-tainted ring

They still would need to be time-weighted or they'd stand out

and thus break their chain

sethsimmons: your own outputs are time weighted for the most part anyway? i mean you don't create all the outputs in your wallet at the same time

well, most people don't anyway

They wouldnt match a normal distribution unless you're a perfect model of the normal user

Because you wouldn't necessarily have outputs across the normal spectrum of time

right, but if you were manually selecting them - in theory you could make sure you "approximated" a normal random selection. however, i do agree its not the "most intelligent" idea

It could have some benefit to power users, could see it being in CLI

thanks dEBRUYNE! Sadly I don't have time to put that together

Doesn't have to be that long to be honest, could simply be a brief extension of your reddit comment

sgp_ dEBRUYNE please review monero-project/monero-site #1170

i left a couple of comments and made a small change

Commented

did 0.15 involve 2 hardforks?

or was that just 0.13 and 0.14

no. AFAIK we always bumped to a major version after a hard fork

sgp_: As far as I could see in the code, only 0.13 and 0.14

ok thanks

sgp_: That was quite a good discussion you and sarang had yesterday with David. It was very impressive how much good information came within a short time.

Do you think so? There was little discussion of actual methods

Granted, it was interesting to learn that they do their own transactions (which I did not expect to be the case)

There was some reading between the lines as well (bunch of smart people) but nothing malicious or strange at all thank goodness.

Well, from a protocol perspective, "malicious" is in the eyes of the beholder

sarang: That's one thing that impressed me the most, knowing super well your lack of ability to respond (due to David's constant 'oh I'm not the math guy' statement.)

?

But you still maintained a very stable topic course, and avoided abandon.

My goal wasn't to accuse them of anything

nor to let them get away with wishy-washy answers

it was to learn

and I remain somewhat frustrated at the lack of detail, though I don't fault Dave necessarily for not knowing the math

It didn't seem to be a planned lack of information, rather it seemed that David would have invited others to be better prepared if he knew it was needed (and had the time not usually avialble on the first day of a 1.0 tool release.)

I do hope they respond to our more technical questions

but I get if they don't want to... the fact that he even took the interview is appreciated

Yes, that was quite good of Dave. We should be thankful.

I was expecting a total waste of time in listening, and the discussion yielded exactly the opposite. But I still did read between the lines when Dave mentioned his goal of 'helping Monero avoid delisting.' Very smart, but not helpful if you think about it enough.

I wonder if the raise in txs these last few months are these guys spamming the blockchain

I do wonder if part of the incentive for his company was to increase the reach of news about their tool

but this is just speculation

sarang: Dave really turned on the charm with 'being Moneros friends' and probably he's at least mostly sincere about it.

But spreading rumours that 'we cracked Monero' even a little helps a profit quite a lot.

Well, he certainly implied that they wish to work with the Monero community; I suppose we'll have to see

I'm sure there's a PR incentive to be seen as the company that works nicely with projects, but he certainly could be genuinely interested in collaboration

Since the communities do a lot of analysis research, supporting that would make sense from his perspective, I guess

I do find the idea of being an analysis company that also makes transactions to be somewhat off-putting, but this should not be unexpected from a threat model perspective

I know of other companies who at least publicly deny doing anything active like this

Kudos to Dave for being open that they do it, I guess...

sarang: That's what I kept thinking each time the charm was enabled, that it's the smartest thing for Dave to do with any group at all (Ethereum, Swedish government, Monero, Bitcoin, local University...)

Sure, no point in burning bridges really

So that makes it difficult to decide if their intentions are good or not. It really sounded like they are good, but any talented social engineer can achieve that.

And I certainly didn't want the interview to come across as adversarial either

Well, there's no way to know their intentions

and their intentions shouldn't matter from our perspective

sarang: I think you and sgp_ did a great job and avoiding an adversarial feeling. I don't know how you prepared or practiced that so well.

We had some questions discussed in advance, and I believe sgp_ had sent most of them to Dave

That explains the very smooth flow a little, but it was still quite impressive.

Thanks

I hope it was useful to the communities

It was very useful and I hope we get more of these public discussions. But I think it won't happen, it's very unusual for people to have time for it.

Yeah, I hope he (or his team) are willing to discuss the technical follow-up questions that sgp_ sent today

I would be pleasantly surprised if they did, to be honest

I asked many very direct questions about methods and heuristics

Yes, for several on their team to spend time preparing answers would probably be expensive. I'm not sure a normal company wants to make gifts like that.

And it was very clear that Dave wished to keep many things proprietary

I mean, they are a for-profit company engaged in what could be considered a very adversarial method of analysis

But still, gotta ask anyway =p

can it still be called "analysis" if the blockchain is being actively tinkered with (poisoned tx)?

I would term that an attack

sech1: Dave stated they do that a lot with other currencies, but not with Monero. Maybe because of the 1.0 release limitations?

My general mode of thinking is that analysis is passive, whereas an attack is active

msvb-lab: he said they engage in transactions

This terminology might differ based on whom you ask sech1

One follow-up question I posed was whether this is done in a targeted fashion (e.g. in EABE-style attacks) or more broadly (e.g. general output spam attacks)

I should have asked this directly in the interview, and I regret not doing so :/

But I had a lot running through my mind during that time!

sech1 sarang: Please consider making an entry for our Grayhat appearance:

...those are potential topics to develop into half hour speech presentations.

Ask me or another project admin if you want to be added to the project management for Grayhat.

<sarang> One follow-up question I posed was whether this is done in a targeted fashion (e.g. in EABE-style attacks) or more broadly (e.g. general output spam attacks) <---- I have received a handful of BTC satoshi over the years which I suspect was due to the actions of these companies. It is an attack because if they are included in a tx it increases the fee

I don't particularly care about what specifically is defined to be "an attack" or not

The methods are what is useful

ArticMine: I added you to the Grayhat project, thanks for helping with the identifier problem.

Thanks

<msvb-lab> Did you get the info on Daniel?

ArticMine: Yes, and he intj440_ is present here as well. If Daniel wants to offer content or prepare something, I hope he knows it's very welcome.

Great under intj440_ as opposed to intj440?

Probably an IRC nickname artifact

There is an underscore missing?

The underscores are always strange, a few of us have this feature/problem.

That is what confused me

I only see Daniels id here with the underscore added.

And we probably won't have the time or resources to make our Grayhat appearance as good as past conferences, so we may need to depend on each person to self serve their management hours. For example entering a presentation proposal in the project management by themselves.

can someone high-level this conference for me?

...rather than wait for a CFP manager to ask the right questions and periodically review the schedule.

sgp_: You want a status report of our engagement at Grayhat (end of October) right?

We were asked to propose a Monero Village to give Grayhat something similar to what we do at Defcon.

I made the proposal after we had a minimum interest level (measured during the last community meeting.)

And today our proposal was accepted by the Grayhat CFV (call for villages) administration.

sgp_: Is that good for high level?

okay, so another village sort of deal

Yet another village engagement (YAVE.)

I think Grayhat is aware that we (and probably others) will offer very limited content.

I can talk for 30 minutes on Monero adoption and why privacy implementation matters

I think that's a good avenue to focus on

but I don't want to handle the recording and stuff for this conference

lol sgp_ now people know that you are good at the recording stuff

sgp_: That's a very nice offer, of course yes thanks. You probably don't want to join the project management (because it's Taiga) so do you want me to make an entry for your presentation sgp_?

so you are forever typecast into this role

haha msvb-lab indeed, that would be really awesome for you to add. thanks!

just let me know when it is once you know

Our CFP is self serve this time, unless a staff member pledges to take the role.

ideally someone should take it. I think Defcon 2019 went well in part because we actively solicited speakers

You know the whole CT thing. Does this mean that Craig Wright was correct (just off by a few months)?

I remember he said there was a tool coming out...

Perhaps him and David are buddies

when did he say something?

Does it matter? A lot of people say a lot of things

saying "someone will make a commercial tracing tool at some point" isn't exactly a novel prediction

And remember, we still have no details or evidence of how CipherTrace is doing anything, nor whether the results are accurate

I still would draw very few conclusions from that interview

Except for a few small points, like "CipherTrace messes with the blockchain actively to some degree"

which I think is a fair assessment of my questions to Dave

Dave talked a lot about the general idea of heuristics, sure... but a heuristic is just a guess, with some level of input as to how likely you happen to think that guess is of being true

You can use known examples to examine the effectiveness of your heuristic, but it's no guarantee

Breaking Monero talks about lots of different heuristics

agree, main takeway is that they target users with transactions

I would not use "we use many heuristics" as a proxy for "our tool does what customers expect it to"

Note that we have asked follow-up questions recently, and haven't heard back

So it may be the case that they do explain these methods

As I've said before, I don't fault Dave for not being an expert in the math

and he didn't need to give that interview at all

hm. Tone and Jimmy talking about the DHS headline for tracking Monero - and are still at ringsize 7: youtube.com/watch?v=nRykeCaYvl4

<sarang "My general mode of thinking is t"> Yeah, that is usually the case for OSINT CTF's as well. Anything that involves changing the state of data (e.g. password resets to validate an email tied to account) will disqualify you and in some cases result in bans in the case of active LE/missing persons cases

^--

what does feather as a websocket server mean? we can use it headless like monero-wallet-rpc?

It has been known for a long time that the DHS had a contract for tracing Monero so any speculation that there will be a tracking tool coming out is......................

We had joked that MRL should apply for the grant

asymptotically: you have access to the code, go look :P

Oh sorry, you mean as WS server.

It's when you run feather on a server ./feather --wallet-file bla.keys --ws-server and it'll open `127.0.0.1:6666/ws` and then you can connect a websocket client to it, and get events from feather (onPaymentReceived, onNewBlock, etc) and also create transactions

headless feather.

so will CypherTrace donate to MRL's next CCS?

Ideally, it's impossible to know for sure =p

nice :D

10/10 would fund

time machine needed for funding

dsc_: what are the two milestones?

ah, first is October alpha?

No, first is now/yesterday :)

sgp_: no. He tweeted ages ago that Monero's privacy would be broken, that people are working on it and they a working product would be provided by Xmas 2019

He was out by 8 months

*that a working product...

midipoet: Who did?

Feels like I am missing some context

I highly doubt he had any insider view lol

Craig Wright

Think that was it

Ffs

Hang on

no way he actually had evidence

this is before the DHS contract was even in writing

The DHS research started ages ago, no?

no

Are you sure?

certainly not before that tweet

Government research projects are usually quite long

especially security ones (which this would be)

afaict it was about a year, probably a bit longer

I would imagine the Terms of Reference for the research had a lot of the base work

in any case I find this independent to the Wright discussion. There's basically no reasoning that would get me to assume he knew anything

They just tender for the actual work

Oh totally could be unrelated...I just remembered it

<xmrhaelan> Triptych: A New Algorithm Protecting Monero Users monerooutreach.org/stories/monero-triptych.html

<xmrhaelan>

<xmrhaelan> Twitter:

<xmrhaelan> twitter.com/xmroutreach/status/1300830577134723072

<xmrhaelan>

<xmrhaelan> Reddit: reddit.com/r/Monero/comments/ikn8t7…w_algorithm_protecting_monero_users

CLSAG = _Concise_ Linkable...

It was changed after a reviewer grumbled

shrug

I don't really care either way :D

Reviewers always grumble

fo sho

dont forget the duck

lol true

so true

That was certainly not this reviewer's only grumble...

needmoney90: that's a great story about the duck

rottensox: as promised we're trying to get on top of payout transparency in Cypher Market: cyphermarket.com/foss-payout-may-august-2020

Whoever is interested in participating at the Monero Village at Grayhat (October) event please remember we will have our first (of four) meetings this Saturday.

On this channel.

msvb-lab: Do you have some time to comment here? reddit.com/r/Monero/comments/ikt5ln…nk_its_time_we_talked_about_kastelo

midipoet: the contract was awarded August 2018 govtribe.com/award/federal-contract…d/definitive-contract-140d7018c0008

I assumed it was later, sorry

Hello dEBRUYNE. I'll read the article.

I did my best, considering there were no questions asked.

msvb-lab: I think perhaps the underlying question would be, "What is the status given last updates to Taiga/GitHub were ~5-6 months ago'? Is there an ETA on a purchasable product?." Obviously you've been occupied w/ DC and now GreyHat