This is a surprisingly good analysis that strengthens the argument that a Government agency created Bitcoin (Much like what Paul Graham suggested)
The main point is the same one that PG brought up, that the transaction graph is very easy to follow and if the gatekeepers are compromised then most of transactions become transparent.
A novel point they make is that some group (probably the creators of Bitcoin) control 25% of the money supply. I have not read the paper yet so cannot comment but I was under the impression 95% of Satoshi's coins have never moved since being mined. (If he does control them at all) Of course if they do control 25% of all the circulated Bitcoins this would forever stunt its growth as that actor would always be far too powerful.
Whilst I do not believe a Government created Bitcoin I welcome these articles that counter my own views. This also re-emphasizes the work that needs to go into coinjoin or zerocoin implementations as soon as possible. Also we need to seriously fix the 7 tx/sec limit.
>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.
>A novel point they make is that some group (probably the creators of Bitcoin) control 25% of the money supply. I have not read the paper yet so cannot comment but I was under the impression 95% of Satoshi's coins have never moved since being mined.
From Table 7 on page 11 of the linked paper:
Entity ID | Accumulated Incoming BTC's | Number of Transactions
A | 2,886,650 | 246,012
B | 2,206,170 | 477,526 //Mt. Gox
Since there were 9 million in the address graph, I assume that the 25% remark refers to unidentified Entity A in this table. However, I did not see any claim in the paper that there was evidence that this unnamed entity was trying to hide this accumulation.
Does anyone know why this claim was made in the article?
Yup, because I misread the paper :-/ I thought it also stated that entity A had done large amounts of churning, which it hasn't. I'll fix that, thankyou...
>The main point is the same one that PG brought up, that the transaction graph is very easy to follow and if the gatekeepers are compromised then most of transactions become transparent.
I agree with that point, but where did PG say that?
Plenty of people on the cryptography mailing list mined the first coins like Hal Finney who wrote he is leaving them for his kids which is why they havent moved. Satoshi buggered off the day Gavin announced he was presenting BTC to the CIA seems odd he wouldnt stick around and try to influence development if he was a gov agent. His opsec was perfect though, which could mean he was an NSA or GCHQ employee doing this as a secret side project for himself. Nobody has had better opsec than Satoshi not once did he talk about anything personal even in PMs to Gavin or leave indicators to analyze. Somebody even scanned for every unique word Satoshi used to match it up to existing whitepapers and mailing lists, nothing turned up
yeah, the one thing that makes me think this was the work of one person is the fact that a group, even a close knit group of NSA/CIA/GCHQ operatives could not produce, test and release something liek this without one of them making an error. I assume that satoshi thought through the production and release of this software well in advance of actually doing it, i.e. never suggesting it on a forum account, never testing or discussing it with anyone until he was soewhat ready to go. However his posting to the cypherpunks group does make me think he was at least a lurker on there before he signed in as satoshi, hence his decent OpSec.
The gateway monitoring argument is also pretty feeble since how are they going to extract ID scans or other info from worldwide gateways or p2p sales. Sure bitcoin is risky if using a major exchange in a western country but good luck getting info on a trade from a Russian exchange, or IRC exchanger connected via Tor who lives in Vietnam
The entire worth of all bitcoins is just north of $50 billion. It wouldn't be very difficult for any soveriegn to gain control of 25% of that market.
Whether government created bitcoins is a moot point, knowing the answer to this question doesn't mean anything. The question is whether bitcoins provide a superior environment for transacting business when compared to alternatives.
Bitcoin is at least one order of magnitude more complex than Tarsnap, or the crypto used in v1 of the Amazon AWS API. We should have seen far more bugs of varying severities if it was a one man band.
Is there any actual analysis to support the claim that it is an order of magnitude more complex than AWS crypto or Tarsnap?
There have been numerous vulnerabilities in the software implementation[1], and there has been (arguably) at least two bug in the algorithm[2][3].
I'd note that both the AWS & Tarsnap problems were implementation bugs, not algorithmic problems. That is a much better record than both the Bittorrent implementation and algorithmic record.
That's impressive, but doesn't seem superhuman.
Bittorrent (which was the work of one person AFAIK), for example has had no real algorithmic changes to the core protocol since it was released[4], and it is much more widely used than Bitcoin. (Yes, I know about trackerless .torrents, but that's more the discovery mechanism than the core transport algorithm).
"Is there any actual analysis to support the claim that it is an order of magnitude more complex than AWS crypto or Tarsnap?"
I don't think so, and I personally disagree with this statement.
As a developer, I find bitcoin 0.1.0's code easy to read and understand (I had requested a tarball of it about 2 years ago from one of the developers, as it was not in source control). And even the number of lines of code is not particularly impressive. Version 0.1.0 has only 13k lines of C++ code (excluding GUI code):
417 ./ui.h
720 ./uibase.h
1806 ./uibase.cpp
3228 ./ui.cpp
6171 total
For comparison, many HN readers who are talented developers would consider 5k LoC of C++ relatively easy to write in a span of 3-5 weeks, as a day job, for a small project that they have a precise idea how to implement. So 13k lines for a
project that apparently spanned a few months of Satoshi's time is absolutely plausible.
I may be wrong, but I thought Satoshi had been working on Bitcoin for 2 years before releasing anything. Granted he worked on the concepts and the white paper alongside the code.
I've always found Satoshi's choice of email address interesting. Gmx.com didn't launch until 2008, the same year Satoshi published his Bitcoin paper.
GMX is a German company and the @gmx.de email address is highly popular in here, especially since Gmail was late to the party (legal action over 'gmail'). Web.de and Yahoo are the two other big players.
GMX uses geo-location to direct users to specific GMX TLDs. To use the .com you would need to use Tor or a VPN. Without using some kind of geo-anonymising tool, I am stuck with a GMX.de account.
Why choose GMX.com? Did he/she read about GMX launching in the US as he was looking for a new email account provider specifically to be used for Bitcoin correspondence? Was he/she based in Germany, knew of GMX and in using Tor or a VPN from Germany exited in the US and got a GMX.com account?
It doesn't mean anything in itself, but I always thought the choice of gmx.com was a curious one.
I have been told by people who received emails from Satoshi that he was sending even his emails over Tor. Aren't most Tor exit nodes in the USA? That could explain why he got a gmx.com address rather than gmx.de
I don't believe it is a honeypot, just a fundamental limitation for a distributed protocol.
This is why I think in the long run a true blinded-signature form of ecash is essential. Handle distribution by having millions+ of issuers, independent, and then meta-currencies and realtime exchanges, just like real life, not a single distributed currency.
I also think trusted computing is an essential component to safely handling money which is fully anonymous, irrevocable, and for meaningful amounts, which is why I've been working on that kind of stuff for a while. Sadly we're still a few years off from practical currency-handling trusted computing, and probably a decade from practical general-purpose trusted computing, but once people can genuinely trust their devices to not be subverted, things will be vastly more awesome.
Zerocoin remains an option, but it is complex (I like simple), and difficult to implement. I didn't even think it was possible until Matt Green et al published; blinded signatures, on the other hand, are awesome, but fairly straightforward.
The main counterargument to this is that the bitcoin technology is so unusually clever and its success such an incredible fluke anyway that you'd have to assume the government to have an almost god-like intelligence and foresight to pull this off.
I'll point out why I don't find this a credible hypothesis.
I imagine someone highly-placed in the NSA speaking to their superiors:
"Yes, we have built this alternative form of money. It can be used almost-anonymously for the purchase of drugs or for online gambling, for the funding of terrorists and anything else that people want to hide from the government. It will allow users to skirt money-laundering laws and avoid payment of income and sales taxes. But because of our ubiquitous surveillance, we think we can (probably) track anyone using it... well, MOST people using it."
"It is a completely innovative idea -- few in the world have even had idle speculation about the idea of a currency like this and no one is currently working on building such a thing. Yes, it will probably spur development of similar crypto-currencies."
"So, Mr. Director, can we have permission to release this into the wild?"
I cannot imagine someone in charge saying, "Yes: release it."
On the flip side, this would give the CIA a fantastic opportunity to launder their own drug money into black budgets. It also gives them a great way to fund "freedom fighters" in countries that they don't like. No flying bags of cash around anymore.
I think this is just as unlikely as the idea that Facebook is a law enforcement honeypot to track terrorists' social graphs. Your arguments sound somewhat plausible now, but back in 2009 bitcoin was just a cypherpunk's toy and no one had any idea how big it was going to become.
I would argue that a conventional internet currency (like egold or liberty reserve) would make a far better honeypot (easier to track, shutdown at any time, cybercriminals were used to currencies like that)
Value overflow bug (let anyone produce billions of bitcoin)
Block merkle tree hash practically vulnerable to second preimage attacks (allowed anyone to select and kill arbitrary blocks, and thus rewrite the consensus)
Plus a mountain of smaller design bugs and more conventional software crashes issues.
The overall design is highly idiosyncratic in many ways. Novel integer serializations, random byte endianess.
It makes more sense once you realize things like Tor were created specifically for the USG intelligence community[1]. Bitcoin could, for example, be used to trade money between drug traffickers and the CIA, whilst allowing DEA to track the funds around the world. Fun!
The Navy was originally interested in techniques for decentralized communication between ships in a fleet, in such a way that the flagship would be unidentifiable. There are lots of applications for such a network that different government organizations would be interested in; The Government isn't a monolithic entity.
> If one individual cryptographer had written Bitcoin, it would contain far more idiosyncracies than it does, not just in the cryptosystem design but also in the C++ code itself.
Well, it's not that uncommon for a single person to write a very secure and minimal software that really works. Look at almost anything produced by DJB.
That's true, but then it's equally true that DJBs software, while absolutely excellent, is definitely idiosyncratic. If DJB anonymously published code using the same style, e.g. the configuration language, refusal to use standard UNIX daemons, etc., anyone who read the code would know immediately that it was him.
I came to comment on this, that entire paragraph seems to contradict itself:
> Likewise Colin's own one-person-product, the highly secure backup facility Tarsnap has also had only one serious vulnerability to date.
Here he is showing how a one-person-product can be extremely secure and although he does suggest it's an order of magnitude more complex I still think the logic doesn't hold up.
This is a brilliant troll that makes me reassess bitcoin. Exactly what good security is. Because "it can't be, right?" I don't buy it, but we're going to have to debunk this carefully!
> "Bitcoin was apparently designed by good cryptographers and peer-reviewed before it was released"
I think this understates the effect of outliers. If you consider the incredible ability of Srinivasa Ramanujan to, quite literally, dream up ground-breaking theorems, then it becomes a lot more plausable that a single dedicated, highly unusual individual could produce Bitcoin.
The same argument applies to OpSec. 99.99% are lacking the means (technologically or, more importantly, mentally) to maintain perfect cover. But it's the 0.01% outlier we're interested in. Comparing to existing cases is, by definition, invalid.
I realise that "evidence" is a term with a broader meaning. However, for most of the points brought up, I fail to see how they support the hypothesis that Bitcoin stems from a natsec background. Things like group efforts and maintaining anonymous identities are not specific for that environment.
The Hezbollah reference was irritating and I would that consider a very remote analogy, if at all.
Point 6 holds valid for a lot of financial services that allow to transfer monetary value in a non-physical fashion.
Nevertheless, all points are probably either interesting knowledge about Bitcoin or valid statements about it.
Yar, I realise the Hezbollah thingy is only tangentally applicable, but I couldn't find a better example of a single mistake compromising an identity and thereby a network. I think that someone (maybe Cory Doctorow?) wrote a better, at-length post about how hard it is to stay anonymous but I couldn't find it, so I used this example instead.
Point 6 is my main stepping-stone from 'organised and capable' to 'government'. FWIW governments have deliberately set up 'dodgy banks' as a way of attracting money launderers and then busting them, so I think it's valid.
I guess my perspective on this is blurred by me being German, or in a broader context, European. Our institutions are not really known for laying such "traps". I guess it's different in the world of the secret services (as opposed to traditional law enforcement). And well, yes, in the US there's the DEA, maybe the FBI, too, but I always thought that their ability to legally create "dodgy banks" or similar are kind of a Hollywood thing.
In general, the US seems a lot more willing and capable to really invest capacities in fighting money laundery than any agency I can imagine here in the EU.
Well, at least you agree the Hezbollah analogy is a stretch. Not sure I buy the opsec argument, or I don't understand it. Maintaining anonymity in this context doesn't seem very hard, although I may be naive there. Satoshi isn't an assassin in a high-profile paramilitary organization (so far as we know!) He doesn't have those kinds of people looking for him, the ones with extensive network taps, long histories of surveilling specific targets, and a drive to get answers even at high cost and legal/moral/diplomatic jeopardy. Or at least I doubt any law enforcement, natsec, or spy agencies thought much of this post[1] at the time, if they weren't the poster.
Of course there are more mundane slipups than the ones you mentioned, such as letting a traceable IP address into the email path log, etc. It just seems pretty easy to avoid those, and thus easy to avoid detection from people that are merely good researchers, as opposed to wide-scale network surveillers and crackers.
Bottom line, to borrow a point from sibling poster csomar, look at the trail that led to Ross Ulbricht (at least the one they're feeding the public, that doesn't involve NSA surveillance and cracking.) I believe ultimately he blew his cover by using his real name in a Gmail address. (He also recycled a pseudonym in multiple contexts that allowed investigators to link the little clues in each context together.. I guess Satoshi did that too, although arguably without such obvious clues.) It seems like not doing things this stupid would be good enough.
It has just occurred to me that there are non-technical things like language usage and times of online activity. People have analyzed stuff like this for Satoshi, but I don't think there's much conclusive, so I don't know if that's due to Satoshi's prowess or just the weak nature of such evidence. Even if there were pretty solid clues here, how would you really _prove_ that since Professor So-and-So used phrase XYZ in a paper and Satoshi did too, that means they are the same person? So what if there's only one known world-class cryptographer in the timezone Satoshi appears to be posting from?
yeah but those are much more easily controlled, there is no controlling bitcoin once it is out in the wild.
If it was an NSA project to catch, say terrorists, well first they have to wait for bitcoint o get enough traction for it to be worthwhile being used by terrorists, then you have to factor in the amount of work required to identify those terrorists and that you may actually enable terrorists that would otherwise have failed to get funding i.e. you assist in terrorist plots more than you identify terrorists from it.
The article makes some good points, but I don't think goverment involvement is the single most likely explanation for the facts we are able to observe. In my opinion, it is equally likely that Bitcoin is simply an elaborate Ponzi-type scheme.
Think about it. A group of people with probable backgrounds in mathematics, cryptography, software development and economy bands together and creatse a new kind of digital currency. They gain control of a large chunk of the total money supply in the beginning when it is easy to do so. Then they wait and hope for widespread adoption. Thanks to combination of the the hard limit on money supply and general mass psychology their currency hugely appreciates in value. They now have a large amount of money in their hands created from nothing but the work they put into creating BTC. All that is left is to cash out at some point. The latter is admittedly difficult to do without it being detected, but that doesn't mean that it won't happen at some point.
Ponzi scheme requires breaking trust in promises. Satoshi was not giving anyone promises or taking anyone's money. Everyone voluntarily evaluates safety of the protocol and decides to mine or buy bitcoins from others.
Well, we know that bitcoin was developed by someone, and that they've managed to keep their identity(s) secret. The smaller the group, the easier it is to keep secrets. It's likely that if the NSA was behind it, or knows who is, then that would have come out in the Snowden leaks.
When you are building a transaction, you can hand pick the inputs and outputs you want to use. There are no constraints or limits. CoinJoin effectively allows you to collude with multiple parties when generating a transaction (take multiple inputs {see:unspent outputs} from the different parties), such that it is difficult to follow the coins to their respective outputs.
Gmaxwell says it better than I:
>The signatures, one per input, inside a transaction are completely independent of each other. This means that it's possible for Bitcoin users to agree on a set of inputs to spend, and a set of outputs to pay to, and then to individually and separately sign a transaction and later merge their signatures. The transaction is not valid and won't be accepted by the network until all signatures are provided, and no one will sign a transaction which is not to their liking.[1]
Well there would need to be a server/host to manage all the signatures, but it could be built into a client. There is one implementation I know of so far: https://github.com/calafou/coinjoin
I wouldn't recommend using it, not sure if it's complete or not.
I am attracted to BitCoin-as-a-currency by it's near-zero-transaction-cost property.
I am attracted to the technology (for peer-to-peer trading), by it's potential to disrupt traditional asset classes.
I am rather disinterested in the privacy/secrecy aspect of the technology.
Indeed, I would quite like to see ALL financial transactions made public; as that would greatly assist the fight against corruption, and many many many forms of wrongdoing.
It would be helpful if you would clarify what you mean by "all financial transactions."
What about transactions such as a teenage girl buying a pregnancy test kit? Should the children in her high school be able to go to a website and see that she purchased a pregnancy test?
What about the guy that is struggling with alcoholism? Should his purchases of drugs such as Naltrexone be a matter of public record as well?
w_t_payne did not specify the level of detail, so it's conceivable that s/he intended that the transactions be sufficiently detailed so as to be able to ascertain, for example, what products Sally purchased.
But even in your case, indicating anything about Sally's activities seems to me to put her at the mercy of the tribe, such that they might start asking her "So, what did you buy at the pharmacy, Sally? I see EPT test kits are $11.87, when you include sales tax. I'll bet you're sexually active! Am I right?"
With respect, there are reasons that are both legitimate and moral to not have to disclose one's activities to strangers, and compromising on this principle isn't a good idea, in my view.
The responses raise some pretty good points - but do you think that there is a level of detail at which public disclosure is OK? What about if transactions were randomly made public, with a probability of disclosure that increased with the size of the transaction? The chances of Sally's activities being made public would therefore be vanishingly small, but any cash flow, or series of flows, which were significant (in aggregate) would be made public with near certainty. Obviously, there are parameters that control this mechanism, and there is harm to be had, as well as good.
Are there sets of parameters for which the good outweighs the bad, and, if so, is there a parameter that maximises either the good / bad ratio, or maximises the good for a certain "acceptable" level of good, or minimises the bad for a certain "desired" level of good.
I appreciated your comment and the opportunity to further discuss a topic (privacy) that I think is important and under attack in our society today. Thank you.
Are you keeping up with your duties? Did you perform your ritual of self-criticism this morning? Remember, you have to chant your oath of loyalty and subservience to Gen^H^H^H Lord Alexander at least five times a day!
It was I, N Bourbaki, working with Francis Bacon, William Shakespeare, Grothendiek, and the sender of dreams, from our aecret Atlantis undersea fortress.
The main point is the same one that PG brought up, that the transaction graph is very easy to follow and if the gatekeepers are compromised then most of transactions become transparent.
A novel point they make is that some group (probably the creators of Bitcoin) control 25% of the money supply. I have not read the paper yet so cannot comment but I was under the impression 95% of Satoshi's coins have never moved since being mined. (If he does control them at all) Of course if they do control 25% of all the circulated Bitcoins this would forever stunt its growth as that actor would always be far too powerful.
Whilst I do not believe a Government created Bitcoin I welcome these articles that counter my own views. This also re-emphasizes the work that needs to go into coinjoin or zerocoin implementations as soon as possible. Also we need to seriously fix the 7 tx/sec limit.