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.
> 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.
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.
I can't find what you mean by block validation inheriting OpenSSL's quirks. Could you explain what you mean? A quick google search suggests that Bitcoin uses OpenSSL only by passing it messages and fixed-size ECDSA keys for validation.
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'.
I forget the exact problem with OpenSSL, but it accepts particular invalid representations of signatures that the applicable standards say it shouldn't accept, because it doesn't treat the sign bit as a sign bit. This isn't generally a problem because those numbers should never actually be negative, but it's an issue for Bitcoin because everyone needs to agree on which signatures are valid.
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?
No. You would have 100% control of the subtree following that failing block, but it would be very quickly outpaced by another subtree that the rest of the network would be working on. You need to construct a block that close to 50% of clients fail on, so that the network's work is split between two subtrees and they grow at about the same rate.
Well, if they crashed on a certain block then the operators of the client would notice and presumably update to a newer version of the client. The problem in this case was more subtle: the old clients did not crash on the block, they simply rejected it as invalid and continued working on an alternate subtree.
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.
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.
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?
Clients emit a warning in the GUI (and IIRC disable the RPC interface, which would be the fail-safe for merchants) when this kind of issue is detected (namely, conflicting blockchains of significant length received from different peers). So the most secure thing would be to be connected to a high diversity of peer nodes, and to pause transaction processing and check the news when you get a warning.
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...
They didn't catch this because it wasn't a bug in the client code itself, rather it was a bug in a third-party library, which is currently being migrated away from. Further (as far as I'm aware) it's only happened by chance, never deliberately by a malicious entity.
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.
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.
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.)
"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?
It is - but how long do people wait before sending goods on ebay? If you're sending them a couple of hours later you check to make sure it's ok before you send. Ebay is a case where bitcoin works well because you can afford to wait before sending the goods. Realtime processing is where bitcoin really isn't safe.
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.
Well if that's the case then they won't be excepting bitcoin. There's just no getting around that.
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.
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.
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.
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.
even selling contraband you are probably covered as long as you do not ship within the first hour or two of the order being placed. Within that time frame confirmations would have occurred or a problem identified. Even digital delivery goods that await confirmatins are fine, it really affects digital good sellers who send on 1st confirmation or do not require confirmations, bitcoins have a confirmation system for the protection of users, if you dont use that protection then you have only yourself to blame.
I'll admit it's unlikely that a single user / group is going to 51% the network (and in that case we're all hosed anyway), but you know that in that case, they could perpetuate a fork for a very long time in the darkness, and break it out later when they are ready to "unleash the fraud" on everyone, after the merchandise is received and they have permanently left the scene of the crime.
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."
It's a matter of cost, not a possible vs impossible thing.
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.
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.
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.
Actually, one of the reasons I'm so bullish about Bitcoin in the long run is the experience and maturity of most members of the main dev team. Yes, it's only about 6 core devs now, but that will grow as bitcoins market cap increases (presumably). The recent block chain split (a Bitcoin emergency if there ever was one) was handled so quickly and decisively by the core devs that the price remained relatively stable. That's pretty amazing.
I was impressed by how small the price change was as a result of this blockchain split - it gives me a lot more confidence in the future of Bitcoin. Mt. Gox saw a selloff and price drop of about 20%, which was mostly stabilized in a day, and about back to the starting price in 2. All of the other exchanges look about the same or less severe.
Your logic is slightly wrong. When a project is opensourced and popular, odds are you actually have more engineers looking at it and fixing things, than when you have isolated teams working on software for each individual bank. And that's not even talking about testers.
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.
Insurance in any form is never a good deal, actuarially -- the house always wins. What insurance is, is a way to trade a non-zero risk of ruin (someone steals all your bitcoin and you are broke) for a zero risk of ruin and a guaranteed risk of a small loss (someone steals your credit card number and you are not liable, but you pay 2% of every transaction).
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.
There's nothing out there that prevents companies to create Bitcoin services to store and insure your savings for you. I believe they will inevitably emerge as the Bitcoin economy grows.
There's every reason to believe the infrastructure will grow as needed. Where there's money, there's people solving problems to make sure it keeps flowing.
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).
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.
[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.
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".
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.
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.
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.
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.
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 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.
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.
Anything of value on the end of an HTTP transaction has some centralization, such as bank accounts, Amazon.com, or other things that involve real money.
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.
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.
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.
Good question. I know that any transactions in forked chains that have been orphaned are included as transaction if it hasn't been double spent on the other chain.
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.
They do indeed pay in bitcoins. The payment transactions during the fork weren't lost, however-- they were confirmed on both branches of the chain. The only transactions that disappeared were the block reward transactions on 0.8.
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.
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.
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.
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.
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.
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.
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" ...
It's completely reasonable. Bitcoin is not a good candidate for a medium of exchange despite what some adopters will tell you. It is more like virtual gold. You can see in the real world that mediums of exchange and stores of value aren't the same thing because the properties that are desirable in one are not desirable in the other.
And there's another electronic currency system coming online now that should handle instant transactions well: ripple.com Its a new incarnation of a relatively old idea, but the good thing about the new ripple is that transactions are (and should continue to be) nearly instant. And it is very, very easy to trade bitcoin for ripple using the ripple system, and should get even easier. So I imagine a future where value is stored in btc, and spent using ripple (in any of the supported currencies).
How do you think credit card transactions work? The auth code you get back from a "valid" cc transaction doesn't represent a transfer of money. That might not happen for another 24 hours.
Doesn't reserve funds, it's rarely realtime. "Guarantees payment" just means that the cost has been shifted from the retailer to the card provider - for a while anyway, then the card provider starts grabbing money back.
Yeah it does reserve the funds, I've worked in this industry. Settlement happens later, but authorisation does put a reserve on the funds in the credit account if the transaction has gone end-to-end.
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
End to end is the key point, loads of places still use off line terminals that batch the job up at eod.
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):
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.
> 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
"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.
Hmm, having now read Kamisnky's thoughts on BTC, were I a BTC enthusiast I'd be less than happy to pointing to them.
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.
The bitcoin industry/community is not the same as the official client though is it?
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.
Sure Satoshi's original code & protocol design are good. But Satoshi's gone. All that's left is people who thought storing unsalted MD5 hashs of user passwords is acceptable (MtGox)
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.
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.
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.
The guy used a $10,000 double spend to publicly extort OKPay to expedite a smaller refund, rather than go through support. I'm not sure I'd be very gracious either, or ever do business with this guy again.
I got the impression he had tried to go through support, and got no response until he ended up with $10,000 of their money. Then all of a sudden, they solved his problem.
But if it happened like you think, I definitely agree with you.
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.
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.
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.
Ok - let's say the price of a dollar rises 10 cents. If that meant an increase in confidence, then the price would rise even more and it would go on and the price would rise really fast. In reality the price rises and some people are more confident and some are thinking that the price will drop soon and they will buy again.
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.