Why did BitGo allow 120,000 BTC to be withdrawn from thousands of users in 3 hours? This is obviously not normal market operations. Where are the human fail safes?
There’s no way Bitfinex was stupid enough to allow unlimited daily withdrawals, so the hacker must have been able to change this online with the compromised API keys. (Either that or BitGo’s servers were compromised – but they said they weren’t!!)
If I’m wrong and BFX had unlimited withdrawals setup, then thats really dumb. And BitGo would be stupid for telling them “Yeah, we don’t see anything wrong with unlimited withdrawals, we’ll just sign everything blindly, no problem!” It would be no different than using a 1-of-1 hot wallet — why would they bother paying BitGo any money? Just false sense of security for customers? Thats bad.
Why is BitGo scrubbing their website, around pages about their insurance policy?
THEY INTENTIONALLY LEFT THE DOOR OPEN – look at who is involved.. ex google Microsoft and aig employees what do you expect! CFTC forces them over to their AIG buds and wammo here ya go.. welcome to the banksters world of criminality.
If any of you think any system allow ‘continual AUTO SIGNATURES on mutli sig’ systems I have a bridge to sell you!
Why have they given up so easily on catching and punishing the thief, declaring that “the Bitcoins are gone”? The withdrawal addresses are right there on the blockchain, so they need to be publicized and blacklisted, but they seem uninterested in doing that.
The only retaliation against unauthorized transactions currently is the ability to double-spend and hope that the 2nd transaction spreads faster than the first. This usually is a futile effort, as there is a very short time between the original transaction and the moment a retailer can see the 2nd transaction conflicting with it.
The other forms of delay, that I know of, can be done in 2 ways: First, a trusted intermediary can delay the transaction, but assure the seller that they will get paid. Escrow services and credit card companies currently do this, for a fee, but it also gives them the power (and sometimes the legal obligation) to stop transactions, against the wishes of both the buyer and seller.
The other option is to have either or both parties confirm the transaction later. A bitter buyer could deny it after the purchase, or a cheating seller could confirm it despite not delivering the products. If they disagree, someone has to arbitrate that disagreement, and we’re back in option 1.
The only way around this is to have a 2-phase transaction in which the sender confirms in both phases. First it is sent, then the parties sit around for a while to make sure nothing bad happens. Then they both confirm it, as the seller delivers the goods to the buyer.
This other system is just a way of designating coins for an upcoming purchase and announcing it, and a user would only catch a fraudulent spend if the delay was at least several hours (probably an entire day). I suppose this could give a chance for the sender to provide a 2nd authentication, which could be helpful, but it also slows the system significantly. This means uploading a transaction to the network, letting it spread, letting it sit, and then re-signing and re-spreading it across the network. That doubles the bandwidth requirement, and greatly increases the buffer of pending transactions.
That’s still a good idea for large transactions. The biggest flaw, to me, is that it creates a system with 2 kinds of transactions and thus doubles the complication of any other software that uses bitcoin. And requiring a 2nd key to be used only on rare occasions is a bad security practice, as those rarely-used keys tend to be lost or forgotten.
Many of the Chinese exchanges have a 2nd password, called a trade password, that needs to be used on each transaction; even after the user has logged in. That’s a bit more like a pre-emptive version of this, as a properly implemented system would require it before releasing the coins. At the end of the day, it’s just an extra signature requirement.