01:47:12 I'm reading about menro and this seems pretty concerning? https://monero.fail/opsec 01:47:31 bridges/swap services are the only realistic monero on-ramp. but once it gets deposited in your wallet with tainted metadata, what can you do? the page recommends using a third-party wallet... does the native monero wallet not offer this kind of mitigation? 01:49:06 The recommendations include ways to mitigate the tainted coins. It’s only recommended because it’s more user friendly but it can certainly done in the native wallet. 01:49:55 It’s not a big deal if you recycle addresses, and if you are receiving tiny amounts and suspected tainted coins, then churn them away a few times 01:50:11 Menro 01:50:19 Well they say water finds it's level 01:50:32 Menro gud coin 01:51:04 Very accessible 01:51:12 Guest0: Tracing is only probabilistic so once you start churning you reduce the probability. 01:51:33 iza_menace is there a tutorial for how to do this in the official wallet? how come it's not implemented by default? 01:52:06 I feel I was kind of lucky to even find the page about this specific attack 01:52:49 I'd prefer to do this in the official wallet 01:52:54 > bridges/swap services are the only realistic monero on-ramp. but once it gets deposited in your wallet with tainted metadata, what can you do? the page recommends using a third-party wallet... does the native monero wallet not offer this kind of mitigation? 01:52:54 It’s not depositing into a wallet with tainted utxos, it’s when you send coins and those tainted utxos are involved. The recipient entity can do the probabilistic matching. IE becomes an issue when you are sending menro to an untrusted party and you potentially have tainted utxos 01:55:00 the problem is that brdiges are the only realistic on-ramp (for most users) and they taint their deposits. so it's 100% necessary when the user *starts* using monero to defend against this attack. or am I wrong? 01:55:04 https://mrelay.p2pool.observer/m/monero.social/xofkGxuhcQzFnjKRCBvTMxcD.jpeg (0F826EA6-E238-4FD2-9407-1B648D447B38.jpeg) 01:55:08 https://mrelay.p2pool.observer/m/monero.social/OWkiCZspVuZaWedhXODFzIQv.jpeg (6ABB602C-E19D-44B1-B090-A143B51AA16E.jpeg) 01:55:09 It is implemented by default. > iza_menace is there a tutorial for how to do this in the official wallet? how come it's not implemented by default? 01:56:15 Guest0: Recommended to churn by sending to yourself a few times if you’re worried about maximally protecting privacy 01:56:28 You’re correct 01:56:37 ok so these are the wallet commands necessary to reproduce the recommendations on that page? 01:57:17 do I basically do sweep_all a few time to my own wallet? 01:58:20 Yes. Using CLI 01:58:36 but if the deposit from the bridge is just one transaction, does this still help? since there is nothing to "consolidate", although it does trigger a new transaction, so I'm not sure whether it helps. does it make more sense to break the initial deposit into 2, so that there is something to consolidate? 02:01:15 I think it’s less about consolidation and more adding additional ring members. 02:03:06 I have a surface level understanding of the cryptography, but to reduce it, every transaction you’re mixing your utxo with 15 other dummy entries (ring members). If you send a tainted utxo to a malicious party they have a 1/16 chance of guessing which one belonged to you. If you send multiple times you now mix with N other ring members, decreasing the probability of their guess. 02:03:28 Someone should fact check that but that’s my layman understanding 02:03:59 my understanding is that the metadata they taint the transactions with makes it possible to trace *that transaction* as it gets re-sent across the network. i.e to trace where it gets spent. so if you just send that same transaction to yourself, it can still be traced. but if you consolidate it with other transactions, then maybe the metadata get 02:04:00 mangled, or something... 02:04:55 sometimes I send small donations to any public address around just to spread outputs around 02:04:55 the only part I'm not sure about is the last sentence. but the rest is consistent with this video https://www.youtube.com/watch?v=WkphgF6Hn4w 02:05:38 Monero hides in the crowd, the more transactions, the larger the crowd 02:06:25 it's not that simple. this attack vector relies on mailicious public nodes that taint transactions with metadata which makes it traceable if you spend it later 02:07:11 they add some kind of fingerprint to it 02:07:23 you trust remote nodes with certain things 02:07:31 it's more that public nodes can keep logs 02:07:50 it's not about using public nodes, it's about using bridges. bridges do this too when they deposit to your wallet 02:08:19 what they can log is still limited though. it's not like you can find everything out about a remote wallet user... but you can find out some obvious things like ip sometimes 02:08:40 the bridges are create problems with their logs 02:08:49 you're referring to a different attack vector 02:08:56 it's the same issue 02:09:03 no, it's not 02:09:07 if you're swapping something, your peer gets some information 02:09:17 if you're using a light wallet, your peer gets some information 02:09:32 and the mitigations are different too. what you're talking about is solved by using a proxy, or Tor. it's unrelated 02:10:09 this is about decoy metadata used to taint transactions, that makes it possible to trace that transaction when it gets spent later 02:10:21 "decoy metadata" is nonsense 02:10:33 DataHoarder[m]^ 02:10:49 they're adding metadata to key images 02:11:00 tracking*--you can't add data to a key image on chain 02:11:22 I posted the sources earlier 02:12:12 yeah, the .fail ... it's the same class of problem as using a remote node 02:12:15 I disagree w your assessment there completely basically 02:13:46 or rather, it's the same in that the solution is to not engage with swaps or remote modes or not connect directly 02:14:27 nodes*. a malicious atomic swap provider can log some similar sorts of information 02:15:00 that's the same as saying the solution is not to use monero at all. DEX/bridges are the only available on-ramp for most users 02:15:26 or not connect directly 02:16:00 what does that mean? you need the bridge to make a deposit to your wallet. when the transaction arrives, it's tainted. what's the solution? 02:16:49 it's not that simple. this attack vector relies on mailicious public nodes that taint transactions with metadata which makes it traceable if you spend it later <<>> Cat never uses a public node 02:16:49 well, churn, first of all 02:16:57 but it's up to you what information you reveal in that swap process 02:16:58 why do you? 02:17:18 what swap service, did you use an account, did you connect clearnet, did you kyc 02:17:21 even then 02:17:25 what they can know is limited 02:17:29 nioc this isn't about using public nodes. it's about using bridges for the initial deposit and on-ramp 02:17:54 they can know if someone used their key image in a ring ... currently, that's changing soon ... but not if it was a decoy. they can't know where you spend it 02:17:55 jbabb again you're talking about unrelated attack vectors 02:17:58 @lza_menace: Hmm? Context? 02:18:06 some attacks rely on tainting with multiple small outputs and recognizing when they're spent together 02:18:07 big brains have studied churning and after that had no recommendations on how to churn properly 02:18:29 nah there's a protocol but it's basically to churn 02:21:52 how about, when buying send to a wallet, then send to another wallet and throw away the first wallet 02:22:17 nioc: I don't think that's necessary if you just churn internal to a wallet 02:22:36 for extra paranoia use coin control and churn addresses individually before spending them together 02:22:52 I was thinking also about addresses 02:23:15 some people increment subaddresses for every transaction 02:23:16 yes I know, subaddresses :) 02:23:19 some people separate funds into accounts 02:23:25 some people move wallet to wallet 02:24:37 I believe CLI doesn't have coin control 02:24:39 nioc if it's just 1 transaction you're moving around, I don't think it helps at all, because it retains the tainted metadata. that's how the attack works in the first place,the point is being able to trace that specific output as it gets spent later 02:24:55 Guest0: what tainted metadata? 02:25:20 sorry, earlier when I said "that's nonsense" I meant: I don't understand what you mean because this isn't the terminology I'm used to seeing 02:25:32 I posted the sources earlier 02:25:45 once you spend a key image and create a new one they can't know where that new one went 02:25:49 monero.fail.opsec? 02:26:28 a "tainted UTXO" isn't a real term: it's just a key image that they logged some information about 02:26:35 yes, but this explains it in more detail: https://www.youtube.com/watch?v=WkphgF6Hn4w 02:26:42 using it once basically breaks the link 02:27:36 ok, you know more than me about this. I'd appreciate if you watched that video and confirmed that we're talking about the same things and that I can use your recommendation 02:28:01 in the video they call it a decoy transaction output I think 02:28:08 ah yeah again, that article and that video aren't really in depth technical looks at how chainalysis works 02:28:31 so when you create a ringct tx, as people have pointed out above, you pick decoys and create an output: a "key image" 02:28:58 when a swap provider sends you your monero they can just keep track of whenever that is used in the future. now, any output can be selected randomly as a "decoy" 02:29:23 so even that they "know" it's spent is a little "bogus": it's probabilistic as mentioned above 02:29:39 they aren't adding info to the key image that then lives with it as it gets spent to create a new output/key image 02:30:17 they can kind of sort of guess that it might have been spent. and might have a higher probability of guessing right if you for example spent multiple outputs together in one tx together, part of that tainting attack mentioned 02:30:33 a probabilistic fingerprint it still concerning 02:30:38 you are partly right that they're different vectors than for example using a remote node or a light wallet 02:30:45 but the solution is still imo the same 02:31:28 wasn't your solution to not use a swap in the first palce? 02:31:43 I said "... or not connect directly" 02:31:53 that isn't a total "do not use swaps" 02:32:05 that is a " or connect directly" 02:32:09 and I asked what does it mean to "conenct directly" when you're using a swap to make the initial deposit to your wallet 02:32:31 I mean that you should think about what that swap provider can know 02:32:41 ip, certain wallet addresses (maybe on two chains) 02:32:52 do they have an account? do they kyc? etc., what all info CAN they know about you 02:33:04 it knows how to trace the transaction they sent, that's all that matters 02:33:36 if you post your address and I send a transaction to it and that key image I know about because I created it is spent quickly I can guess you spent it 02:33:40 but what all can I know about you? 02:33:46 I can google Guest0 02:33:56 if I ran the matrix server I might be able to maliciously log some ips on you 02:34:01 maybe your email address 02:34:24 ok I see. well since the other side of the swap exchange does not come from monero, then obviously it's not anonymous 02:34:41 not impossibly 02:34:54 for most users, that is going to be the case 02:35:24 it's most likely a bitcoin wallet funded using a centralised onramp 02:35:31 with KYC 02:35:39 I also wasn't precise with my output vs. key image terminology which I mixed up a bit 02:37:40 I used key image and output basically interchangeably and that's wrong. a swap provider in creating an output can see when that is used in the future but can't know whether it's a decoy or the "real spend" 02:38:01 the bridge and everything before it is not anonymised. and if it's and edge case where it's anonymised (e.g you minted bitcoin in 2010), then the use case for monero decreases anyway 02:38:22 whereas neither swap services/exchanges nor remote nodes create key images, sorry, those are created at spend 02:38:45 well, however you access whatever bridge, swap, exchange, etc., is up to you 02:39:31 it's important to assume that the bridge is not used anonymously, for this conversation to be helpful 02:40:01 that's dumb 02:40:07 use your bridge anonymously 02:40:14 why are you not using your bridge anonymously? 02:40:39 we're going in cricles 02:40:41 but no, you're right, you risk leaking information at basically every step 02:40:56 rings perhaps 02:43:20 menro stronk, not concerned > I'm reading about menro and this seems pretty concerning? https://monero.fail/opsec 02:43:32 git gud 02:44:10 no, sorry, again, that's rude of me, and a bit unhelpful to dismiss concerns 02:44:41 it's good you're thinking about the various ways in which users can have some of their privacy degraded and we have good news 02:48:55 based on the sources I've posted, it seems to me that the most effective way to mitigate this attack vector is to split the initial bridge deposit into multiple chunks, then either do a sweep_all once, or break it down into stages using the transfer command (using it with the specific transactions outputs). if anyone is familiar with this specific 02:48:55 attack vector, I want to know if this will be effective. 02:49:47 I wouldn't recommend splitting it into chunks then spending those separate chunks together 02:50:05 I would churn everything received as many times as you can afford to ... 2, 5, 10 02:50:05 jbabb please let other people answer now 02:50:09 before joining them together 02:50:12 if you use accounts 02:50:23 you can track how many times you're churned by the index of the subaddress 02:50:37 once you get to address 9 (or whatever) you can consolidate accounts together 02:51:47 splitting the initial "bridge deposit" and joining them together negates any benefit splitting would have which isn't necessarily going to help at all 02:52:06 splitting would necessitate churning before rejoining them 02:54:09 sorry, that last statement isn't exactly right either: it's more that if you split them up and join them together you're linking them again unless you do due diligence and churn 02:54:26 but no, avoid sweep_all 02:55:19 (and due diligence isn't JUST churning, it's also includes if you're using a light wallet server or remote node) 02:55:59 yes, use transfer and coin control, but also if you create distinct accounts for each service and sweep_all internal to that and churn it, that's better than combining things together without churning 02:56:54 so if Swap Service A creates a bunch of outputs and sends you a bunch of dust trying to track when you spend things together and you sweep it all together, well, you've broken the link in that one sweep and each churn adds chances that it's a decoy rather than a "true spend", basically 02:57:26 I generally don't recommend accounts because you can easily forget to activate accounts on restore later and they aren't widely supported, but all the official wallets do 02:58:09 Cake Wallet does tho iirc 02:58:31 I don't think they show the subaddress index you're at tho, do they? 03:00:53 so like let's say there's a ransomware group that's receiving monero and swapping it for btc then selling it on an exchange 03:01:03 or fill in the group 03:01:28 jesus you've just burried my question for a second time... 03:01:52 well, that's not the best example, because that's not exactly what your video or article were referencing 03:02:21 > based on the sources I've posted, it seems to me that the most effective way to mitigate this attack vector is to split the initial bridge deposit into multiple chunks, then either do a sweep_all once 03:02:21 no 03:02:40 > or break it down into stages using the transfer command 03:02:41 better but not always yes 03:03:01 which part of "let other people answer" was not clear? 03:03:27 alright so I have been thinking 03:03:38 about these seeeed formats 03:03:49 polyseed? yes, please! but I need more words 03:03:54 16 words is just not enough for my security needs 03:04:21 logorrhea is a treatable condition 03:05:13 I won't be happy til we have at least kb addresses 03:06:05 also, new proposal: cut to doom and gloom, we're blooming, baby 03:07:11 I know nobody's brave enough to say it, but I will: Monero has the most welcoming and good natured community of any crypto online and the haters are gaslighting us that we have serious talent retention issues due to assholes 03:09:16 btw, are you Diego’s brother? the ramblings and musings are similar 03:09:42 summoned by my lover again 03:10:04 are you Diego's brother and he appears 03:10:11 I hope that means yes 💓 03:10:20 sorry to shitpost on main boss... 03:13:32 > based on the sources I've posted, it seems to me that the most effective way to mitigate this attack vector is to split the initial bridge deposit into multiple chunks, then either do a sweep_all once, or break it down into stages using the transfer command (using it with the specific transactions outputs). if anyone is familiar with this specific 03:13:32 Plz don't do this, this is the worst possible thing you do can do to affect on-chain traceability 03:14:30 3/3 j.babb, j.effro and j.ofrn all agree 03:15:05 4 out of 5 menro users agree 03:15:28 Maybe what could be worse is putting a PGP signature and SSN announcing that you are the spender of that tx 03:17:09 If you must churn, do sweep_single's with long random delays b/t each step. NEVER EVER UNDER ANY CIRCUMSTANCES RECOMBINE 03:19:46 Yo 03:19:54 up above where I said each service / counterparty should get their own account: to be more accurate, I should say: each session should get its own account 03:19:54 so if you use Swap Service A in two sessions, you want to churn those outputs separately and not sweep_all them together 03:20:16 however, practically speaking, I just churn things a lot before joining outputs 03:20:58 FWIW CLI, RPC, GUI, and Cake wallet all show subaddress indices > <@jbabb:cypherstack.com> I don't think they show the subaddress index you're at tho, do they? 03:21:27 nice, Cake Wallet. hope those stick around thru the redesign 03:21:27 accounts are helpful for me for tracking how churned an output from a session is 03:21:38 or rather, the subaddress index in an account 03:21:55 @jeffro256: Monfluo too 03:26:05 @jeffro256: Oh, I usually just combine all into one output. This is not ideal? 03:26:21 *why is it not ideal 03:27:01 @lza_menace: It is ideal if youre just cleasing a bunch on poison into a de-poisoned output 03:27:44 But counter-intuitive if you are actively acquiring 100 different inputs with a goal of gaining a privacy advantage 03:28:17 if someone knows about multiple outputs and have logged information / metadata about them and then you spend them together, that can link them 03:28:55 @ofrnxmr:xmr.mx: ONLY if you know that the poisoned outputs are from the same person 03:29:23 Its counterproductive if its from multiple entities 03:29:28 @jbabb:cypherstack.com: But only on the first spend, not after consolidation / churning rounds? 03:30:10 their guess is less and less sure with each hop / churn 03:30:13 avoid consolidation 03:30:21 if you have to, be careful about it 03:30:36 @jeffro256: If its from multiple entities, its a matter of whether you are hiding that you own(ed) them all, or whether you are hiding ehere they are being spent 03:30:53 If the former, combinibg rhem will expose that one person owns them all 03:30:57 This is a bit misleading because the new output is still poisoned because the poison collection tx is so traceable . so if you do this , you must also assume that the new one is poisoned and should churn it by itself > <@ofrnxmr:xmr.mx> It is ideal if youre just cleasing a bunch on poison into a de-poisoned output 03:31:15 churn before and after consolidation 03:31:19 @ofrnxmr:xmr.mx: but will protect spend privacy when you finally come to spend them 03:31:36 @jbabb:cypherstack.com: or rather: if you have to consolidate, you have to churn 03:32:04 @jeffro256: Yes 03:32:15 @jbabb:cypherstack.com: Yes 03:33:36 If you dont consolidate them before churning, (if you churn them separately) and then combine the small churned outputs == you essentially make is statistically likely that those churns are the original poison 03:34:40 So if i have 100x1xmr poisoned outputs, and sweep_single them, then combine them in a 10, its harder but still relatively easy for softwsre to map out thst tese 03:36:13 So i recommend cutting the link early - combining them into a single input, exposing that a single user owned them all - then churning, then resplitting if necessary 03:36:49 And i recommend splitting into churns of 1 output (+ change to yourself), otherwise you again create standout txa 03:37:39 @ofrnxmr:xmr.mx: eh, avoid consolidation. I have to restudy the churning papers and discussions but I had filed it all under "the more, the merrier" and recommend churning before consolidation 03:37:42 like, dont split your churn into 4 outputs in a single tx, cuz youre the only one making txs like that 03:37:55 Split it so the txs are 1in/2out or 2in/2out 03:38:37 before and after of course 03:38:40 @jbabb:cypherstack.com: I recommend the opposite. Consolidating before churning. Or even churning -> consolidating -> churning 03:38:52 also, I prefer to consolidate bit by bit 03:39:21 I'm so glad we get to stop worrying about this soon 03:39:32 so if Swap Service A, B, and C have separate accounts, they'd all get churned separately, then A and B would be consolidated into D and churned until it could be consolidated with C 03:40:10 @jbabb:cypherstack.com: This doesnt really helpbsince youre just leaving a paper trail. Just yolo consolidate (if u dont care abiut "use john doe owns all of these inputs", then churn and split however u like 03:40:50