knaccc


@moneromooo-monero the hash is just a simple hash of the subaddress. So alongside every output in every transaction (whether involving exchanges or otherwise), the hash that appears corresponds to whatever...

@UkoeHB thanks, I'll ponder your points. If decoy buckets get stale, the wallet could initiate a churn to make a clean break and select new buckets. Also, decoys should be...

To reframe the proposal: Through the lens of "does this fully solve untraceability"? The answer is no, therefore the proposal can be dismissed. But imagine that the current state of...

One other quick thing: to avoid disclosing the count of transactions going to donation addresses (or to any addresses when those addresses becomes known), more than one address-hash could be...

> I believe maintaining the status quo is the Schelling Point I agree, this proposal is not compelling enough _yet_ for even me to endorse. Having said that, 'instant-on' will...

Note that iterated-EABE is a problem even in a world without large exchanges. Consider the iterated-ABC problem, where A is an employer, B is an employee, and C is a...

> a separate "change subaddress" for each payee address Makes sense to me. Or alternatively, the hash could be fewer than 32 bits to cause just enough collisions to solve...

It doesn't matter if a view-only wallet (that has no key images) cannot know the hashes of change outputs in order to search for them. The view-only wallet only needs...

@UkoeHB makes the excellent point that "Once some decoy partners have been selected, you are kind of stuck with them". It makes sense that this is the way things need...