4 ms·

"The thing you must realize is that those previous systems didn't solve the problem Bitcoin solves" That is not the point. Previous work in the field of digit

"The thing you must realize is that those previous systems didn't solve the problem Bitcoin solves" That is not the point. Previous work in the field of digital cash and in multiparty computation is very much relevant to Bitcoin, even if Bitcoin addresses a modified problem. The failure to even mention that such work has been done, coupled with a woefully deficient analysis, indicates that the author of the Bitcoin paper had not done much background research. What stands out the most is the security analysis for Bitcoin. First, the author makes the claim that the system is secure as long as the attacker controls less than half the sum of the computing power of all nodes in the system. This is not really a well-understood model of security; cryptography researchers usually speak of either "honest but curious" models i.e. everyone follows the protocol faithfully or "malicious" models i.e. some parties may deviate from the protocol in arbitrary ways. The idea of a party that can deviate, but only as long as their work is less than the sum of the work done by all other parties, is strange -- but this new security model is not discussed in any depth, nor is it even mentioned as being a new model of security. No time is spent actually proving the claim, which is unsurprising given that the security model itself is not even formalized. Worse still, the security analysis that is presented only deals with a specific attack carried out in a specific way. The author proves in a somewhat-formal way that this particular attack cannot be carried out in the way he envisioned. No evidence is given that another method of carrying out the attack is impossible, nor is any evidence given that other attacks are impossible. There is an old proverb in cryptography: anyone can come up with a cryptosystem they themselves cannot break. That is what you are seeing with Bitcoin, but even worse, because the developers know how to break it but do not believe that anyone would be willing to put in the effort. The German cryptographers were surprised to discover that the Allies were willing to build the code-breaking machine necessary to crack Enigma; they knew it had weaknesses but believed that the cost of exploiting those weaknesses was too high for anyone to justify. My point is less about what problem Bitcoin solves, and more about whether or not Bitcoin's developers are aware of just how much work has been done on secure multiparty computation or digital cash systems.

