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).
> 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).
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.
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.
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.
(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.
"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.
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...
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.
> 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.
Yes, but something has to instill faith in that bank. This is real-world identity in a rule of law jurisdiction, which is why they used the word "bank". "Banks" can't have their only point of contact be an onion address.
> .. you can have multiple banks that are responsible .. or to reimburse the bank's customers e.g. FDIC
You're missing that all of these systems rely on the incumbent identity providers (governments) to not shut down the banks. "Group signatures" only obfuscate this problem, the signers still cannot be anonymous, lest you're back in Sybil attack territory.
> you need to present a novel definition ... What I am saying is that such a definition is necessary, at least as far as cryptography is concerned
First, most of the definitions you want for don't globally exist because we've given up the assumption of global consistency. The answer to my hypothetical ABC example is "no" if you are deciding to accept the coin, and "how fast can you spend it" if you already have it. Each node's view of the world is quite simplistic - the emergent system behavior is the important part. And IIRC the paper does analyze as-coded transaction validity, and of course comes out with a probabilistic answer.
More importantly, stop talking about "cryptography". Do you have reason to believe that ECDSA signatures or SHA2 proofs of work are broken? These are the only cryptographic parts of Bitcoin, and there is nothing novel about them. The novelty is a stochastic solution to Byzantine agreement, which is a protocols problem. I keep mentioning this, and you keep blowing right past it to harp on transaction properties that only make sense in the context of well-defined authority.
I think the problem here is that you are trying to decouple money from the government. If you have a definition of money and an economic theory that allows for such a system, that is fine. Do you have such a definition or theory, and are you willing to share it?
"most of the definitions you want for don't globally exist because we've given up the assumption of global consistency"
You might have, but for currency to work there needs to be consistency across the entire market (not necessarily all markets, of course; currency exchanges exist mainly to allow people to move between markets). One of the most important functions of money is as a medium of exchange, which requires an agreement across the entire market about what constitutes valid money.
"More importantly, stop talking about "cryptography"."
Why should I? Digital cash is a cryptography problem. Secure multiparty computation is a major field of study in cryptography; Silvio Micali and Shafi Goldwasser, the pair who recently won a Turing award for their work on defining public key cryptography, also happen to have done extensive SMC work over their respective careers. Cryptographic solutions to the Byzantine Generals problem have been presented many times over the past 20 years. No matter how you try to describe Bitcoin, it absolutely is a cryptosystem and cryptography absolutely is relevant to the conversation.
Furthermore it is dead wrong to think that the security of a signature system or a hash function is the whole story. Unless you can rigorously prove that the security of ECDSA and SHA256 imply the security of Bitcoin (whatever the rigorous definition of security would be for Bitcoin), there is no point in saying that ECDSA and SHA256 are secure. Nobody is calling their security into question here. Bitcoin can be insecure in the cryptographic sense even if ECDSA and SHA256 are secure, unless you think that Bitcoin is a signature system or a hash function.
"you keep blowing right past it"
What I keep doing is asking for definitions. You have ignored or avoided the question over and over again here. To be clear, I am asking you to give a rigorous definition of the security property you want to achieve. That can and should be given as a corollary to a definition of money, since you are not using the definitions economists are familiar with. If Bitcoin is nothing more than a solution to the Byzantine agreement problem, then I see no reason to continue talking about money -- unless you can define money in terms of Byzantine agreement.
Yeah I wish the HN mods didn't change my title. Saying it's from 2011, or that the mystery is now reopened, doesn't do the article justice. It provides highly compelling evidence for the exact identification of Satoshi Nakamoto, most of the tech public is not aware of this hypothesis, and the oddity of the responses in the May 2013 update, if anything, suggest the story really has legs.
Oh good pick-up. Only the correction was May 2013. But no update, i.e. no new information that refutes this hypothesis, is if anything an indicator that this isn't "old news" and is a promising hypothesis that has yet to gain currency (pardon the pun).
