A successful Bitcoin double spend – USD 10000

https://bitcointalk.org/index.php?topic=152348

by balsam • 13 years ago

198 103 13 years ago

maaku2• 13 years ago

Should be noted that the money was returned.

w-ll2• 13 years ago

I might be wrong, but it wasn't returned, but that doesn't matter, all the mining ops switched to the 0.7 chain, and the transaction is now in limbo (for lack of a better term); the forked 0.8 chain.

waterlesscloud3• 13 years ago

He paid it back, he said something about it in the irc channel this morning.

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.

eric_bullington6• 13 years ago

It was returned, and an OKPay rep confirmed it (with not much gratitude, in my opinion): https://bitcointalk.org/index.php?topic=152348.80

tantalor• 13 years ago

Can somebody explain without the technical jargon?

jmillikin• 13 years ago

Bitcoin's security is based on the idea of a "block chain", which is sort of a mutually agreed-upon list of transactions. As long as all participants in the Bitcoin economy are using the same block chain, then double-spending money is (for all practical purposes) impossible.

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)

For technical reasons, it was decided that the 0.8 block chain would be abandoned, and all clients should switch to the "forked" block chain that was accidentally created by old clients.

  dead    | <- 0.7-readable block chain is now "official"
  |       |
  ---> _  |
       |  |
       | /
       |/
       *  <- block that old versions can't process
       |
       |
  (history)

This causes a problem, because until that switch happens, a person could issue a transaction to a 0.8 client that would be accepted only by clients running the "bad" 0.8 blockchain.

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.

ctz• 13 years ago

What happened to bitcoins 'mined' on the 0.8 chain in the meantime? Did people lose their currency?

URSpider945• 13 years ago

Less technical, and mostly correct (I left plenty of room to nitpick)

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.

T-hawk• 13 years ago

I can't find a cite, but I read an article somewhere that some transit fare systems work like that. Each node tracks every customer's balance and broadcasts transactions. That's how the turnstile is always able to respond instantly, because the validation is local. It's possible to duplicate a card and swipe it simultaneously at different stations to double-spend. It's considered an acceptable leak in the system given the high effort, infungibility of the good, and near-zero actual cost of a free-rider.

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.

nostromo• 13 years ago

I've actually thought about putting some play money in Bitcoin, but these stories prevent me from doing so.

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.

snitko3• 13 years ago

Technical problems resulting in people losing money happen all the time outside of the Bitcoin economy. In fact, the way these recent events were handled by Bitcoin developers and the community are way more encouraging than, say, actions taken by Visa after someone supposedly stolen a million credit card numbers.

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.

taligent• 13 years ago

Sure technical problems happen all the time. But there are tens/hundreds of thousands of engineers/testers across the world who get paid very well to fix them. Bitcoin doesn't have that sort of infrastructure. And if you are responsible about money safety then putting your money into Bitcoin is pretty stupid. Banks around the world insure credit card losses for any fraudulent transactions.

johnsoft7• 13 years ago

Sadly, I have to agree with you. I have a fair amount of money in bitcoin right now, but if I didn't understand the ins and outs of the protocol and like debugging, I can think of a few incidents which would have caused me to lose money (or at least think I lost money), and that would have frustrated me enough to pull out entirely.

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

jimrandomh3• 13 years ago

This guy wasn't the one screwed, OKPay (a payment processor) was; he took advantage of a several-hour window during the blockchain fork that happened a few days ago, to send them coins, wait until they gave him money for those coins, then take the coins back. This sort of thing is a risk for those operating exchanges and payment processors, not for end users. He returned the coins later - he had to, since he used an account linked to his real name - but a more-anonymous version of the same scenario is theoretically possible.

(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.)

Nursie6• 13 years ago

"This sort of thing is a risk for those operating exchanges and payment processors, not for end users."

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?

makomk4• 13 years ago

If someone did a big enough version of the attack on one of the smaller exchanges or payment providers there'd be plenty of end users hurting, trust me - with a big enough attack they're not going to be able to swallow the losses or pay back customer funds, and there's no FDIC insurance for Bitcoin deposits.

