6 ms·

I do not think it is unbelievable that a cryptographer would not have heard of Bitcoin. Bitcoin is just not that interesting to cryptography researchers or pro

I do not think it is unbelievable that a cryptographer would not have heard of Bitcoin. Bitcoin is just not that interesting to cryptography researchers or professionals; there is a polynomial time attack (for a vague notion of what it means to attack Bitcoin), no security definition, and a requirement that the honest parties scale their work with the work done by the attacker. It is almost certainly not the case that Bitcoin was created by an expert cryptographer or by a team of experts; one need not look any further than the original Bitcoin paper to see why (no references to previous work on digital cash? no reference to security multiparty computation? an expert cryptographer would most likely have mentioned at least some related work).

mindslight 13y ago
> requirement that the honest parties scale their work with the work done by the attacker You're always repeating this as if it's an indictment. But you're applying the cryptography standard (comfortable asymptotic complexity results) to a coordination problem. If you aren't willing to use trusted (untrustable :P) third parties, something else has to define authority. And control of this will always be a struggle between competing groups, whether it's minor disagreements on protocol, or full fledged slash-and-burn attackers. (And I say this as someone who thinks Bitcoin is an unfortunate distraction).
- betterunix 13y ago
  What you are saying is not true. It is possible in other settings to create fully decentralized protocols that are secure even if all but one of the parties is malicious (i.e. the attacker can control all but one of the parties in the system). Those protocols are secure in the cryptographic sense: the attacker's effort grows exponentially with the work done by the honest parties (even if there is only one honest party). The issue with Bitcoin is not a coordination problem. Sure there is a team of developers who act as a central authority in Bitcoin, but that's irrelevant; some other person can implement Bitcoin. The problem is fundamental and inherent in Bitcoin's design. Ignoring the poorly formed notion of "security" in Bitcoin, at a high level the work needed to attack Bitcoin scales linearly with the work needed to run Bitcoin, regardless of the implementation details. That is not a coordination problem, it is a fundamental problem in the design of Bitcoin.
  - mindslight 13y ago
    I'm using coordination problem in purely technical protocols sense. Can you be specific about which other decentralized protocols you're referring to? I agree that many protocols fit your description, but I can't see how any of them could be both partition-tolerant and prevent conflicting transactions (double spends in this case). It seems like partitions lead to honest disagreements about what happened first, and these are indistinguishable from an attacker. To reconcile these disagreements, we need some majority-metric so both sides can agree which one wins out.
    - betterunix 13y ago
      "Can you be specific about which other decentralized protocols you're referring to?" Well, let's just take this (random Google result) as an example: http://groups.csail.mit.edu/cis/pubs/shafi/2002-disc.pdf http://groups.csail.mit.edu/cis/pubs/shafi/2002-disc.pdf There you have a protocol that can tolerate honest parties aborting and can tolerate a malicious majority. Partitioning is a slightly different problem than aborting, of course, but that is beside the point. My point was that there is nothing inherent in secure computation that requires you to allow polynomial time attacks or even to require an honest majority. It is hard to excuse a system that is supposed to be based on cryptography that fails to provide anything remotely close to the security we expect out of cryptosystems. Really there is a deeper problem here, which is the lack of a well-formed security definition for Bitcoin. You use terms like "double spending" but those terms are very poorly defined for Bitcoin; I would go further and say that there may not even be such a definition, given that there is nothing wrong with a Bitcoin user spending more money than they receive (due to "mining"). It is impossible to apply the security definitions of other digital cash systems, which invoke a bank. Underlying all this is the lack of a definition of money; Bitcoin dispenses with economic theory but fails to provide a satisfactory replacement.
      - mindslight 13y ago
        (Disclaimer: I'll admit to not having the best understanding of the applicability of secure MPC. For instance, seeing things about parallel composability, I have a hard time fathoming how multiple instances of something couldn't be secure in parallel. So I can only conclude the papers are written from a much different perspective than I have.) > there is nothing inherent in secure computation that requires you to allow polynomial time attacks or even to require an honest majority But, that paper comes right out and says: "On the other hand, as we have mentioned, in the range of t [malicious parties] ≥ n/2 [half of total parties] the definitions of secure computation do not imply Byzantine agreement." In order to have a currency (fungibility), we need widespread agreement as to what constitutes value. Several nodes saying a transaction is good aren't enough - all nodes must agree. The hard part is achieving quorum of the majority of nodes, after which the remaining nodes acquiesce and follow (even if they vehemently disagree! that is, assuming they want to keep transacting with everyone else. also notice we've left out any judgement of honesty) But also, what constitutes a "node"? If we aren't going to have a trusted party handing out limited identities, we need some non-forgeable ability. Bitcoin uses computing power measured in SHA2s. If you compute twice the hashes, you count as twice the nodes for purposes of quorum. You're free to explore a different system for avoiding Sybil attacks, but it's still going to come out as a one-to-one balance between "honest" and "dishonest" nodes.

