14:14:53 Great news; the CLSAG auditors have completed their code review, and it's extremely positive, with no security problems identified 14:15:49 Only a few select recommendations to improve the code 14:15:57 excellent! 14:16:23 Still reviewing their non-public initial draft; once corrections are made and they produce the final report, it will of course be made publicly available 14:16:34 We don't want multiple versions floating around that may contain errors 14:16:56 e.g. there were some errors corrected in the initial preprint review 16:20:23 maybe i've gone mad, but this is my new madness: https://github.com/monero-project/research-lab/issues/75 16:21:02 please let me know if I've made a critical lapse :) 16:25:11 "Radical idea: Fix Monero's iterated-EABE traceability problem and eliminate wallet scanning times by tagging outputs with a subaddress hash" 16:35:37 Would you then keep track of these to enforce single use ? 16:36:09 Hmm, that'd break various uses, nevermind. 16:36:40 So you could basically know whenever someone donates to the EFF, assuming they have a long lived donation address. 16:37:01 nononononono that would split one big anonymity set into a myriad of small anonymity puddles 16:37:09 killing the anonymity of transactions 16:37:20 chainalys would be happy 16:38:22 moneromooo you don't want to have single use addresses in a per-tx sense, but you do want to have a single subaddress issued per sender for this to work. and you're right, that can't be enforced, but i'm not even sure it is much of a privacy loss if people don't have a subaddress per sender 16:38:52 sech1 from an abstract point of view, what i'm proposed seems bad. but in reality, it's a major improvement over an anonymity size of 1. 16:39:04 people will never bother creating subaddresses per sender 16:39:25 so you're trying to fix one problem by creating problems everywhere else 16:39:38 sech1 and if they don't, please explain exactly why that's so bad 16:39:52 or how it's worse than an anonymity set size of 1 16:40:00 Because... we like privacy -_- 16:40:19 yes, and an anonymity set size of 1 ISN'T privacy! 16:40:25 I can't explain in detail now, but adding so much juicy data to analyze (16 bytes per tx) just seems wrong 16:40:53 sech1 yes, i know it seems wrong, but i challenge you to really think through if it's as wrong as it first seems 16:42:08 No. *You* make simulations that proves your system is better at privacy :) 16:42:22 (or you wait till someone's interested in making them) 16:43:06 * moneromooo better step off IRC, bad mood today 16:43:19 the problem has always been that unless i can get a dump of an exchange's data, i can't show you a huge list of highly certain transactional relationships between exchange users 16:43:24 adding so much data to the blockchain just so a wallet can avoid EABE... Maybe just add a function to wallet to churn some outputs automatically? 16:43:35 the outputs you receive to a specific subaddress 16:44:26 if churning fixed this, i wouldn't have suggested what i suggested 16:45:36 churning individual output 2-3 times does fix this 16:46:46 the chances of multipe sets of 3^11=1331 size anonymity sets intersecting when there are tens of millions of outputs in existence are tiny 16:47:38 and churning more than 2-3 times gets easily detected on the blockchain, and doesn't actually increase the anonymity set size as much as the 11^n hope would suggest 16:55:56 apart from it being crazy (you wrote yourself about stealth addresses), there's no way for miners to verify such transactions. They can't verify this 128-bit hash because they don't know recipient's address. So there will be no consensus and some modified wallets would just put random data there 16:56:06 I'd definitely modify my wallet in this way 16:57:54 heck, even exchanges can exploit this to mark all user's subaddresses with their own "hash" 16:58:15 sech1 it's crazy only because it seems crazy. I'd argue the reality is that the real craziness is that Monero is offering no untraceability where there are multiple EABE transactions 16:58:34 and if the exchange did do that, people would not locate the transactions since their wallets would be relying on it 16:59:04 wallets refusing to find already mined transaction? 16:59:20 where are the coins then? In oblivion? 16:59:22 if they rely on the 128-bit hash to locate incoming transactions, yes 16:59:40 and they're just as much in oblivion as if someone didn't put in the correct tx pub key 17:00:02 or if the new proposal is adopted, didn't put in the right ecdh tag on the output 17:00:19 not my proposal, the other view key tags proposal i mean 17:01:28 i'm trying to get people to take monero's untraceability seriously, because right now there just isn't any if someone withdraws from an excange and pays a particular merchant on more than one occasion 17:01:50 and that's collosally unacceptable 17:02:15 as is my spelling of colossally 17:02:57 serisously, this looks like crutches and not a proper well-thought solution 17:03:10 we have no idea how this data can be used to break anonymity in other ways 17:03:19 and no one has, until someone eventually figures it out 17:03:21 right, i'm not saying it requires no further thought! 17:03:42 but it's been more than 3 years now since iterate-EABE was discovered, and there has been zero progress 17:03:52 so i'm trying to get people thinking about it 17:06:02 it's very possible that there is something i've not thought of yet that makes stealth addresses advantageous. But I can't think of it so far, and I'm very interested to hear anyone's thoughts about what I might be missing. That conversation might lead somewhere 17:07:34 yes, stealth addresses. Removing them is like cutting your arm to fix a broken nail. 17:07:45 because....? 17:07:51 i'm interested in the reasoning 17:07:55 because this removes them? 17:08:01 essentially 17:08:37 right, but how does that threaten privacy for anyone issuing a subaddress per sender? if they're not issuing a subaddress per sender, they're already compromising their privacy 17:09:23 and even if they don't issue a subaddress per sender, how does that compromise their privacy in any meaningful way? 17:10:05 I don't know, we need smarter people on this ^^^ 17:10:30 my proposal might seem rash, but i've been thinking about this for nearly 4 years 17:11:39 i think stealth addresses made sense before subaddresses were introduced, and then no one really thought deeply about whether they were still necessary after subaddresses were commonplace 17:13:39 the problem i'm looking to solve here is so bad that it's as if in many situations people weren't using ring signatures at all 17:13:55  fwiw in the GUI we might switch to a system that will give you a fresh subaddress everytime: https://github.com/monero-project/monero-gui/pull/2936 17:14:26 ooh interesting, thanks selsta for pointing that out 17:14:59 (PR is not reviewed yet) 17:15:23 then how does this proposal work with one-time subaddresses? All hashes will be different them and wallet can't choose groups... 17:17:05 sech1 aha, ok that is a very valid criticism, i'll think about it 17:18:16 the solution might be to treat the "group" as all outputs received to a wallet account, rather than to a particular subaddress 17:19:20 i think that would be an improvement over my current proposal, i'll ponder it more 17:20:13 so from the wallet's perspective, the group is all outputs received to any subaddress within the account. but the decoy groups are still per-subaddress groups, because that's what's visible on the blockchain 17:20:26 and the scheme still works 17:32:00 per-subaddress groups are all of size 1 if everyone uses one-time subaddresses, right? 17:32:21 sech1 correct 17:32:57 "Take care to often choose decoy outputs that have a group size of 2 or more." 17:33:06 fail ^^^ 17:34:13 if you want to anonymity among those that withdraw xmr from an exchange on more than one occasion, then you need to use decoys at least some of the time that represent subaddresses where funds have been withdrawn to that subaddress more than once 17:34:19 it's a simple principle 17:35:04 i say 'often' and not 'always' because you also want to mix in with people that have so far only withdrawn once, but will withdraw again in the future 18:01:20 i wouldn't remove stealth addressing. "use a new address" has been recommended for bitcoin for what, 10 years? and still, ppl reuse addresses afaict 18:02:21 its removing a default and putting it in the users hands 18:02:31 humans bad. computers good 18:33:00 gingeropolous i'd like more reasoning as to specifically why what you're describing is problematic 18:33:26 it's easy for everyone to just pile in with "stealth addresses were good, therefor no stealth addresses are bad" 18:33:57 knaccc I'm going to need a diagram or something of the selection process, since I read this a few times and can't quite wrap my head around it 18:34:05 i'm looking for particular scenarios and heuristics that can be exploited 18:34:29 sgp_ sure, thanks for the feedback, i'll see if i can find a way to be clearer, with a diagram or otherwise 18:34:59 thanks, crazy ideas are awesome to review 18:44:08 the only reasoning I have is that the less the user can do to muck things up, the better. but then again, plopping your base address into an exchange is also the user mucking things up. 18:45:39 gingeropolous yes, and i'm looking for specifics on exactly what it is that could be mucked up in the worst-case scenario. i think the fear of downside is much greater than the reality of the situation 18:46:14 i agree eabe sux and not much has been done about it 18:46:28 but im a believer in ringsize 1 bajillion fixes eveuthing 18:46:33 e.g. someone used the same wallet address with everyone. now they've already messed up, and all those people can confer to figure out they're dealing with the same person 18:46:54 It's a tough statistical problem to avoid 18:46:58 "gingeropolous | but im a believer in ringsize 1 bajillion fixes eveuthing" yes, that does fix everything 18:47:19 Address testing introduces a new layer of risk, though 18:47:26 Which is also problematic 18:47:29 it certainly is a risk 18:47:42 but iterated-EABE is an extreme problem 18:47:44 As to "what risks are worse" this isn't something that can be universally assessed 18:48:16 monero basically offers zero untraceability to anyone that wants to send funds more than once to someone else 18:49:03 it's a fundamental breach of the most basic aspect of what monero promises 18:56:19 I appreciate where you're coming from, knaccc; but the proposal is a major tradeoff 18:57:39 sarang i'm more than willing to accept that the proposal may be hugely flawed. in fact i'd say it's more likely than not that it is flawed. But I'd like to hear specifics about exactly what the downsides are, in terms of scenarios and heuristics, rather than "gee, i don't know, sounds risky" 18:58:02 Address testing strikes me as the most obvious 18:58:14 can you elaborate pls? 18:59:11 Users who have longer-lived addresses, or who otherwise don't follow the single-address-per-sender idea, have addresses effectively directly exposed on chain 19:00:00 and what is the threat there, other that it being possible for someone they shared their address with to know the total sum of transactions ever sent to that address? 19:00:29 there might be timing attacks, but i'm looking to flesh out the scenarios and consider the downsides rigorously 19:01:14 and remember, anyone that doesn't issue an address-per-sender has already screwed up their privacy by allowing people to see they're dealing with the same person 19:01:50 and so the received-tx-count privacy breach is nothing compared to the identity breach 19:01:58 papercut on top of a stab wound 19:02:52 Do you see this change mitigating cases where large entities do _not_ collude in the traditional EAB...XYZE sense? 19:02:56 and the iterated-EABE is a dirct shotgun blast to the face 19:06:02 What this idea seems to do is replace one type of transaction correlation (the case for repeated payments and collusion) for another (recipient correlation for all non-"single"-use addresses to certain entities, without collusion) 19:06:12 sarang if exchanges don't peek, are not required to divulge, and aren't ever hacked, then yes there are still advantages. if Alice is an employer, Bob is an employee, and Charlie is a pro-life charity, then if C ever gets hacked, A can see that B donates regularly to C and fire B, Brendan Eich-style 19:06:19 Necessitating a more rigorous examination of relative risk, as you say 19:09:59 (in my example, the scenario of course is that it is iterated-ABC, where A pays B and B donates to C) 19:10:02 And then you'd have to determine the additional/alternate relative risk of the ISP revealing transaction information as well 19:10:14 It's a different risk, but still present without careful network mitigations 19:10:34 i2p to the rescue :) 19:10:54 or VPN 19:11:03 Sure, if you're careful 19:11:16 But all of these things assume the user is careful is certain ways 19:11:32 right, if they weren't interested in being careful, they would use bitcoin 19:11:44 Network mitigations, knowing which addresses are public/semi-public, asserting senders use different subaddresses, knowing the consequences of senders colluding, etc. 19:12:55 i agree, privacy is hard. but if it's too hard, why even bother with ring signatures 19:13:00 Nah, I get that 19:13:17 if untraceability isn't working monero, why not just use grin 19:13:19 But at some point you simply have to draw the line at how many entities are colluding, and in what ways 19:13:39 I'm not saying that should/shouldn't include an exchange breach 19:14:05 sarang can you expand a bit on the "hot many entities colluding bit" 19:15:04 Entities like senders, exchanges, governments, ISPs, etc. 19:15:12 All introduce different risks 19:15:37 and different ways those entities could pool data to gain information 19:15:45 ah ok, i thought you might have meant multiple monero entities 19:16:59 i think it'd be sad if we had to roll back monero's value proposition to just fungibility, and not untraceability 19:17:25 FWIW I hate the term untraceability 19:17:31 how come 19:18:06 Because it's a very absolute term, whereas using any digital asset implies interacting with entities that necessarily introduce some risks 19:18:10 becuase it gives a false impression of the extent of untraceability on offer, when outside-of-monero issues are considered such as ISPs? 19:18:11 like those I mentioned above 19:18:14 right 19:18:16 yeah i see 19:18:35 I've suggested several times before to stop using that word 19:19:16 At some point, with enough things going wrong with user actions or collusion or breaches or whatnot, you are certain to arrive at a point where _any_ particular product or asset is unsuitable for a particular use case and threat model 19:19:31 This isn't to say that improvements are useless, obviously 19:20:05 yeah it's a good point 19:20:42 So as an example, whether address testing is better or worse than the breach-collusion example depends entirely on your threat model and use cases 19:22:01 On one hand, you could argue that exchanges _do_ get breached, and that this is far worse in consequence than address linking 19:22:39 On the other hand, you could argue that address linking requires no collusion, but with different potential consequences... and that an exchange breach probably leaks a ton of other personal information that could be used by bad actors in non-Monero ways 19:22:55 the address-testing issue doesn't cause address-linking. if a subaddress isn't issued per sender, the address-linking was already there 19:23:24 Sorry, I should have said address testing... typed faster than my brain there 19:23:25 all address-testing exposes is the number of outputs sent to a particular subaddress 19:23:37 oh ok 19:24:13 yeah i'm interested in fleshing out these threats 19:24:31 i'd assume an exchange breach where untraceability holds up is not all that much of a threat 19:24:42 you just get to see how much someone cashed in or out 19:24:51 where they spent, or who spend with them, is far more damaging 19:24:59 spent* 19:25:12 Well, having some form of a rich list linked to identity could be dangerous as well 19:25:34 People will large holdings/activity are already exposed to real-world threats partly on that basis 19:25:58 yeah, i think that's probably an unfixable problem wrt exchanges 19:26:06 unless they're kyc-free 19:26:10 I don't claim to have a good way to quantify these risks relative to each other in a universal way 19:26:21 yet :) 19:28:39 FWIW the point of the Breaking Monero video series was to be open and transparent about some of these current protocol limitations 19:28:53 oh yeah i know 19:29:07 and i'm very proud of the openness the community tends to have with these issues 19:29:34 having said that, the homepage says "You can spend safely, knowing that others cannot see your balances or track your activity" 19:29:58 it's technically true 19:30:13 because others doesn't explicitly state "all others" 19:30:31 Well, it used to use the phrasing "reasonably private" which I liked 19:30:51 It was a quick way to mention that "private" isn't an on-or-off switch, with anything 19:31:32 Unfortunately a thorough analysis of threat models is not exciting or fun 19:32:21 I've been asked before things like "well, what if you were targeted by some major state-level actor?" 19:32:52 And my typical answer now is something like "then it's probably not totally safe to use _any_ digital tools of any kind, or the internet, etc." 19:32:59 well a state-level actor can just 0-day your OS/phone and bypass anything monero could every do 19:33:06 yup 19:33:12 That's an extreme example, of course 19:33:48 A strong stance to take would be a very narrowly-defined threat model, with no claims or guarantees outside of it 19:34:03 i am a very concrete thinker 19:34:45 so when i think about why monero is useful, it's to e.g. donate to pro-life without getting fired in a blue state, or to donate to planned parenthood without getting fired in a red state 19:35:04 and it's possible i'm focusing on something that isn't what others look to monero to provide 19:35:56 Something tangentially related to this, which I've brought up before, is that I don't know of circumstances where the plausible deniability of something like Monero's ring signatures or Zcash's shielded pools has been linked to specific tests in real-world scenarios 19:36:11 One extreme example is "oh, you used Monero/Zcash/whatever... you're fired" 19:36:29 Another is "oh, this output has a possible spend path... you're fired" 19:36:44 Another is "oh, multiple possible spends with some statistical likelihood... you're fired" 19:37:00 yeah i've never heard of a wallet/exchange breach involving monero txs 19:37:29 So in some sense it's throwing darts with a blindfold on 19:37:32 but then, if we don't have to worry about exchange breaches, we're back to "why not use btc" 19:38:23 Well, there's zero on-chain plausible deniability for transaction paths there, which is _something_ 19:38:25 and the best answer is fungibility if we don't have untraceability 19:38:30 Every output in a transaction definitely signed 19:39:28 The consequences of that (non)-deniability do certainly depend on later identity links, which analysis companies certainly work to do 19:41:27 Anyway, this is a fascinating conversation to have, and I'm very glad you're considering such threat models in detail 19:41:35 Your proposal is certainly bold 19:42:09 heh yeah i apologize if anyone thinks i'm pushing this point too hard. i tend to try to push it in proportion to whether there might be anything we can do to resolve it 19:43:36 Well, it's exceptionally difficult to translate relative real-world risk to concrete technical choices 19:44:20 Shift one piece of the protocol and the whole balance can change in unexpected ways 19:44:54 That being said, good analysis on this interplay of tradeoffs is elusive 19:51:30 maybe i'm missing something, but i think that given the choice between "1. if you're not careful, and give the same address to multiple people, those people will be able to see the total count of outputs received to that address, and therefore see how often other people send funds to you" and "2. if you withdraw from an exchange and send funds to someone on more than one occasion, you have zero 19:51:32 untraceability", that doesn't even seem like a remotely-close contest to me 19:53:13 Depends on how much you trust those people, or how much you trust that exchange 19:54:51 i can't think of a scenario where breach of a received-output count is ever remotely close to being worse than breach of untraceability, with your real-world identity suddenly linked to the real-world identity of the person you're transacting with 19:55:51 i think i see your point that if an exchange is perfectly secure and hack-proof, you never worry about the untraceability leak wrt the exchange 19:56:16 but i think we have to assume an eventual exchange breach 19:56:25 it's just a question of when 19:56:43 Does the proposed output selection method's effectiveness depend on using groups from _that exchange's_ customers? 19:56:53 no 19:57:36 it can't tell whether any other output-groupings it sees relate to users of an exchange 19:58:00 all it can see is a grouping of outputs that must have been sent to the same subaddress 19:58:13 No, but I mean from the perspective of the exchange breach/collusion 19:58:30 I'm trying to work through some examples of the implications of the selection method in the event of public breach, collusion, etc. 19:58:45 (but only somewhat... also working on Arcturus stuff that's due tonight) 19:59:24 Obviously the wallet doesn't know anything about exchange customers 19:59:30 i don't think i understand your question 20:00:02 oh i think i see 20:00:13 Suppose the exchange records are leaked 20:00:20 ok pls continue 20:00:24 You have entities trying to trace things 20:00:44 Senders/recipients who are not the exchange 20:00:46 The exchange 20:00:47 etc. 20:01:06 and I'm thinking through what the effects of the selection algorithm are in different scenarios 20:01:20 e.g. do certain decoy groupings come from the _same_ exchange list? 20:01:39 or from other random unknown (yet) subaddresses 20:01:42 and so on 20:01:59 it helps in any ABC scenario or AB...C scenario where C leaks wallet info. 20:02:40 and then you'd have to know how much more effective it is (statistically) based on things like overall ring size relative to number of repeated transactions, etc. 20:03:11 yeah to really nail down how severe this iterared-eabe intersection attack is, i'd need exchange records 20:03:28 If it's still extremely likely that the entities can identify likely spends based on this, then you killed address testing protection for perhaps a minimal gain 20:03:38 agreed 20:03:47 so you need to quantify how _many_ repeats you're ok with 20:03:48 it's definitely a bad idea if it doesn't work 20:03:51 etc. 20:04:00 by repeats, you mean eabe iterations? 20:04:21 Separate transactions between the same (eventual) parties 20:04:31 i think your'e screwed with just two passages through the EABE loop 20:04:42 Since this all hinges on the idea that you're making repeat spends 20:04:47 but almost certainly screwed with 3 passages 20:05:06 oh absolutely, untraceability is totally intact if you only pay someone once, ever 20:05:15 actually that's not quite true 20:05:36 if you do ABC, then ABD, if both C and D are hacked, untraceability is broken 20:05:51 Anyway, what I'm getting at is that the effectiveness of this method seems to rely pretty heavily on the interplay between the number of repeated spends, the ring size, number of possible hops, etc. 20:05:54 because it's then as if C and D are one entity for the purposes of examining the link 20:06:56 yeah one of the biggest flaws that might become apparently is whether someone that makes 12 iterations through EABE can be protected if the decoy groups all have a group size of considerably fewer than 12 20:07:03 apparent* 20:07:43 the figure 12 is arbitrary, i just mean an imbalance between user iterations and group size of decoys 20:07:51 aye 20:08:39 btw if you need to get back to your deadline, pls do. thanks for thinking this through with me 20:09:12 It's tricky because you can build something against a particular threat model, and someone will show up and say AHA, it doesn't work against (threat model)+1 ! 20:09:15 -___- 20:09:41 yes, it'll need a lot of lateral thinking from as many people as possible 20:10:31 Well, and at some point any protocol decision is going to be useful against some threats, marginal against others, and not useful against still others 20:10:40 regardless of how much thinking and designing you do 20:10:55 Which is somewhere between realistic and nihilistic =p 20:11:20 haha 20:12:32 I'm still of the opinion that Monero does a damn fine job for the typical user 20:12:51 and that using basically anything makes it far more likely to introduce practical tracing and linking through typical use 20:13:00 (e.g. Zcash pool transitions, etc.) 20:13:13 Which isn't to say that's a reason not to iterate and improve, of course 20:14:59 Certainly highlights that exchanges are a big weak point, both for Monero and for something like Zcash 20:18:04 i really don't understand how "zero untraceability if you buy xmr and send to someone more than once" can ever be considered anything close to a damn fine job 20:18:35 On the assumption of collusion, breach, or leaks? 20:18:53 when placed in context of the advantage of xmr over btc in terms of traceability 20:18:57 I can tell that's a risk that you care a lot about :) 20:19:30 heh maybe the fundamental issue is that i think that untraceability is by far the #1 part of the value proposition 20:19:51 because if it isn't, i don't see much reason to use xmr other than fungibility 20:20:16 eh? there is no fungibility without untraceability 20:21:01 hyc fungiblity means that when i make my tx, it isn't rejected in the moment. untraceability means my transactional relationship with someone is still private, even if an exchange wants to snoop or is hacked 20:22:21 Unfortunately I need to get back to the Arcturus revision stuff, due to a deadline, sorry 20:22:23 it means your coins have no discernible history 20:23:10 hyc i take back what i said. i'll see if i can try again to explain what i mean 20:28:40 hyc ok here is what i mean: consider a PAB scenario. P is planned parenthood, and employs and pays A. A then buys ramen noodles from B. In the moment, B can't trace the origin of the funds back to A, so can't reject the purchase out of political distaste for anyone employed by PP. So there is fungibility in the moment. But one day, B may be hacked, and now P can see that A was spending with B, so 20:28:42 untraceability is lost. So there is a time dimension. 20:29:45 s/trace the origin of the funds back to A/trace the origin of the funds back to B 20:29:45 knaccc meant to say: hyc ok here is what i mean: consider a PAB scenario. P is planned parenthood, and employs and pays A. A then buys ramen noodles from B. In the moment, B can't trace the origin of the funds back to B, so can't reject the purchase out of political distaste for anyone employed by PP. So there is fungibility in the moment. But one day, B may be hacked, and now P can see that A was spending with B, so 20:29:54 doh i screwed it up a second time 20:30:02 s/trace the origin of the funds back to A/trace the origin of the funds back to P 20:30:02 knaccc meant to say: hyc ok here is what i mean: consider a PAB scenario. P is planned parenthood, and employs and pays A. A then buys ramen noodles from B. In the moment, B can't trace the origin of the funds back to P, so can't reject the purchase out of political distaste for anyone employed by PP. So there is fungibility in the moment. But one day, B may be hacked, and now P can see that A was spending with B, so 20:31:53 ...untraceability is lost. So there is a time dimension. 20:32:26 your actors are still confused. why does P care where their employee A spent his funds? 20:33:06 my particular scenario doesn't say P would care. but this is an example where there is fungibility in the moment, and then suddenly traceability later 20:33:07 the implication is that B getting hacked gives P info. why would P obtain that info, unless P hacked B? 20:33:42 P doesn't have to back B. P just needs to observe a hack of B when it is leaked 20:33:49 i should come up with a scenario where P would care 20:34:08 the point is though, there was fungiblity without untraceability 20:34:20 because it was eventual untraceability 20:36:20 or a variation on that is when an exchange can clearly see EABE happening, and E doesn't care about rejecting funds from B on political grounds, but B would want to reject funds from A on political grounds if it had the ability to break the untraceability in the way that E can in real-time 20:37:37 so it can because of a time dimension or a difference in visibility 20:37:40 this sounds unsolveable, if you also require that senders be able to prove they sent txns 20:38:50 hyc i'm asking senders to tag outputs with the hash of the destination subaddress. so in theory, if the wallet can make intelligent decoy selections such that E has no visibility, then there is no eventual untraceability 20:39:15 or it can be solved with a gigantic ring size 20:40:00 the ring size can be infinite, still doesn't solve the problem that a sender can see when a recipient spends their output 20:40:20 at least 1 extra hop will always be required, regardless of ringsize 20:40:48 oh i see, you're talking about a timing attack 20:42:56 hyc hmmm i wonder if you can properly spell out your scenario, my mind is trying to consider all sorts of possiblities of what you're saying at once 20:43:19 i don't think i'm quite following 20:43:53 right now, a sender can always see when the recipient truly spends the output that the sender sent 20:44:15 but the ring signature prevents that? 20:44:18 they always have perfect knowledge that that output is getting spent 20:45:34 this is the underpinning of an EABE attack isn't it? 20:45:45 oh sorry you're talking about a breach scenario 20:45:49 yes 20:46:11 ok so in iterated-EABE, yes the exact txns and outputs can be determined 20:46:29 but only if an intersection attack is possible 20:46:39 the point of my proposal is to prevent the intersection attack 20:47:01 by having an intersection that is much greater than 1 20:47:45 you want to tag outputs so that in PAB, A can choose to send outputs to B that didn't come from P 20:48:49 oh, no, that's not what i am proposing, maybe it was poorly explained 20:49:04 i'm proposing that A is still able to send outputs to B that came from P 20:49:16 but in a way that causes an intersection of anonymity sets that is greater than 1 20:49:23 and is thus genuinely untraceable 20:50:13 because decoys are selected such that the is a greater overlap of anonymity sets 20:50:37 and that cleverer decoy selection is only possible if outputs are tagged with a hash of the destination subaddress 20:52:44 so this only works if sending to a subaddress? 20:53:42 consider all of my uses of the term subaddress to be inclusive of the main wallet address as the one of the subaddresses 20:54:01 ok 20:57:10 i'm working on a diagram to try and explain this more clearly. it remains questionable as to whether i can achieve that 22:51:08 <@sarang> It's tricky because you can build something against a particular threat model, and someone will show up and say AHA, it doesn't work against (threat model)+1 ! 22:51:13 Can we call this "obstruction by induction" 22:51:37 ahahaha that's fantastic Isthmus 22:51:43 yes plz