dfc• 13 years ago

What is a vin? A cursory google search did not turn up anything obvious.

johnsoft7• 13 years ago

vin = the source of coins that are being spent, plus some auxiliary data. The source consists of a (txid, vout) pair, where vout is an output index. If the client comes across an identical pair as a source in multiple transactions, all but the first will be rejected as invalid.

ewillbefull• 13 years ago

It's not as if the bitcoin developers are asking people to throw their money into it. It's still experimental, subject to change and hard forks, and they've said over twitter and the forums many times not to invest what you can't afford to lose.

celticninja2• 13 years ago

He is not getting screwed, this guy is the one who made the double spend, he basically spent $10k and then when he realised the problem and tried to spend the $10k again, he did so successfully. He then made a post about it and informed the company (OKPAY) so that the problem could be resolved.

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.

yebyen2• 13 years ago

I think it's basically true that unless you're selling contraband or digital goods, it's unlikely that you'll get screwed, because like any other transaction you must necessarily collect a shipping address and other personally identifiable information in order to complete the transaction.

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.

ramanujan• 13 years ago

It looks like this possibility was known and broadcasted to merchants during the maintenance window two days ago. It's kind of like the Rails mass assignment or security bug: merchants are just going to have to stay on top of Bitcoin issues.

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.

TylerE• 13 years ago

Calling what happened the other day a "maintenance window" is about as truthful as describing a fire that burns your house as down as a "redecorating party".

pavel_lishin• 13 years ago

> merchants are just going to have to stay on top of Bitcoin issues.

So, in other (foreign) words, caveat venditor?

eric_bullington6• 13 years ago

If you're talking about play money, say $20, why not just try? Or even $5 if you're worried about losing $20? And then try spending it at one of the thousands of businesses listed here: https://bitcointalk.org/index.php?topic=152348.80

I think you'll find that transferring money to a business or person without a bank is a very empowering experience.

zby2• 13 years ago

There was a visible fork of the blockchain - a clearly exceptional condition showing that the network did not work correctly at that moment. All merchants should stop accepting payments for duration of that - this can easily be automated.

URSpider945• 13 years ago

Forks of the blockchain happen all the time as a natural side effect of the distributed nature of blockchain calculation. How do you propose that a merchant detect a pathological fork?

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.

nazgulnarsil2• 13 years ago

this is already built into the protocol.

zby2• 13 years ago

A pathological fork is when both parts grow in a visible way. The normal thing is when a part of the network is split off - and it grows it's own blockchain - then it gets connected and the chains get re-conciliated. When the reconciliation does not happen even if it could - that is when it is visible that both chains grow - then either the internet is in some funny state or the bitcoin system is.

rmc3• 13 years ago

this can easily be automated.

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.

RoboTeddy4• 13 years ago

> However this source now will be the target for no end of attacks (both hacking and legal)

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.

rms• 13 years ago

Yet the price keeps rising...

gusgordon2• 13 years ago

Rising price doesn't mean confidence in the currency. If that were the case growth would be exponential (it's not). It should exclusively be the other way around.

tudorizer• 13 years ago

Can you elaborate on this?

bdcravens• 13 years ago

Indeed, every time a negative story comes out, proponents always talk about the MtGox price and how that indicates how strong BitCoin is.

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.

aianus• 13 years ago

Even if Bitcoin fails at everything except conversion into and out of fiat currency, it's still a major win. It significantly undercuts existing services for international payments while also circumventing currency controls, AML regulations, and censorship.

johnsoft7• 13 years ago

This was only possible because of an obscure bug in a database library used by the reference client, which the developers are in the process of migrating away from. The latest 0.8-beta release inadvertently caused a size restriction on some part of the block structure to be loosened. Since the majority of the network's mining power had upgraded, older clients wouldn't accept these blocks, and the blockchain diverged, with 0.7 and 0.8 each on a different fork, seeing an inconsistent view of recent transactions. Miners were quickly contacted and asked to downgrade to 0.7, and once the 0.7 chain caught up with the 0.8 chain, the network resolved the problem and the view of transactions became consistent again.

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.

