

The Bitcoin Crypto-Currency Mystery Reopened (2011) - dsrguru
http://www.fastcompany.com/1785445/bitcoin-crypto-currency-mystery-reopened

======
betterunix
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).

~~~
mindslight
> _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).

~~~
betterunix
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.

~~~
mindslight
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.

~~~
betterunix
"Can you be specific about which other decentralized protocols you're
referring to?"

Well, let's just take this (random Google result) as an example:

[http://groups.csail.mit.edu/cis/pubs/shafi/2002-disc.pdf](http://groups.csail.mit.edu/cis/pubs/shafi/2002-disc.pdf)

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.

~~~
mindslight
(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.

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

A good, intuitive example is this: I personally cannot win against a Chess
grandmaster or even play to a draw; if I play two games in sequence, I will
lose both times. However, I can guarantee that I can either win a game or draw
two games if I am allowed to play two grandmasters simultaneously, one as
white and one as black. I can simply copy the moves from one board to the
other, and each grandmaster will be forced to play against another grandmaster
(but they will be playing against me, and I can claim to win half the games I
play against grandmasters -- much better than I can do I my own!).

"In order to have a currency (fungibility), we need widespread agreement as to
what constitutes value."

At a basic level, what we really need is a definition of _validity_ for our
money. In the case of gold as currency, for example, validity is defined in
terms of chemistry -- weights of a particular element are valid as money. For
fiat currencies validity is defined via the law, by a government. In the
digital cash systems developed by the cryptography research community, money
is valid if the bank will accept it for deposit.

The problem with Bitcoin is that validity is not well-defined and can change
without warning. There is a vague notion that money is valid if everyone
agrees that it is valid, but that agreement can be invalidated by a single
party that happened to have done a lot of computation. Security in Bitcoin is
equally vague -- you use terms like "double spending," but what does that even
mean (rigorously)?

"If we aren't going to have a trusted party handing out limited identities,"

It is worth mentioning that in _online_ digital cash protocols (like Chaum's),
there is no need for an authority on identities, or even for identities. The
withdrawal protocol involves blind signatures, without a need for identities,
and the bank could simply accept a cash payment for the digital cash. The
payment protocol requires that the merchant verify the validity of the tokens
with the bank, but rather than deposit, the bank could engage in a withdrawal
protocol with the merchant trading the deposited tokens for withdrawn tokens,
allowing the merchant to spend the money further. Sure, it sucks to have to be
connected to a payment processor, but that is not much worse than being
connected to the Bitcoin network, or to a Bitcoin exchange.

"If you compute twice the hashes, you count as twice the nodes for purposes of
quorum"

More important: if you can compute hashes twice as fast, you get twice as much
of a vote. If you can compute hashes asymptotically faster, your power in the
network will keep increasing. There is no reason that you cannot compute SHA2
hashes asymptotically faster than I can -- nothing about the security of a
hash function requires that all implementations have identical running times.

There's the rub, in a nutshell: you are relying on the inability of the
adversary to compute lots of hashes, but simultaneously demanding that the
honest parties compute lots of hashes.

~~~
mindslight
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...](https://gnunet.org/sites/default/files/Tech%20Report%20-%20A%20Survey%20of%20Solutions%20to%20the%20Sybil%20Attack.pdf)

~~~
betterunix
"Three words: bank shuts down"

It is not as though cryptographers gave no thought at all to the single point
of failure in digital cash:

[http://cs.brown.edu/~anna/papers/lr98.ps](http://cs.brown.edu/~anna/papers/lr98.ps)

You can set things up so that it would take the failure of the entire banking
system to destroy your cash, which is not different than the failure of all
Bitcoin exchanges. This is still neatly aligned with the modern understanding
of fiat currency; you can have multiple banks that are responsible for issuing
currency and accepting deposits.

It is also important to recognize that while a bank failure would be fatal to
a digital cash system, a "51% attack" on Bitcoin would not be fatal to Bitcoin
(the system allows such attacks as part of its design). The attack could be
selective, it could be disguised as a "block chain fork," etc. Equally
important is that the "51% attack" can be performed by any party -- it
requires no secret knowledge or special privileges. As bad as a single point
of failure may sound, the bank is a clear point of failure and it is not
unreasonable to imagine taking special precautions to protect the bank from
failure (or to reimburse the bank's customers e.g. FDIC). No special measures
can protect Bitcoin users from one party doing a lot of computation and
invalidating / reversing / denying transactions, something that is _inherent_
in the design of Bitcoin.

"Actually there is, but that requirement is concentrated in the bank, which
all users have to trust to steward the currency's value"

I had said _identity_ authority, not _currency_ authority. Look at Chaum's
online protocol again, and find the place where an authority on identities is
required. The bank is the only party in the system that requires a signing
key.

Offline protocols are different, but that is beyond the scope of any
conversation about Bitcoin. Bitcoin is an inherently online protocol: every
transaction requires a connection to the Bitcoin network.

"your definitions preclude the novel and necessary parts of Bitcoin"

I think you have that backwards. Chartalism and modern monetary theory (which
forms the basis for fiat money) predate Bitcoin by decades. The security
definitions used in provably secure digital cash systems predate Bitcoin as
well. Bitcoin's own design makes it incompatible with those previous
definitions.

There is nothing wrong with rejecting the existing definitions if you find
that they fail to capture some important property, but if you choose that
route you need to present a novel definition. That is exactly what you see in
the work on offline digital cash: the security definition used for online
protocols is too restrictive, so a different definition is used (i.e. it is
possible to cheat but the identity of a cheater must be revealed).
Unfortunately the Bitcoin community has yet to present a novel security
definition or a novel definition of money, or at least they have failed to
present satisfactory definitions. Again, _what_ is the definition of "valid"
money in Bitcoin? What is the definition of "security" for Bitcoin?

"If exchange A calls coins stolen and refuses to exchange them, exchange B
will still exchange them because it hasn't become aware of this yet, and less-
reputable exchange C will exchange them at a 50% discount, are they "valid" ?"

This is a case-in-point. There is no definition of "validity" for Bitcoin
money, so there is no answer to that question. I am not saying it is easy to
formulate a good definition. What I am saying is that such a definition is
_necessary_ , at least as far as cryptography is concerned.

~~~
mindslight
> _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.

~~~
betterunix
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.

------
kylelibra
Before you write this off as old news, it features a lengthy update from May
2013.

~~~
sp332
Sorry but where is the update? I just see a correction about a LinkedIn
profile.

~~~
dsrguru
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).

------
kintamanimatt
Why would the creator want to remain anonymous?

