Bitcoin as a law enforcement/natsec honeypot: what is the evidence?(ianso.blogspot.be) |
Bitcoin as a law enforcement/natsec honeypot: what is the evidence?(ianso.blogspot.be) |
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.
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.
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.
>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... :-)
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.
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?
I agree with that point, but where did PG say that?
Its not in his post here: https://news.ycombinator.com/item?id=5547423
Really? Who was that, I don't recall ever hearing about a real textual analysis being done.
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.
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).
[1] https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu...
[2] http://sourceforge.net/p/bitcoin/mailman/message/25954806/, https://bitcointalk.org/index.php?topic=822.msg9503#msg9503
[3] http://en.wikipedia.org/wiki/Bitcoin#The_fork_of_March_2013
[4] http://bittorrent.org/beps/bep_0003.html (note the change history are all clarifications)
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.
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.
This is a conspiracy theory.
What else can the g-men really do... now is a good time considering after SR and all.
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."
http://www.google.com/hostednews/afp/article/ALeqM5j6QonBKKM...
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)
e.g.
OP_RETURN bug (let anyone spend anyone elses coin)
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.
[1] http://www.networkworld.com/community/blog/no-conspiracy-the...
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.
> 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.
Whether Bitcoin is or is not a natsec honeypoint can not affect any of Bitcoin properties, therefore this question is meaningless.
Maybe it's time Zerocoin (by Matthew Green's students) got implemented into Bitcoin:
http://blog.cryptographyengineering.com/2013/04/zerocoin-mak...
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.
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.
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.
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]
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.
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?
But, yes, I believe the general idea is that there is a webpage where you could see that little Sally spent $11.87 at the pharmacy on Saturday.
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):
7 ./irc.h
71 ./headers.h
156 ./key.h
177 ./sha.h
182 ./market.h
201 ./base58.h
264 ./market.cpp
265 ./irc.cpp
373 ./util.cpp
399 ./util.h
420 ./db.h
498 ./bignum.h
554 ./sha.cpp
597 ./script.h
604 ./db.cpp
750 ./uint256.h
856 ./net.h
1020 ./net.cpp
1127 ./script.cpp
1151 ./serialize.h
1317 ./main.h
2660 ./main.cpp
13649 total
417 ./ui.h
720 ./uibase.h
1806 ./uibase.cpp
3228 ./ui.cpp
6171 total
I believe Bitcoin was written by one man.
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.
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?
[1]http://www.mail-archive.com/cryptography@metzdowd.com/msg099...
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.
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.
Silkroad? Seems like the perfect example to me.
Here's the thread for that bug: https://bitcointalk.org/index.php?topic=823.0
I wouldn't recommend using it, not sure if it's complete or not.
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.
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.
source: i have worked for govt.
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.
How much NSA code have you seen? SELinux is one of the few pieces available and seems reasonably competent.
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.
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.
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?
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" ?
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.
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.
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.
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."
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.