"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.
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.