-
sarang
Great news; the CLSAG auditors have completed their code review, and it's extremely positive, with no security problems identified
-
sarang
Only a few select recommendations to improve the code
-
hyc
excellent!
-
sarang
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
-
sarang
We don't want multiple versions floating around that may contain errors
-
sarang
e.g. there were some errors corrected in the initial preprint review
-
knaccc
maybe i've gone mad, but this is my new madness:
monero-project/research-lab #75
-
knaccc
please let me know if I've made a critical lapse :)
-
knaccc
"Radical idea: Fix Monero's iterated-EABE traceability problem and eliminate wallet scanning times by tagging outputs with a subaddress hash"
-
moneromooo
Would you then keep track of these to enforce single use ?
-
moneromooo
Hmm, that'd break various uses, nevermind.
-
moneromooo
So you could basically know whenever someone donates to the EFF, assuming they have a long lived donation address.
-
sech1
nononononono that would split one big anonymity set into a myriad of small anonymity puddles
-
sech1
killing the anonymity of transactions
-
sech1
chainalys would be happy
-
knaccc
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
-
knaccc
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.
-
sech1
people will never bother creating subaddresses per sender
-
sech1
so you're trying to fix one problem by creating problems everywhere else
-
knaccc
sech1 and if they don't, please explain exactly why that's so bad
-
knaccc
or how it's worse than an anonymity set size of 1
-
moneromooo
Because... we like privacy -_-
-
knaccc
yes, and an anonymity set size of 1 ISN'T privacy!
-
sech1
I can't explain in detail now, but adding so much juicy data to analyze (16 bytes per tx) just seems wrong
-
knaccc
sech1 yes, i know it seems wrong, but i challenge you to really think through if it's as wrong as it first seems
-
moneromooo
No. *You* make simulations that proves your system is better at privacy :)
-
moneromooo
(or you wait till someone's interested in making them)
-
» moneromooo better step off IRC, bad mood today
-
knaccc
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
-
sech1
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?
-
sech1
the outputs you receive to a specific subaddress
-
knaccc
if churning fixed this, i wouldn't have suggested what i suggested
-
sech1
churning individual output 2-3 times does fix this
-
knaccc
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
-
knaccc
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
-
sech1
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
-
sech1
I'd definitely modify my wallet in this way
-
sech1
heck, even exchanges can exploit this to mark all user's subaddresses with their own "hash"
-
knaccc
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
-
knaccc
and if the exchange did do that, people would not locate the transactions since their wallets would be relying on it
-
sech1
wallets refusing to find already mined transaction?
-
sech1
where are the coins then? In oblivion?
-
knaccc
if they rely on the 128-bit hash to locate incoming transactions, yes
-
knaccc
and they're just as much in oblivion as if someone didn't put in the correct tx pub key
-
knaccc
or if the new proposal is adopted, didn't put in the right ecdh tag on the output
-
knaccc
not my proposal, the other view key tags proposal i mean
-
knaccc
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
-
knaccc
and that's collosally unacceptable
-
knaccc
as is my spelling of colossally
-
sech1
serisously, this looks like crutches and not a proper well-thought solution
-
sech1
we have no idea how this data can be used to break anonymity in other ways
-
sech1
and no one has, until someone eventually figures it out
-
knaccc
right, i'm not saying it requires no further thought!
-
knaccc
but it's been more than 3 years now since iterate-EABE was discovered, and there has been zero progress
-
knaccc
so i'm trying to get people thinking about it
-
knaccc
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
-
sech1
yes, stealth addresses. Removing them is like cutting your arm to fix a broken nail.
-
knaccc
because....?
-
knaccc
i'm interested in the reasoning
-
sech1
because this removes them?
-
sech1
essentially
-
knaccc
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
-
knaccc
and even if they don't issue a subaddress per sender, how does that compromise their privacy in any meaningful way?
-
sech1
I don't know, we need smarter people on this ^^^
-
knaccc
my proposal might seem rash, but i've been thinking about this for nearly 4 years
-
knaccc
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
-
knaccc
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
-
selsta
fwiw in the GUI we might switch to a system that will give you a fresh subaddress everytime:
monero-project/monero-gui #2936
-
knaccc
ooh interesting, thanks selsta for pointing that out
-
selsta
(PR is not reviewed yet)
-
sech1
then how does this proposal work with one-time subaddresses? All hashes will be different them and wallet can't choose groups...
-
knaccc
sech1 aha, ok that is a very valid criticism, i'll think about it
-
knaccc
the solution might be to treat the "group" as all outputs received to a wallet account, rather than to a particular subaddress
-
knaccc
i think that would be an improvement over my current proposal, i'll ponder it more
-
knaccc
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
-
knaccc
and the scheme still works
-
sech1
per-subaddress groups are all of size 1 if everyone uses one-time subaddresses, right?
-
knaccc
sech1 correct
-
sech1
"Take care to often choose decoy outputs that have a group size of 2 or more."
-
sech1
fail ^^^
-
knaccc
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
-
knaccc
it's a simple principle
-
knaccc
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
-
gingeropolous
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
-
gingeropolous
its removing a default and putting it in the users hands
-
gingeropolous
humans bad. computers good
-
knaccc
gingeropolous i'd like more reasoning as to specifically why what you're describing is problematic
-
knaccc
it's easy for everyone to just pile in with "stealth addresses were good, therefor no stealth addresses are bad"
-
sgp_
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
-
knaccc
i'm looking for particular scenarios and heuristics that can be exploited
-
knaccc
sgp_ sure, thanks for the feedback, i'll see if i can find a way to be clearer, with a diagram or otherwise
-
sgp_
thanks, crazy ideas are awesome to review
-
gingeropolous
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.
-
knaccc
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
-
gingeropolous
i agree eabe sux and not much has been done about it
-
gingeropolous
but im a believer in ringsize 1 bajillion fixes eveuthing
-
knaccc
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
-
sarang
It's a tough statistical problem to avoid
-
knaccc
"gingeropolous | but im a believer in ringsize 1 bajillion fixes eveuthing" yes, that does fix everything
-
sarang
Address testing introduces a new layer of risk, though
-
sarang
Which is also problematic
-
knaccc
it certainly is a risk
-
knaccc
but iterated-EABE is an extreme problem
-
sarang
As to "what risks are worse" this isn't something that can be universally assessed
-
knaccc
monero basically offers zero untraceability to anyone that wants to send funds more than once to someone else
-
knaccc
it's a fundamental breach of the most basic aspect of what monero promises
-
sarang
I appreciate where you're coming from, knaccc; but the proposal is a major tradeoff
-
knaccc
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"
-
sarang
Address testing strikes me as the most obvious
-
knaccc
can you elaborate pls?
-
sarang
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
-
knaccc
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?
-
knaccc
there might be timing attacks, but i'm looking to flesh out the scenarios and consider the downsides rigorously
-
knaccc
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
-
knaccc
and so the received-tx-count privacy breach is nothing compared to the identity breach
-
knaccc
papercut on top of a stab wound
-
sarang
Do you see this change mitigating cases where large entities do _not_ collude in the traditional EAB...XYZE sense?
-
knaccc
and the iterated-EABE is a dirct shotgun blast to the face
-
sarang
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)
-
knaccc
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
-
sarang
Necessitating a more rigorous examination of relative risk, as you say
-
knaccc
(in my example, the scenario of course is that it is iterated-ABC, where A pays B and B donates to C)
-
sarang
And then you'd have to determine the additional/alternate relative risk of the ISP revealing transaction information as well
-
sarang
It's a different risk, but still present without careful network mitigations
-
knaccc
i2p to the rescue :)
-
knaccc
or VPN
-
sarang
Sure, if you're careful
-
sarang
But all of these things assume the user is careful is certain ways
-
knaccc
right, if they weren't interested in being careful, they would use bitcoin
-
sarang
Network mitigations, knowing which addresses are public/semi-public, asserting senders use different subaddresses, knowing the consequences of senders colluding, etc.
-
knaccc
i agree, privacy is hard. but if it's too hard, why even bother with ring signatures
-
sarang
Nah, I get that
-
knaccc
if untraceability isn't working monero, why not just use grin
-
sarang
But at some point you simply have to draw the line at how many entities are colluding, and in what ways
-
sarang
I'm not saying that should/shouldn't include an exchange breach
-
knaccc
sarang can you expand a bit on the "hot many entities colluding bit"
-
sarang
Entities like senders, exchanges, governments, ISPs, etc.
-
sarang
All introduce different risks
-
sarang
and different ways those entities could pool data to gain information
-
knaccc
ah ok, i thought you might have meant multiple monero entities
-
knaccc
i think it'd be sad if we had to roll back monero's value proposition to just fungibility, and not untraceability
-
sarang
FWIW I hate the term untraceability
-
knaccc
how come
-
sarang
Because it's a very absolute term, whereas using any digital asset implies interacting with entities that necessarily introduce some risks
-
knaccc
becuase it gives a false impression of the extent of untraceability on offer, when outside-of-monero issues are considered such as ISPs?
-
sarang
like those I mentioned above
-
knaccc
right
-
knaccc
yeah i see
-
sarang
I've suggested several times before to stop using that word
-
sarang
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
-
sarang
This isn't to say that improvements are useless, obviously
-
knaccc
yeah it's a good point
-
sarang
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
-
sarang
On one hand, you could argue that exchanges _do_ get breached, and that this is far worse in consequence than address linking
-
sarang
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
-
knaccc
the address-testing issue doesn't cause address-linking. if a subaddress isn't issued per sender, the address-linking was already there
-
sarang
Sorry, I should have said address testing... typed faster than my brain there
-
knaccc
all address-testing exposes is the number of outputs sent to a particular subaddress
-
knaccc
oh ok
-
knaccc
yeah i'm interested in fleshing out these threats
-
knaccc
i'd assume an exchange breach where untraceability holds up is not all that much of a threat
-
knaccc
you just get to see how much someone cashed in or out
-
knaccc
where they spent, or who spend with them, is far more damaging
-
knaccc
spent*
-
sarang
Well, having some form of a rich list linked to identity could be dangerous as well
-
sarang
People will large holdings/activity are already exposed to real-world threats partly on that basis
-
knaccc
yeah, i think that's probably an unfixable problem wrt exchanges
-
knaccc
unless they're kyc-free
-
sarang
I don't claim to have a good way to quantify these risks relative to each other in a universal way
-
knaccc
yet :)
-
sarang
FWIW the point of the Breaking Monero video series was to be open and transparent about some of these current protocol limitations
-
knaccc
oh yeah i know
-
knaccc
and i'm very proud of the openness the community tends to have with these issues
-
knaccc
having said that, the homepage says "You can spend safely, knowing that others cannot see your balances or track your activity"
-
knaccc
it's technically true
-
knaccc
because others doesn't explicitly state "all others"
-
sarang
Well, it used to use the phrasing "reasonably private" which I liked
-
sarang
It was a quick way to mention that "private" isn't an on-or-off switch, with anything
-
sarang
Unfortunately a thorough analysis of threat models is not exciting or fun
-
sarang
I've been asked before things like "well, what if you were targeted by some major state-level actor?"
-
sarang
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."
-
knaccc
well a state-level actor can just 0-day your OS/phone and bypass anything monero could every do
-
sarang
yup
-
sarang
That's an extreme example, of course
-
sarang
A strong stance to take would be a very narrowly-defined threat model, with no claims or guarantees outside of it
-
knaccc
i am a very concrete thinker
-
knaccc
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
-
knaccc
and it's possible i'm focusing on something that isn't what others look to monero to provide
-
sarang
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
-
sarang
One extreme example is "oh, you used Monero/Zcash/whatever... you're fired"
-
sarang
Another is "oh, this output has a possible spend path... you're fired"
-
sarang
Another is "oh, multiple possible spends with some statistical likelihood... you're fired"
-
knaccc
yeah i've never heard of a wallet/exchange breach involving monero txs
-
sarang
So in some sense it's throwing darts with a blindfold on
-
knaccc
but then, if we don't have to worry about exchange breaches, we're back to "why not use btc"
-
sarang
Well, there's zero on-chain plausible deniability for transaction paths there, which is _something_
-
knaccc
and the best answer is fungibility if we don't have untraceability
-
sarang
Every output in a transaction definitely signed
-
sarang
The consequences of that (non)-deniability do certainly depend on later identity links, which analysis companies certainly work to do
-
sarang
Anyway, this is a fascinating conversation to have, and I'm very glad you're considering such threat models in detail
-
sarang
Your proposal is certainly bold
-
knaccc
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
-
sarang
Well, it's exceptionally difficult to translate relative real-world risk to concrete technical choices
-
sarang
Shift one piece of the protocol and the whole balance can change in unexpected ways
-
sarang
That being said, good analysis on this interplay of tradeoffs is elusive
-
knaccc
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
-
knaccc
untraceability", that doesn't even seem like a remotely-close contest to me
-
sarang
Depends on how much you trust those people, or how much you trust that exchange
-
knaccc
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
-
knaccc
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
-
knaccc
but i think we have to assume an eventual exchange breach
-
knaccc
it's just a question of when
-
sarang
Does the proposed output selection method's effectiveness depend on using groups from _that exchange's_ customers?
-
knaccc
no
-
knaccc
it can't tell whether any other output-groupings it sees relate to users of an exchange
-
knaccc
all it can see is a grouping of outputs that must have been sent to the same subaddress
-
sarang
No, but I mean from the perspective of the exchange breach/collusion
-
sarang
I'm trying to work through some examples of the implications of the selection method in the event of public breach, collusion, etc.
-
sarang
(but only somewhat... also working on Arcturus stuff that's due tonight)
-
sarang
Obviously the wallet doesn't know anything about exchange customers
-
knaccc
i don't think i understand your question
-
knaccc
oh i think i see
-
sarang
Suppose the exchange records are leaked
-
knaccc
ok pls continue
-
sarang
You have entities trying to trace things
-
sarang
Senders/recipients who are not the exchange
-
sarang
The exchange
-
sarang
etc.
-
sarang
and I'm thinking through what the effects of the selection algorithm are in different scenarios
-
sarang
e.g. do certain decoy groupings come from the _same_ exchange list?
-
sarang
or from other random unknown (yet) subaddresses
-
sarang
and so on
-
knaccc
it helps in any ABC scenario or AB...C scenario where C leaks wallet info.
-
sarang
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.
-
knaccc
yeah to really nail down how severe this iterared-eabe intersection attack is, i'd need exchange records
-
sarang
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
-
knaccc
agreed
-
sarang
so you need to quantify how _many_ repeats you're ok with
-
knaccc
it's definitely a bad idea if it doesn't work
-
sarang
etc.
-
knaccc
by repeats, you mean eabe iterations?
-
sarang
Separate transactions between the same (eventual) parties
-
knaccc
i think your'e screwed with just two passages through the EABE loop
-
sarang
Since this all hinges on the idea that you're making repeat spends
-
knaccc
but almost certainly screwed with 3 passages
-
knaccc
oh absolutely, untraceability is totally intact if you only pay someone once, ever
-
knaccc
actually that's not quite true
-
knaccc
if you do ABC, then ABD, if both C and D are hacked, untraceability is broken
-
sarang
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.
-
knaccc
because it's then as if C and D are one entity for the purposes of examining the link
-
knaccc
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
-
knaccc
apparent*
-
knaccc
the figure 12 is arbitrary, i just mean an imbalance between user iterations and group size of decoys
-
sarang
aye
-
knaccc
btw if you need to get back to your deadline, pls do. thanks for thinking this through with me
-
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 !
-
sarang
-___-
-
knaccc
yes, it'll need a lot of lateral thinking from as many people as possible
-
sarang
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
-
sarang
regardless of how much thinking and designing you do
-
sarang
Which is somewhere between realistic and nihilistic =p
-
knaccc
haha
-
sarang
I'm still of the opinion that Monero does a damn fine job for the typical user
-
sarang
and that using basically anything makes it far more likely to introduce practical tracing and linking through typical use
-
sarang
(e.g. Zcash pool transitions, etc.)
-
sarang
Which isn't to say that's a reason not to iterate and improve, of course
-
sarang
Certainly highlights that exchanges are a big weak point, both for Monero and for something like Zcash
-
knaccc
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
-
sarang
On the assumption of collusion, breach, or leaks?
-
knaccc
when placed in context of the advantage of xmr over btc in terms of traceability
-
sarang
I can tell that's a risk that you care a lot about :)
-
knaccc
heh maybe the fundamental issue is that i think that untraceability is by far the #1 part of the value proposition
-
knaccc
because if it isn't, i don't see much reason to use xmr other than fungibility
-
hyc
eh? there is no fungibility without untraceability
-
knaccc
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
-
sarang
Unfortunately I need to get back to the Arcturus revision stuff, due to a deadline, sorry
-
hyc
it means your coins have no discernible history
-
knaccc
hyc i take back what i said. i'll see if i can try again to explain what i mean
-
knaccc
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
-
knaccc
untraceability is lost. So there is a time dimension.
-
knaccc
s/trace the origin of the funds back to A/trace the origin of the funds back to B
-
monerobux
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
-
knaccc
doh i screwed it up a second time
-
knaccc
s/trace the origin of the funds back to A/trace the origin of the funds back to P
-
monerobux
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
-
knaccc
...untraceability is lost. So there is a time dimension.
-
hyc
your actors are still confused. why does P care where their employee A spent his funds?
-
knaccc
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
-
hyc
the implication is that B getting hacked gives P info. why would P obtain that info, unless P hacked B?
-
knaccc
P doesn't have to back B. P just needs to observe a hack of B when it is leaked
-
knaccc
i should come up with a scenario where P would care
-
knaccc
the point is though, there was fungiblity without untraceability
-
knaccc
because it was eventual untraceability
-
knaccc
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
-
knaccc
so it can because of a time dimension or a difference in visibility
-
hyc
this sounds unsolveable, if you also require that senders be able to prove they sent txns
-
knaccc
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
-
knaccc
or it can be solved with a gigantic ring size
-
hyc
the ring size can be infinite, still doesn't solve the problem that a sender can see when a recipient spends their output
-
hyc
at least 1 extra hop will always be required, regardless of ringsize
-
knaccc
oh i see, you're talking about a timing attack
-
knaccc
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
-
knaccc
i don't think i'm quite following
-
hyc
right now, a sender can always see when the recipient truly spends the output that the sender sent
-
knaccc
but the ring signature prevents that?
-
hyc
they always have perfect knowledge that that output is getting spent
-
hyc
this is the underpinning of an EABE attack isn't it?
-
knaccc
oh sorry you're talking about a breach scenario
-
hyc
yes
-
knaccc
ok so in iterated-EABE, yes the exact txns and outputs can be determined
-
knaccc
but only if an intersection attack is possible
-
knaccc
the point of my proposal is to prevent the intersection attack
-
knaccc
by having an intersection that is much greater than 1
-
hyc
you want to tag outputs so that in PAB, A can choose to send outputs to B that didn't come from P
-
knaccc
oh, no, that's not what i am proposing, maybe it was poorly explained
-
knaccc
i'm proposing that A is still able to send outputs to B that came from P
-
knaccc
but in a way that causes an intersection of anonymity sets that is greater than 1
-
knaccc
and is thus genuinely untraceable
-
knaccc
because decoys are selected such that the is a greater overlap of anonymity sets
-
knaccc
and that cleverer decoy selection is only possible if outputs are tagged with a hash of the destination subaddress
-
hyc
so this only works if sending to a subaddress?
-
knaccc
consider all of my uses of the term subaddress to be inclusive of the main wallet address as the one of the subaddresses
-
hyc
ok
-
knaccc
i'm working on a diagram to try and explain this more clearly. it remains questionable as to whether i can achieve that
-
Isthmus
<@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 !
-
Isthmus
Can we call this "obstruction by induction"
-
sarang
ahahaha that's fantastic Isthmus
-
sarang
yes plz