URSpider945• 13 years ago

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.

runn1ng2• 13 years ago

>as long as the majority of the network is running software that plays by the same rules, this kind of thing isn't possible

Isn't this against the idea of decentralization?

Shish2k• 13 years ago

HTTP is decentralised

mcherm• 13 years ago

Not at all, rather it is the key that makes decentralization possible.

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.

SoftwareMaven• 13 years ago

You know the next time something like this happens (and, this is software, it will happen), there will be a lot of people trying this attack. It was theoretical before with "enough effort"; now, it is known to be easy.

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.

batgaijin• 13 years ago

shard the currency

platypii2• 13 years ago

OK, so it's not hard to imagine double spends happening during a fork. This incident proves that as long as there is at least one provider willing to exchange BTC automatically, and is unaware of a fork in progress, then one can exploit the fork and double spend. This is bad, and should be fixed with a technical solution if possible. People will be looking for this in the future.

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.

jimrandomh3• 13 years ago

> This could be a failure at any point in the bitcoin software.

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.

makomk4• 13 years ago

The code that actually determines whether a block is valid is not a small amout of code at all though - that's the entire problem! Whether a block is valid or not depends on subtle behavioural details of huge third-party libraries. The current issue resulted from a quirk of BDB and the developers still haven't managed to fully figure out when exactly it does cause a block to be treated as invalid. We also already knew that block validation inherits some of OpenSSL's quirks which aren't compatible with other, more spec-compliant crypto libraries. It's entirely likely that other code outside of the Bitcoin client also affects which blocks are valid.

IgorPartola2• 13 years ago

That is a beautiful thing. So if I construct a block such that 100% of the clients fail on it, I can then have my own patched client control the entire BTC betwork, right?

johnsoft7• 13 years ago

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 who know there are millions of dollars at stake, and this bug would need to affect parts of the P2P network but not others, keeping in mind everyone voluntarily chooses which software to run. I think calling it "relatively easy" is a bit of a stretch.

w-ll2• 13 years ago

Well it happened, with a simple decision to switch from BerkeleyDB to LevelDB. Luckily no-one malicious discovered it first, and it got fuzz'ed out.

platypii2• 13 years ago

When I say relatively easy, I mean compared to the prevailing wisdom that causing a fork requires controlling 51% of the total bitcoin mining capacity.

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

michaelt• 13 years ago

  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

Couldn't you monitor the version control system trunk for patches fixing bugs in the critical section of the code, work out the bug based on the fix, and exploit it before everyone had their systems patched?

  everyone voluntarily chooses which software to run.

In things like operating systems heterogeneous software is often seen as a defence against bugs - but in this instance, wasn't it the differences between the 0.7 and 0.8 clients that triggered the split in the blockchain?

Surely the most secure thing is to be on the most widely used client?

rmc3• 13 years ago

You claim it is hard to do. However it accidentally happened recently. So it can't be that hard.

After all, if all "security experts" are so good, why didn't they catch the recent fork?

makomk4• 13 years ago

Yes, and this issue is well known to anyone who's actually looked into the technical details of Bitcoin. It's really scary from a technical perspective - I believe that the developers have accidentally introduced similar issues before, it's just that no-one mined a block that triggered them.

gritzko• 13 years ago

http://pds.ewi.tudelft.nl/~victor/bitcoin.html

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.

marco-fiset• 13 years ago

I was looking forward for BitCoins to be hacked. This tells me it's not secure enough yet.

unclebucknasty• 13 years ago

There are people saying that this shouldn't happen again, etc. but it will. Perhaps not in this exact form, but in some form.

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.

cadetzero• 13 years ago

I submitted the exact same a day ago.

https://news.ycombinator.com/item?id=5365083

A successful Bitcoin double spend – USD 10000

Related Stories