00:03:30 <sgp_> https://youtu.be/w5rtd3md11g
00:09:26 <lh1008[m]> Maybe the math is perfect. Can a wallet be created that flags txs? The same as what the iOS xwallet tried to do.
00:14:13 <sarang> How so?
00:37:16 <kayabaNerve> lh1008[m]: You can leak info to a centralized server OR have the wallet generate a custom extra.
00:38:23 <kayabaNerve> 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)
00:38:31 <kayabaNerve> Or you can use an undefined field
01:09:26 <lh1008[m]> 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?
01:10:37 <lh1008[m]> If there's a flag then you just make a request.
01:10:54 <sarang> Transactions can store arbitrary extra data
01:11:16 <sarang> Default wallets will not do this
01:14:07 <lh1008[m]> Default as in official monero wallets right?
01:15:21 <sarang> Yes
01:15:40 <sarang> There's a lot of discussion about removal of this capability altogether at the protocol level as well
01:15:50 <sarang> I support such removal
01:19:40 <lh1008[m]> Thank you sarang :)
01:30:21 <kayabaNerve> 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.
01:31:22 <kayabaNerve> 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.
01:31:40 <kayabaNerve> Though the removal of MinerGate's field would be pleasant.
07:30:13 <midipoet> 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
07:49:19 <sech1> midipoet "trusted nodes"? In a trustless network? Just encourage everyone to use their own nodes.
07:49:40 <midipoet> sech1: yeah, maybe the phrasing is incorrect
07:49:56 <midipoet> if we know some nodes are just sitting there churning, for example
07:50:06 <midipoet> you could call them a seed node
07:50:09 <sech1> nodes don't churn, users churn
07:50:52 <midipoet> right, so perhaps an algorithm that churns that is attached to a node. would that me a more apt description?
07:51:33 <sech1> we can't know which node sent a transaction
07:51:49 <midipoet> we don't need to know
07:54:13 <midipoet> 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?
07:54:21 <midipoet> of course, we could try and do that with adoption...
07:54:35 <midipoet> and i know that is the preferred method for a number of reasons
07:59:04 <midipoet> 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.
08:08:41 <midipoet> 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
08:12:50 <fluffypony> midipoet: yes, but a restored wallet still has to scan through those outputs
08:13:00 <fluffypony> even if it's created by "churn nodes" sitting and re-mixing 1 XMR over and over
08:25:49 <midipoet> 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
08:26:45 <midipoet> 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
08:29:25 <midipoet> good reading on similar issues: https://www.supremecourt.uk/docs/speech-191112.pdf
08:30:00 <midipoet> the above has specific mention to blockchain and risk
08:33:29 <midipoet> 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.
08:34:02 <midipoet> more on this:
08:34:03 <midipoet> https://epic.org/algorithmic-transparency/crim-justice/
08:34:30 <midipoet> all this is coming from Law Researchers in my company btw - not just pulling it out of my arse
10:47:55 <dEBRUYNE> sarang, sgp_: Great work on the interview
10:48:03 <dEBRUYNE> I do think it would be worthwhile to add a short blog post to the website as well
10:48:23 <dEBRUYNE> Some people just want to read something briefly and don't want to spend time (or have time) to watch a lengthy interview
10:50:28 <sech1> some people just read headlines, so we should make a sensational headline too
10:50:47 <sech1> like "Ciphertrace were destroyed in the interview, they can't trace shit!"
10:51:06 <dsc_> we're above that! :-D
10:51:18 <sech1> and then send it to all the "journalists" who published FUD yesterday
10:51:28 <sech1> dsc_ ok we can omit "shit" from the headline :D
10:52:18 <dsc_> :)
10:58:04 <midipoet> "CipherTrace forgoe their own science and admit arbitrary risk scoring"
10:58:08 <midipoet> how is that?
10:58:17 <midipoet> oh wait
10:58:22 <midipoet> "CipherTrace forgoe their own pseudo-science and admit arbitrary risk scoring"
10:58:55 <midipoet> "CipherTrace forgoe their own pseudo-science and admit Arbitrary Risk Scoring (ARS)"
11:11:57 <sech1> Arbitrary Risk Scoring Estimate (ARSE)
11:17:04 <ErCiccione[m]> 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
11:17:30 <midipoet> sech1: that's the one!
11:18:27 <sech1> blog post would be worth it after the second interview with "the math guys"
11:18:48 <ErCiccione[m]> yeah
11:26:52 <dEBRUYNE> ErCiccione[m]: The issue is that a lot of people currently use the headlines as a given
11:26:59 <dEBRUYNE> We need to debunk / refute / clarify that
11:27:44 <Inge-> "We have yet to see conclusive evidence of real-life tracing ability"-ish?
11:38:55 <ErCiccione[m]> 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.
11:44:05 <knaccc> i don't really feel like people are taking this seriously
11:44:21 <knaccc> 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."
11:44:36 <knaccc> so it's not FUD. it's "an analysis technique known for quite some time"
11:44:45 <knaccc> and no one is disputing that
11:45:23 <knaccc> do we want to fix the problem, or just try and spin it away?
11:47:08 <azy> how might it be fixed?
11:47:49 <knaccc> well one way that i have very high confidence in is showing people how to properly churn inputs independently before spending them
11:47:57 <knaccc> that destroys this "analysis technique known for quite some time"
11:48:32 <knaccc> two outputs known to belong to the same person that are later spent in the same transaction is a dead giveaway
11:49:35 <knaccc> maybe we should consider not letting wallets spend owner outputs together unless they have been churned
11:49:43 <knaccc> s/owner/owned
11:49:43 <monerobux> knaccc meant to say: maybe we should consider not letting wallets spend owned outputs together unless they have been churned
11:50:09 <dsc_> Luck has it that my wallet™© has output control
11:50:29 <knaccc> aha, yes, featherwallet is the answer :)
11:50:33 <dEBRUYNE> knaccc: But it also depends on what kind of information you have on the other end
11:50:37 <dsc_> knaccc: was worth a shot :-P
11:50:48 <dEBRUYNE> If you merely know to outputs belong to a person, these get 'merged', then analysis from there will be quite difficult
11:51:35 <knaccc> dEBRUYNE if they spend it directly to an exchange, then Ciphertrace can assign a very high threat score to it
11:51:43 <knaccc> and then get the exchange to disclose user information
11:51:59 <knaccc> i assume that's the threat model we're addressing here
11:52:35 <knaccc> i'm very concerned about their quote that there is an "art" to getting information from exchanges that don't normally share it
11:55:59 <ErCiccione[m]> 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
11:56:25 <sethsimmons> It has to be either automated by the wallet or mandatory, otherwise it won't happen for 99% of users
11:56:27 <knaccc> 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
11:56:51 <sethsimmons> He also specifically said in the interview it was not just merge analysis, but Idk if we can take his word on that
11:57:07 <sethsimmons> He also specifically said he didn't choose that example for any reason (he loves to be arbitrary apparently)
11:57:33 <knaccc> it's not hard to assign a probability score to a merge
11:57:38 <sethsimmons> 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 :)
11:57:56 <knaccc> you just pick 1000 pairs of outputs on the blockchain and see the probabilitiy of them randomly being spent together in the same tx
11:58:07 <ErCiccione[m]> 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
11:58:19 <sethsimmons> THey certainly sound like they have no idea what they're doing
11:58:39 <sech1> CLI wallet already tells me when I try to spend more than 1 output, is this not enough?
11:58:41 <sethsimmons> 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
11:58:53 <selsta> sech1: yea we should add that to GUI
11:59:01 <sethsimmons> a warning isn't enough for the GUI if it doesn't clearly say why and what to do next
11:59:05 <knaccc> the merge threat is really not very hard for anyone to understand. it's not math or anything
11:59:12 <sethsimmons> And single output churning is not easy in the GUI either
12:00:11 <ErCiccione[m]> People don't want to understand. They want to be able to do something or not knowing about it
12:00:15 <knaccc> right
12:00:24 <sethsimmons> 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.
12:00:37 <sethsimmons> That way you're not "needlessly" churning *all* inputs
12:00:48 <selsta> sethsimmons: using different accounts makes it easy to not mix outputs
12:00:50 <sethsimmons> But you have an easy way to say "I want to churn these as I'm concerned about off-chain surveillance
12:00:51 <selsta> afaik
12:00:56 <knaccc> 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
12:01:00 <dsc_> sethsimmons: yes, freezing individual txos
12:01:21 <ErCiccione[m]> anyway isn't this discussion better suited for -dev?  Some people who would be very helpful in this discussion (like mooo) are not here
12:01:27 <sethsimmons> Probably
12:01:28 <sethsimmons> we can move there :)
12:01:32 <knaccc> we have to decide, are we selling covid protection, or covid protection theatre
12:01:44 <ErCiccione[m]> yeah
12:02:15 <dEBRUYNE> knaccc: How would raising the ring size to, say, 50 help in this regard?
12:02:56 <knaccc> dEBRUYNE ring size bumps help, but not enough to avoid needing churn
12:03:20 <sech1> with merge analysis, ring size starts to matter when it's 1000's or even more
12:15:30 <midipoet> if you had a wallet that allowed you to manually choose the set of decoys in a ring, could that help in some way?
12:16:06 <sethsimmons> sounds dangerous
12:16:20 <sethsimmons> Peoples "randomness" would stand out on-chain, most likely
12:16:42 <sethsimmons> there's a clear fix to merge analysis -- churning single outputs from untrusted sources
12:16:52 <sethsimmons> Its just tricky to implement
12:17:23 <midipoet> sethsimmons: sure - but if you were to select all your own outputs in a ring and then churn a few times...
12:17:49 <sethsimmons> If they knew those outputs you'd fix nothing with the transaction
12:18:03 <midipoet> who is "they"?
12:18:04 <sethsimmons> As that would be something you'd statistically never see via the normal decoy selection
12:18:15 <sethsimmons> The attacking party (like CipherTrace)
12:18:20 <midipoet> what do you mean staistically?
12:18:31 <sethsimmons> Merge analysis is most potent (or maybe only potent) when there are poisoned/known outputs being merged
12:18:57 <sethsimmons> <midipoet "what do you mean staistically?"> The current decoy selection algo is time-weighted and selects across all outputs
12:19:17 <sethsimmons> 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
12:19:17 <midipoet> sethsimmons: yes, so selecting your own outputs avoids a tainted selection being included in a ring (assuming you have no tainted or blacklisted outputs)
12:19:32 <midipoet> sethsimmons: how do they know its a churn?
12:19:34 <sethsimmons> oh you mean to avoid false positives in their system?
12:20:15 <midipoet> sethsimmons: how would they know you have selected all your own outputs? (honest question)
12:20:25 <sethsimmons> <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
12:20:42 <sethsimmons> (this whole scenario is in the case of poisoned/known outputs)
12:21:08 <midipoet> sethsimmons: unless i misunderstand the protocol i am pretty sure they cannot distinguish who owns the outputs within a ring, can they?
12:21:13 <midipoet> isn't that the whole idea?
12:21:55 <sethsimmons> Well I'm addressing what CT supposedly showed us, which was a merge analysis on poisoned outputs
12:22:21 <sethsimmons> <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
12:22:32 <midipoet> sethsimmons: yes, but in my example one assumes your own outputs aren't tainted.
12:22:38 <sethsimmons> But if they know 11 of your outputs due to poisoning, and you select all 11, it stands out
12:22:44 <sethsimmons> <midipoet "sethsimmons: yes, but in my exam"> Well then yeah
12:22:47 <midipoet> so you automatically create a non-tainted ring
12:22:52 <sethsimmons> They still would need to be time-weighted or they'd stand out
12:22:54 <midipoet> and thus break their chain
12:23:26 <midipoet> 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
12:23:35 <midipoet> well, most people don't anyway
12:24:08 <sethsimmons> They wouldnt match a normal distribution unless you're a perfect model of the normal user
12:24:25 <sethsimmons> Because you wouldn't necessarily have outputs across the normal spectrum of time
12:26:56 <midipoet> 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
12:30:07 <sethsimmons> It could have some benefit to power users, could see it being in CLI
13:48:45 <sgp_> thanks dEBRUYNE! Sadly I don't have time to put that together
13:49:54 <dEBRUYNE> Doesn't have to be that long to be honest, could simply be a brief extension of your reddit comment
14:12:16 <ErCiccione[m]> sgp_ dEBRUYNE please review https://github.com/monero-project/monero-site/pull/1170
14:12:26 <ErCiccione[m]> i left a couple of comments and made a small change
14:37:21 <dEBRUYNE> Commented
14:44:58 <sgp_> did 0.15 involve 2 hardforks?
14:45:17 <sgp_> or was that just 0.13 and 0.14
14:46:00 <ErCiccione[m]> no. AFAIK we always bumped to a major version after a hard fork
14:58:56 <dEBRUYNE> sgp_: As far as I could see in the code, only 0.13 and 0.14
14:59:52 <sgp_> ok thanks
16:21:23 <msvb-lab> 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.
16:21:40 <sarang> Do you think so? There was little discussion of actual methods
16:22:00 <sarang> Granted, it was interesting to learn that they do their own transactions (which I did not expect to be the case)
16:22:04 <msvb-lab> There was some reading between the lines as well (bunch of smart people) but nothing malicious or strange at all thank goodness.
16:22:22 <sarang> Well, from a protocol perspective, "malicious" is in the eyes of the beholder
16:22:40 <msvb-lab> 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.)
16:22:53 <sarang> ?
16:23:01 <msvb-lab> But you still maintained a very stable topic course, and avoided abandon.
16:23:34 <sarang> My goal wasn't to accuse them of anything
16:23:40 <sarang> nor to let them get away with wishy-washy answers
16:23:45 <sarang> it was to learn
16:24:03 <sarang> and I remain somewhat frustrated at the lack of detail, though I don't fault Dave necessarily for not knowing the math
16:24:10 <msvb-lab> 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.)
16:24:12 <sarang> I do hope they respond to our more technical questions
16:24:38 <sarang> but I get if they don't want to... the fact that he even took the interview is appreciated
16:25:36 <msvb-lab> Yes, that was quite good of Dave. We should be thankful.
16:25:41 <msvb-lab> 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.
16:27:03 <vp11> I wonder if the raise in txs these last few months are these guys spamming the blockchain
16:27:04 <sarang> I do wonder if part of the incentive for his company was to increase the reach of news about their tool
16:27:16 <sarang> but this is just speculation
16:29:41 <msvb-lab> sarang: Dave really turned on the charm with 'being Moneros friends' and probably he's at least mostly sincere about it.
16:29:43 <msvb-lab> But spreading rumours that 'we cracked Monero' even a little helps a profit quite a lot.
16:30:35 <sarang> Well, he certainly implied that they wish to work with the Monero community; I suppose we'll have to see
16:30:59 <sarang> 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
16:31:14 <sarang> Since the communities do a lot of analysis research, supporting that would make sense from his perspective, I guess
16:32:07 <sarang> 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
16:32:22 <sarang> I know of other companies who at least publicly deny doing anything active like this
16:32:35 <sarang> Kudos to Dave for being open that they do it, I guess...
16:33:17 <msvb-lab> 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...)
16:33:47 <sarang> Sure, no point in burning bridges really
16:33:57 <msvb-lab> 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.
16:34:00 <sarang> And I certainly didn't want the interview to come across as adversarial either
16:34:10 <sarang> Well, there's no way to know their intentions
16:34:18 <sarang> and their intentions shouldn't matter from our perspective
16:34:45 <msvb-lab> 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.
16:35:03 <sarang> We had some questions discussed in advance, and I believe sgp_ had sent most of them to Dave
16:35:32 <msvb-lab> That explains the very smooth flow a little, but it was still quite impressive.
16:35:36 <sarang> Thanks
16:35:47 <sarang> I hope it was useful to the communities
16:36:23 <msvb-lab> 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.
16:37:03 <sarang> Yeah, I hope he (or his team) are willing to discuss the technical follow-up questions that sgp_ sent today
16:37:18 <sarang> I would be pleasantly surprised if they did, to be honest
16:37:27 <sarang> I asked many very direct questions about methods and heuristics
16:38:24 <msvb-lab> 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.
16:38:57 <sarang> And it was very clear that Dave wished to keep many things proprietary
16:39:18 <sarang> I mean, they are a for-profit company engaged in what could be considered a very adversarial method of analysis
16:39:37 <sarang> But still, gotta ask anyway =p
16:40:11 <sech1> can it still be called "analysis" if the blockchain is being actively tinkered with (poisoned tx)?
16:40:37 <sarang> I would term that an attack
16:40:50 <msvb-lab> sech1: Dave stated they do that a lot with other currencies, but not with Monero. Maybe because of the 1.0 release limitations?
16:40:55 <sarang> My general mode of thinking is that analysis is passive, whereas an attack is active
16:41:14 <sarang> msvb-lab: he said they engage in transactions
16:41:42 <sarang> This terminology might differ based on whom you ask sech1
16:42:29 <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)
16:42:44 <sarang> I should have asked this directly in the interview, and I regret not doing so :/
16:42:57 <sarang> But I had a lot running through my mind during that time!
16:46:16 <msvb-lab> sech1 sarang: Please consider making an entry for our Grayhat appearance:
16:46:18 <msvb-lab> https://taiga.getmonero.org/project/michael-grayhat/us/3?kanban-status=9449
16:46:40 <msvb-lab> ...those are potential topics to develop into half hour speech presentations.
16:47:05 <msvb-lab> Ask me or another project admin if you want to be added to the project management for Grayhat.
16:48:22 <ArticMine> <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
16:49:16 <sarang> I don't particularly care about what specifically is defined to be "an attack" or not
16:49:20 <sarang> The methods are what is useful
16:49:57 <msvb-lab> ArticMine: I added you to the Grayhat project, thanks for helping with the identifier problem.
16:50:40 <ArticMine> Thanks
16:51:43 <ArticMine> <msvb-lab> Did you get the info on Daniel?
16:53:48 <msvb-lab> 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.
16:55:00 <ArticMine> Great under intj440_ as opposed to intj440?
16:55:25 <sarang> Probably an IRC nickname artifact
16:55:35 <ArticMine> There is an underscore missing?
16:55:37 <msvb-lab> The underscores are always strange, a few of us have this feature/problem.
16:55:53 <ArticMine> That is what confused me
16:56:01 <msvb-lab> I only see Daniels id here with the underscore added.
16:56:10 <msvb-lab> 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.
16:56:25 <sgp_> can someone high-level this conference for me?
16:56:38 <msvb-lab> ...rather than wait for a CFP manager to ask the right questions and periodically review the schedule.
16:57:02 <msvb-lab> sgp_: You want a status report of our engagement at Grayhat (end of October) right?
16:57:36 <msvb-lab> We were asked to propose a Monero Village to give Grayhat something similar to what we do at Defcon.
16:57:56 <msvb-lab> I made the proposal after we had a minimum interest level (measured during the last community meeting.)
16:58:17 <msvb-lab> And today our proposal was accepted by the Grayhat CFV (call for villages) administration.
16:58:27 <msvb-lab> sgp_: Is that good for high level?
16:58:28 <sgp_> okay, so another village sort of deal
16:58:46 <msvb-lab> Yet another village engagement (YAVE.)
16:59:14 <msvb-lab> I think Grayhat is aware that we (and probably others) will offer very limited content.
16:59:51 <sgp_> I can talk for 30 minutes on Monero adoption and why privacy implementation matters
17:00:01 <sgp_> I think that's a good avenue to focus on
17:00:46 <sgp_> but I don't want to handle the recording and stuff for this conference
17:01:01 <sarang> lol sgp_ now people know that you are good at the recording stuff
17:01:07 <msvb-lab> 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_?
17:01:07 <sarang> so you are forever typecast into this role
17:01:38 <sgp_> haha msvb-lab indeed, that would be really awesome for you to add. thanks!
17:01:50 <sgp_> just let me know when it is once you know
17:03:47 <msvb-lab> https://taiga.getmonero.org/project/michael-grayhat/task/32/
17:04:10 <msvb-lab> Our CFP is self serve this time, unless a staff member pledges to take the role.
17:21:35 <sgp_> ideally someone should take it. I think Defcon 2019 went well in part because we actively solicited speakers
17:27:56 <midipoet> You know the whole CT thing. Does this mean that Craig Wright was correct (just off by a few months)?
17:28:10 <midipoet> I remember he said there was a tool coming out...
17:28:22 <midipoet> Perhaps him and David are buddies
17:28:39 <sgp_> when did he say something?
17:28:42 <sarang> Does it matter? A lot of people say a lot of things
17:29:00 <sgp_> saying "someone will make a commercial tracing tool at some point" isn't exactly a novel prediction
17:29:12 <sarang> And remember, we still have no details or evidence of how CipherTrace is doing anything, nor whether the results are accurate
17:29:26 <sarang> I still would draw very few conclusions from that interview
17:29:39 <sarang> Except for a few small points, like "CipherTrace messes with the blockchain actively to some degree"
17:29:48 <sarang> which I think is a fair assessment of my questions to Dave
17:31:06 <sarang> 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
17:31:32 <sarang> You can use known examples to examine the effectiveness of your heuristic, but it's no guarantee
17:31:43 <sarang> Breaking Monero talks about lots of different heuristics
17:31:50 <sgp_> agree, main takeway is that they target users with transactions
17:32:00 <sarang> I would not use "we use many heuristics" as a proxy for "our tool does what customers expect it to"
17:32:16 <sarang> Note that we have asked follow-up questions recently, and haven't heard back
17:32:24 <sarang> So it may be the case that they do explain these methods
17:33:33 <sarang> As I've said before, I don't fault Dave for not being an expert in the math
17:33:52 <sarang> and he didn't need to give that interview at all
17:39:22 <Inge-> hm. Tone and Jimmy talking about the DHS headline for tracking Monero - and are still at ringsize 7: https://www.youtube.com/watch?v=nRykeCaYvl4
17:39:24 <monerobux> [ Bitcoin Brief - Monero not Private, ETH Fees, INX Armies & Fidelity Fund - YouTube ] - www.youtube.com
17:41:16 <xmrscott[m]> <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
18:01:15 -xmr-pr- [css-proposals] dsc opened pull request #164: Feather wallet
18:01:15 -xmr-pr- > https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/164
18:11:32 <dsc_> ^--
18:13:12 <asymptotically> what does feather as a websocket server mean? we can use it headless like monero-wallet-rpc?
18:14:02 <niocbrrrrrr> 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......................
18:14:24 <sarang> We had joked that MRL should apply for the grant
18:14:25 <dsc_> asymptotically: you have access to the code, go look :P
18:14:39 <dsc_> Oh sorry, you mean as WS server.
18:15:59 <dsc_> It's when you run feather on a server ./feather --wallet-file bla.keys --ws-server and it'll open `http://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
18:16:42 <dsc_> headless feather.
18:16:50 <niocbrrrrrr> so will CypherTrace donate to MRL's next CCS?
18:18:59 <sarang> Ideally, it's impossible to know for sure =p
18:19:40 <asymptotically> nice :D
18:19:42 <asymptotically> 10/10 would fund
18:20:37 <dsc_> time machine needed for funding
18:24:11 <sgp_> dsc_: what are the two milestones?
18:24:34 <sgp_> ah, first is October alpha?
18:27:00 <dsc_> No, first is now/yesterday :)
18:40:01 <midipoet> 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
18:40:08 <midipoet> He was out by 8 months
18:40:32 <midipoet> *that a working product...
18:41:01 <dEBRUYNE> midipoet: Who did?
18:41:05 <dEBRUYNE> Feels like I am missing some context
18:41:09 <sgp_> I highly doubt he had any insider view lol
18:41:28 <midipoet> Craig Wright
18:42:43 <midipoet> https://twitter.com/ProfFaustus/status/1061229656081350656
18:42:50 <midipoet> Think that was it
18:43:15 <midipoet> Ffs
18:43:18 <midipoet> Hang on
18:44:11 <midipoet> https://reddit.com/r/Monero/comments/9vv7jp/proffraudstus_makes_threats_to_monero/
18:44:12 <monerobux> [REDDIT] @ProfFraudstus® makes threats to Monero (https://twitter.com/ProfFaustus/status/1061229656081350656) to r/Monero | 28 points (73.0%) | 70 comments | Posted by caffeine93 | Created at 2018-11-10 - 15:38:39
18:44:27 <sgp_> no way he actually had evidence
18:44:56 <sgp_> this is before the DHS contract was even in writing
18:46:00 <midipoet> The DHS research started ages ago, no?
18:46:17 <sgp_> no
18:46:24 <midipoet> Are you sure?
18:46:25 <sgp_> certainly not before that tweet
18:46:42 <midipoet> Government research projects are usually quite long
18:46:57 <midipoet> especially security ones (which this would be)
18:47:07 <sgp_> afaict it was about a year, probably a bit longer
18:47:52 <midipoet> I would imagine the Terms of Reference for the research had a lot of the base work
18:47:53 <sgp_> 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
18:48:02 <midipoet> They just tender for the actual work
18:48:17 <midipoet> Oh totally could be unrelated...I just remembered it
18:52:08 <xmrmatterbridge> <xmrhaelan> Triptych: A New Algorithm Protecting Monero Users https://www.monerooutreach.org/stories/monero-triptych.html
18:52:09 <xmrmatterbridge> <xmrhaelan>
18:52:10 <xmrmatterbridge> <xmrhaelan> Twitter:
18:52:12 <xmrmatterbridge> <xmrhaelan> https://twitter.com/xmroutreach/status/1300830577134723072
18:52:13 <xmrmatterbridge> <xmrhaelan>
18:52:14 <xmrmatterbridge> <xmrhaelan> Reddit: https://www.reddit.com/r/Monero/comments/ikn8t7/triptych_a_new_algorithm_protecting_monero_users/
18:52:15 <monerobux> [REDDIT] Triptych: A New Algorithm Protecting Monero Users (https://www.monerooutreach.org/stories/monero-triptych.html) to r/Monero | 59 points (97.0%) | 5 comments | Posted by MoneroOutreach | Created at 2020-09-01 - 16:15:12
18:52:55 <sarang> CLSAG = _Concise_ Linkable...
18:53:04 <sarang> It was changed after a reviewer grumbled
18:53:06 <sarang> shrug
18:53:14 <sarang> I don't really care either way :D
18:54:19 <midipoet> Reviewers always grumble
18:54:26 <sarang> fo sho
19:23:27 <needmoney90> dont forget the duck
19:24:02 <needmoney90> https://rachelbythebay.com/w/2013/06/05/duck/
19:24:40 <sarang> lol true
19:24:41 <sarang> so true
19:24:58 <sarang> That was certainly not this reviewer's only grumble...
19:47:22 <needmoney90> https://np.reddit.com/r/Monero/comments/ikog5e/some_great_talent_profiles_on_monero_jobscom/g3mrt7p/
19:47:23 <monerobux> [REDDIT] Some Great Talent Profiles on Monero Jobs.com (self.Monero) | 13 points (94.0%) | 1 comments | Posted by plummy-23 | Created at 2020-09-01 - 17:16:08
19:47:31 * needmoney90 starts drama
19:58:36 <midipoet> needmoney90: that's a great story about the duck
20:31:42 <rehrar> rottensox: as promised we're trying to get on top of payout transparency in Cypher Market: https://www.cyphermarket.com/foss-payout-may-august-2020/
21:48:20 <msvb-lab> 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.
21:48:22 <msvb-lab> https://taiga.getmonero.org/project/michael-grayhat/wiki/meet-1/
21:48:42 <msvb-lab> On this channel.
22:00:15 -xmr-pr- [meta] michaesc opened issue #504: Village Workgroup Meeting: 5 September 2020 17:00 UTC
22:00:15 -xmr-pr- > https://github.com/monero-project/meta/issues/504
22:11:37 <dEBRUYNE> msvb-lab: Do you have some time to comment here? https://www.reddit.com/r/Monero/comments/ikt5ln/i_think_its_time_we_talked_about_kastelo/
22:11:38 <monerobux> [REDDIT] I think it's time we talked about kastelo. (self.Monero) | 8 points (100.0%) | 2 comments | Posted by xXCsd113Xx | Created at 2020-09-01 - 21:18:47
22:18:11 <sgp_> midipoet: the contract was awarded August 2018 https://govtribe.com/award/federal-contract-award/definitive-contract-140d7018c0008
22:18:25 <sgp_> I assumed it was later, sorry
22:28:01 <msvb-lab> Hello dEBRUYNE. I'll read the article.
22:57:54 <msvb-lab> I did my best, considering there were no questions asked.
23:35:49 <xmrscott[m]> 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