[nwh]

> Surely whatever scheme you have to obfuscate the trail could be built into the network? If so, why wasn't it?

Not really. Mixing Bitcoin relies on shared wallets controlled by a third party. You trust in them not to leak the details of what Bitcoin went where, and you also trust them not to just pocket the inputs and never send anything back. That would never make it into the network. The alternative is something called CoinJoin, which allows people to pair up and spend each others Bitcoin to ruin the trail through the blockchain, this probably will be implemented at some point, but it's just in development stages thus far.

> Do you think normal people are going to take the care to obfuscate their Bitcoin transactions properly? I don't.

By the same token, do they need to?

[feral]

As you say, mixing isn't really a solution - it requires that you trust the mixer to not steal your coins, and that you trust the mixer to not keep records. Looking at the efforts to compromise TOR, I don't think you can assume that mixers won't be adversaries.

But I accept your point that if trusting mixers is your obfuscation scheme, then its at least non-trivial to put that into the system spec.

What I was thinking about instead was the 'linking' property - which leaks so much information - why wasn't that avoided at a system level?

Clients could also make network analysis much harder by moving Bitcoins between newly generated addresses randomly. Why wasn't that in the system?

>By the same token, do they need to?

This sounds like saying "they only need to be worried about privacy if they have something to hide" ?

[betterunix]

"Looking at the efforts to compromise TOR, I don't think you can assume that mixers won't be adversaries"

That really depends on how things are being done. Tor involves making a temporary, random choice of relays, and periodically updating that choice. If all your transactions are sent through a randomly chosen chain of mixing services, you might have some kind of anonymity (but this is poorly defined to begin with, since mix-nets are supposed to enable anonymous communications rather than anonymous payments, and so it is not even clear that what applies to one still applies to the other).

"What I was thinking about instead was the 'linking' property - which leaks so much information - why wasn't that avoided at a system level?"

Like I said elsewhere, there is no specific problem definition for Bitcoin, so why bother to ask such a question? Really if you want a digital cash system without a central authority, you need to first define what that actually means; likewise if you want that hypothetical system to not have this "linking" property, whatever that actually means.

[feral]

>Like I said elsewhere, there is no specific problem definition for Bitcoin, so why bother to ask such a question?

Are you saying that, as Bitcoin doesn't have a publicly stated problem definition, its immune from any criticism of its design choices? That's a bizarre argument.

First off, Nakamoto's original paper has a section on Privacy, talking about how to maintain privacy by keeping public keys anonymous. If Bitcoin, in practice, fails to provide privacy for its users, it is absolutely fair game to point that out.

Secondly, perhaps you mean that the original paper didn't have a formal specification of the 'privacy' desired, which the performance of Bitcoin can be evaluated against? Again, that's a bizarre argument.

Lets say I release a new design of car. You build one and drive it, and then it goes on fire due to a design flaw. How would you feel if I argued "But I didnt formally specify the parameters within which it wouldnt go on fire and injure you!"

That'd clearly be a nonsense argument, because there are expected standards of operation of a car, even if there isn't a formal spec. If you write an informal section on privacy in your paper, and your system compromises user privacy, criticism is absolutely fair.

> if you want that hypothetical system to not have this "linking" property, whatever that actually means.

The "linking" property is well defined in the context of Bitcoin anonymity; I refer to the situation where multiple addresses used as inputs to a transaction reveal the shared ownership of all those addresses.

As Nakamoto writes: "Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner."

[betterunix]

"Are you saying that, as Bitcoin doesn't have a publicly stated problem definition, its immune from any criticism of its design choices? That's a bizarre argument."

There is nothing bizarre about it. Let's put it this way: if you cannot identify the problem Bitcoin solves, why should I not be able to criticize Bitcoin for not improving the fuel economy of my car, or solving the traveling salesman problem, or computing missile trajectories, or any number of other ludicrous demands that Bitcoin obviously cannot meet? Clearly there needs to be some concept of what Bitcoin is supposed to do before there can be any criticism about it.

"First off, Nakamoto's original paper has a section on Privacy"

A section that does not bother to define the meaning of "privacy" in this context, so what is your point?

"there are expected standards of operation of a car, even if there isn't a formal spec"

In fact, real engineers do work off of specifications when they design cars. That is why, for example, I could not sue Volkswagen if I destroy my car by putting gasoline in the tank rather than diesel: the specifications of the engine assume diesel fuel and there are no guarantees about the car working without that. Engineers design systems that meet specified requirements under specified constraints.

"If you write an informal section on privacy in your paper, and your system compromises user privacy, criticism is absolutely fair."

Not when you do not bother to define the meaning of "privacy." There are a lot of privacy notions; you cannot criticize Bitcoin for failing to meet your preferred notion of privacy if nobody ever claimed that it meets that notion.

Let's put it this way: I call a cryptosystem that can be attacked in polynomial time insecure. Bitcoin can be attacked in polynomial time, and that is mentioned in the Bitcoin paper itself. You want a privacy property, I want security against efficient attacks. The Bitcoin community dismisses the "51% attack," and with it the notion that polynomial time attacks are a thing that should be prevented, and the argument simply boils down to the fact that nobody claimed that Bitcoin can protect against such attacks. Well, that applies to your demands as well: nobody claimed that Bitcoin meets your privacy requirement either.