This is kind of like the German cryptographers knowing that Enigma had weaknesses saying, "Who would invest in the effort needed to take advantage of those problems?"
File sharing could still be a crime. It could just have a punishment to actually fit the offense.
No punishment at all then?
The real problem here is how extremely cruel and unusual the "punishment" is.
No, the problem is that the RIAA decided that instead of adapting its business model to the reality of new technology, they would just abuse the legal system. The courts happily went along with this, and for decades our elected representatives have been giving the copyright lobbyists ever more legal handouts. Great technologies were killed early on to protect these businesses and their outdated notion of how entertainment is distributed.
If a bank didn't have a door on it's vault, or any forms of security whatsoever, would you walk in and take out all the money?
Translation: a pile of money is sitting out in a field, nobody is guarding it.
Even if you proceeded directly to the local police department to report the security flaw and deliver the unguarded money, you'd find yourself in quite a bit of trouble.
Translation: how dare you do the right thing without permission? It's not your job to do the right thing, you should just do your own job and let us do ours.
This is no different than finding a weakness at any other level of the OSI model, the fact people can easily understand HTTP GET's doesn't make them any less serious and dangerous to an attacker.
There is a very important difference: the GET string is sitting right there in the URL. It is meant to be seen by users. It is meant for users to use as they please.
If we are going to base our crimes on "intent," perhaps we should consider the purpose and intent of the GET string in a URL -- let's start with the fact that it is in the URL.
Exploiting a weakness is by definition hacking
Maybe that's your definition, and I suppose Hollywood's definition, but in the real world people exploit weaknesses in systems all the time. Let's put it this way: you just implicated every corporation that pays for shills to post positive reviews on websites, an attack category with its own name:
What, it's not criminal hacking when a powerful corporation does it for the purpose of tricking individual people into buying their products, but it is criminal hacking when an individual person does it to embarrass a power corporation? Interesting world we live in...
It's one thing to send an e-mail to AT&T and copy a security mailing list with a simple example, it's another to write a program and automate the extraction of over 120k e-mails and then package the data and send it to Gawker, while boasting about it on IRC channels.
Yeah: one of those embarrasses AT&T, the other does not. Beyond that, there is no real difference. Email addresses are not top-secret information, and even if they were, AT&T is at fault for doing nothing to protect that list. There was no attempt at security here. All you have is a guy who accessed the system in an unexpected way, who will now be in prison for years while the rest of society cowers in fear, terrified to do unusual things with their computers.
The problem here is that you have this far-right theory about computer ethics, which basically says this: you must ask permission to do anything. If we lived in a world where people hesitated to use their computers without explicit permission, there could never have been anything like Google. We should not have to be terrified to use our computers without permission, even if we are doing things people never expected or intended for us to do.
Law enforcement should be about protecting society from harm. If Weev had gone ahead and used this database to engage in a phishing attack, then raided some bank accounts, I would be all for prosecution, since there was actual fraud being committed. That did not happen. There is no clear harm and no fraud at all. Weev's imprisonment sends a message: get in line, shut the hell up, and do what you are told, otherwise you'll go to jail.
The bitcoin consensus system you point at as being attackable is only solvable by switching to a central authority?
I will not rule out the possibility that a fully-decentralized system could be secure, at least not without some evidence of that. I would not be surprised, however, if that is indeed the case; it is possible that the digital currency problem cannot be solved securely without some kind of authority in the system. That is the situation with identity-based encryption (i.e. public key encryption where a person's email address is their public key): a decryption key issuing authority is needed for IBE. As I had proposed for digital cash, there are IBE schemes where the authority is really a group of authorities that use a threshold system, so that no single authority can decrypt messages on their own. It is also the case that many secure computation systems require authoritative IDs for each party (i.e. some authority must assign names) or common reference strings (i.e. somehow the parties must have a publicly known string that was not generated by the parties themselves), and such systems often solve very difficult problems (e.g. universal composability, which means that a protocol is secure even when arbitrarily composed with any other protocol, including itself).
The real question is this: is a central authority really a bad thing here? It is certainly the case that a central transaction processor is a bad thing; we should be able to spend money anonymously, and we should be able to do so securely. We also want to ensure that nobody can be attacked the way Wikileaks was attacked, so there must be a way for a party to continue to receive and spend money without relying on the authority and without sacrificing security. On the other hand, is it necessarily a bad thing to rely on an authority to *issue* fresh units of value in the system?
The only non-economic argument against an issuing authority is the possibility that the authority will disappear somehow. That is certainly possible; on the other hand, a threshold system would more or less solve that problem, basically creating a situation where *all* authorities would have to simultaneously vanish from the system to shut things down. I do not think it is unrealistic to assume that at least some banks would continue to operate even when others were failing.
Economic arguments are another matter. Bitcoin is predicated on the theory that money does not require a central authority or group of authorities; this is not universally accepted. At the very least, Bitcoin is a good chance to test that theory: if Bitcoin can become mainstream, it would be good evidence for that theory. My own view is that money has value as a result of the law (tax laws, debt laws, torts, etc.), and so Bitcoin will never be able to survive without the ability to exchange it for fiat currencies and that the use of exchanges is too risky and inconvenient for the majority of day-to-day transactions. Again, time will tell; if Bitcoin goes mainstream, my view of money would have to change.
Thanks for clarifying points I've misunderstood.
No problem, and sorry if I came off as rude there.
The problem with Chaum's system is that it appears to rely on a central authority with respect to the banks, and is therefore at the whim of a "benevolent dictator for life".
Sure, but in theory banks have an incentive to run transaction processing systems, and if its competitors participate in a digital cash system then the bank is compelled to do so as well. Bitcoin exchanges are in roughly the same position, at least as far as I can tell: most Bitcoin transactions would never happen if there were no exchanges available. If Bitcoin were to become mainstream, I think the most likely mode would be merchants immediately bringing Bitcoins they receive to a Bitcoin exchange, and trading for whatever currency is used in their nation. At the very least, a merchant with significant Bitcoin business would have to use the exchanges to get enough of their nation's currency to pay their taxes.
Except the issue here, the issue that this article was talking about is precisely that of a disconnected network
No, the nodes in the network were all still communicating with each other, the problem was that they were unable to form a global consensus on which transactions had occurred. A fragmented network would have experienced the same problem, but this was not a fragmented network.
And THAT is why double-spend became possible. Because the network was split. It was not a problem with the abstract design of bitcoin.
No, it was a problem with the abstract design, because the abstract design permits this sort of disagreement to happen regardless of whether the nodes can communicate with each other. This same problem could be caused deliberately by having nodes refuse to follow the block chain.
This sounds like it would run into the same issues as bitcoin just did if the multiple cooperating banks were for some reason unable to communicate
No, as long as the threshold number of banks can communicate, the protocol would complete just fine; if somehow all the banks could be split from one another, the protocol would not run at all. That is the point of a threshold system: it works as long as the threshold number of parties is working together.
Then coins could be drawn from the same account at both banks, and the double spend would go undetected.
Accounts are not what is distributed here, coin generation and online clearing is.
Withdrawal involves coin generation. If you withdraw two coins from two banks, you are not double spending.
If you were to double spend, even if the banks were partitioned into two networks, your double spending would be detected by both once the double spent coins were deposited or when the online clearing protocol is used.
You claim to have read Chaum's work, but you seem to have a lot of misconceptions about it...
Is it economical though? If you can't steal more than it costs then feasibility isn't all that relevant.
Even if we were to accept such an argument -- and it is a very dubious argument -- all that says is that if the value of Bitcoin rises enough, the known attack will be profitable. In other words, your security depends on a deflationary currency not increasing in value over time.
KORUS does allow for administrative procedures like the DMCA's rule-making to adopt temporary exemptions, but not permanent ones. The challenge before Congress is to devise a permanent exception for cell phone unlocking that does not breach the obligations under KORUS and other similar free trade agreements
The US constitution allows temporary copyrights; Congress has managed to ignore the spirit of the constitution by extending copyright terms 20 years every 20 years. How about we just do the same with DMCA exemptions?
if the bank cannot be reached because the network was bisected? An online clearing system only works if there is communication.
Here I was, thinking we were talking about double spending attacks and not denial of service attacks. If you cannot spend anything, you cannot double spend, and so you did not really violate the security of the digital cash system.
To put it another way, you could go to my street, cut my cable line, and disconnect me from the Internet and my email server. That would not be a successful attack on PGP.
Again, if part of the system can't reach the bank for some reason, then double spending is possible.
And again, you are no longer talking about an attack on the digital cash system, you are talking about a denial of service attack. In this case, you are talking about an even more extreme attack: you will prevent your victims from taking their smartcard or computer to the bank i.e. you can restrict their physical mobility (and there is nothing that a digital cash system can do to help there anyway).
It is also worth noting that these attacks are possible in Bitcoin. You can cut a person off from the Bitcoin network, and then they can either refuse to accept payments or they can risk unconfirmed payments. These sorts of attacks are really beyond the scope of what a cryptosystem can help with.
If you can prevent communication between a party and 'the issuing bank' then you can double spend. I fail to see how this is any different?
Here is the difference, since you need it spelled out for you:
In Chaum's system, you need to be able to prevent a party from communicating and restrict their ability to physically move in order to double spend. Lacking that, you need computer power that is exponentially large in a parameter that can be arbitrarily big.
In Bitcoin, you can double spend if you can accumulate computing resources proportional to the total computer power of all Bitcoin participants. You do not need to disconnect anyone from the network to do this. You can also double spend by "forking the block chain," which also does not involve disconnecting anyone from the network.
Does that help clarify things? Nobody but you is talking about disconnecting people from any network. Bitcoin is vulnerable to an attacker that can corrupt nodes in the network, which is not at all unrealistic -- worms that target specific software systems are already known.
I don't think so. You just need to corrupt/takedown 'the bank' and you can do all sorts of evil with all the coins it issued.
Corrupting the bank in a Chaumian system is the equivalent of inserting malicious code into the main Bitcoin client.
Taking down the bank would eventually shut the system down, since offline payments cannot scale without the bank occasionally "refreshing" the tokens. Chaum proved that in his work.
Shutting down the bank's Internet connection with a denial-of-service attack would not stop people from walking into the lobby and using the offline transaction protocol to deposit money with the bank. You would still be caught double spending once that happens.
Temporarily shutting down the bank would still result in you being caught and being ejected from the system.
Single point of failure
Also false, it is possible to create a threshold/MPC system where multiple banks cooperate in the issuing/refreshing/verification process.
as opposed to needing to corrupt >50% of the network to overwhelm its consensus.
You left out the "buying that much computing power." Sure, it is hard, but so was this:
That is where the real difference lies: it is not infeasible to gather enough computing power to attack Bitcoin. Even in an ideal world where no computers could ever be corrupted by an attacker, Bitcoin would be insecure compared to Chaum's protocols, at least under the cryptographic notion of "security."
it's hard to see how a network of malicious nodes could replicate the issue.
Most successful attacks are "hard to see" until someone manages to pull them off. That is why cryptographers spend so much time proving that protocols and cryptosystems satisfy certain security definitions, and why so much research has been done on multiparty computation.
Presumably eventually they would sync, and your overdraft would be detected.
Right, and by that point you have cashed out, created a new Bitcoin address, and are prepared to start the attack again.
my understanding of Chaum's double-spending protocol doesn't prevent doublespending, it just allows eventual identification of the party that did it
There were two ideas that Chaum proposed for fighting double spending:
Online clearing, which preserves the anonymity of the buyer but not the anonymity of the seller. The seller connects to the bank, asks for a verification of the buyer's money, and the bank checks if it has seen the token's ID before. This makes double spending impossible, but requires an online protocol and allows the bank to blacklist certain sellers (e.g. the way Wikileaks was blacklisted).
De-anonymizing double spenders, which is what you are thinking of. The idea is that the bank eventually receives the double-spent money, identifies the cheater, and sends out a blacklist that prevents the cheater from spending anything. The bank might also inform the police of the fraud, although cutting the double-spender out of the system is probably enough punishment. Protections against malicious banks that lie about double-spenders are possible. The main advantage of this approach is that it allows offline payments, i.e. payments that are done peer-to-peer, and potentially long offline payment "chains." It is thus possible to live "off the grid" with such a system and still make electronic payments, by receiving all payments offline.
As for the relevance of Chaum's work, this is what you said originally:
I'm not sure any currency is secure enough for monetary transactions according to the standard you appear to demand.
The standard is not really beyond what Chaum's systems promise: even a party that can corrupt a majority of participants cannot double-spend. In the case of online clearing, this is obvious: the bank will just not make a deposit to the seller's account. In the case of an offline protocol (de-anonymizing), double spending is possible only as long as nobody brings their money to the bank; once the double-spending is identified, the attacker is removed from the system entirely. Violating these properties requires computational power that is exponential in a security parameter, whereas the work required to use the system is polynomial in that parameter.
Compare this to Bitcoin: successful double spending is possible when the attack controls more than half the computational power of the network, and even when the attack is stopped, the attacker can rejoin the system and repeat their attack over and over. The computational power needed to successfully attack Bitcoin is proportional to the computational power needed to use Bitcoin at all.
that wouldn't help here, because the network is effectively bisected and something you doublespend on one side can't propagate to the other, so the doublespend will never be resolved.
That is my entire point: Bitcoin does not even provide the security that other systems can provide, even for basic digital cash security notions like preventing double spending.
No amount of malicious nodes spouting garbage is going to prevent two good nodes from talking to each other.
It is not about "spounting garbage;" a node can lie about what messages it received from other nodes. Bitcoin is a consensus protocol; i
That's a bit over the top. I'm not sure any currency is secure enough for monetary transactions according to the standard you appear to demand. You do realize people counterfeit cash a lot easier than bitcoins, right?
I keep saying this, and somehow the Bitcoin crowd never bothers: read Chaum's work. A lot of papers were published on digital cash, they are all easy to find online and can be read at no cost. Chaum's design was resilient to double spending, provided actual anonymity, allowed offline payments to be made (i.e. payments that do not require any Internet connection, only a point-to-point connection between the buyer and seller), and came at the cost of a central issuing authority (which could potentially be split into multiple authorities in a threshold system). In Chaum's system, the work required to successfully violate the security properties of the system is exponential in the security parameter, which can be arbitrarily scaled, while the users' work is polynomial in that parameter.
The problem isn't corruption or malice
"Corrupting" a node in a multiparty system is the equivalent of running malware on that node; it means that the party may deviate from the protocol in arbitrary ways.
That being said, yes, malice is the problem: an attacker is going to send bad messages, desynchronize messages, modify messages, and so forth. If an attacker can send malformed or dishonest messages into the network, and in doing so enable a double spending attack, then the system is not secure. If the attacker has to run malware on some number of nodes to pull off the attack, the system is not secure.
There are already reports of people taking advantage of the forked block chain to double spend their money. If this can be caused by an accident, then it might also be caused deliberately by a motivated attacker.
The problem with your argument is that an incompatibility between two cryptosystems should not render those systems insecure. In the case of Bitcoin, the "fork" allowed people to double spend, violating a key security property of any digital cash system.
Let's put it this way: an attacker might deliberately create incompatibilities between nodes in Bitcoin by using some kind of malware; trigger this when enough nodes are infected and you give yourself the perfect opportunity to double spend.
In general, a multiparty computation system (a category that includes all digital cash systems, Bitcoin included) needs to be able to maintain its security properties even when some parties are corrupted. Malicious parties in a system might deviate from the protocol in arbitrary ways, for arbitrary reasons. If Bitcoin cannot survive that sort of deviation, then Bitcoin is not secure enough for monetary transactions, even if you are talking about a third or even half the nodes in the network being malicious.
Well there is a missing phrase there: secure in the abstract sense. ElGamal is secure in abstract terms (i.e. against a chosen plaintext attack); the only way for implementations of ElGamal to be insecure is by side channel attacks, and anything else would not be an implementation of ElGamal (e.g. a system that fails to use a random number generator is not an implementation of ElGamal, which requires a random number generator). Similarly, David Chaum's digital cash systems were secure in the abstract sense (for various notions of security), and so any vulnerabilities would either involve side channel attacks or incorrect implementations.
Bitcoin, on the other hand, seems to lack the property that it is secure in the abstract sense. If all it takes is a sufficiently large fraction of participants in the network to use an outdated implementation, then an adversary who can corrupt that many participants can successfully attack the network. Yes, security against adversaries who can corrupt more than a third of the participants in any multiparty system is hard to achieve, but given that the Bitcoin crowd expects people to trust Bitcoin with real-world monetary transactions, I think it is fair to demand something better (especially given all the work on digital cash in the 80s and 90s).
OK, but if the entire system's ability to securely process transactions (which is what this really boils down to) hinges on the clients all using the same version of the same software, Bitcoin is extremely vulnerable to attack. One can easily imagine some malware that goes around introducing this sort of bug into Bitcoin clients, and when enough machines are infected, the bug is triggered to create a fork and the attacker uses that fork to engage in large-scale double spending. One might not even require malware; the attacker only needs to find some subtle bug in future versions of the software, trigger it, and exploit the fork.
Basically, an attacker who can corrupt a sufficient number of Bitcoin participants can break the security model; that number may be even smaller than people thought. We already know that an attacker who controls more than half the computing power of the Bitcoin network could do that, so this is not really news. There is a reason modern cryptographers do not usually make such arguments:
If the system "forked" the security against double spending is broken. Can I spend money I accumulated prior to the fork on both networks? If money is generated in one network, can I use it on both networks simultaneously?
In general, a digital cash system should not permit one unit of value to be spent by more than one party simultaneously.
I see a bigger issue: the fact that the abstract security of this system is dependent on specific implementation details like which database is used or what its maximum atomic update size is. A cryptographic currency system needs to be secure regardless of how it is implemented, how many implementations there are, or what underlying technologies are chosen for those implementations. Anything less renders the system insecure and open to attack.
The problem is that not enough users have upgraded to the replacement yet
This sounds like a horribly broken cryptosystem: your security depends on how many other users of the system have upgraded to a new version of some database?
Do you even know what "crypto" means? How is that in any way related to the database chosen in the implementation?
Usually, cryptosystems do not rely on things like the maximum size of atomic transactions in a database to work or to be secure in the abstract sense; it seems that in the case of Bitcoin, that is exactly what happened. This bug is not some kind of side channel attack (e.g. as you saw with Skype, where the cryptosystem was theoretically secure but where the implementation had an easily exploited side channel), it is not an implementation that leaves a secret key in some publicly accessible place, it is not a failure to properly implement the abstract cryptosystem. This is a cryptosystem whose security depends on specific implementation details.
To put it another way, imagine if instead of the database implementation, it was the CPU architecture that determined the security of the system. As long as everyone uses x86, it is fine, but if a few people start using ARM or PowerPC the system "forks." Would you trust such a system? What differentiates that hypothetical scenario from the database issue?
I know a bit about trucks from a roommate, my current girlfriend (a former bus driver) and an uncle. The problem with slowing a truck down is the enormous weight you are dealing with; if the vehicle is moving fast enough, friction braking is insufficient and in the worst case can fail entirely. Engine braking is important in trucks, and truckers will shift to a lower gear when going downhill or when they need to slow down or stop.
If you ever hear a truck that sounds like a jackhammer, that is a truck that is using a kind of braking system called compression-release braking or a "Jake brake." Basically, this system works by using a piston to compress air as it moves upward, then releasing the compressed air through the exhaust; the energy needed to compress the air comes from the turning crankshaft, and ultimately from the vehicle's forward motion (hence slowing it down). Some places have banned the use of these systems because of the noise pollution, but that is equivalent to telling truckers they cannot use a safety feature of their vehicle.
They are looking for a whistleblower. An encrypted message to the press is a big red flag that says, "I am a whistleblower," unless all the deans are in the business of communicating with the press. A message to an anonymous remailer is equally incriminating.
The real answer here is to take the documents out of Harvard on a thumb drive and mail them from an Internet cafe or somewhere else that cannot be monitored by the administration.
Slashdot Mirror
This is kind of like the German cryptographers knowing that Enigma had weaknesses saying, "Who would invest in the effort needed to take advantage of those problems?"
File sharing could still be a crime. It could just have a punishment to actually fit the offense.
No punishment at all then?
The real problem here is how extremely cruel and unusual the "punishment" is.
No, the problem is that the RIAA decided that instead of adapting its business model to the reality of new technology, they would just abuse the legal system. The courts happily went along with this, and for decades our elected representatives have been giving the copyright lobbyists ever more legal handouts. Great technologies were killed early on to protect these businesses and their outdated notion of how entertainment is distributed.
If you paid for a subsidized phone under a contract then no until that contract is over, then yes you should be able to.
What if I want to pay for another contract simultaneously without buying a second phone?
If a bank didn't have a door on it's vault, or any forms of security whatsoever, would you walk in and take out all the money?
Translation: a pile of money is sitting out in a field, nobody is guarding it.
Even if you proceeded directly to the local police department to report the security flaw and deliver the unguarded money, you'd find yourself in quite a bit of trouble.
Translation: how dare you do the right thing without permission? It's not your job to do the right thing, you should just do your own job and let us do ours.
This is no different than finding a weakness at any other level of the OSI model, the fact people can easily understand HTTP GET's doesn't make them any less serious and dangerous to an attacker.
There is a very important difference: the GET string is sitting right there in the URL. It is meant to be seen by users. It is meant for users to use as they please.
If we are going to base our crimes on "intent," perhaps we should consider the purpose and intent of the GET string in a URL -- let's start with the fact that it is in the URL.
Exploiting a weakness is by definition hacking
Maybe that's your definition, and I suppose Hollywood's definition, but in the real world people exploit weaknesses in systems all the time. Let's put it this way: you just implicated every corporation that pays for shills to post positive reviews on websites, an attack category with its own name:
https://en.wikipedia.org/wiki/Sybil_attack
What, it's not criminal hacking when a powerful corporation does it for the purpose of tricking individual people into buying their products, but it is criminal hacking when an individual person does it to embarrass a power corporation? Interesting world we live in...
It's one thing to send an e-mail to AT&T and copy a security mailing list with a simple example, it's another to write a program and automate the extraction of over 120k e-mails and then package the data and send it to Gawker, while boasting about it on IRC channels.
Yeah: one of those embarrasses AT&T, the other does not. Beyond that, there is no real difference. Email addresses are not top-secret information, and even if they were, AT&T is at fault for doing nothing to protect that list. There was no attempt at security here. All you have is a guy who accessed the system in an unexpected way, who will now be in prison for years while the rest of society cowers in fear, terrified to do unusual things with their computers.
The problem here is that you have this far-right theory about computer ethics, which basically says this: you must ask permission to do anything. If we lived in a world where people hesitated to use their computers without explicit permission, there could never have been anything like Google. We should not have to be terrified to use our computers without permission, even if we are doing things people never expected or intended for us to do.
Law enforcement should be about protecting society from harm. If Weev had gone ahead and used this database to engage in a phishing attack, then raided some bank accounts, I would be all for prosecution, since there was actual fraud being committed. That did not happen. There is no clear harm and no fraud at all. Weev's imprisonment sends a message: get in line, shut the hell up, and do what you are told, otherwise you'll go to jail.
Getting at those addresses took some deliberate work on his part
That "deliberate work" amounted to this:
Weev: "Can I have the email address for whoever is associated with this number?"
AT&T: "Sure, it's xxx@yyy.zzz!"
Now that's a criminal mastermind hacker if I ever saw one!
The bitcoin consensus system you point at as being attackable is only solvable by switching to a central authority?
I will not rule out the possibility that a fully-decentralized system could be secure, at least not without some evidence of that. I would not be surprised, however, if that is indeed the case; it is possible that the digital currency problem cannot be solved securely without some kind of authority in the system. That is the situation with identity-based encryption (i.e. public key encryption where a person's email address is their public key): a decryption key issuing authority is needed for IBE. As I had proposed for digital cash, there are IBE schemes where the authority is really a group of authorities that use a threshold system, so that no single authority can decrypt messages on their own. It is also the case that many secure computation systems require authoritative IDs for each party (i.e. some authority must assign names) or common reference strings (i.e. somehow the parties must have a publicly known string that was not generated by the parties themselves), and such systems often solve very difficult problems (e.g. universal composability, which means that a protocol is secure even when arbitrarily composed with any other protocol, including itself).
The real question is this: is a central authority really a bad thing here? It is certainly the case that a central transaction processor is a bad thing; we should be able to spend money anonymously, and we should be able to do so securely. We also want to ensure that nobody can be attacked the way Wikileaks was attacked, so there must be a way for a party to continue to receive and spend money without relying on the authority and without sacrificing security. On the other hand, is it necessarily a bad thing to rely on an authority to *issue* fresh units of value in the system?
The only non-economic argument against an issuing authority is the possibility that the authority will disappear somehow. That is certainly possible; on the other hand, a threshold system would more or less solve that problem, basically creating a situation where *all* authorities would have to simultaneously vanish from the system to shut things down. I do not think it is unrealistic to assume that at least some banks would continue to operate even when others were failing.
Economic arguments are another matter. Bitcoin is predicated on the theory that money does not require a central authority or group of authorities; this is not universally accepted. At the very least, Bitcoin is a good chance to test that theory: if Bitcoin can become mainstream, it would be good evidence for that theory. My own view is that money has value as a result of the law (tax laws, debt laws, torts, etc.), and so Bitcoin will never be able to survive without the ability to exchange it for fiat currencies and that the use of exchanges is too risky and inconvenient for the majority of day-to-day transactions. Again, time will tell; if Bitcoin goes mainstream, my view of money would have to change.
Thanks for clarifying points I've misunderstood.
No problem, and sorry if I came off as rude there.
The problem with Chaum's system is that it appears to rely on a central authority with respect to the banks, and is therefore at the whim of a "benevolent dictator for life".
Sure, but in theory banks have an incentive to run transaction processing systems, and if its competitors participate in a digital cash system then the bank is compelled to do so as well. Bitcoin exchanges are in roughly the same position, at least as far as I can tell: most Bitcoin transactions would never happen if there were no exchanges available. If Bitcoin were to become mainstream, I think the most likely mode would be merchants immediately bringing Bitcoins they receive to a Bitcoin exchange, and trading for whatever currency is used in their nation. At the very least, a merchant with significant Bitcoin business would have to use the exchanges to get enough of their nation's currency to pay their taxes.
That is like saying that getting my car serviced by a local mechanic instead of the dealer is "theft."
Except the issue here, the issue that this article was talking about is precisely that of a disconnected network
No, the nodes in the network were all still communicating with each other, the problem was that they were unable to form a global consensus on which transactions had occurred. A fragmented network would have experienced the same problem, but this was not a fragmented network.
And THAT is why double-spend became possible. Because the network was split. It was not a problem with the abstract design of bitcoin.
No, it was a problem with the abstract design, because the abstract design permits this sort of disagreement to happen regardless of whether the nodes can communicate with each other. This same problem could be caused deliberately by having nodes refuse to follow the block chain.
This sounds like it would run into the same issues as bitcoin just did if the multiple cooperating banks were for some reason unable to communicate
No, as long as the threshold number of banks can communicate, the protocol would complete just fine; if somehow all the banks could be split from one another, the protocol would not run at all. That is the point of a threshold system: it works as long as the threshold number of parties is working together.
Then coins could be drawn from the same account at both banks, and the double spend would go undetected.
You claim to have read Chaum's work, but you seem to have a lot of misconceptions about it...
Is it economical though? If you can't steal more than it costs then feasibility isn't all that relevant.
Even if we were to accept such an argument -- and it is a very dubious argument -- all that says is that if the value of Bitcoin rises enough, the known attack will be profitable. In other words, your security depends on a deflationary currency not increasing in value over time.
KORUS does allow for administrative procedures like the DMCA's rule-making to adopt temporary exemptions, but not permanent ones. The challenge before Congress is to devise a permanent exception for cell phone unlocking that does not breach the obligations under KORUS and other similar free trade agreements
The US constitution allows temporary copyrights; Congress has managed to ignore the spirit of the constitution by extending copyright terms 20 years every 20 years. How about we just do the same with DMCA exemptions?
if the bank cannot be reached because the network was bisected? An online clearing system only works if there is communication.
Here I was, thinking we were talking about double spending attacks and not denial of service attacks. If you cannot spend anything, you cannot double spend, and so you did not really violate the security of the digital cash system.
To put it another way, you could go to my street, cut my cable line, and disconnect me from the Internet and my email server. That would not be a successful attack on PGP.
Again, if part of the system can't reach the bank for some reason, then double spending is possible.
And again, you are no longer talking about an attack on the digital cash system, you are talking about a denial of service attack. In this case, you are talking about an even more extreme attack: you will prevent your victims from taking their smartcard or computer to the bank i.e. you can restrict their physical mobility (and there is nothing that a digital cash system can do to help there anyway).
It is also worth noting that these attacks are possible in Bitcoin. You can cut a person off from the Bitcoin network, and then they can either refuse to accept payments or they can risk unconfirmed payments. These sorts of attacks are really beyond the scope of what a cryptosystem can help with.
If you can prevent communication between a party and 'the issuing bank' then you can double spend. I fail to see how this is any different?
Here is the difference, since you need it spelled out for you:
Does that help clarify things? Nobody but you is talking about disconnecting people from any network. Bitcoin is vulnerable to an attacker that can corrupt nodes in the network, which is not at all unrealistic -- worms that target specific software systems are already known.
I don't think so. You just need to corrupt/takedown 'the bank' and you can do all sorts of evil with all the coins it issued.
Single point of failure
Also false, it is possible to create a threshold/MPC system where multiple banks cooperate in the issuing/refreshing/verification process.
as opposed to needing to corrupt >50% of the network to overwhelm its consensus.
You left out the "buying that much computing power." Sure, it is hard, but so was this:
https://en.wikipedia.org/wiki/Bombe
That is where the real difference lies: it is not infeasible to gather enough computing power to attack Bitcoin. Even in an ideal world where no computers could ever be corrupted by an attacker, Bitcoin would be insecure compared to Chaum's protocols, at least under the cryptographic notion of "security."
that is an inevitable consequence of any p2p system, simply because the participants are the network
That is not true; see e.g.:
http://eprint.iacr.org/2012/441
Here is a layman's translation:
In other words, this is a system that protects against an even more sophisticated version of the attack I described above.
Okay, how could it be improved?
Drop the idea of not having any banks, and then create the sort of system described in this line of research:
http://www.cs.ut.ee/~lipmaa/crypto/link/protocols/ecash.php
it's hard to see how a network of malicious nodes could replicate the issue.
Most successful attacks are "hard to see" until someone manages to pull them off. That is why cryptographers spend so much time proving that protocols and cryptosystems satisfy certain security definitions, and why so much research has been done on multiparty computation.
Presumably eventually they would sync, and your overdraft would be detected.
Right, and by that point you have cashed out, created a new Bitcoin address, and are prepared to start the attack again.
my understanding of Chaum's double-spending protocol doesn't prevent doublespending, it just allows eventual identification of the party that did it
There were two ideas that Chaum proposed for fighting double spending:
As for the relevance of Chaum's work, this is what you said originally:
I'm not sure any currency is secure enough for monetary transactions according to the standard you appear to demand.
The standard is not really beyond what Chaum's systems promise: even a party that can corrupt a majority of participants cannot double-spend. In the case of online clearing, this is obvious: the bank will just not make a deposit to the seller's account. In the case of an offline protocol (de-anonymizing), double spending is possible only as long as nobody brings their money to the bank; once the double-spending is identified, the attacker is removed from the system entirely. Violating these properties requires computational power that is exponential in a security parameter, whereas the work required to use the system is polynomial in that parameter.
Compare this to Bitcoin: successful double spending is possible when the attack controls more than half the computational power of the network, and even when the attack is stopped, the attacker can rejoin the system and repeat their attack over and over. The computational power needed to successfully attack Bitcoin is proportional to the computational power needed to use Bitcoin at all.
that wouldn't help here, because the network is effectively bisected and something you doublespend on one side can't propagate to the other, so the doublespend will never be resolved.
That is my entire point: Bitcoin does not even provide the security that other systems can provide, even for basic digital cash security notions like preventing double spending.
No amount of malicious nodes spouting garbage is going to prevent two good nodes from talking to each other.
It is not about "spounting garbage;" a node can lie about what messages it received from other nodes. Bitcoin is a consensus protocol; i
That's a bit over the top. I'm not sure any currency is secure enough for monetary transactions according to the standard you appear to demand. You do realize people counterfeit cash a lot easier than bitcoins, right?
I keep saying this, and somehow the Bitcoin crowd never bothers: read Chaum's work. A lot of papers were published on digital cash, they are all easy to find online and can be read at no cost. Chaum's design was resilient to double spending, provided actual anonymity, allowed offline payments to be made (i.e. payments that do not require any Internet connection, only a point-to-point connection between the buyer and seller), and came at the cost of a central issuing authority (which could potentially be split into multiple authorities in a threshold system). In Chaum's system, the work required to successfully violate the security properties of the system is exponential in the security parameter, which can be arbitrarily scaled, while the users' work is polynomial in that parameter.
The problem isn't corruption or malice
"Corrupting" a node in a multiparty system is the equivalent of running malware on that node; it means that the party may deviate from the protocol in arbitrary ways.
That being said, yes, malice is the problem: an attacker is going to send bad messages, desynchronize messages, modify messages, and so forth. If an attacker can send malformed or dishonest messages into the network, and in doing so enable a double spending attack, then the system is not secure. If the attacker has to run malware on some number of nodes to pull off the attack, the system is not secure.
There are already reports of people taking advantage of the forked block chain to double spend their money. If this can be caused by an accident, then it might also be caused deliberately by a motivated attacker.
The problem with your argument is that an incompatibility between two cryptosystems should not render those systems insecure. In the case of Bitcoin, the "fork" allowed people to double spend, violating a key security property of any digital cash system.
Let's put it this way: an attacker might deliberately create incompatibilities between nodes in Bitcoin by using some kind of malware; trigger this when enough nodes are infected and you give yourself the perfect opportunity to double spend.
In general, a multiparty computation system (a category that includes all digital cash systems, Bitcoin included) needs to be able to maintain its security properties even when some parties are corrupted. Malicious parties in a system might deviate from the protocol in arbitrary ways, for arbitrary reasons. If Bitcoin cannot survive that sort of deviation, then Bitcoin is not secure enough for monetary transactions, even if you are talking about a third or even half the nodes in the network being malicious.
Well there is a missing phrase there: secure in the abstract sense. ElGamal is secure in abstract terms (i.e. against a chosen plaintext attack); the only way for implementations of ElGamal to be insecure is by side channel attacks, and anything else would not be an implementation of ElGamal (e.g. a system that fails to use a random number generator is not an implementation of ElGamal, which requires a random number generator). Similarly, David Chaum's digital cash systems were secure in the abstract sense (for various notions of security), and so any vulnerabilities would either involve side channel attacks or incorrect implementations.
Bitcoin, on the other hand, seems to lack the property that it is secure in the abstract sense. If all it takes is a sufficiently large fraction of participants in the network to use an outdated implementation, then an adversary who can corrupt that many participants can successfully attack the network. Yes, security against adversaries who can corrupt more than a third of the participants in any multiparty system is hard to achieve, but given that the Bitcoin crowd expects people to trust Bitcoin with real-world monetary transactions, I think it is fair to demand something better (especially given all the work on digital cash in the 80s and 90s).
OK, but if the entire system's ability to securely process transactions (which is what this really boils down to) hinges on the clients all using the same version of the same software, Bitcoin is extremely vulnerable to attack. One can easily imagine some malware that goes around introducing this sort of bug into Bitcoin clients, and when enough machines are infected, the bug is triggered to create a fork and the attacker uses that fork to engage in large-scale double spending. One might not even require malware; the attacker only needs to find some subtle bug in future versions of the software, trigger it, and exploit the fork.
Basically, an attacker who can corrupt a sufficient number of Bitcoin participants can break the security model; that number may be even smaller than people thought. We already know that an attacker who controls more than half the computing power of the Bitcoin network could do that, so this is not really news. There is a reason modern cryptographers do not usually make such arguments:
https://en.wikipedia.org/wiki/Bombe
The security was never broken
If the system "forked" the security against double spending is broken. Can I spend money I accumulated prior to the fork on both networks? If money is generated in one network, can I use it on both networks simultaneously?
In general, a digital cash system should not permit one unit of value to be spent by more than one party simultaneously.
I see a bigger issue: the fact that the abstract security of this system is dependent on specific implementation details like which database is used or what its maximum atomic update size is. A cryptographic currency system needs to be secure regardless of how it is implemented, how many implementations there are, or what underlying technologies are chosen for those implementations. Anything less renders the system insecure and open to attack.
The problem is that not enough users have upgraded to the replacement yet
This sounds like a horribly broken cryptosystem: your security depends on how many other users of the system have upgraded to a new version of some database?
They'll have to upgrade sooner or later though.
According to whom?
Do you even know what "crypto" means? How is that in any way related to the database chosen in the implementation?
Usually, cryptosystems do not rely on things like the maximum size of atomic transactions in a database to work or to be secure in the abstract sense; it seems that in the case of Bitcoin, that is exactly what happened. This bug is not some kind of side channel attack (e.g. as you saw with Skype, where the cryptosystem was theoretically secure but where the implementation had an easily exploited side channel), it is not an implementation that leaves a secret key in some publicly accessible place, it is not a failure to properly implement the abstract cryptosystem. This is a cryptosystem whose security depends on specific implementation details.
To put it another way, imagine if instead of the database implementation, it was the CPU architecture that determined the security of the system. As long as everyone uses x86, it is fine, but if a few people start using ARM or PowerPC the system "forks." Would you trust such a system? What differentiates that hypothetical scenario from the database issue?
So the currency that is supposedly based on crypto winds up forking into two different currencies because of a database update? Nice job guys.
I know a bit about trucks from a roommate, my current girlfriend (a former bus driver) and an uncle. The problem with slowing a truck down is the enormous weight you are dealing with; if the vehicle is moving fast enough, friction braking is insufficient and in the worst case can fail entirely. Engine braking is important in trucks, and truckers will shift to a lower gear when going downhill or when they need to slow down or stop.
If you ever hear a truck that sounds like a jackhammer, that is a truck that is using a kind of braking system called compression-release braking or a "Jake brake." Basically, this system works by using a piston to compress air as it moves upward, then releasing the compressed air through the exhaust; the energy needed to compress the air comes from the turning crankshaft, and ultimately from the vehicle's forward motion (hence slowing it down). Some places have banned the use of these systems because of the noise pollution, but that is equivalent to telling truckers they cannot use a safety feature of their vehicle.
They are looking for a whistleblower. An encrypted message to the press is a big red flag that says, "I am a whistleblower," unless all the deans are in the business of communicating with the press. A message to an anonymous remailer is equally incriminating.
The real answer here is to take the documents out of Harvard on a thumb drive and mail them from an Internet cafe or somewhere else that cannot be monitored by the administration.
You realize that if you leak anything that is on a computer, you need to access that computer at some point.