
Bitcoin blockchain issue - Mt Gox Bitcoin deposits temporarily suspended - tlrobinson
https://mtgox.zendesk.com/entries/21477395-Bitcoin-blockchain-issue-bitcoin-deposits-temporarily-suspended
======
jimrandomh
Ok, here's what happened and what it means. Bitcoin is built on a chain of
blocks, each of which contains a set of transactions, the hash of the previous
block, and a cryptographic proof-of-work which takes a lot of computing power
to construct. Whichever block-chain is highest (that is, has the most total
computing power invested in it) is considered valid, and has more blocks added
to it by miners. People "mine" by taking outstanding transactions, writing
them into a block together with the hash of the current highest-numbered
block, performing cryptographic proof-of-work and publishing their new block.

A block was mined (by the Slush mining pool) which is accepted as valid by 0.8
clients, but rejected by 0.7 clients. More than half of the mining power was
on 0.8, so the longest chain includes this block - but the 0.7 clients reject
it, and have built a side-chain. The developers have asked all miners and
mining pools to switch from 0.8 to 0.7, so that the 0.7 chain will grow to be
longer than the 0.8 chain; once this happens, all Bitcoin clients will agree
that it is the real one. In the meantime, however, merchants running Bitcoin
0.8 may be targeted by double-spend attacks: if they receive money in a
transaction that exists only in the 0.8 blockchain, the same money is spent in
a different way on the 0.7 blockchain so the transaction can't just be copied
over, and they act on the receipt of money by sending goods before the
situation is resolved, then they could lose money. This is why MtGox has
suspended Bitcoin deposits. (This can only happen if the coins were sent by
someone who is using malicious, nonstandard software; transactions made by
honest users will be copied to the 0.7 fork and mined without any issue.)

The height of the two chains can be monitored at
<https://coinbase.com/network/blocks> . Currently the 0.7 chain is 13 blocks
behind, which (since the normal mining rate is 6 blocks per hour) sets a lower
bound of about two hours on resolution - assuming everyone switches their
mining power immediately - but realistically it will probably be more like
6-12 hours.

~~~
joshaidan
"The developers have asked all miners and mining pools to switch..."

In the grand scheme of things, how much control over bitcoin do the developers
have? My understanding of bitcoin is that there is no central authority
controlling it like a central bank, but this statement almost implies that the
developers have some kind of control, or influence at least, over bitcoin.

~~~
plaguuuuuu
The developers have influence in that they are relied upon to a massive extent
to keep bitcoin running.

As far as I can tell this sort of centralisation of influence is a common
emergent property in most anarchic human systems.

Luckily if something particularly egregious occurs in this case, the community
can easily fork the codebase and start a rival blockchain.

~~~
joshaidan
Would they need to start a rival block chain? Or do they just need 51% of the
current community to run their clients to take over the current block chain?
(as suggested by a comment above)

~~~
gizmo686
Technically speaking, getting 51% of the community to switch is still creating
a rival block chain. You don't even need 51%. As was the case in this
incident, if you have incompatible nodes, the block chain would fork itself
naturally.

------
Titanous
From a Bitcoin core developer[1]:

> .7 and older nodes use BDB for storing the blockchain databases. It seems
> this database has a limit on the size of the modification it can make
> atomically to the database. With the larger blocks of the past days, it
> seems to have triggered the limit. The result is that 0.7 (by default, it
> can be tweaked manually) will not accept "too large" blocks (we don't yet
> know what exactly causes it, but it is very likely caused by many
> transactions in the block). Specifically, block
> 000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023
> (height=225430) with >1700 transactions.

> However. 0.8 (which uses a different database system) has no such limit, and
> happily accepts the block. As the majority of the hash power was on 0.8, the
> longest chain ended up using this block, which is not accepted by older
> nodes.