mindslight 14y ago
I don't really disagree with anything you're saying. Bitcoin has a lack of rigor all around, and it's quite annoying to see the masses of people defending Bitcoin as being anonymous (etc) when they've no context to place it in. What I am trying to point out is that Bitcoin has a design property that enables it to actually be adopted (no "bank" - something no other ecash system had, as they were mostly designed in an era when people still believed that banks would be interested in preserving their customers' privacy. lol). This is important if someone is to ever build a better system. I'm less familiar with recent MPC literature, but the general concept strikes me as more of an existence proof, given the actual efficiency of resulting implementations. Practical ZK/WI results seem to generally decompose larger domain-specific chunks of the problem into primitive operations, rather than one crypto op per generic logic gate. Which seems to be what Bitcoin is doing, in a bumbling sort of way. And I don't see too much of a philosophical leap between "majority of parties" and "majority of computation", given that the former is wishful thinking that admits Sybil attacks.
- betterunix 14y ago
  "What I am trying to point out is that Bitcoin has a design property that enables it to actually be adopted (no "bank" - something no other ecash system had, as they were mostly designed in an era when people still believed that banks would be interested in preserving their customers' privacy. lol). This is important if someone is to ever build a better system." Keep in mind that there is more to digital cash than just maintaining customer privacy (and Bitcoin itself does not really give you anonymity, at least with any reliable guarantees). Banks benefits from digital cash because of the difficulty of committing fraud and (assuming offline transactions) the reduced load on their transaction processing systems. The real issue is not that banks have no incentive to deploy such a system, but rather that their existence fraud-mitigation measures are more cost effective (in the short term). As my colleagues who have worked with banks have explained it to me, the banks only want to know what amount of fraud would occur; if your system can reduce that fraud more than it costs to deploy, then the bank will spend the money to deploy it. The same design that has led to Bitcoin's adoption is also something of a liability for the system. Without any banks, converting Bitcoin to other currencies requires the use of an exchange, which carries increased costs and risks. The lack of stability in the price of Bitcoin relative to USD is a result of this issue. It is easy to forget that there is a source of demand for USD, one that is grounded in legal structures like the tax code, debt law, torts, etc. Even when people use Bitcoin for their business, they still need to eventually exchange Bitcoin for some national currency to pay taxes and repay debts (and perhaps to pay employees who lack the time or sophistication needed to use a Bitcoin exchange). Another issue is more technical: there is no secure way to process an offline Bitcoin transaction. In one of his published papers, Chaum proved a property of offline digital cash systems that is as relevant to Bitcoin as it is to Chaum's design: the amount of information that needs to be exchanged in an offline transaction must grow linearly in the length of the offline transaction chain (imagine if a dollar bill became heavier every time it was given from one person to another). What this means is that either you need the ability to "refresh" the unit of value (e.g. reissuing the token in Chaum's system) or else your offline transactions are either insecure or not scalable. As there is nothing in Bitcoin that can "reissue" currency (which involves creating fresh units and destroying old units), Bitcoin is either insecure, insecure for offline transactions, or it does not scale (note that "secure" in this case refers to formal notions of security; Bitcoin does not actually meet that standard, so this point may be moot anyway). "Practical ZK/WI results seem to generally decompose larger domain-specific chunks of the problem into primitive operations, rather than one crypto op per generic logic gate." Right, and that is within the field of MPC research. General MPC using circuits or some other description of functions is much slower than special-purpose protocols, which are themselves usually slower than just using a trusted third party. You are correct that Bitcoin is an example of special-purpose protocol; the problem is that Bitcoin as it exists today would only be secure in a minutely stronger variant of the honest-but-curious model. Honest-but-curious is really just a research tool, a model that is used to give feasibility results or to test new designs, and it is certainly not the right security model for anything involving money (of any sort). "I don't see too much of a philosophical leap between "majority of parties" and "majority of computation"," The leap is this: a single party might gather immense computing power without corrupting any other party. As a simple example, my research group has access to a supercomputer run by the University of Texas, which I could potentially run anything on (not necessarily legally). If you and I were going to use a two-party protocol of some kind, would you really want to use one that forced you to get access to a similarly powerful supercomputer just to be secure? Worse still, you might not be aware of the computing resources available to other parties. The Germans were not aware of the Enigma-cracking effort until after the end of the war. In today's world, it is possible that your adversary has a botnet, a bunch of EC2 credits, or that you are dealing with the NSA. In all cases, you do not want to rely on a system that requires you to get equal computing power to remain secure. Some MPC protocols are secure unconditionally, meaning that even an attacker whose computing power is completely unbounded will not be able to violate the security property of the system. In such a case, controlling a majority of the computing power of all parties is not even a relevant detail, because increased computing power does not convey any advantage. It is more common to assume some bound on the attacker's computing power and to use complexity theoretic arguments about security. Typically, the attacker is assumed to be able to scale their computing power up by some polynomial in the parameters of the system, which includes the participants. Again, it is because there are real-world adversaries who control large amounts of computing power, potentially in secret, that such models are used. The justification is intuitively this: if you have one desktop and your adversary requires a cluster of ten thousand desktops to break the security of the system, you can get a second desktop and double the work you need to do while forcing your adversary to find ten thousand clusters of ten thousand desktops (i.e. squaring his workload). Super-polynomial growth tends to "run away" at the second half of the chess board, so that a modest increase in the work done by honest parties can result in the attacker needing to keep working until the heat death of the sun. On the other hand, a powerful adversary could potentially corrupt or control parties in the system. The Mafia is not going to buy NSA-level computers; they are going to find the participants and beat them with wrenches. A more real-world example would be the suspicious appearance of lots of highly-reliable anonymous remailers after the September 11th attacks. Having a lot of computing power does little to defeat the remailer system, but if you control all the remailers you can deanonymize anyone. Remailers have a nice security property: only one honest remailer is required to preserve your security (assuming you send your messages through all the remailers and that the remailer protocol itself has certain security properties which real-world remailers lack). Sorry if that was a bit long. This is a pretty deep topic, and even the foundations are highly technical.

mindslight 14y ago

I don't really disagree with anything you're saying. Bitcoin has a lack of rigor all around, and it's quite annoying to see the masses of people defending Bitcoin as being anonymous (etc) when they've no context to place it in. What I am trying to point out is that Bitcoin has a design property that enables it to actually be adopted (no "bank" - something no other ecash system had, as they were mostly designed in an era when people still believed that banks would be interested in preserving their customers' privacy. lol). This is important if someone is to ever build a better system. I'm less familiar with recent MPC literature, but the general concept strikes me as more of an existence proof, given the actual efficiency of resulting implementations. Practical ZK/WI results seem to generally decompose larger domain-specific chunks of the problem into primitive operations, rather than one crypto op per generic logic gate. Which seems to be what Bitcoin is doing, in a bumbling sort of way. And I don't see too much of a philosophical leap between "majority of parties" and "majority of computation", given that the former is wishful thinking that admits Sybil attacks.

betterunix 14y ago
"What I am trying to point out is that Bitcoin has a design property that enables it to actually be adopted (no "bank" - something no other ecash system had, as they were mostly designed in an era when people still believed that banks would be interested in preserving their customers' privacy. lol). This is important if someone is to ever build a better system." Keep in mind that there is more to digital cash than just maintaining customer privacy (and Bitcoin itself does not really give you anonymity, at least with any reliable guarantees). Banks benefits from digital cash because of the difficulty of committing fraud and (assuming offline transactions) the reduced load on their transaction processing systems. The real issue is not that banks have no incentive to deploy such a system, but rather that their existence fraud-mitigation measures are more cost effective (in the short term). As my colleagues who have worked with banks have explained it to me, the banks only want to know what amount of fraud would occur; if your system can reduce that fraud more than it costs to deploy, then the bank will spend the money to deploy it. The same design that has led to Bitcoin's adoption is also something of a liability for the system. Without any banks, converting Bitcoin to other currencies requires the use of an exchange, which carries increased costs and risks. The lack of stability in the price of Bitcoin relative to USD is a result of this issue. It is easy to forget that there is a source of demand for USD, one that is grounded in legal structures like the tax code, debt law, torts, etc. Even when people use Bitcoin for their business, they still need to eventually exchange Bitcoin for some national currency to pay taxes and repay debts (and perhaps to pay employees who lack the time or sophistication needed to use a Bitcoin exchange). Another issue is more technical: there is no secure way to process an offline Bitcoin transaction. In one of his published papers, Chaum proved a property of offline digital cash systems that is as relevant to Bitcoin as it is to Chaum's design: the amount of information that needs to be exchanged in an offline transaction must grow linearly in the length of the offline transaction chain (imagine if a dollar bill became heavier every time it was given from one person to another). What this means is that either you need the ability to "refresh" the unit of value (e.g. reissuing the token in Chaum's system) or else your offline transactions are either insecure or not scalable. As there is nothing in Bitcoin that can "reissue" currency (which involves creating fresh units and destroying old units), Bitcoin is either insecure, insecure for offline transactions, or it does not scale (note that "secure" in this case refers to formal notions of security; Bitcoin does not actually meet that standard, so this point may be moot anyway). "Practical ZK/WI results seem to generally decompose larger domain-specific chunks of the problem into primitive operations, rather than one crypto op per generic logic gate." Right, and that is within the field of MPC research. General MPC using circuits or some other description of functions is much slower than special-purpose protocols, which are themselves usually slower than just using a trusted third party. You are correct that Bitcoin is an example of special-purpose protocol; the problem is that Bitcoin as it exists today would only be secure in a minutely stronger variant of the honest-but-curious model. Honest-but-curious is really just a research tool, a model that is used to give feasibility results or to test new designs, and it is certainly not the right security model for anything involving money (of any sort). "I don't see too much of a philosophical leap between "majority of parties" and "majority of computation"," The leap is this: a single party might gather immense computing power without corrupting any other party. As a simple example, my research group has access to a supercomputer run by the University of Texas, which I could potentially run anything on (not necessarily legally). If you and I were going to use a two-party protocol of some kind, would you really want to use one that forced you to get access to a similarly powerful supercomputer just to be secure? Worse still, you might not be aware of the computing resources available to other parties. The Germans were not aware of the Enigma-cracking effort until after the end of the war. In today's world, it is possible that your adversary has a botnet, a bunch of EC2 credits, or that you are dealing with the NSA. In all cases, you do not want to rely on a system that requires you to get equal computing power to remain secure. Some MPC protocols are secure unconditionally, meaning that even an attacker whose computing power is completely unbounded will not be able to violate the security property of the system. In such a case, controlling a majority of the computing power of all parties is not even a relevant detail, because increased computing power does not convey any advantage. It is more common to assume some bound on the attacker's computing power and to use complexity theoretic arguments about security. Typically, the attacker is assumed to be able to scale their computing power up by some polynomial in the parameters of the system, which includes the participants. Again, it is because there are real-world adversaries who control large amounts of computing power, potentially in secret, that such models are used. The justification is intuitively this: if you have one desktop and your adversary requires a cluster of ten thousand desktops to break the security of the system, you can get a second desktop and double the work you need to do while forcing your adversary to find ten thousand clusters of ten thousand desktops (i.e. squaring his workload). Super-polynomial growth tends to "run away" at the second half of the chess board, so that a modest increase in the work done by honest parties can result in the attacker needing to keep working until the heat death of the sun. On the other hand, a powerful adversary could potentially corrupt or control parties in the system. The Mafia is not going to buy NSA-level computers; they are going to find the participants and beat them with wrenches. A more real-world example would be the suspicious appearance of lots of highly-reliable anonymous remailers after the September 11th attacks. Having a lot of computing power does little to defeat the remailer system, but if you control all the remailers you can deanonymize anyone. Remailers have a nice security property: only one honest remailer is required to preserve your security (assuming you send your messages through all the remailers and that the remailer protocol itself has certain security properties which real-world remailers lack). Sorry if that was a bit long. This is a pretty deep topic, and even the foundations are highly technical.