8 ms·

>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

by nwh 13y ago

>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.

josephagoss 13y ago
> Bitcoin was not the work of a skilled team. 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.
- bunderbunder 13y ago
  > 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.
  - gknoy 13y ago
    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.
  - celticninja 13y ago
    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. source: i have worked for govt.
  - josephagoss 13y ago
    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.
- 13y ago
ianso 13y ago
>>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 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_Exposures https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu... :-)
- nwh 13y ago
  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. Here's the thread for that bug: https://bitcointalk.org/index.php?topic=823.0 https://bitcointalk.org/index.php?topic=823.0
feral 13y ago
>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.
- nwh 13y ago
  > 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 13y ago
    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" ?
quantumpotato_ 13y ago
Tinfoil hat conspiracy: bitcoin v1 client released with intentional bugs to appear it was made by an amateur.
imsofuture 13y ago
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.
- nwh 13y ago
  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 nwh 13y ago

josephagoss 13y ago

> Bitcoin was not the work of a skilled team. 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.

bunderbunder 13y ago
> 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.
- gknoy 13y ago
  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.
- celticninja 13y ago
  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. source: i have worked for govt.
- josephagoss 13y ago
  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.
13y ago

ianso 13y ago

>>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 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_Exposures https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu... :-)

nwh 13y ago
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. Here's the thread for that bug: https://bitcointalk.org/index.php?topic=823.0 https://bitcointalk.org/index.php?topic=823.0

feral 13y ago

>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.

nwh 13y ago
> 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 13y ago
  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" ?

quantumpotato_ 13y ago

Tinfoil hat conspiracy: bitcoin v1 client released with intentional bugs to appear it was made by an amateur.

imsofuture 13y ago

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.

nwh 13y ago
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.