>Bitcoin is, by design, highly vulnerable to network analysis.
By design as in, that's the only way the network could conceivably work. Each node must be able to verify that the chain is intact and valid, otherwise they would have to be trusting a third party. There's ways of obfuscating this anyway, which seem to work quite well in practise.
> This is a surprisingly good analysis that strengthens the argument that a Government agency created Bitcoin
It's not really. If the US government were to create something like this, they wouldn't have risked releasing something as ridiculously buggy as the original Satoshi client. You're talking massive remote exploits, people able to make their own coins due to an integer overflow, just chaos in the code. It's truly miraculous that it even took off at all, and the developers are still trying to fix the issues that Satoshi unknowingly introduced. Bitcoin was not the work of a skilled team.
>I was under the impression 95% of Satoshi's coins have never moved since being mined
That's correct, though you can't even verifiably say that all the coins were minted by Satoshi. I doubt they'll ever move, given that Satoshi made it very clear that remaining part of the community is a bad idea. In their shoes, I would have been mining to a bit bucket, which I imagine is the case here.
> This also re-emphasizes the work that needs to go into coinjoin or zerocoin implementations as soon as possible.
Coinjoin is well and good, but zerocoin is a no show at the moment. It's immature, creates massive signatures, and is completely untested. There's no way it would ever make it's way into the mainstream client in it's current state, and the developers know that too.
> Also we need to seriously fix the 7 tx/sec limit.
I'd go close to calling that one a myth. There's really nothing stopping 7 transactions a second at the moment, in fact it's intended to be tight for block space in order to create a market in which people battle for transaction fees. There's also nothing to stop the block limit from just being increased, 1MB is just arbitrary at the moment.
>By design as in, that's the only way the network could conceivably work. Each node must be able to verify that the chain is intact and valid, otherwise they would have to be trusting a third party. There's ways of obfuscating this anyway, which seem to work quite well in practise.
You can say that there's no other way the network could conceivably work, or that its possible to obfuscate the trail, but it doesn't make sense to say both.
Surely whatever scheme you have to obfuscate the trail could be built into the network? If so, why wasn't it?
Normal people don't encrypt their e-mail.
According to some, even security researchers don't encrypt their e-mail.
Do you think normal people are going to take the care to obfuscate their Bitcoin transactions properly? I don't.
I have always found it worrying that Nakamoto, a person or group who took such pains to - henceforth successfully - hide their own identity, made so little effort to strength or design the privacy of Bitcoin.
Bitcoin does not and never did have well-defined requirements or constraints, so it is kind of pointless to ask why some feature is not present or why the creators of Bitcoin have not worked to improve it in some particular way. None of the definitions of privacy or security defintiions that apply to academic digital cash can be satisfied by Bitcoin, as those definitions all assume the existence of a central bank in the system. Similarly, definitions that are applicable to anonymous messaging (e.g. mix-nets) are useless here unless you want to use Bitcoin as an anonymous messaging system (rather than as a digital cash system).
> 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.
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" ?
"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.
>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."
"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.
>>Bitcoin is, by design, highly vulnerable to network analysis.
>By design as in, that's the only way the network could conceivably work.
This network, yes. But you can construct truly anonymous cryptocurrencies with e.g. zero-knowledge proofs, yet the author(s) chose not to. This would have enabled AP, maybe answering PGs question in point #2 of his post (https://news.ycombinator.com/item?id=5547423).
I didn't know the original code was that buggy, I confess I was lulled a bit by the line "This was the only major security flaw found and exploited in Bitcoin's history" in the wiki article. Maybe it needs changing in the light of https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu... :-)
I don't think any of them ever got a CVE to be quite honest. There's a few that come to mind, my favourite being an integer overflow that lead to the creation of billions of Bitcoin in a single transaction.
This is refreshing to hear, however the Government does not have a history of writing good code (excluding NASA)
I still feel like the Government argument could be correct.
> I'd go close to calling that one a myth
Well the limit is based on size, and 7tx/sec assumes an average transaction I think.
> in fact it's intended to be tight for block space in order to create a market in which people battle for transaction fees
I remember reading Satoshi did not intend for limited blockchain space and envisioned 500GB blocks.
> 1MB is just arbitrary at the moment.
A hard fork will be required, this will not be an issue if no one complains.
> the Government does not have a history of writing good code
I'd love to hear more about that, because it goes against my own experience. (And I'll go ahead and disclaim that I'm obviously speaking anecdotally here.)
Whenever I've run into software that was developed by the US government it's generally been pretty competent. No worse, and maybe a little better, than what I'm used to seeing come out of the companies I've worked with. Certainly better than the stream of epic fails that seems to characterize what results from outsourcing to private contractors.
Partly that may be because they can (in theory) work closer to the true customer, rather than having an additional contract/specification-based interface to getting things made. When you don't find out for six months that you completely misunderstood the client's needs, it's hard to build good stuff -- frustrating for the client, and for the developers.
If, however, you ARE your own client, such as writing research code or simulation/test code, you likely have a clearer idea of what needs to be done.
it depends on who does what, if the people that want/need/use the code are responsible for writing it then I woudl agree, if you have a different department/wing/group writing the code then what you end up with may not be useable by the end user or may not be as useful anyway. If you add in another step where lots of disparate groups have input i.e. impse a set of requirements, usually indepdent of one another, then what you get left with is an expensive, unworkable, useless piece of spftware that everyone is forced to use until someone else decide to have a crack at improving it.
Sorry it was just an assumption I made. Over the years all the stuff I have read point towards bad code from the Government. I guess the NSA would be of higher caliber though, similar to NASA embedded code.
I don't think you can really argue either way on Government code quality. It depends entirely on how the project was set up and who did it.
There's plenty of Government software projects with the usual lists of WTF-generators like lowest-bid contractors, poor requirements communication, incompetent managers mostly concerned with covering their own asses, etc.
And there's plenty of other Government software projects made by a tight-knit core of highly skilled hackers with good goals under good management. See Stuxnet, etc.
I can't say how this applies within the NSA, but (security) hackers tend to write better publicly released code than academic mathematicians, as the constraints imposed on them tend to encourage soundness of implementation over soundness of concept. I have no idea how applicable this trend is to NSA security engineers vs whoever inside the NSA might have been tasked with this. I just think it's possible that if this were an NSA project, that doesn't necessarily imply good code.
> This is refreshing to hear, however the Government does not have a history of writing good code (excluding NASA) I still feel like the Government argument could be correct.
My point was more that if it was set up to be a honeypot, they'd want to do quite a good job to ensure that it was picked up by a community. The Satoshi client was anything but, and in itself would have had quite a high risk at completely bombing out. Developers are still battling with some of the less sensible bits of the design.
> Well the limit is based on size, and 7tx/sec assumes average transaction I think.
More clients moving to compressed keys would help with that, but yes, I think that's where the 7tx/second number comes from.
> envisioned 500GB blocks
I still think everybody would struggle with that. It's not a small amount of data to move around. I don't think I could even write 500GB to a hard disk in under 10 minutes, let alone the 6 or so minutes between blocks at the moment. It'll be a long time until that's even possible on a network-wide scale, my current node is under heavy enough load responding to it's peers as it is.
If Bitcoin is truly a covert operation led by the government to attract criminals, they would be funding this through a completely unrelated subsidiary who either provides grants to research institutions or contracts the work out.
In either case the code will be shit. The problem with this argument is that it is incredibly hard to prove without knowing the circumstances behind bitcoins inception.
Can you elucidate on your point about Zerocoin? I'm really fascinated by what I've read about it, but admittedly don't have much of a basis to evaluate on.
The idea is good, and it would actually work as it currently stands. The fundamental issue is that the signatures it creates would be massive in comparison to the lean scripts that the Bitcoin network uses internally. There's certainly ways of making it work, it just needs a little more baking before any of the Bitcoin developers would even consider using it.
By design as in, that's the only way the network could conceivably work. Each node must be able to verify that the chain is intact and valid, otherwise they would have to be trusting a third party. There's ways of obfuscating this anyway, which seem to work quite well in practise.
> This is a surprisingly good analysis that strengthens the argument that a Government agency created Bitcoin
It's not really. If the US government were to create something like this, they wouldn't have risked releasing something as ridiculously buggy as the original Satoshi client. You're talking massive remote exploits, people able to make their own coins due to an integer overflow, just chaos in the code. It's truly miraculous that it even took off at all, and the developers are still trying to fix the issues that Satoshi unknowingly introduced. Bitcoin was not the work of a skilled team.
>I was under the impression 95% of Satoshi's coins have never moved since being mined
That's correct, though you can't even verifiably say that all the coins were minted by Satoshi. I doubt they'll ever move, given that Satoshi made it very clear that remaining part of the community is a bad idea. In their shoes, I would have been mining to a bit bucket, which I imagine is the case here.
> This also re-emphasizes the work that needs to go into coinjoin or zerocoin implementations as soon as possible.
Coinjoin is well and good, but zerocoin is a no show at the moment. It's immature, creates massive signatures, and is completely untested. There's no way it would ever make it's way into the mainstream client in it's current state, and the developers know that too.
> Also we need to seriously fix the 7 tx/sec limit.
I'd go close to calling that one a myth. There's really nothing stopping 7 transactions a second at the moment, in fact it's intended to be tight for block space in order to create a market in which people battle for transaction fees. There's also nothing to stop the block limit from just being increased, 1MB is just arbitrary at the moment.