3 ms·

"For instance, seeing things about parallel composability, I have a hard time fathoming how multiple instances of something couldn't be secure in parallel." A

"For instance, seeing things about parallel composability, I have a hard time fathoming how multiple instances of something couldn't be secure in parallel." A good, intuitive example is this: I personally cannot win against a Chess grandmaster or even play to a draw; if I play two games in sequence, I will lose both times. However, I can guarantee that I can either win a game or draw two games if I am allowed to play two grandmasters simultaneously, one as white and one as black. I can simply copy the moves from one board to the other, and each grandmaster will be forced to play against another grandmaster (but they will be playing against me, and I can claim to win half the games I play against grandmasters -- much better than I can do I my own!). "In order to have a currency (fungibility), we need widespread agreement as to what constitutes value." At a basic level, what we really need is a definition of validity for our money. In the case of gold as currency, for example, validity is defined in terms of chemistry -- weights of a particular element are valid as money. For fiat currencies validity is defined via the law, by a government. In the digital cash systems developed by the cryptography research community, money is valid if the bank will accept it for deposit. The problem with Bitcoin is that validity is not well-defined and can change without warning. There is a vague notion that money is valid if everyone agrees that it is valid, but that agreement can be invalidated by a single party that happened to have done a lot of computation. Security in Bitcoin is equally vague -- you use terms like "double spending," but what does that even mean (rigorously)? "If we aren't going to have a trusted party handing out limited identities," It is worth mentioning that in online digital cash protocols (like Chaum's), there is no need for an authority on identities, or even for identities. The withdrawal protocol involves blind signatures, without a need for identities, and the bank could simply accept a cash payment for the digital cash. The payment protocol requires that the merchant verify the validity of the tokens with the bank, but rather than deposit, the bank could engage in a withdrawal protocol with the merchant trading the deposited tokens for withdrawn tokens, allowing the merchant to spend the money further. Sure, it sucks to have to be connected to a payment processor, but that is not much worse than being connected to the Bitcoin network, or to a Bitcoin exchange. "If you compute twice the hashes, you count as twice the nodes for purposes of quorum" More important: if you can compute hashes twice as fast, you get twice as much of a vote. If you can compute hashes asymptotically faster, your power in the network will keep increasing. There is no reason that you cannot compute SHA2 hashes asymptotically faster than I can -- nothing about the security of a hash function requires that all implementations have identical running times. There's the rub, in a nutshell: you are relying on the inability of the adversary to compute lots of hashes, but simultaneously demanding that the honest parties compute lots of hashes.

mindslight 13y ago
Ah, that is a great illustration of parallel instances. It seems like it's mostly of theoretical relevance for parties of differing computational abilities, which is why I had a hard time grokking it. But it'd definitely come into play say if one ran two instances with the same RSA group. > in online digital cash protocols (like Chaum's), there is no need for an authority on identities, or even for identities Actually there is, but that requirement is concentrated in the bank, which all users have to trust to steward the currency's value. While it's theoretically possible to bootstrap a trustable identity, there's little incentive to trust one party against whom you have no recourse, so adoption requires a real-world identity. These systems would be in widespread use if any government preserved individual rights. Alas. > The problem with Bitcoin is that validity is not well-defined and can change without warning So can Chaum's system. Three words: bank shuts down. The protocol instance is fine, but all real-world balances become invalid. In general, it feels like you're reacting to a lack of guarantees that are usually provided by the assumptions of existing systems, and that your definitions preclude the novel and necessary parts of Bitcoin. If there were only one exchange, we would say validity is whatever it accepts (which would hopefully be well-defined and non-repudiable. yes, Bitcoin would make an absolutely terrible single-issuer protocol). But once you talk about multiple exchanges, the definition must become fluid. If exchange A calls coins stolen and refuses to exchange them, exchange B will still exchange them because it hasn't become aware of this yet, and less-reputable exchange C will exchange them at a 50% discount, are they "valid" ? The reliance on hashing is another fallout from deconcentrating authority. I can think of a few other ways to remove trusted authorities, but they'd be equally disconcerting. This does line up with research, see https://gnunet.org/sites/default/files/Tech%20Report%20-%20A%20Survey%20of%20Solutions%20to%20the%20Sybil%20Attack.pdf https://gnunet.org/sites/default/files/Tech%20Report%20-%20A...
- betterunix 13y ago
  "Three words: bank shuts down" It is not as though cryptographers gave no thought at all to the single point of failure in digital cash: http://cs.brown.edu/~anna/papers/lr98.ps http://cs.brown.edu/~anna/papers/lr98.ps You can set things up so that it would take the failure of the entire banking system to destroy your cash, which is not different than the failure of all Bitcoin exchanges. This is still neatly aligned with the modern understanding of fiat currency; you can have multiple banks that are responsible for issuing currency and accepting deposits. It is also important to recognize that while a bank failure would be fatal to a digital cash system, a "51% attack" on Bitcoin would not be fatal to Bitcoin (the system allows such attacks as part of its design). The attack could be selective, it could be disguised as a "block chain fork," etc. Equally important is that the "51% attack" can be performed by any party -- it requires no secret knowledge or special privileges. As bad as a single point of failure may sound, the bank is a clear point of failure and it is not unreasonable to imagine taking special precautions to protect the bank from failure (or to reimburse the bank's customers e.g. FDIC). No special measures can protect Bitcoin users from one party doing a lot of computation and invalidating / reversing / denying transactions, something that is inherent in the design of Bitcoin. "Actually there is, but that requirement is concentrated in the bank, which all users have to trust to steward the currency's value" I had said identity authority, not currency authority. Look at Chaum's online protocol again, and find the place where an authority on identities is required. The bank is the only party in the system that requires a signing key. Offline protocols are different, but that is beyond the scope of any conversation about Bitcoin. Bitcoin is an inherently online protocol: every transaction requires a connection to the Bitcoin network. "your definitions preclude the novel and necessary parts of Bitcoin" I think you have that backwards. Chartalism and modern monetary theory (which forms the basis for fiat money) predate Bitcoin by decades. The security definitions used in provably secure digital cash systems predate Bitcoin as well. Bitcoin's own design makes it incompatible with those previous definitions. There is nothing wrong with rejecting the existing definitions if you find that they fail to capture some important property, but if you choose that route you need to present a novel definition. That is exactly what you see in the work on offline digital cash: the security definition used for online protocols is too restrictive, so a different definition is used (i.e. it is possible to cheat but the identity of a cheater must be revealed). Unfortunately the Bitcoin community has yet to present a novel security definition or a novel definition of money, or at least they have failed to present satisfactory definitions. Again, what is the definition of "valid" money in Bitcoin? What is the definition of "security" for Bitcoin? "If exchange A calls coins stolen and refuses to exchange them, exchange B will still exchange them because it hasn't become aware of this yet, and less-reputable exchange C will exchange them at a 50% discount, are they "valid" ?" This is a case-in-point. There is no definition of "validity" for Bitcoin money, so there is no answer to that question. I am not saying it is easy to formulate a good definition. What I am saying is that such a definition is necessary, at least as far as cryptography is concerned.

mindslight 13y ago

Ah, that is a great illustration of parallel instances. It seems like it's mostly of theoretical relevance for parties of differing computational abilities, which is why I had a hard time grokking it. But it'd definitely come into play say if one ran two instances with the same RSA group. > in online digital cash protocols (like Chaum's), there is no need for an authority on identities, or even for identities Actually there is, but that requirement is concentrated in the bank, which all users have to trust to steward the currency's value. While it's theoretically possible to bootstrap a trustable identity, there's little incentive to trust one party against whom you have no recourse, so adoption requires a real-world identity. These systems would be in widespread use if any government preserved individual rights. Alas. > The problem with Bitcoin is that validity is not well-defined and can change without warning So can Chaum's system. Three words: bank shuts down. The protocol instance is fine, but all real-world balances become invalid. In general, it feels like you're reacting to a lack of guarantees that are usually provided by the assumptions of existing systems, and that your definitions preclude the novel and necessary parts of Bitcoin. If there were only one exchange, we would say validity is whatever it accepts (which would hopefully be well-defined and non-repudiable. yes, Bitcoin would make an absolutely terrible single-issuer protocol). But once you talk about multiple exchanges, the definition must become fluid. If exchange A calls coins stolen and refuses to exchange them, exchange B will still exchange them because it hasn't become aware of this yet, and less-reputable exchange C will exchange them at a 50% discount, are they "valid" ? The reliance on hashing is another fallout from deconcentrating authority. I can think of a few other ways to remove trusted authorities, but they'd be equally disconcerting. This does line up with research, see https://gnunet.org/sites/default/files/Tech%20Report%20-%20A%20Survey%20of%20Solutions%20to%20the%20Sybil%20Attack.pdf https://gnunet.org/sites/default/files/Tech%20Report%20-%20A...

betterunix 13y ago
"Three words: bank shuts down" It is not as though cryptographers gave no thought at all to the single point of failure in digital cash: http://cs.brown.edu/~anna/papers/lr98.ps http://cs.brown.edu/~anna/papers/lr98.ps You can set things up so that it would take the failure of the entire banking system to destroy your cash, which is not different than the failure of all Bitcoin exchanges. This is still neatly aligned with the modern understanding of fiat currency; you can have multiple banks that are responsible for issuing currency and accepting deposits. It is also important to recognize that while a bank failure would be fatal to a digital cash system, a "51% attack" on Bitcoin would not be fatal to Bitcoin (the system allows such attacks as part of its design). The attack could be selective, it could be disguised as a "block chain fork," etc. Equally important is that the "51% attack" can be performed by any party -- it requires no secret knowledge or special privileges. As bad as a single point of failure may sound, the bank is a clear point of failure and it is not unreasonable to imagine taking special precautions to protect the bank from failure (or to reimburse the bank's customers e.g. FDIC). No special measures can protect Bitcoin users from one party doing a lot of computation and invalidating / reversing / denying transactions, something that is inherent in the design of Bitcoin. "Actually there is, but that requirement is concentrated in the bank, which all users have to trust to steward the currency's value" I had said identity authority, not currency authority. Look at Chaum's online protocol again, and find the place where an authority on identities is required. The bank is the only party in the system that requires a signing key. Offline protocols are different, but that is beyond the scope of any conversation about Bitcoin. Bitcoin is an inherently online protocol: every transaction requires a connection to the Bitcoin network. "your definitions preclude the novel and necessary parts of Bitcoin" I think you have that backwards. Chartalism and modern monetary theory (which forms the basis for fiat money) predate Bitcoin by decades. The security definitions used in provably secure digital cash systems predate Bitcoin as well. Bitcoin's own design makes it incompatible with those previous definitions. There is nothing wrong with rejecting the existing definitions if you find that they fail to capture some important property, but if you choose that route you need to present a novel definition. That is exactly what you see in the work on offline digital cash: the security definition used for online protocols is too restrictive, so a different definition is used (i.e. it is possible to cheat but the identity of a cheater must be revealed). Unfortunately the Bitcoin community has yet to present a novel security definition or a novel definition of money, or at least they have failed to present satisfactory definitions. Again, what is the definition of "valid" money in Bitcoin? What is the definition of "security" for Bitcoin? "If exchange A calls coins stolen and refuses to exchange them, exchange B will still exchange them because it hasn't become aware of this yet, and less-reputable exchange C will exchange them at a 50% discount, are they "valid" ?" This is a case-in-point. There is no definition of "validity" for Bitcoin money, so there is no answer to that question. I am not saying it is easy to formulate a good definition. What I am saying is that such a definition is necessary, at least as far as cryptography is concerned.