mindslight 13y ago

> requirement that the honest parties scale their work with the work done by the attacker You're always repeating this as if it's an indictment. But you're applying the cryptography standard (comfortable asymptotic complexity results) to a coordination problem. If you aren't willing to use trusted (untrustable :P) third parties, something else has to define authority. And control of this will always be a struggle between competing groups, whether it's minor disagreements on protocol, or full fledged slash-and-burn attackers. (And I say this as someone who thinks Bitcoin is an unfortunate distraction).

betterunix 13y ago
What you are saying is not true. It is possible in other settings to create fully decentralized protocols that are secure even if all but one of the parties is malicious (i.e. the attacker can control all but one of the parties in the system). Those protocols are secure in the cryptographic sense: the attacker's effort grows exponentially with the work done by the honest parties (even if there is only one honest party). The issue with Bitcoin is not a coordination problem. Sure there is a team of developers who act as a central authority in Bitcoin, but that's irrelevant; some other person can implement Bitcoin. The problem is fundamental and inherent in Bitcoin's design. Ignoring the poorly formed notion of "security" in Bitcoin, at a high level the work needed to attack Bitcoin scales linearly with the work needed to run Bitcoin, regardless of the implementation details. That is not a coordination problem, it is a fundamental problem in the design of Bitcoin.
- mindslight 13y ago
  I'm using coordination problem in purely technical protocols sense. Can you be specific about which other decentralized protocols you're referring to? I agree that many protocols fit your description, but I can't see how any of them could be both partition-tolerant and prevent conflicting transactions (double spends in this case). It seems like partitions lead to honest disagreements about what happened first, and these are indistinguishable from an attacker. To reconcile these disagreements, we need some majority-metric so both sides can agree which one wins out.
  - betterunix 13y ago
    "Can you be specific about which other decentralized protocols you're referring to?" Well, let's just take this (random Google result) as an example: http://groups.csail.mit.edu/cis/pubs/shafi/2002-disc.pdf http://groups.csail.mit.edu/cis/pubs/shafi/2002-disc.pdf There you have a protocol that can tolerate honest parties aborting and can tolerate a malicious majority. Partitioning is a slightly different problem than aborting, of course, but that is beside the point. My point was that there is nothing inherent in secure computation that requires you to allow polynomial time attacks or even to require an honest majority. It is hard to excuse a system that is supposed to be based on cryptography that fails to provide anything remotely close to the security we expect out of cryptosystems. Really there is a deeper problem here, which is the lack of a well-formed security definition for Bitcoin. You use terms like "double spending" but those terms are very poorly defined for Bitcoin; I would go further and say that there may not even be such a definition, given that there is nothing wrong with a Bitcoin user spending more money than they receive (due to "mining"). It is impossible to apply the security definitions of other digital cash systems, which invoke a bank. Underlying all this is the lack of a definition of money; Bitcoin dispenses with economic theory but fails to provide a satisfactory replacement.
    - mindslight 13y ago
      (Disclaimer: I'll admit to not having the best understanding of the applicability of secure MPC. For instance, seeing things about parallel composability, I have a hard time fathoming how multiple instances of something couldn't be secure in parallel. So I can only conclude the papers are written from a much different perspective than I have.) > there is nothing inherent in secure computation that requires you to allow polynomial time attacks or even to require an honest majority But, that paper comes right out and says: "On the other hand, as we have mentioned, in the range of t [malicious parties] ≥ n/2 [half of total parties] the definitions of secure computation do not imply Byzantine agreement." In order to have a currency (fungibility), we need widespread agreement as to what constitutes value. Several nodes saying a transaction is good aren't enough - all nodes must agree. The hard part is achieving quorum of the majority of nodes, after which the remaining nodes acquiesce and follow (even if they vehemently disagree! that is, assuming they want to keep transacting with everyone else. also notice we've left out any judgement of honesty) But also, what constitutes a "node"? If we aren't going to have a trusted party handing out limited identities, we need some non-forgeable ability. Bitcoin uses computing power measured in SHA2s. If you compute twice the hashes, you count as twice the nodes for purposes of quorum. You're free to explore a different system for avoiding Sybil attacks, but it's still going to come out as a one-to-one balance between "honest" and "dishonest" nodes.