A successful Bitcoin double spend – USD 10000
bitcointalk.org
bitcointalk.org
Here's the scary thing revealed by this bug however: Causing (intentionally) a fork is WAY easier than I thought!
You don't need to control a majority of mining. All you need is to craft a block such that some large % of the mining clients will fail on it. This could be a failure at any point in the bitcoin software. If there is a size limit discrepancy between versions (in this case the DB), or maybe a unicode parsing bug in some library used, or whatever. It doesn't need to be an exploitable code bug. It just needs to cause some % of mining clients to fail and reject a particular block.
It's relatively easy to find a bug that causes some software to crash. Most of the time these bugs are minor, and don't allow any remote execution or anything, so programmers don't necessarily worry about them most of the time. But in bitcoin they could potentially cause a blockchain fork! Which could be exploited, as this incident proves. This seems to lower the bar considerably to exploit BTC.
No, it can only be a failure in the code that determines whether a block is valid. This is a small amount of code, subject to pretty intense scrutiny. And it can only be a bug that makes clients produce conflicting answers, not one that makes clients crash outright. (The 0.7 client, apparently, caught an exception and handled it by treating the block as invalid. We now know that this was a mistake; it should be made to crash instead.)
During the fork, 0.7 clients detected that they weren't on the longest chain and received an automatic message saying that their client might be out of date. People are now talking about building fork detection into merchants' systems, to fall back to safe mode if a fork is detected.
The BDB problem is not mysterious like you suggest, and the whole thing could've been converted from a fork to a DoS by changing a 'return false' to an 'assert'.
If you did somehow create a block that all clients except yours crashed on, you still wouldn't gain control of the network because the difficulty of creating a new block is calibrated according to the total power of the network, and only re-calibrates every few blocks. So for a while, you would still be effectively competing against the former power of the network, giving the client developers time to fix the crash.
Also, it doesn't need to be a crypto failure. Just a divergence of the clients on how they handle the protocol. Possibly a discrepancy that would be very unlikely to occur by chance or in testing, and only manifests itself when a malicious user triggers it. This is the threat model bitcoin has to worry about now...
You would need to find a very localized, specific
class of bug in a piece of software that has been
highly scrutinized over many years by cryptography
and security experts
everyone voluntarily chooses which software to run.
Surely the most secure thing is to be on the most widely used client?
After all, if all "security experts" are so good, why didn't they catch the recent fork?
This guy is (apparently?) unhappy, and he's knowledgable enough about bitcoin to know to inspect forks and vins and OKPAY transactions -- and then to make two double (?) spend transactions.
If this guy is getting screwed, I'd surely manage to lose twice my investment somehow.
So, philosophically speaking, Bitcoin encourages people to start thinking about being more responsible about their money safety (which they anyway have to do, regardless of what they use, Bitcoin or a bank), at the same time providing a much better way to perform transactions and save for the future.
Then you also are paying much higher fees for what is supposed to be more safety. These fees come in various forms: government taxes, inflation, transaction fees.
Most people will take this trade all day, every day -- and they are not wrong to do so. It's a valid decision to pay for predictability.
They are working with some major Wall St insurers to insure and store large quantities of btc.
On the other hand, there are centralized services that manage these details for you, but then you arguably start to lose some of the benefit and appeal of bitcoin (beyond just an investment).
(On the other hand, there have been a few high-profile instances of end-users getting their coins stolen - usually by keeping them in an unencrypted wallet on a computer that gets a virus, but also in more exotic ways, like depositing them in an "online wallet service" run anonymously and registered to the Cayman islands.)
How so? Any double-spend is a risk for anyone receiving BTC, surely? You sell something on an ebay equivalent, someone sends you BTC, you send the goods but later find out there was a fork and double-spend situation, what happens?
Someone selling digital goods could well be vulnerable though.
Is there a mechanism that alerts of these forks in the blockchain? In this case it seems that something as simple as a single machine watching a 0.7 miner and 0.8 miner would have been enough to alert everyone of the issue before it went as far as it did.
Sometimes only minutes after payment.
"If you're sending them a couple of hours later you check to make sure it's ok before you send."
And if the fork lasts longer than a couple of hours?
That's why I'm saying there should be some overview mechanism to alert of these blockchain partitions. In general you can be sure the transaction is safe fairly quickly. If the network is obviously partitioned (as it was in this - so much so it was basically manually fixed) you'd be a fool to accept transactions until it's back to normal.
The problem in this case is that someone handed over $1000 in cash while the network was partitioned without sense checking it. The bigger issue is that there doesn't seem to be a mechanism in place to help them do the checking. Really there should have been big red "bitcoin is not safe to use right now" flags going up.
Personally I think that the place bitcoin could really win would be something like micro donations for content (instead of paywalls / ads). Read an article you like, click a button at the bottom to send over a small amount of money. That feels like the sort of use case it's really well suited for. Payments that can take a while / fail in very exceptional circumstances.
Essentially a whitehat response to the problem. The reason you wont get screwed in this way when you sue bitcoin is because of people like him that operate int he community.
While disposable shipping addresses (like other bogus contact details) are not unobtainable, it's usually risky because the address does tend to belong to someone, and I think it's true as well that most people are not scammers.
I am not an expert on Bitcoin but I think this kind of attack is possible. In that case as long as you spend your bad blocks before they can be invalidated by a longer chain, it becomes someone else's problem. If someone who knows more than me can enlighten us to why this attack would not work, I hope there is another reason than "it's unlikely that anyone would be able to 51% mighty Bitcoin now."
I think at 30TH/s, you'd need 500 new ASIC miners, and $500/day in power, to hit 50%. But that's just arbitrary - 2% would allow some attacks, 99% would allow more profitable ones.
At 50% of the network you'd theoretically solve 50% of the blocks, gaining 25BTC every 20m, or 72 times per day, for a "street value" of $80,000. During the day maybe $8M USD in BTC is traded.
You're talking about spending your money twice. Writing a transaction sending the BTC to someone and letting them record the transaction (transfer it to "the network") while trying to generate the next block containing which contains a matching transaction from that wallet to another wallet you control. If you fall behind you simply pretend you never tried and lose nothing by trying, except the costs of the transaction. If you win you can reveal your 1-unit chain to gain $1100 (your rightful reward for mining) or you can hide it to wait for a double-spend opportunity and try to lengthen your chain.
Meanwhile the merchant takes your transaction and sends it to the network and waits. If they're trusting they send you your merchandise now, but usually they wait for one or more blocks to be published to verify the transaction. Let's say that you can see the instant they do and their action is irrevocable. This is the best state for you. You then "simply" need to win more blocks than the rest of the network for however long until you see the transaction be finalized and reveal your chain with your blocking transaction at the head, causing the transfer to the merchant to be ignored by the rest of the network after renegotiation.
This simple plan won't work well though because when the network resyncs it's obvious which transactions are double-spent and your BTC will be known and people can refuse to deal with wallets that receive stolen coins - turning it into a painful single-spend, and loss of your mining earnings. So you need to actually coordinate a double-spend, getting something else irrevocably sent from another merchant with the same BTC. This is where it gets hard because each merchant is watching the same global pool for their confirmation and would see you spending the same BTC in another transaction.
Double-spends can only really happen when merchants are on separate blockchains already, as with the recent bug.
You're looking for something that can be converted into directly and efficiently back into BTC because if you don't manage your double-spend you're going to own this thing - this is like the house's cut. And something commodity and untraceable so you can unload it when hot. The best-case would be if someone was sending gold-bars via anonymous remailers - you'd only lose shipping costs.
A seller selling one-of-a-kind yachts which they special deliver to customers has nothing to worry about. In the months it takes to build and deliver a yacht the theoretical 51% enemy has earned enough for many yachts and doesn't need to double-spend. But a gold-bar dealer - they're justifiably worried. Luckily real-time gold shipments aren't a big deal. They can wait a day.
And when you double-spend you'd essentially lose your BTC from mining as the accounts they were paid to for the day would be blacklisted. So unless you bought more gold than your expected daily take in BTC you'd have been better off mining.
And remember that you're buying a bar of gold for every block you win and trying to get ahead enough at any point to manage to not pay so you've got to have a big bankroll and keep from going bust from transactional and infrastructure costs until you sell those incoming bars you ended up having to pay for (ie, all but the last one).
All this while competing with index funds and other far safer bets....
If you're dealing with an extremely technical adversary who you feel would spend $1M + $100K/day to mess with you, worry and plan appropriately to mitigate risk. General merchants are relatively safe though.
http://www.reddit.com/r/Bitcoin/comments/1a51xx/now_that_its...
[Submitted March 12]
It's DanielTaylor again and I wanted to create a simple yet
intuitive post to explain the folks out there what happened
a couple of hours ago. This might also be useful for
bloggers or journalists who might be going to write about
it in the following hours.
TL;DR
The programs that read the blockchain, the bitcoin ledger,
disagree.
Due to a bug in 0.7, it says that HIS is the correct
version of this ledger and 0.8 says that HIS is the correct
version.
Miners (the people who add pages to the blockchain) are
told to switch to the 0.7 program so that this version
gains more support and the other one is discarded.
(orphaned).
Regular users are not affected. Their transactions are
included in both ledgers and don't need to change any
programs.
During that time, though, there is a slight chance of a
double-spend ocurring. That is why people recommended
merchants and exchanges to wait until there is one single
blockchain again before processing purchases and
merchandise.
...
What's a double-spend?
This is the reason why some merchants and exchanges stopped
processing incoming bitcoins for a couple of hours.
The bitcoin network prevents people from spending the same
coins by mantaining this unique ledger, the blockchain. But
now that there were two of them, it was theoretically
possible to broadcast two different transactions with the
same coins and still get some confirmations.
With some luck, someone could sneakily sneakily* buy a
television to a merchant who was reading the 0.8 ledger and
have the transaction confirmed. At the same time he could
have sent the same coins back to himself and, with some
luck, have the transaction confirmed on the 0.7 ledger.
What happens is that, in the end when 0.7 wins, the thief
will have the television and his bitcoins. Remember that
there were two different versions of the same coins!
This is not something easy to do and requires a lot of luck
because the blocks mined (the pages added to the ledger)
must be mined precisely in the correct order. But still, in
this situation it was easier to pull off and so it was
recommended for merchants and exchanges to temporarily stop
processing incoming transactions.
Now the situation has resolved and the blockchain keeps
growing happily, page by page, block y block.So, in other (foreign) words, caveat venditor?
I think you'll find that transferring money to a business or person without a bank is a very empowering experience.
One of his transactions was on the 0.8 chain (during its short life, and the other was on the 0.7 chain. So it's better to think of it as a transaction being invalidated rather than double-spent, because in the end there were no outputs that didn't come from an input.
This was only possible to to extraordinary circumstances, and as long as the majority of the network is running software that plays by the same rules, this kind of thing isn't possible.
This is using semantics to try to minimize the severity of what happened. For a time, the world thought there were more bitcoins in circulation than there actually were. Someone thought they were holding BTC which turned out not to exist, since after the chains were merged, those extra BTC just ceased to exist.
That isn't a big deal if both sets of BTC were sitting in a holding account somewhere. On the other hand, it IS a big deal if (as is the case in most financial transactions), the parties exchanged another item of value (say, $1000 cash) in return for receiving each BTC transaction. One of those parties now has -$1000 and zero BTC to show for it.
Isn't this against the idea of decentralization?
The reason bitcoin can be decentralized is that ultimate authority comes, not from a central server, but from a consensus among the community of bitcoin processors and miners. The cryptography just enforces the consensus. In other words, ANYONE could write their own blockchain... even one that showed everyone else in the world giving all their money that person. It's just that no one would pay any attention to that blockchain... we'd all be working off the consensus view.
This is also why bitcoin is resistant to being controlled by "the authorities", but not immune to it. If someone controlled over 50% of the compute power that's doing mining and processing payments, they could change the system and "fix" the numbers. The fact that it is decentralized is a defense against this because (hopefully) no one entity controls a significant portion of the compute power.
And, this was an accident. As we know, there are many people with the ill-intent and incentive to look for or create exploits 24/7. Saying this won't happen again is like saying "Ok, this is the LAST FireFox patch you'll ever need. Really. We've thought of everything."
This is a game of cat and mouse, similar to one I've involuntarily had to play with fraudsters in my business over the years, and we've all been involved with via viruses, software patches, etc.
I am not sure why we continue to have such supreme confidence that we have discovered something even approaching bulletproof here, when history has taught us that we should believe anything but. It's partly the developer mindset, I suppose. We all tend to believe we've thought of every path and that our code is bug free, until someone encounters a bug that is.
We need to abandon that overly optimistic mindset and look for solutions that accomodate the inevitability of this happening again, whether they be process, technical, or both.
This might include the notion of a central registry on the network, which can help to resolve/identify potential forks, etc. While I know the notion of decentralization is sacrosanct in the BTC community, it is really a fallacy that there is not centralization now. The "core team" is actually playing that role, albeit manually, and what this issue shows is that it may well be a necessary role. I am not talking about doing away with the P2P nodes or controlling them centrally, just acknowledging that pure P2P has strong merits, but also introduces vulnerabilities.
This incident was containable and manageable. In the future (and especially at scale), it may well be infeasible for such manual intervention to clean up the mess. Rather than all convince ourselves that we have now thought of everything, we need to assure ourselves that we haven't and never will, then use our collective brainpower to build in the kinds of safeguards and redundancies that will help avert catastrophe when the inevitable happens.
And the problem will get harder to manage as BC becomes more popular. They could restrict damage because the ecosystem is still small, but when if there are millions of merchants? The alternative is centralized processors, which doesn't make BC that much better than cash.
It was recently discovered that a change in Bitcoin 0.8 caused an entry in the block chain that old versions can't process. The old versions, unable to verify the 0.8 block chain, automatically started their own block chain based on the last block they could deal with.
0.8-readable block chain continues
|
---> |
| | <- 0.7-readable block chain splits off
| /
|/
* <- block that old versions can't process
|
|
(history)
dead | <- 0.7-readable block chain is now "official"
| |
---> _ |
| |
| /
|/
* <- block that old versions can't process
|
|
(history)
The OP states that he has done this successfully. He submitted a transaction to a BTC<->USD service running 0.8. The service, checking the bad block chain, thought it had received Bitcoins and therefore sent him USD. But his transaction was never sent to the "official" block chain, so according to the rest of the Bitcoin world, he still has his original Bitcoins.
This is significant because prevention of double-spending is a fundamental feature of Bitcoin. If it can be bypassed, then the entire Bitcoin economy is endangered.
But what happens to the mining reward, I don't know. Anyone?
A mining reward is actually just a special transaction that the miner includes in blocks they find that let them pay themselves out of thin air.
So, the mining reward transactions on the 0.8 branch only exist on that branch, since the 0.7 chain had its own reward transactions made out to its own miners. When the network reached consensus on the 0.7 branch, money that miners on 0.8 thought they earned just disappeared (other clients stopped acknowledging their reward bitcoins).
Some pool operators lost out too, since they paid people who found blocks on the 0.8 branch.
If pools paid miners using bitcoins from their own mined blocks, this problem would go away-- that's not a bad idea!
edit: I asked -- some pool operators apparently already do this. The ones that lost out are the ones that don't.
Imagine a bank that, instead of having a central computer that all the ATM's call into, relies on each ATM to track every customer's balance. When I try to withdraw money from any ATM in the network, it checks its records of my balance, then broadcasts the transaction to all of the other ATM's.
Since the network is distributed, an evil-minded customer might send his brother out with a second ATM card, and time two withdrawals of the complete account balance, to take place at virtually the same second. Since it takes a few seconds for each transaction to be disseminated, there is a chance that both withdrawals will succeed before either ATM learns of the other transaction -- thus leaving the bank short by that amount, and me and my bro with twice the cash that we should have.
So, the bank institutes a policy of nominating one ATM at random to issue a report of all transactions that it has received once every minute. This report is guaranteed to be self-consistent -- if a customer's balance would go below zero, then that withdrawal is not included in the report. Ties are broken by time stamp down to the microsecond, and then by random chance in the unlikely event of a tie. Now, an ATM can ensure it's not being duped by transmitting the proposed withdrawal, then waiting to receive the next report and verifying that the withdrawal is included in it, then dispensing the money.
Then one day, a major network cable linking the East Coast and West Coast ATM clusters breaks. Both halves continue right on operating (they are fault-tolerant), but now transactions are only spread to half of the network, and each minute two independent reports are issued, again to only half the network each. Now, if you live in NYC and your brother is in LA, you can each withdraw the full balance from your account, and both transactions will be verified since they are being processed by two independent networks.
Later, when the network cable is patched, the two halves have to merge their respective reports and one of the withdrawals will be thrown out as invalid -- but you still have twice the cash.
Where subways diverge from Bitcoin is that sold goods can represent a real loss, can be resold thus creating the incentive to scam, and that Bitcoin is anonymous where subway cards aren't (security cameras) so repeated instances of this crime can be caught. So the consequences of double-spending with Bitcoin are vastly higher and the network can't just choose to live with it.
If you're going to tell me that it depends upon the length of the fork, then you'd better be waiting at least that many blocks before you verify a transaction.
If you mean waiting for x validations before accepting a transaction, yes -- but do you really think that it's practical to wait 30 minutes before delivering goods for a transaction? That's going to be a really long time spent staring at the little spinny thing over a line of text saying "verifying your payment" ...
If you mean the 'chargeback' feature when you say "then the card provider starts grabbing money back", then yes, absolutely, this is a feature of card payments and is essential for people to have any trust in internet commerce at all. Chargeback is good
I wasn't referring to chargeback; I meant stroppy card providers. The sort of thing these guy are fighting (although that was for a security breach rather than too many authorised charges against empty accounts):
http://www.out-law.com/en/articles/2013/march/retail-victim-...
No it can't.
The only way is to have a source saying "Bitcoin is OK, accept transactions" or "Bitcoin is not OK, no transactions". However this source now will be the target for no end of attacks (both hacking and legal), since it literally allows you to turn off the bitcoin economy. The bitcoin industry/community seems incapable of writing secure software. So I wouldn't put much faith in them doing anything well.
It's possible to build a decentralized fork detector that anyone can run. All you have to do is run a bunch of versions of bitcoin nodes, and run a cron job to check and see if they have differing opinions on which fork is currently valid.
If you discover a recent fork of length > x, you might want to hold off on verifying or making transactions for a bit until things clear up.
> The bitcoin industry/community seems incapable of writing secure software
Dan Kaminsky (http://en.wikipedia.org/wiki/Dan_Kaminsky) would probably disagree:
"When I first looked at the code, I was sure I was going to be able to break it, Kaminsky said, noting that the programming style was dense and inscrutable. The way the whole thing was formatted was insane. Only the most paranoid, painstaking coder in the world could avoid making mistakes.…He quickly identified nine ways to compromise the system…when he found the right spot, there was a message waiting for him. Attack Removed, it said. The same thing happened over and over, infuriating Kaminsky. I came up with beautiful bugs, he said. But every time I went after the code there was a line that addressed the problem.…I’ve never seen anything like it, Kaminsky said, still in awe…Either there’s a team of people who worked on this, Kaminsky said, or this guy is a genius."
Kaminsky was talking about Satoshi's code, but some of the current devs seem good. For example, there's Mike Hearn, a senior security engineer at Google. And Jeff Garzik, a linux kernel developer.
I'm pretty sure that the poster was referring to the community of services that exist around bitcoin, rather than the protocol itself, that have been repeatedly and expensively compromised.
His evaluation is that the crypto is sound, but that as transaction volume increases the cost of entry goes up massively and the whole system has to morph into a centralised, bank-based operation run by a few parties with masses of processing power and storage capabilities. Interesting.
https://en.bitcoin.it/wiki/Scalability (which has some recent research on CPU optimizations) and https://bitcointalk.org/index.php?topic=34597.0 (a response from a year ago) answer some of Kaminsky's scalability criticisms.
There's also the possibility of off-the-chain transactions: http://gavintech.blogspot.co.il/2012/07/off-chain-transactio...
There is a plethora of truly wonderful effects possible once the transaction chain is forked. The guy did the simplest thing possible with the least effort invested after the chain forked on its own, basically. In case we had several BitCoin codebases operating in the wild, such forks would be too easy to trigger.
Key point: the technology is crap but the demand is huge.
Still, it's an exploitable vulnerability. Very difficult to make the conditions happen, but if they happen naturally it's something that can be taken advantage of. It'll need to be addressed in one way or another.
What IRC channel out of curiosity?
But if it happened like you think, I definitely agree with you.
BitCoin's raison d'etre isn't for conversion to fiat currency - it's to become an alternative to fiat currency. I'd love to see a breakdown of how much has been converted into fiat currency vs. how much has been spent for goods/services. Likely, I bet it's well over 100:1. So what has happened? BitCoin is helping put more fiat currency in people's hands as it grows, which is (theoretically) being spent on iPhones and bubble gum, strengthening the value of fiat currency in general.