[1]
[https://bitcointalk.org/index.php?topic=152030.msg1613200#ms...](https://bitcointalk.org/index.php?topic=152030.msg1613200#msg1613200)

~~~
Negitivefrags
I use BDB and I doubt they are actually running in to any kind of hard limit
of the database. They are probably just running out of locks. Number of locks
is a configuration option.

Each modified database page needs an allocated lock that is held during the
database transaction until it is committed.

~~~
nazgulnarsil
You might want to shoot Gavin an email on the off chance he doesn't know this.

~~~
vessenes
This is well understood; Peter Wuille detailed this in his first e-mail about
the issue. Thanks though!

------
aegiso
I wasn't involved at all in the discussions, but the cryptopunk in me wonders
if this isn't malice. Running out of DB entries in the client can be predicted
with reasonable accuracy. "Accidentally" slip in this bug, and "fix" it in a
future version. Then time a major transaction to coincide with the fork you
know will happen, and bam! Engineered transaction reversal.

That would be one great hack. But my imagination is probably just getting the
best of me.

~~~
gizmo686
Not to mention one giant hack that would be recorded in the publicly available
block chain. Given how high-profile this bug is, I suspect that many people
will check both chains to see how much double spending occured, and if any of
them are suspicious.

------
ISL
Is there a sensible fashion by which two robust blockchain forks might merge?

Widespread use of the currency is troublesome if it's possible for _anyone_ to
have reasonable odds of forking the chain. If it's possible for a mass panic
to reverse transactions, it's not as reliable.

If Asia (4 billion people), banking institution (US federal debt = ~23% of
world GDP), or a social group (Catholicism: 63% of the Americas) buys a bunch
of stuff then decides, en masse, to revert to an earlier blockchain, it could
drive instability. Large groups of people sometimes do unpredictable things
(Gangnam Style: 1.4 billion views).

~~~
mrb
_"Is there a sensible fashion by which two robust blockchain forks might
merge?"_

They will not merge, but transactions will homogeneize.

I have simulated this scenario, forking the Bitcoin chain on a private network
2 years ago. What happens is that if the chain is forked, and if a client
unexpectedly sees that another chain (say chain B) suddenly replaces the chain
it was following (say chain A), thereby reverting a bunch of transactions,
then the client will automatically retransmits its transactions that it had
saved in chain A, to have them saved again in chain B.

That is how a non-malicious client operates.

Of course, if you are a malicious person, you can actually kill the client and
manually wipe out its cache of transactions before it has time to retransmit
transactions for chain B (therefore recovering coins that you had spent on
chain A).

~~~
makomk
I think this scenario is worse because in theory the transactions aren't going
to get copied over from the 0.8 chain to the 0.7 chain until the 0.7 chain
overtakes the 0.8 one. The two versions aren't database-compatible, so anyone
who follows the advice and manually downgrades to get on the right chain is
going to lose all the transactions from the previous chain whether they want
to or not.

~~~
Statistical
The fork was at the block level not transaction level.

The transactions are on both chains. While they may be in v0.8 blocks and
still unconfirmed in the v0.7 fork they do exist in the v0.7 fork. The only
transactions which couldn't exist in the v0.7 fork are those generated in
"v0.8 only blocks" and those are hard locked by the protocol for 100 blocks.

Had both halves of the fork existed for more than 100 blocks that would have
presented a more serious problem. This is why the stakeholders (exchanges,
merchants, miners, and developers) moved quickly to halt transactions, warn
users, and move to the v0.7 version of the chain BEFORE one chain got more
than 100 blocks from the fork point.

------
yuvadam
The way the Bitcoin community handled this mornings fork in the bitcoin
blockchain is nothing short of incredible. This event significantly increases
my confidence in the Bitcoin ecosystem to thrive even when faced with critical
issues.

If only the global finance institutions had a fraction of bitcoins capacity to
resolve crises with the same unconditional transparency and full cooperation
with all agents in the ecosystem.

~~~
betterunix
"This event significantly increases my confidence in the Bitcoin ecosystem to
thrive even when faced with critical issues."

It does the opposite for me, because it demonstrates that Bitcoin is
_extremely_ vulnerable to double spending. Either everyone uses the same
version of the software, or you have to deal with the possibility that this
event will happen again. Worse still, an attacker might use some kind of
malware to modify Bitcoin clients, until they are able to fork the network and
double spend.

Yes, making cryptosystems that are secure against malicious majorities is
difficult, and experts have published tons of papers and several books on the
subject. If Bitcoin's developers want people to trust their system for
anything non-trivial, they really need to fix this problem. To break David
Chaum's digital cash systems, an attacker would have required exponential
computing power in a security parameter that could be scaled arbitrarily,
while the users only require polynomial computing power in that same
parameter; to break Bitcoin, an attacker only requires a little more than half
the sum of all the computing power in the Bitcoin network. The Germans learned
the hard way that just because an attack seems too pricey for anyone to bother
with does not mean that the attack actually is too pricey for anyone to bother
with.

~~~
mozboz
The ability for clients to erroneously or maliciously fork the chain can't be
designed out whilst keeping the system open and decentralised. The blockchain
is a distributed copy of a shared truth which takes time to propagate and has
to be agreed upon by all participants. If the network is open, then me, or me
and 500,000 friends, can join the network and attempt to propagate a different
truth.

If you compare the way the Bitcoin community responded to this with the
response you might have expected from even a very well run company, I think
the Bitcoin community comes out ahead.

It would be useful and or interesting to compare the Bitcoin community
response with a specific failure and response of a for-profit closed-
technology company, but I'm not sure what case to use for comparison.

Maybe the recent cloudflare outage?

~~~
betterunix
"The ability for clients to erroneously or maliciously fork the chain can't be
designed out whilst keeping the system open and decentralised"

That is not true. Cryptographers have published many thousands of papers on
securing multiparty computation against malicious participants over the past
twenty years. Here is a very brief introduction:

<https://en.wikipedia.org/wiki/Secure_multi-party_computation>

The relevant citations in this field, like the relevant citations about
digital cash protocols, are conspicuously absent from Satoshi's writeup about
Bitcoin. This is one of the things that bugs me the most about the Bitcoin
community: nobody seems to have done any background research at all. There is
a _huge_ volume of work that has been done in this field, but little mention
of it among Bitcoin's developers. The Bitcoin developers do not even seem to
be worried about the fact that the work required to attack Bitcoin scales
linearly with the work required to run the Bitcoin system:

[https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_...](https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power)

"If you compare the way the Bitcoin community responded to this with the
response you might have expected from even a very well run company, I think
the Bitcoin community comes out ahead."

OK, the community is great at admitting that there are bugs and finding
workarounds. That does not count for much in a secure multiparty system, where
subtle problems in a protocol can undermine the security of the entire system.
Security in a system like Bitcoin is about more than just "avoid X, remember
to do Y, and patch bugs quickly!" Malicious clients are going to have to be
dealt with in Bitcoin, and they are going to have to be dealt with better than
what we saw today.

~~~
mindslight
The thing you must realize is that those previous systems didn't solve the
problem Bitcoin solves. It's not quite obvious - I read the Bitcoin paper when
it had pretty much just come out, didn't recognize the actual problem it was
solving, and ignored it as yet another "contradictory-caveat" system (eg.
paper title: "Anonymous Offline Payments!!@" ... later section: "identity
escrow, merchant accounts, only offline for honest parties, etc"). It sucks
that there's finally a widespread digital currency and it's non-anonymous, but
that's not the problem Satoshi actually solved.

<https://news.ycombinator.com/item?id=4979732>

~~~
betterunix
"The thing you must realize is that those previous systems didn't solve the
problem Bitcoin solves"

That is not the point. Previous work in the field of digital cash and in
multiparty computation is very much relevant to Bitcoin, even if Bitcoin
addresses a modified problem. The failure to even mention that such work has
been done, coupled with a woefully deficient analysis, indicates that the
author of the Bitcoin paper had not done much background research.

What stands out the most is the security analysis for Bitcoin. First, the
author makes the claim that the system is secure as long as the attacker
controls less than half the sum of the computing power of all nodes in the
system. This is not really a well-understood model of security; cryptography
researchers usually speak of either "honest but curious" models i.e. everyone
follows the protocol faithfully or "malicious" models i.e. some parties may
deviate from the protocol in arbitrary ways. The idea of a party that can
deviate, but only as long as their work is less than the sum of the work done
by all other parties, is strange -- but this new security model is not
discussed in any depth, nor is it even mentioned as being a new model of
security. No time is spent actually proving the claim, which is unsurprising
given that the security model itself is not even formalized.

Worse still, the security analysis that is presented only deals with a
specific attack carried out in a specific way. The author proves in a
somewhat-formal way that this particular attack cannot be carried out in the
way he envisioned. No evidence is given that another method of carrying out
the attack is impossible, nor is any evidence given that other attacks are
impossible.

There is an old proverb in cryptography: anyone can come up with a
cryptosystem they themselves cannot break. That is what you are seeing with
Bitcoin, but even worse, because the developers know how to break it but do
not believe that anyone would be willing to put in the effort. The German
cryptographers were surprised to discover that the Allies were willing to
build the code-breaking machine necessary to crack Enigma; they knew it had
weaknesses but believed that the cost of exploiting those weaknesses was too
high for anyone to justify.

My point is less about what problem Bitcoin solves, and more about whether or
not Bitcoin's developers are aware of just how much work has been done on
secure multiparty computation or digital cash systems.

~~~
mindslight
I don't really disagree with anything you're saying. Bitcoin has a lack of
rigor all around, and it's quite annoying to see the masses of people
defending Bitcoin as being anonymous (etc) when they've no context to place it
in.

What I am trying to point out is that Bitcoin has a design property that
enables it to actually be adopted (no "bank" - something no other ecash system
had, as they were mostly designed in an era when people still believed that
banks would be interested in preserving their customers' privacy. lol). This
is important if someone _is_ to ever build a better system.

I'm less familiar with recent MPC literature, but the general concept strikes
me as more of an existence proof, given the actual efficiency of resulting
implementations. Practical ZK/WI results seem to generally decompose larger
domain-specific chunks of the problem into primitive operations, rather than
one crypto op per generic logic gate. Which seems to be what Bitcoin is doing,
in a bumbling sort of way. And I don't see too much of a philosophical leap
between "majority of parties" and "majority of computation", given that the
former is wishful thinking that admits Sybil attacks.

~~~
betterunix
"What I am trying to point out is that Bitcoin has a design property that
enables it to actually be adopted (no "bank" - something no other ecash system
had, as they were mostly designed in an era when people still believed that
banks would be interested in preserving their customers' privacy. lol). This
is important if someone is to ever build a better system."

Keep in mind that there is more to digital cash than just maintaining customer
privacy (and Bitcoin itself does not really give you anonymity, at least with
any reliable guarantees). Banks benefits from digital cash because of the
difficulty of committing fraud and (assuming offline transactions) the reduced
load on their transaction processing systems. The real issue is not that banks
have _no_ incentive to deploy such a system, but rather that their existence
fraud-mitigation measures are more cost effective (in the short term). As my
colleagues who have worked with banks have explained it to me, the banks only
want to know what amount of fraud would occur; if your system can reduce that
fraud more than it costs to deploy, then the bank will spend the money to
deploy it.

The same design that has led to Bitcoin's adoption is also something of a
liability for the system. Without any banks, converting Bitcoin to other
currencies requires the use of an exchange, which carries increased costs and
risks. The lack of stability in the price of Bitcoin relative to USD is a
result of this issue. It is easy to forget that there is a source of demand
for USD, one that is grounded in legal structures like the tax code, debt law,
torts, etc. Even when people use Bitcoin for their business, they still need
to eventually exchange Bitcoin for some national currency to pay taxes and
repay debts (and perhaps to pay employees who lack the time or sophistication
needed to use a Bitcoin exchange).

Another issue is more technical: there is no secure way to process an offline
Bitcoin transaction. In one of his published papers, Chaum proved a property
of offline digital cash systems that is as relevant to Bitcoin as it is to
Chaum's design: the amount of information that needs to be exchanged in an
offline transaction must grow linearly in the length of the offline
transaction chain (imagine if a dollar bill became heavier every time it was
given from one person to another). What this means is that either you need the
ability to "refresh" the unit of value (e.g. reissuing the token in Chaum's
system) or else your offline transactions are either insecure or not scalable.
As there is nothing in Bitcoin that can "reissue" currency (which involves
creating fresh units and destroying old units), Bitcoin is either insecure,
insecure for offline transactions, or it does not scale (note that "secure" in
this case refers to formal notions of security; Bitcoin does not actually meet
that standard, so this point may be moot anyway).

"Practical ZK/WI results seem to generally decompose larger domain-specific
chunks of the problem into primitive operations, rather than one crypto op per
generic logic gate."

Right, and that is within the field of MPC research. General MPC using
circuits or some other description of functions is much slower than special-
purpose protocols, which are themselves usually slower than just using a
trusted third party. You are correct that Bitcoin is an example of special-
purpose protocol; the problem is that Bitcoin as it exists today would only be
secure in a minutely stronger variant of the honest-but-curious model. Honest-
but-curious is really just a research tool, a model that is used to give
feasibility results or to test new designs, and it is certainly not the right
security model for anything involving money (of any sort).

"I don't see too much of a philosophical leap between "majority of parties"
and "majority of computation","

The leap is this: a single party might gather immense computing power without
corrupting any other party. As a simple example, my research group has access
to a supercomputer run by the University of Texas, which I could potentially
run anything on (not necessarily legally). If you and I were going to use a
two-party protocol of some kind, would you really want to use one that forced
you to get access to a similarly powerful supercomputer just to be secure?

Worse still, you might not be aware of the computing resources available to
other parties. The Germans were not aware of the Enigma-cracking effort until
after the end of the war. In today's world, it is possible that your adversary
has a botnet, a bunch of EC2 credits, or that you are dealing with the NSA. In
all cases, you do not want to rely on a system that requires you to get equal
computing power to remain secure.

Some MPC protocols are secure _unconditionally_ , meaning that even an
attacker whose computing power is completely unbounded will not be able to
violate the security property of the system. In such a case, controlling a
majority of the computing power of all parties is not even a relevant detail,
because increased computing power does not convey any advantage.

It is more common to assume some bound on the attacker's computing power and
to use complexity theoretic arguments about security. Typically, the attacker
is assumed to be able to scale their computing power up by some polynomial in
the parameters of the system, which includes the participants. Again, it is
because there are real-world adversaries who control large amounts of
computing power, potentially in secret, that such models are used. The
justification is intuitively this: if you have one desktop and your adversary
requires a cluster of ten thousand desktops to break the security of the
system, you can get a second desktop and double the work you need to do while
forcing your adversary to find ten thousand clusters of ten thousand desktops
(i.e. squaring his workload). Super-polynomial growth tends to "run away" at
the second half of the chess board, so that a modest increase in the work done
by honest parties can result in the attacker needing to keep working until the
heat death of the sun.

On the other hand, a powerful adversary could potentially corrupt or control
parties in the system. The Mafia is not going to buy NSA-level computers; they
are going to find the participants and beat them with wrenches. A more real-
world example would be the suspicious appearance of lots of highly-reliable
anonymous remailers after the September 11th attacks. Having a lot of
computing power does little to defeat the remailer system, but if you control
all the remailers you can deanonymize anyone. Remailers have a nice security
property: only one honest remailer is required to preserve your security
(assuming you send your messages through all the remailers and that the
remailer protocol itself has certain security properties which real-world
remailers lack).

Sorry if that was a bit long. This is a pretty deep topic, and even the
foundations are highly technical.

~~~
mindslight
> _Banks benefits from digital cash because of the difficulty of committing
> fraud and (assuming offline transactions) the reduced load on their
> transaction processing systems_

Decades of non-adoption say otherwise. It's hard to say what the exact reason
is - paralyzing conservatism, business models built on _decommoditizing_ money
into an identity-based instrument, conspiracy via government regulation, or
something else. But enough time has passed that if banks were remotely
receptive to the idea of digital cash, it would have caught on _somewhere_.

> _there is nothing in Bitcoin that can "reissue" currency_

Every new wallet address, no? Offline transactions are vulnerable to double
spends, but this is the case with every digital cash system. IIRC, the ones
that protect against offline double spends do so by revealing the fraudster's
identity if a token is spent twice - requiring a bank and legal system for
recourse.

> _It is more common to assume some bound on the attacker's computing power
> and to use complexity theoretic arguments about security._

Sure, and this is what the SHA2/DSA parts of Bitcoin do. Nobody can forge
transactions, the worry comes about from double-spending. You have to
remember, digital currency is _not_ a two-party problem - every involved party
is what gives the currency value. This is essentially a coordination problem
(which database copy is authoritative?), and is precisely the novel problem
that Bitcoin _solved_. Previous p2p attempts would do something like "majority
of parties", which is always vulnerable to Sybil attacks. Bitcoin went for
something that _can_ be algorithmically enforced, staking its outcome on the
belief that NSA-level computing would both not dwarf the rest of the network,
and that double spends would be detected and could be somehow mitigated down
the line.

~~~
betterunix
"enough time has passed that if banks were remotely receptive to the idea of
digital cash, it would have caught on somewhere."

Again, the way I understand it, the problem is not a lack of benefit but that
the benefit is not sufficient to convince any bank to switch. Banks are very
concerned about fraud; the problem is that they do not get enough fraud
protection from digital cash to outweigh the cost, because they already have
good fraud mitigation methods. Why switch to a car that gets one more mile per
gallon of fuel, when the cost of doing so would not be recouperated for
decades?

"Offline transactions are vulnerable to double spends, but this is the case
with every digital cash system."

The difference is that a person can double-spend in Bitcoin over and over
again, even if the double spending is detected at some point. In Chaum's
design, a person who double-spends is eventually ejected from the system, and
so a person can only double spend until the double-spent money makes its way
back to the bank. A legal system is not strictly needed here; all it takes is
the bank blacklisting cheaters.

"this is what the SHA2/DSA parts of Bitcoin do. Nobody can forge transactions"

One does not follow from the other. SHA2 is a (hopefully) secure hash
function. DSA is a secure signature system. People might still be able to
forge transactions, due to some other property of the Bitcoin protocol that
composes poorly with DSA/SHA2. A transaction in Bitcoin is not merely a signed
message; there is a protocol that is used to decide the validity of the
transaction, and that protocol might be vulnerable to attack (and maybe
vulnerable to attack _as a result_ of using DSA, as opposed to some other
signature system). Without a formal proof of security for the entire
transaction protocol, it is hard to say.

A simpler example might help to illustrate the point. Imagine a system for
telling employees that they have been fired that works as follows: the boss
signs and encrypts the letter "F" using his signing key and the target's
encryption key. It may appear that forging a firing notification is hard,
because the signature marks it as authentic and the encryption designates the
target (i.e. if you cannot open the message, then you were not fired).
However, it is possible for an employee who is fired to turn around and fire
others by re-encrypting the message and signature -- which works _even if the
signature and encryption systems used are secure_.

(This issue has been studied in the past; see e.g.
<http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html> or
<http://eprint.iacr.org/2008/440>)

"This is essentially a coordination problem (which database copy is
authoritative?),"

What does "authoritative" actually mean in the absence of an authority?
Without a good definition, it is hard to actually say what a solution would
have to look like.

"the novel problem that Bitcoin solved."

The fact that Tuesday's fork could happen is pretty strong evidence that
Bitcoin is not really a solution to the problem (assuming we even know what
the problem actually is). The fact that a double spending attack was made
possible by the fork is a sign that Bitcoin is either (a) solving the wrong
problem or (b) not solving the problem at all.

Even if we limit ourselves to considering only Sybil attacks, Bitcoin does not
truly solve the problem. Sybil attacks are still possible; the only difference
is that now the attacker will need more CPU power (maybe; more sophisticated
attacks are certainly conceivable).

"Bitcoin went for something that can be algorithmically enforced"

Except that it is not enforced (at least not under any well-understood
definition of that word), it is based on this sort of thing:

"staking its outcome on the belief that NSA-level computing would both not
dwarf the rest of the network"

In other words, it is assumed that the adversary could never accumulate as
much computing power as all the Bitcoin users combined have accumulated. This
is a pretty bad assumption to make, since it fails under any number of
entirely plausible circumstances. NSA-level computing is a complete mystery to
the outside world; maybe they are using computing technology nobody else has,
that works substantially more efficiently. How do you know your adversary does
not have such systems? Every so often, Bitcoin "miners" switch to some faster
technology for that task; is an adversary who invents a new technology for
this really so hard to believe?

"double spends would be detected and could be somehow mitigated down the line"

What exactly can be done to "mitigate" double spending in Bitcoin? There is no
system for denying access to the network. An attacker who double-spends
Bitcoin could keep coming back and could keep double-spending. In Chaum's
system, double-spending carries the cost of losing one's access to the system;
with Bitcoin, it carries no cost at all (one might just sell the equipment
used for the attack, and so one only really needs sufficient capital or credit
to procure the equipment in the first place).

~~~
mindslight
> _because they already have good fraud mitigation methods_

Then why is it such a big topic, with the banks even deflecting the blame by
inventing "identity theft" etc? And even if the banks are fine, the
_merchants_ are not, and a new bank should have sprung up to address that.
Which leaves us with the remaining option - incumbent banks are cooperating to
prevent new competition. I'm not trying to specifically convince you of this
paranoia, but provide it as something that _may_ have to be overcome by a
digital payment system to be adopted.

> _Chaum's design, a person who double-spends is eventually ejected from the
> system_

I'm hazy on my ecash citations. Is "Chaum's design" the one where merchants
are assigned identities, payment is offline but specific to the merchant's
identity, and a double spender's identity is revealed if a coin has been spent
at two different merchants? That's the system that's stuck in my head as best-
in-breed _if_ there is a bank on board.

But what I've been trying to get across here is that Bitcoin provides a
property _none_ of those other systems provided - freedom from a trusted
"issuer"/bank/etc. (While those protocols don't trust the bank to preserve
privacy, they _do_ trust the bank to administer the currency by being the
counterparty to the tokens.)

> _People might still be able to forge transactions, due to some other
> property of the Bitcoin protocol that composes poorly with DSA/SHA2_

Oh sorry, you caught me with my rigor-pants down. What I meant to say is that
being built from those primitives, it could be proved as secure as those
primitives. Unlike the Byzantine agreement component, which will always have
other security tradeoffs beyond SHA2.

> _What does "authoritative" actually mean in the absence of an authority?
> Without a good definition, it is hard to actually say what a solution would
> have to look like._

When we give up trusted authorities (and specific "parties" necessarily
created by some trusted authority), what remains? What differentiates "the
majority" ? One of the few things I see is computing power.

> _Sybil attacks are still possible; the only difference is that now the
> attacker will need more CPU power_

No, Sybil attacks have been _defined away_ , as they depend on some notion of
"parties". The "honest parties" wishful-thinking has vanished, leaving only
"majority of computation" as the network authority. Of course the merits of
this security model are still up for debate, but it seems to mostly work.

> _The fact that Tuesday's fork could happen is pretty strong evidence that
> Bitcoin is not really a solution to the problem_

Erm, given that the fork was a rare event, it actually shows that Bitcoin is
_mostly_ solving the problem, just not perfectly.

> _What exactly can be done to "mitigate" double spending in Bitcoin? There is
> no system for denying access to the network_

Lol. "no system for" is not the same as "system prevents" (see what happened
to the End to End principle). I _guarantee_ we will eventually see exchanges
exerting control over what constitutes "valid transactions" and "the network".
This is Bitcoin's real weakness.

~~~
betterunix
"Is "Chaum's design" the one where merchants are assigned identities, payment
is offline but specific to the merchant's identity, and a double spender's
identity is revealed if a coin has been spent at two different merchants?"

More or less; the important concept is that a double-spending attack will not
only be detected, but that it will both reveal the identity of the attacker
and allow the attacker to be blacklisted. It is not necessary to differentiate
"merchants" and "spenders;" re-spending a transferred coin in an offline
protocol is possible (without sacrificing the "double-spending reveals the
attacker's identity" property).

"Bitcoin provides a property none of those other systems provided - freedom
from a trusted "issuer"/bank/etc"

Bitcoin may do this, but it does so by sacrificing rigorous security and
offline payments. Even if we assume that a monetary system without any
authorities makes sense (I am doubtful about that), a system where the
attacker's effort is linear in the system's parameters is not a system that
can be trusted with any significant amount of money.

"What I meant to say is that being built from those primitives, it could be
proved as secure as those primitives"

Except that Bitcoin is not a signature system, nor is it a hash function. The
only statement that can really be made is this, "Bitcoin's security is
dependent on the use of a secure signature system and a secure hash function."
Again, look at the email robustness example; a system built from secure
cryptographic primitives can still fail to meet its security goal.

"When we give up trusted authorities (and specific "parties" necessarily
created by some trusted authority), what remains? What differentiates "the
majority" ? One of the few things I see is computing power."

Parties are not created by authorities; parties are what communicate in a
distributed system. In the commonly used model, the attacker is allowed to
control some number of parties and coordinate their actions; any party, honest
or malicious, can scale their computation by some polynomial of the system
parameters.

In the case of Bitcoin, parties can enter or leave the computation at any
time, without having to send messages to the other parties. That introduces an
entirely different challenge, since the attacker can keep adding parties to
the system, eventually controlling a majority of whatever capability the
parties have. That is not to say that some notion of security cannot be
achieved; rather, it means that any notion of security based on a "majority"
of _anything_ cannot be achieved without some way to restrict the number of
parties the adversary can enter in the system.

The anonymous remailer system faces a similar problem: an attacker can create
as many remailers as he wants. In the case of anonymous remailers, however, it
is OK for the attacker to control a majority of parties, since it only takes
_one_ honest remailer for the system to be secure (i.e. for messages to be
anonymized). That should be the goal of Bitcoin: the ability to prevent
forgery and double spending as long as _some_ honest parties remain in the
system (assuming such a thing is even possible without a central authority; it
could be the case that no such protocol can exist).

"Sybil attacks have been defined away, as they depend on some notion of
"parties"."

I think the parties in Bitcoin are _the people who use it_. After all, the
point of Bitcoin is to facilitate monetary transactions between its users.

"The "honest parties" wishful-thinking has vanished, leaving only "majority of
computation" as the network authority"

No, there is still an issue of "honest parties" versus "malicious parties."
Honest parties in Bitcoin are people who are willing to follow the rules and
who are not trying to double spend their money or spend money they did not
mine/receive. Malicious parties are those who are trying to break the rules by
whatever means are available to them. The fact that the majority of
computational resources is what decides the validity of the transactions just
means that a malicious party needs to collect the majority of computational
resources; this is not infeasible, and it is only _somewhat_ impractical (and
only really impractical for individual people).

"Of course the merits of this security model are still up for debate, but it
seems to mostly work."

It seems to mostly work because nobody with the resources needed to carry out
the known attacks cares enough about Bitcoin to do so. The NSA is too busy
spying on people to worry about Bitcoin, and companies with large numbers of
computers like Amazon or Google are busy using those computers to run their
businesses.

This does bring up an interesting point, however: an attacker would only
really need such large computing resources _during the duration of the
attack_. The hardware would still be useful after the attack, and the attacker
might simply sell it or use it for some profitable purpose. I think the only
thing that really prevents fraudsters from doing this is the lack of
capital/credit needed to procure the equipment in the first place (let's put
it this way: if you were running a bank, would you give a billion dollar loan
to someone whose business plan was "defrauding Bitcoin users?").

"Erm, given that the fork was a rare event, it actually shows that Bitcoin is
mostly solving the problem, just not perfectly."

The problem is that the fork was caused by parties failing to adhere to the
protocol. If Bitcoin is not resilient to parties failing to follow the
protocol _due to a bug_ , then it is also not resilient to parties that do not
follow the protocol _because of a coordinated attack_. In other words, Bitcoin
is not secure against malicious parties (which are defined as parties that do
not faithfully follow the protocol).

~~~
mindslight
> _Bitcoin may do this, but it does so by sacrificing rigorous security and
> offline payments_

Both seem like definite hard tradeoffs to me. Offline transactions imply there
is some ultimate real-world identity that can be punished for fraud. By
"sacrificing rigorous security", I assume you're referring to the majority of
CPU power controlling the network. If we give up having a central authority
and verified identities, we necessitate _some_ measure of "majority of power"
in the system (although it doesn't necessarily have to be CPU).

> _a system built from secure cryptographic primitives can still fail to meet
> its security goal_

Sure, but one _can_ formalize the properties of Bitcoin, and could prove that
it indeed meets those properties.

One of these properties is "network is controlled by the majority of computing
power". I'm not saying this is a universal good thing or ultimate solution.
What I am saying is that this property is what provides independence from a
central authority, which is possibly what has enabled Bitcoin to actually be
adopted.

> _Parties are not created by authorities; parties are what communicate in a
> distributed system_

No, "parties" are a convenient abstraction for distributed systems papers in
that they bound the pervasiveness of an attacker. The reader intuitively
understands them as some notion of identity (IP address, digital certificate,
etc), but here we have no luxury. As you later touch upon, once you get rid of
identities, a single attacker can create an unlimited number of parties.

I think general MPC has only been proved secure if a majority of parties are
honest. Bitcoin is substituting 'parties' with computing power, for precisely
the reason you describe. Would we say MPC is insecure because the effort
required to attack it (number of malicious parties to establish) is linear in
the size of the system (total number of parties)?

I understand this isn't the best security guarantee, but you seem to be having
an allergic reaction to it. Complexity theoretic guarantees are useful
_because_ they work. However, most real-world power balances are close to
linear.

I guess my main point has been that Bitcoin provides a property (authority-
independence) that previous ecash papers have not. Its guarantees of this
aren't the strongest, but if we're to improve it we must recognize the problem
it's solving.

Maybe there's another way of implementing authority-independence that doesn't
succumb to something as simplistic as computing power. As it is, it seems that
Bitcoin will continue to centralize as miners further specialize and the
requirements to be "on the network" (versus transacting through an agent)
grow.

~~~
betterunix
"Sure, but one can formalize the properties of Bitcoin, and could prove that
it indeed meets those properties."

This seems a bit backwards. Rather than formalizing the properties of Bitcoin,
it seems that we should be formalizing the _goal_ of Bitcoin i.e. the
properties we _want_ , and then prove that Bitcoin satisfies those properties
(if it does actually satisfy them). I think that such a formalization would
require a formalization of the entire Bitcoin concept of money, which would
probably be beneficial in and of itself.

"If we give up having a central authority and verified identities, we
necessitate some measure of "majority of power" in the system"

I think that really depends on your notion of money. If you are like me, you
believe that money has value because of its utility: fiat currencies have
utility that is defined by a legal system (taxes, debt law, torts, etc.), but
one could imagine something else. Suppose, for example, that you had a digital
cash system in which the money was redeemable for CPU time in a secure
outsourcing system; this could potentially be decentralized. Controlling more
computing resources would not give an attacker greater power over the network,
but would allow a party to receive more payments (because they are basically
selling access to their CPU). It is of course possible that such a system
could not be securely realized for technical reasons.

"One of these properties is "network is controlled by the majority of
computing power"."

This is not a very precise definition, at least not in the cryptographic
sense. What is the formal definition of computing power here -- what is the
computation model? It would be very hard to _prove_ that a system has this
property in a rigorous way.

On the other hand, in the system I described above, you could formalize the
measure of how much work a node did (and how much payment was received) by
using circuit families as the computation model and the number of gates
evaluated as the measure of work. This sort of abstraction would allow a
rigorous proof of various properties of the protocol; e.g. maybe you want to
show that the payment a party receives will be some proportion of the number
of gates the party evaluates.

"As you later touch upon, once you get rid of identities, a single attacker
can create an unlimited number of parties."

Not _unlimited_ ; the attacker's ability to enter parties into the system is
bounded by the computing power of the attacker. If the attacker can only scale
their computation by some polynomial in the parameters of the system, the
attacker can only enter some polynomial number of parties. If the protocol is
secure as long as there is one honest party, the attacker would not be able to
win _even_ under such a scenario.

"I think general MPC has only been proved secure if a majority of parties are
honest."

It is not really that simple. For example:

<http://eprint.iacr.org/2012/441.pdf>

There is a protocol that is secure even if only one party is honest. The
problem here is that "secure" does not have a single meaning in MPC. There are
various adversary models: an adversary might only be able to choose which
parties to corrupt before the protocol runs, or might be able to corrupt
parties while the protocol is running; he might be allowed to adapt the attack
between the computation rounds and the output round, as in that paper; he
might be allowed to compose protocols together in arbitrary ways; etc. Some
protocols require a setup phase or an authority, some are standalone (as in
the paper), some require a broadcast channel, and so forth.

~~~
mindslight
> _you had a digital cash system in which the money was redeemable for CPU
> time in a secure outsourcing system_ ... _It is of course possible that such
> a system could not be securely realized for technical reasons_

I don't see how it could be possible to design a system were useful CPU work
done for others was _turned into_ tokens, as one could simply create a whole
bunch of fake work. The fundamental question is who is the counterparty to the
tokens? If it's the entity selling CPU time, then you're dealing with a gift
card system that doesn't scale to a real currency. If it's not, then you're no
longer describing the payment system but have switched to describing an
application of it.

> _What is the formal definition of computing power here_

Clearly it's just the ability to calculate SHA2 preimages. If you want
something better, you've got to come up with that formality _and_ an
implementation to show that it is practical.

I'm having a hard time responding because it seems like you want to postulate
systems with these nice-sounding properties, but it seems apparent to me that
you'd never be able to connect them with proofs to make a system. You simply
won't be able to build proofs of work for something as simplistic as "number
of gates evaluated" (and if you're talking about 'gates' in MPC, you're really
just talking about eg group operations).

> _If the attacker can only scale their computation by some polynomial in the
> parameters of the system, the attacker can only enter some polynomial number
> of parties_

What you're describing here _is_ Bitcoin. You've just been spoiled with
attackers usually needing exponential resources. As I said, your formalities
are misleading you - crypto algorithms may work this way, but not everything
does! An algorithm cannot discern good guys from bad guys, meaning they're
both on equal footing and the best we can do is have a power balance.

------
yk
Does this mean, that basically any functional change in the block verification
code can be used to leverage the hashing power of all users of one version
into a 51% attack?

The attack would be essentially to create the current situation artificially
by crafting a block that is only valid by one version of bitcoind, therefore
splitting the block chain. Then one needs to include two different
transactions into the two blockchains. ( In the theoretical scenario, by
mining another block for one of the chains. ) For this I do not need to have
51% of the hashing power, but the branch of the blockchain needs to be
supported by 50% of the hashing power.

EDIT: Thinking a bit more about this, it seems that the probability to suceed
with such an attack seems to rely on the attackers abbility to craft a
'splitting block', which should be proportional to the share of the attacker
controlled hashing power and the ability of the 'incompatible' clients to
outgrow the standard block chain. ( So that a merchant with an 'incompatible'
client accepts a payment based on the fork of the blockchain.) This means that
the attack is probably impossible, if the one CPU one vote approach is not
only used for valid transactions, but also for valid clients.

~~~
phillmv
Ah how awful and awesome that the world is becoming like a William Gibson
book.

------
ck2
Sometimes I wonder how many extra tons of coal have been burned simply because
of the existence of bitcoin.

~~~
DennisP
At the moment, one ton of coal per hour.

Assume that mining reward is approximately equal to investment. This will tend
to be the case, though it fluctuates.

Right now we're rewarding 25 bitcoins, at a price of $45, every ten minutes,
or $6,750 per hour. Let's say half the required investment is hardware, half
electricity at the national average of 11 cents per kWh. Divide 3375/.11 for
30,681 kW power devoted to bitcoin at this moment.

With similar calculations, I recently figured out that if bitcoin were to
reach the size of the U.S. dollar in about 20 years, it would be consuming
about a gigawatt. It was less than I expected, because the number of new coins
per block keeps decreasing, and you only pay electricity for the new ones.
This doesn't account for transaction fees, which increase the mining
investment that can be sustained. At the moment I think they're a small
percentage of the mining award. I'm also neglecting miners' profit margins,
which decrease our energy investment.

Coal is 22% of U.S. power production, and generates 2,460 kWh/ton. (30,681 *
.22) / 2460 happens to equal almost exactly one ton of coal burned per hour to
support bitcoin.

The U.S. generates 227 GW from coal, so our 6.7 MW is about one part in 33,000
of total U.S. coal consumption.

Sources: just type questions into google and all the numbers come right up. I
assumed, perhaps incorrectly, that U.S. numbers were more typical of the
bitcoin population than global numbers.

~~~
DennisP
Math goof, can't edit: 30,681 * .22 is 6750 kWh, which divided by 2460 kWh/ton
is of course 2.74 tons of coal per hour, not sure how I came up with 1 ton.

------
RoboTeddy
From news in #bitcoin-dev, it looks like miners on 0.8 are being instructed to
downgrade to 0.7, and that'll be the winning fork of the chain going forward.
There shouldn't even be any lost bitcoin transactions.

~~~
URSpider94
_There shouldn't even be any lost bitcoin transactions._

That can only be true if there are not conflicting transactions in the two
chains. That might be the lucky outcome, but it's certainly not guaranteed to
be the case.

Any transactions that were confirmed on the faulty chain will have to be re-
confirmed in the correct chain. How long that will take would depend on just
how many transactions need to be processed, and how big their payload is.
Until that is completed, the state of the bitcoins involved in those
transactions is ambiguous.

------
blhack
Well, then, bitcoin was about due for a HUGE DISASTER to bring the price back
down to sane levels, wasn't it?

For those not watching, BTC is currently trading at ~$45.

~~~
eurleif
What determines whether a price is sane or insane for a commodity with no
intrinsic value?

~~~
blhack
It's more than doubled in the last two months.

[http://bitcoincharts.com/charts/mtgoxUSD#rg180ztgSzm1g10zm2g...](http://bitcoincharts.com/charts/mtgoxUSD#rg180ztgSzm1g10zm2g25zv)

~~~
baddox
That doesn't seem necessarily relevant.

~~~
sliverstorm
Wild runs are typically- not by requirement, but typically- indicative of a
crash in the near future. This is because speculation is usually the main
driving force behind very steep ramps.

~~~
icelancer
What determines a "wild run?"

As has been shown time and time again in academic and corporate research, the
single best predictor of an asset's value is the current market trading price
for that asset.

~~~
sliverstorm
So you'd argue there is never a bad time to buy?

~~~
icelancer
No.

~~~
sliverstorm
It's great to have an actual conversation. You should try it some time.

~~~
icelancer
Well, you asked me a yes/no question that has little to do with what I said.
So I figured I'd just answer it in the same manner.

~~~
sliverstorm
You are establishing a pattern of responding to comments with _maximal_
brevity and offering zero constructive input.

Ok, so you think RickHull was using "Exceedingly rudimentary technical
analysis based on non-scientific trends"? What have you got for us that is so
much better?

------
vy8vWJlco
Slightly off-topic, but it is well-known that one can embed arbitrary data in
the bitcoin block chain, so you pretty much have to expect that at some point
someone will inevitably insert one of the many illegal numbers into it,
putting everyone running it openly at risk, regardless of the political
attitudes towards bitcoin itself. I know anonymity isn't one of bitcoin's
purported purposes, but I think it will ultimately be necessary to make it one
because of this.

~~~
aneth4
Not sure what an "illegal number" would be. Certainly someone could embed
child pornography or political propaganda.

Bitcoin seems subject to a vast array of DOS and other attack that could be
seriously problematic if it became an important currency.

~~~
dkulchenko
I think OP is referring to something like an AACS key:
<http://en.wikipedia.org/wiki/Illegal_number>

------
networked
From [1]:

>If this is a widespread problem, it is an emergency. We risk having (several)
forked chains with smaller blocks, which are accepted by 0.7 nodes. Can people
contact pool operators to see which fork they are on? Blockexplorer and
blockchain.info seem to be stuck as well.

So, what would happen to the coins used in those forked transactions? If the
chain does fork what would the best strategy be for performing the merger?

And more interestingly: since bitcoin transactions are considered to not be
reversible bitcoins are easily converted to and from other currencies with
non-reversible transactions. If one were to convert his or her bitcoins to,
e.g., Liberty Reserve right now and the chain got reversed that would result
in pretty much a perfect scam, wouldn't it?

[1]
[http://sourceforge.net/mailarchive/message.php?msg_id=305878...](http://sourceforge.net/mailarchive/message.php?msg_id=30587843)

~~~
yk
The chains do not get merged. It is just, that the longest block chain is the
consensus history of all transaction ( and it needs to be consistent). So if
the .7 branch overtakes the .8 branch, then legitimate clients will detect
that a transaction was not carried out and retransmit it. ( And the scam you
are describing is precisely why Mt Gox did stop accepting bitcoins. They are
afraid that someone can take advantage of the situation.)

------
achalkley
This can only be positive. Finding out issues like this will only make the
software/network better.

~~~
JeremyBanks
This is the first large occurrence of an issue that has always been known to
be possible to people who are reasonably familiar with BitCoin, due inherently
to it's design. This could be bad for BitCoin because now a much large portion
of BitCoin users/investors are also aware of this risk.

~~~
mrb
No this is not the first large occurence of this issue.

A fork this big (dozens of blocks covering multiple hours of transaction
history) already happened in August 15, 2010, due to an unrelated bug:
[https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu...](https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139)

~~~
waterlesscloud
Though to be fair, that's like saying something happened in the precambrian
age when talking about the average bitcoiner's awareness.

------
obilgic
No matter how much I try, there is always a part of Bitcoin which I don't
fully understand, kind of scary actually.

~~~
TomatoTomato
Do you really understand all the inner workings of the current monetary
system?

~~~
niggler
The difference is that enough people accept the current system without
understanding it that you can use it for your needs. Not enough people use
bitcoins that you can gloss over details.

~~~
harshreality
If the Bitcoin monetary system breaks, only those using Bitcoin for savings or
investment get hurt. Those who use BTC as a means of payment (buyers and
sellers) have little reason to care, so long as they frequently convert excess
BTC into other currencies.

That's not so different from the U.S. dollar. You can buy and sell stuff using
U.S. dollars, but unless you foresee the value of USD going up (a kind of
deflation), you don't want a pile of USD under your mattress. (Also, it's
uncomfortable.) Depending on your economic outlook, you want the money in
something else: metals, some sort of investment vehicle, or a basket of
[foreign] currencies.

------
nullc
The fork is now resolved, sites like mtgox should begin processing deposits
again after a couple more blocks.

------
moocows
So the solution from MtGox is to downgrade, wait a bit, then upgrade. What a
currency of the future!

~~~
mcantelon
Very little that has ended up replacing the status quo has done so without
growing pains.

~~~
waterlesscloud
Very little that's actually _in_ the status quo doesn't have similar problems.
Their problems just don't get widely reported.

------
tlrobinson
This could be a very bad thing.

There was a fork in the blockchain, and the community will have to decide how
to resolve it. Some transactions which were "confirmed" could be reverted.

IF YOU ARE A MINER READ THIS:
[http://sourceforge.net/mailarchive/message.php?msg_id=305879...](http://sourceforge.net/mailarchive/message.php?msg_id=30587976)

~~~
waterlesscloud
Word on #bitcoin is that transactions should NOT be lost.

We'll see how it actually shakes out, but that's good news for bitcoin if it
holds up.

------
GigabyteCoin
>Miners are encouraged to downgrade to Bitcoin 0.7.2 - at least temporarily -
to push the correct blockchain forward.

How does one know who to believe when determining what the "correct"
blockchain to forward would be?

~~~
gizmo686
The good thing about this is that there is no major conflict among people
regarding which block-chain is correct. Almost everyone agrees that we need to
solve the problem of having a huge portion of nodes not being compatible with
the current block chain. Only one of the two blockchains meets this criteria.

------
tudorizer
For a clearer explanation see:
[http://www.reddit.com/r/Bitcoin/comments/1a51xx/now_that_its...](http://www.reddit.com/r/Bitcoin/comments/1a51xx/now_that_its_over_the_blockchain_fork_explained/)

------
tudorizer
I was asleep when this happend, but waking up to check HN, reddit and my mtgox
got me up to speed. For some reason, this doesn't worry me a bit. Mostly
because of the steady and strong growth I've see recently.

------
yakiv
Bitcoin seems to be picking up again. From Mt. Gox:

    
    
        > Last price:$45.00000
        > High:$48.46900
        > Low:$36.65000
    

Edit: It could go back down a lot. We'll see what happens.

~~~
btbuildem
Prices have been above $36 for barely a week, 5th/6th rally saw high volumes;
the recovery (8th to 11th) was weaker and did not break the high. The volume
of both sell-offs was comparable, but the today's low is higher. I reckon it
might flatten out around $40 for a bit, then pick up again.

------
CompelTechnic
Guys, it looks like prices are dropping pretty quick now on mtgox.

This will be another... interesting couple of weeks for bitcoin.

~~~
nazgulnarsil
down $4, looks like normal price fluctuations from the last couple weeks.

~~~
CompelTechnic
It was down to $36.50 for a couple seconds/minutes- looks like that got bought
back up though.

Weird.

------
nonpme
I'm curious how this bug will affect bitcoin price. I'm betting it'll go up
even more.

~~~
atomon
How could this possibly result in Bitcoins going up? Even if this is handled
without any hiccups, this should shake a lot of people's faith (myself
included).

This should be a wakeup call for anyone that thinks that Bitcoins are totally
secure. What if next time the bug in the client is more exploitable? Someone
malicious could potentially take out the entire Bitcoin economy in one day by
exploiting it.

~~~
waterlesscloud
If it comes through this with no lost transactions, then the system has proven
a degree of robustness.

~~~
kalleboo
Only because the community is so small that telling "everyone" to downgrade to
0.7 is actually doable. Now imagine a future where everyone uses bitcoin -
imagine getting an institution like a bank to get on the "right" version...

~~~
muyuu
Actually, for this purpose the system is not getting any bigger right now.

You only need to notify miners and mining pools. These have been concentrating
for a while and will continue to concentrate in the future.

Individual users who aren't mining don't need to do anything.

------
cnp
What a stressful 24 hours. Everything has finally been resolved.

------
discountgenius
What is a good way to follow updates on this situation?

~~~
yakiv
This (probably) won't discuss the technical problem, but
<http://www.bitcoinity.org/markets> will let you track Bitcoin prices.

~~~
discountgenius
thanks for the reply. I always have bitcoinity open. (dark theme FTW).

The answer to the question I was trying to ask is
<https://coinbase.com/network/blocks> which enables me to check in on how far
behind the future legitimate blockchain is (7 blocks at time of writing).

~~~
DannyBee
This page is out of date by a bunch of blocks.

<http://blockchain.info/> is updated live.

As you can see, the 0.7 chain has already overtaken the 0.8 chain, and clients
are now resubmitting transactions into the 0.7 chain.

