Bitfinex uses BitGo for multi-signature (MultiSig) transactions. 2-of-3 signatures must be present for user funds to be released.
Keys present:
- Offline key held by Bitfinex
- Online key held by Bitfinex to initiate user withdrawals
- Online key held by BitGo to confirm user withdrawals are within constrained limits in a set timeframe
zanetackett, Product Development of Bitfinex, confirmed that Bitfinex's offline key was not compromised. The attack was also not internal [1]. Another set of comments also suggested that BitGo limits were set in place by Bitfinex [2-3].
The automatic limits are designed to constrain BitGo from signing any transaction from Bitfinex that are irregular in volume or exceed a set amount in any rolling timeframe. Somehow they were bypassed. What we have currently suggests that the limits were too large or that BitGo was not enforcing the limits. BitGo and Bitfinex are also separate established entities, so that both of them being compromised for this attack is unlikely. An improper setup between Bitfinex and BitGo is more likely.
I can't believe I'm saying this but: this is not a Bitcoin problem, per se. This is a Bitcoin exchange problem. (Bitcoin has many security problems, in the same way that an overweight smoker has many health problems, but that doesn't mean that smoking caused the gunshot wound.)
It's possible to have customer balances of $60 million and not lose them. Thousands of businesses manage this. They suffer $5+ million dollars of damages in less than 0.1% of business-years. (SWAG on a reasonable upper bound-- ask an actuary. This is an insurable risk.) Bitcoin exchanges with this level of deposits sustain $5+ million dollars of damages 20%+ of exchange-years.
Running Bitcoin exchange probably requires $10 million a year in engineering and compliance costs, and consequential changes to the business model with an eye towards a) paying for the actual costs of running the business and b) compromising on other things that users/investors care about, like speed of withdraw, degree of engagement with the regulatory state, and growth rate. Instead of making that tradeoff, Bitcoin businesses continue trying to grow at 100%+ YOY on four, five, or six digit risk budgets. And this works... until it doesn't.
"How do we not transfer substantially all of our assets to fraudsters?" would be an acceptable job interview question at the Medici bank in the early 15th century. It was a solved problem then.
It's as much of a Bitcoin problem as the ethereum DAO hack is a ethereum problem. In a normal banking system you just roll back the transaction, which often is possible. In Bitcoin, what's gone is gone.
that's true with US cash too. the problem with some of these exchanges is that they essentially have these buildings with $50M+ cash sitting inside them, but they are NOT also running bank vault level security, quality-wise, to protect that stash. some are better than others, but it makes sense that the worst of them will be run by underqualified people.
I've had the opportunity to look/study behind the scenes at a few major Bitcoin websites, early on, and... let's just say you never wanted to learn how the sausage in the sausage factory gets made. "This PHP kinda works on my box... Let's ship!"
Also the attackers have plenty of time to snoop, wait and watch for an opening. If you were breaking into a real bank then hanging around drilling or whatever is very noticeable and limits your options. I assume they are always scanning for unauthorised access but it only takes one chink and they are very attractive prospects for hackers so the motivation is there.
It is a common misconception that bank transfers can easily be rolled back. In the main if it was fraudulent then the bank compensates you, they take the hit. Some times however they will say it was user fault and you take the hit. I was amazed when I found out that after perhaps 2 transfers it is impossible to get back, larger sums may be more easily (or the bank more motivated to) traced but returning the funds is not always possible.
Normal banking systems can have the same problem when they, too, have lax security. Witness the $100 million heist from the Bangladesh account at the NY Fed.
That the Bangladesh example is the common counterpoint despite tons of banks and money in US unaffected really supports parent's claim. You had go to to a 3rd world country whose banks had little to no security to make average bank look as bad or worse than Bitcoin exchanges. Doesn't work that way.
The quote was "normal banks can", not "average banks do at the same rate or worse". The point is that the same challenge exists with physical banks, it's just been solved better because they have had more time to develop the security protocols.
And they put more effort into doing so with regulations from central authorities pushing it. There are no regulations, central authorities, or even strong investments in such security for the Bitcoin exchanges. So, again, how normal banks handle security vs how Bitcoins are managed is difference between night and day. You bringing in an exceptional situation for normal banking (a) doesn't apply to majority of normal banks, (b) distracts from fact that such things are normal for Bitcoin but not status quo its proponents want people to avoid, and (c) ignores that there's rarely effort in protecting Bitcoin exchanges that matches what players in existing system put in.
So, people should trust or build on existing system if they care about their stuff disappearing or being stolen. There's mitigations that work for that situation for the common case. Unlike Bitcoin and its exchanges.
The point of attack was not. You won't regularly see hackers stealing $100 million through a bank in the U.S. or compromising all its members. You will see Bitcoin exchanges regularly suffer major losses. It's not the exception like Bangladesh: it's the rule. Hence my counterpoint.
Bitcoin has problems, but let's not pretend the normal banking system is unhackable, or even possible to roll back. One group did at least four thefts via SWIFT this year using RAT tools in banks, the largest of which netted $80M. Nothing rolled back, no one caught.
The important part is that the money lost was the Banks (or the insurance companies - it's unclear). $80m is not chump change, but it also isn't a catastrophic loss which gets passed on to savers.
Of course, understanding the difference between an exchange and a bank is worthwhile - but these guys getting rinsed repeatedly and taking out user wallets is a problem that can't be waved away.
Not quite true. The gang that struck Bangladesh attempted to steal a cool billion dollars. After subtracting the transactions that were caught during manual review at other institutions and the transactions that were rolled back, they 'only' got $80 million. Still a lot but it could have been much worse.
Thieves know there's a possibility the transaction can be cancelled, which is why they tend to strike on Friday afternoon. By the time the theft is discovered the destination account has already been drained.
Of course Ethereum had its own giant theft, but that was from a convoluted, poorly-written, and much larger contract. There are ways to avoid the sorts of vulnerabilities that were exploited there: http://www.blunderingcode.com/writing-secure-solidity/
Probably other vulnerabilities will be discovered. But I think simple contracts that secure ether with multiple keys, timelocking, and so on are a pretty good solution for anyone just storing and sending ether. They're also starting to incorporate formal verification of contracts; the online Solidity compiler includes it now, though it doesn't yet support all Solidity features.
Bitcoin's security model is fundamentally different from more traditional money transfer system. Security is distributed pushing responsibility to the edges. Individual users must secure their own keys but only those funds are at risk if those keys are compromised.
By forcing Bitcoin into a central clearing house model like most of these exchanges are doing you arguably have the worst security properties of both models.
Has it been verified that BitGo's key was not simply compromised? As unlikely as it may be that both online keys could be compromised, it certainly seems that it could have happened (perhaps while it was not internal to bitfinex, it could have been internal to BitGo?)
>Who is to blame for this hack, finex, bitgo, users?
>>>We're still investigating the hack to figure out exactly how we were compromised, but it does look like it's on us.
If BitGo was compromised, 1 of the 2 remaining keys still must be used to sign the transaction. BitGo has no access without either of the 2 keys that Bitfinex controls.
Sorry, wasn't clear. I assumed it was obvious that bitfinex's online key was also compromised, no matter what happened with BitGo, whether their key(s) were stolen or if their api was abused.
So if you're playing along at home: the consensus Bitcoin chain is the longest one consistent with the rules of Bitcoin Core, the lineal descendant of the Satoshi client.
This consensus chain currently includes 1+ transactions T, which effected this theft.
The proposal is for a large number of miners to abandon the consensus chain and start mining a new chain at one transaction prior to T, replaying all real transactions minus T plus a new transaction which would moot T.
With enough hashpower, this chain eventually surpasses the current longest chain and at that point all points on network, not just mining cartel, will agree that T never happened.
This is supposed to be impossible because it is incentivize-incompatible, as the mining cartel would lose an incredible amount of segniorage to make it happen and it wouldn't be a sure thing. Point #2 is mooted by mining centralization, a ship which has sailed. Point #1 could get mooted by a payment outside the standard understanding of the Bitcoin protocol.
Someone further down the thread also mentioned a very good point in that the attackers could potentially start a bidding war against such a fork. They would have nothing to lose compared to a situation where the heist is reversed.
They have a fairly elegant mechanism to do so, too: just chain transactions from T to the addresses the miners send their coinbase transactions to. If miners go forward with the re-write history plan, the bribe gets undelivered, Back to the Future style.
It might be one of the first cases of bribery where the briber doesn't have to talk to the bribee to discuss the object of the conspiracy, the price, or how the bribe would be delivered.
Oh it gets better! The attackers can do things like entangle their stolen Bitcoin in systemically important institutions. Say, send 0.01 BTC to Coinbase. Coinbase is probably not operationally capable of separation that Bad Bitcoin from their Good Bitcoin before it's been comingled with customer funds. At that point, reversing T would also invalidate consequential transactions by Coinbase, which is probably something they can't allow to happen, so they would pay miners to not reverse.
It sounds like miners could find a replacement revenue stream even if block rewards go to zero and transaction fees are low: Hold the blockchain hostage for reversal and sell out to the highest bidder!
(Of course, this would likely drive the value of 1 BTC to exactly $0)
(Edit: This is all a demonstration of how the security of the blockchain absolutely depends on mining hashpower being widely decentralized and distributed)
Which is one of the more practical reasons a rollback is very, very unlikely to happen. (It would have been fairly unlikely even in the case of ethereum/theDAO, had not the nature of that exploit effectively locked the funds for a month.)
I'm not 100% sure but I think that anyone can re-submit the "undone" transaction to the new blockchain, as long as the source address hasn't already spent its balance on the new chain? Isn't this what's called a "replay"?
> This is supposed to be impossible because it is incentivize-incompatible
Enter the wonderful world of coco values and side payments in game theory. Incentive compatibility and strategyproofness arguments break down when parties are compensated (implicitly or explicitly) out-of-band. That's not always a bad thing - it can lead to more efficient, utility maximizing equilibria. That said, under the status quo, we're trading one flavor of centralization (monetary policy) for another (core committers and mining pools).
And yet, despite all of this and more, the chaotic Bitcoin apparatus lumbers doggedly forward, with little sign of stopping. Should be interesting to see where it ends up.
This has been proposed for every large hack in the history of Bitcoin. Not sure if it was by core devs every time, but the proposal always comes out.
It has never happened. This time will not be different.
Interesting history: Luke-jr (core dev) blacklisted some addresses in a package install of bitcoin he maintained, but this sort of censorship was never in the mainline source.
Source: joined Bitcoin community in early 2011, been enjoying bottomless popcorn ever since :-)
This talk about bribing miners to re-org the blockchain should be a huge wake-up-call to anyone trusting the nature of bitcoin. Incredibly interesting to watch from the sideline.
I'm sure with a little research, you're going to find even more random talks. Doubt anything will be done, it was a site that got hacked, they'll have to pay anything possible and get bankrupt.
Not quite. No transaction blacklisting. He's proposing paying miners to re-mine the blocks without those transactions. In other words, compensate them for the hashing power required to make a new fork.
Very different from the ethereum situation. Miners won't go for it though. Would cost them too much from confidence loss.
I don't see a problem with (a lot) individual miners makings such choices. Not quite the same as concerted forking to reverse a bug in proprietary system that you don't like that others see as a feature.
Do you know what happened in Ethereum? The block chain split and now both chains are running independently. You can buy New Ether or Ether Classic. If this happens a lot it will be crazy and confusing.
It will be confusing to people thinking in a 20th century way, where everything must have one reality.
The future is all about multiple versions of reality maintained simultaneously. There's no reason there has to be a single monetary system with agreement. Small groups of people with different values can have a totally different view of who has how much money.
You're right it's confusing, that's why this hasn't started happening until the software age. Now that we have software, we don't have to understand the books, we just have to be able to write software that can make sense of them.
There will always be a "main Ethereum" for people who need a single-source-of-truth and don't want to deal with multiple realities. But the point of anarchist software is that everyone doesn't have to agree. Everyone can just do their own thing, and elect to share realities when they want to.
This idea that there is one Bitcoin Network and one Ethereum Network is the biggest misconception people have about federated technologies. People imagine consensus means "one truth". But consensus means many truths, each which only have consensus within themselves. There's always been many Bitcoins. We just ignore most of them, by choice. We're so used to someone forcing us at gunpoint to agree to a single universal legal reality that we have a hard time imagining a world where there are lots of different sets of conflicting rules, and individuals choose which ones to pay attention to.
1) in actual fact, very few votes were cast for ETH. Although many people ran the clients that supported a fork, most of them simply did so because it was the only option for their chosen client - there was no non-fork client option easily available to them. Very few people explicitly chose the clients to support the fork.
2) "Will of the people" defeats the point of ETHs smart contracts. If everyone in the pool decided to buy in on a bet of a digital coin toss, and the bet ends up 51% heads and 49% tails, is it ok for the heads bettors to simply consensus the bet out of the chain and reclaim their money in the event that tails wins?
Blockchains require the will of the people. You can't force people to acknowledge numbers just because they're written down somewhere unless you point a gun at them. If the people you want to interact with start looking at a different source of truth, you can't stop them.
Despite this fundamental truth, blockchains are extremely useful.
That's reasonable enough. I think when there are contracts people actually want to use, no one will be turned away by the small chance that the entire ecosystem will maliciously alter that contract.
All the major clients included a non-fork option. The decision was ultimately made by the miners, who certainly have the technical competence to set options at the terminal.
It only works because the other party (Bitfinex exchange) is centralized and therefore can be held accountable to pay the miners. Reorganizing the blockchain is not possible (aka economically incentivized) in almost all other circumstances. Read his followup for more info: https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_sh...
As much as the joke about bitcoins "take the money and run" exchange business model is bandied about, how do people actually suggest securing exchange wallets?
I'm sure it's talked about, but I've never really found a straightforward explanation of how it should be done - is there even an agreed upon set of best practices? If so, why are these supposedly sophisticated exchanges not able to successfully apply them?
Hey, Sam here, CTO of BitMEX - we're a crypto derivatives exchange that's been open since 2014. When we founded BitMEX, we went through a long period of discussion among the partners on this topic. We were just coming off the low of watching the MTGox heist and it it was obvious that wallets were becoming the #1 point of failure on any exchange.
Ikeboy(sibling comment)'s explanation is as good as you'll get, in my opinion. And you can even skip steps 2 and 3, as we have done for two years on BitMEX.
It's our opinion that customer funds are simply too important to expose to this kind of risk, so we process withdrawals only once a day from airgapped multisig wallets. It's a bear, and it's slow - we developed a few internal tools to make the review process easier and separate signal from noise - but aside from some manual work we've never had a problem.
The #1 surprise, to me, was that customers don't mind the inconvenience. Sure, a few wonder why they can't simply get their funds immediately. But it's explained to them, they seem to appreciate the sensibility of managing this risk seriously. Compared to alternatives like ACH, at least it only takes one day and runs on weekends.
I can't imagine a nightmare worse than losing millions of dollars of other people's money. I hope for Bitfinex's sake that they are able to recover a portion and continue operating. We've spoken personally with much of the team and enjoy the relationship. They - and their customers - don't deserve this loss.
I know in the US you are used to ACH which is dreadful, but in the UK everyone is used to faster payments which allows you to send £100k to anywhere in the UK, often fee free, within 2 hours. Usually it's actually within a few seconds.
Waiting a day for a transfer now seems hilariously outdated now to me.
I understand there are other benefits to bitcoin but something seems inherently wrong if transfers have to be intentionally delayed so long to make the system more secure.
I know in the US you are used to ACH which is dreadful, but in the UK everyone is used to faster payments which allows you to send £100k to anywhere in the UK, often fee free, within 2 hours.
My understanding is that the inconvenience of ACH is by design - they are security delays. If you need to send money from one account to another instantly, you use a wire. If you have the amount of money in your account that is typical of people that need to send wires, they are often freely included with your higher-end checking account. Wires send the money instantly.
They send instantly after you sign the document and fax it back, after the bank manager approves the large amount, etc. It still takes a few hours to do the paperwork in my experience.
A good bank will allow you to do wires directly from their internet banking suite (commonly requiring 2-factor auth before using their wire-related tools).
I commonly see wires hit within ~30 seconds of hitting the "confirm" button, and almost always within <=5 minutes, and that's between separate US banks.
'Faster payments' for me has a sort of 2FA: first payment to a given recipient causes the bank to call me (automated, not human), and I have to enter the code read out over the phone in order to process the transfer.
Just putting some kind of velocity protection on the BitGo side could have had the same effect - if transactions from a client are running a few deviations above normal then start to quarantine until confirmation from client they are valid
1. Have a cold wallet on an airgapped computer with 99% of your funds.
2. Have a warm wallet on a computer with a firewall that only connects to 3, with 1% of your funds
3. Have a web-facing server that sends back commands to 2 when it needs to send money.
2 alerts someone when it needs more money, who then goes to the cold wallet and transfers some, creating the transaction offline and using a new USB key to transfer it to a computer with internet.
The last step can also require multiple people if desired.
When that person goes to the cold storage wallet, the only trustworthy information they have (assuming compomise of the online system) is how much money they are transferring. This means that this arrangement succeeds at making a trustworthy rate limit and nothing more.
If I wanted to make a trustworthy rate limit, I'd have the machine from (1) not airgapped, but connected by a serial (unidirectional) line to the machine from (2) along which it would periodically send signed transactions sending some of the money from "lukewarm" storage to hot storage, and sending change back to the very same "lukewarm" storage address. The machine from (1) can then implement a rate limit.
But then a compromise of 2 and a zero day remote attack can exploit 1. 1 is offline so no attack not involving insiders can affect it.
Edit: actually nvm, didn't get the part about unidirectional. I don't deal with networking but I assume that's possible physically and there's no way to reverse the flow?
"We don't use cold storage for bitcoin, since our implementation with bitgo we've used segregated customer wallets so that each user has their own bitcoin wallet." [0] This was hubris / stupidity.
No, it was US futures trading regulations (though arguably that's the same thing). For regulatory reasons they had to provide "actual delivery" of the bitcoins in question, and the CTFC held that cold storage didn't count as "actual delivery". See http://www.cftc.gov/idc/groups/public/@lrenforcementactions/...
The exchanges are not sophisticated at all. No single exchanges have opensourced their wallet technology. Kraken, Bitstamp and Bitfinex are using BitGo, a private source solution. The first would be to opensource a enterprise grade wallet which can be used for exchanges. And that's exactly what I'm working on. Then develop the procedures to secure funds with operational professionalism. Use of multi-sig is standard, but its not enough. Cold-wallet and transaction monitoring, deposit insurance, in combination with on-chain will develop over the next 1-2 years to keep deposits safe.
I've just run across this the other day, it is a set of guidelines for securing cryptocurrencies: https://cryptoconsortium.org/standards/CCSS . It is about the core crypto asset concerns, not about how to protect a web server.
To start with, store most funds offline. A bank run (or hack) should be subject to intervention by a human. Contact customer if there is any doubt. Implement checks and limits for the remaining balance. Regularly audit and publish cryptographic proof you are in control of funds.
> Regularly audit and publish cryptographic proof you are in control of funds.
What good is that proof of control? Literally the next second it could be drained and no one would know until the next scheduled proof of control. I've never been sure what publishing proof of control is meant to protect against exactly.
It would protect against what happened with MtGox -- if, after losing some but not all customer funds, they tried to keep running the site to make back the money. It would protect you from putting money into a site that is already bankrupt.
If privacy is not a concern, you can just publish a list of your liabilities at a given time. Each account holder can then verify the their own listing, calculate the total, and compare to the proven reserves.
There are more sophisticated schemes that allow you to check the amount in your account, and verify that your account was included in the total, without seeing the size of other accounts: https://iwilcox.me.uk/2014/proving-bitcoin-reserves .
Maybe create a new address type on protocol level, where transactions from that address can be reversed within 36 hours with backup key(s)? Normal users wouldn't accept from these addresses but should be good enough for most exchanges for purposes of cold storage.
Though in this case it looks like it was a hack on a third party provider, which is why relying on third parties for core functions is not a good idea. Why would Bitfinex use that provider instead of a multi-sig cold storage is anybody's idea.
Also, looking at reddit, they moved to a new datacenter recently. So could be that a datacenter employee stole code and database and then submitted the withdrawal requests from the stolen code to Bitgo. Not even sure how to protect against that.
That's a sizeable chunk of the 21m BTC total that can ever be in existence...!
Are the destination wallet addresses for the heist visible in any block chain explorers? Would it even be possible to mix those coins or will they be impossible to spend as tainted?
yeah sure it is possible to spend that amount of tainted coins, and yes everyone knows where they are.
you can't send the tainted coins to an exchange or a bank, because they risk getting seized and your identity compromised
you can give someone the private key on a flash drive for goods, services, or an army.
you can move varying amounts to different addresses each for a different flash drive, to exchange for goods, services, or an army.
physical transfers wouldn't show up on the blockchain.
you can also mix them over time for whatever amount you need. $50,000 a day wouldn't be impractical.
and you can also build up your own bitcoin infrastructure yourself, start another bitcoin casino and all the players get paid out in your otherwise tainted coins
do an ICO for a new project and fund it with all your tainted coins, and others. most crowdsales - like Ethereum's - have one or two large investors amongst the little amounts everyone else contributes.
honestly all the transparency perks of the blockchain is just to rosy it up to regulators. but it undermines any and every capital control in existence.
That's a very nice remark by someone who clearly have a deep understanding of the BTC ecosystem.
(no sarcasm here, I totally agree that's what the ecosystem is like.)
> you can give someone the private key on a flash drive for goods, services, or an army.
But for this part, what if the one who gives out the private key moves the coins later? That's not a finalized transaction at all if both side have the private key.
Conceptually It can be alleviated with having the coins in multisig address where a third party creates one of the signing keys and the original thief retained one, and ideally the second recipient also had a third signing key. Still have the problem of getting the third signing key generated in a way that required no trust, in advance
If the accusations about how the entire exchange was built on a stolen ruby-on-rails source code leak is true..! Let's just say this is the money quote in that thread:
> "There is a good story here, waiting to be written by some investigative journalist. Perhaps we will have to wait for some catastrophe before that happens."
This is how modern heist look like. You do not need guns anymore. Get keyboard, access to internet, learn, learn, learn and then get ~60 mil euros in one evening without going out of home stealing somebodies bitcoins.
And it's not directly physically violent! One could also argue that the people you're stealing from are mostly financial speculators too if it made one feel better.
I think it's time to give BitSquare a go. Distributed exchange, FLOSS, no single point of failure. Not suitable for fast trading due to transfer of real money on every trade, but totally fine if you just want to buy or sell cryptocurrency.
Part of the beauty of start-ups is that anyone can start one. You don't have to have a 20 year vetted resume, a college degree, or extreme wealth. However this is a boom-a-rang that comes around full force when people expect financial and medical services being offered by start-ups to have the same quality as those created by people with 20 year vetted resumes, college degrees, and extreme wealth.
Honestly after the 2008 crash those highly résuméd old people start to look as untrustworthy as anyone, given a bunch of Respected Financial Institutions appear to have accidentally tanked the global economy.
I mean, liable for that much loss is going to be pretty meaningless at the end of the day because none of the actors would be able to cover the liability.
But that money wasn't really stolen from the fed. It was stolen from somebody who had a fed account. We know exactly who lost money, and the answer isn't everybody.
Yes, but impact of Bitfinex far, far greater. It represents about 0.75% of all Bitcoins. If you include only paper currency, there's almost $1 trillion in circulation (about 4x that if you include coins). I assume amount on deposit is much higher. However, being the most generous with the numbers, the Fed hack represents 0.002%.
If you're talking physical cash, a person would have to get to the physical location to take it (as opposed to being available to everyone in the world with an internet connection).
If you're talking digital cash in a bank, most banks have a form of insurance that will cover your losses (for example, most US banks are FDIC insured and cover up to $250,000 USD in losses).
Stock assets may be the closest comparison, as brokerage firms aren't backed by an independent agency, and losses that occur from cyber-theft would only be reimbursed if the firm wanted to.
Stock trading accounts in the US are backed by the SIPC up to $500k (even for non-US persons). This protects you from an all-out insolvency of the institution, which would happen if somehow they had all their money stolen by hackers.
But it does not protect you from hacking of your individual account. If someone tricks your broker/custodian into selling your stocks and wiring them the money, SIPC (perhaps surprisingly) will not save you.
Obviously you can't go with "You can trust us, we know what we're doing"
You could find a party that is endorsed by someone going "You can trust them, They know what they are doing, Trust us on this, we know what we're doing"
But that just moves the point of concern.
Is there yet any "You can trust them, if we are wrong about that we will cover your losses" insurance. (even then how can you be certain they will follow through)
Surely you wouldn't store your cash in a bitcoin exchange? It's not a bank.
With bitcoin you don't even necessarily need a third party, a hardware wallet could do just fine. That can be stored in a safety deposit box if you feel like it.
>Is there yet any "You can trust them, if we are wrong about that we will cover your losses" insurance. (even then how can you be certain they will follow through)
While you can certainly insure anything if you pay enough, I don't think there's anyone publicly offering that in the crypto space. But then there doesn't seem to exist a similar mechanism for USD accounts of any significant size either.
"quis custodiet ipse custodies" (who guards the guards themselves) by Juvenal in the first century seems to be the root cause of so many modern issues - from finance, to politics, to automatic server monitoring.
I'd say it's a little harder than not losing cash. If you put cash in a safe, you can be confident that an attacker can't take the cash without getting into the safe. If you put bitcoin in a safe, an attacker can take it without ever getting into the safe if you happened to forget about a copy of your private key somewhere else.
Dealing with nondevelopers, never say "string". Did that once and the person on the other end of the phone was obviously confused. After 2 seconds, realized how bizarre it sounded.
I have no skin at all in this game, but at this point I have to wonder why anybody is still investing in this, it's been one scam after another every six months for as long as BitCoin had been around. Is it all just the greater fool theory?
The thing with the greater fool is: they get the fuck out when the investment goes cold. They're not interested in calm, orderly profit, they're interested in action. By definition, they're irrational.
Leaving aside the fact that (what I call) the semi-intrinsic value of BTC is designed to increase over time, when the end is in sight either because of security snafus or actual source exhaustion, the greater fool will go elsewhere, leaving the lesser fools holding the bag.
Nobody seems to be handling BTC correctly, and nobody seems to agree on the correct way to handle it. That leads me to my own thesis: if a currency is so convoluted to handle that consensus can't be reached on proper handling of escrow funds or deposit balances, it's not a currency, it's just a long-running argument.
Bitfinex uses BitGo for multi-signature (MultiSig) transactions. 2-of-3 signatures must be present for user funds to be released.
Keys present:
- Offline key held by Bitfinex
- Online key held by Bitfinex to initiate user withdrawals
- Online key held by BitGo to confirm user withdrawals are within constrained limits in a set timeframe
zanetackett, Product Development of Bitfinex, confirmed that Bitfinex's offline key was not compromised. The attack was also not internal [1]. Another set of comments also suggested that BitGo limits were set in place by Bitfinex [2-3].
The automatic limits are designed to constrain BitGo from signing any transaction from Bitfinex that are irregular in volume or exceed a set amount in any rolling timeframe. Somehow they were bypassed. What we have currently suggests that the limits were too large or that BitGo was not enforcing the limits. BitGo and Bitfinex are also separate established entities, so that both of them being compromised for this attack is unlikely. An improper setup between Bitfinex and BitGo is more likely.
[1]: https://www.reddit.com/r/Bitcoin/comments/4vtuxo/bitfinex_se...
[2]: https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_sh...
[3]: https://www.reddit.com/r/Bitcoin/comments/4vtuxo/bitfinex_se...