Bitcoin withdrawal processing suspended (opens in new tab)

Bitcoin "Banks" (read exchanges) exist only through their reputation. They can die within a few days as shown from MtGox. This is the way traditional banks should operate instead of being propped by tax payers so that they are allowed privatize gains and socialize losses.

Regulation would have provided that they would have gotten their funds back/in a timely manner.

Lack of regulation means that others learn from their misfortune.

When it's a bank, the bug and liability is on them

Does using Bitcoin require one to join the libertarian hivemind?

> not greedy government bureaucrats waiting to be bribed

Instead of greedy speculators who are willing to pump and dump or crash the economy to make money off of the ignorant?

You are guaranteed $100,000 in free insurance when you deposit your money at an FDIC-insured bank.

No matter what bugs, attacks, malware or whatever happens, the US Government will pay you back your deposited money, to the fullest extent that it can.

If you don't see why this is useful, maybe you need a sanity check.

A "truly free market" is like a unicorn, it only exists in fairy tales. In reality, Somalia is probably the closest you'll come.

I wouldn't call it stupidity. It's like saying that the internet wouldn't last very long without ISPs.

Without many real places to deal with USD <-> BTC, then of course it will be hard to deal with the cryptocurrency (the passage is needed to allow for a transition period in currencies).

How do you self-contain anythng in this world of interconnectivity?

If you understood cryptocurrency you would understamd that their success is not measured in the price point. That is the most marketable aspect so that is what you know, the utility and use of the protocol is as good if not a better measure of their success. the relative speed with which issues are identified and resolved speaks to the success of the protocol not the daily/weekly highs and lows.

That doesn't make any sense. How do you obtain a new currency without an exchange?

Why should they be self-contained and not affected by exchanges? An exchange is just a market where you trade one good for another, where both the goods happen to be currencies (fiat or crypto). It's like saying that a market where you trade Bitcoins for domain names or Bitcoins for food is stupid.

Because of the massive (and justified) collapse of confidence in everyone building web servies for this space.

It shouldn't surprise anyone that after months (years!) of BTC services absconding with millions of dollars worth of users money and now the exchanges starting to collapse in a similar fashion (users can't get money out) that the wider user base of bitcoin would begin to default toward not trusting services that purport to store coins 'securely'.

This is bad in the short term as the remaining exchanges prices show, but likely a positive progression in the safe use of crypto currencies going forward--

Yes, confidence in a currency is very important to its survival. The crazy volatility, the inability to withdraw sometimes, the competitors, the uncertainty everywhere. Bitcoin is not helping itself.

If you maintain control of both bitcoin and dollar, how could the exchange function? It requires storage of both.

Gambling exchanges have worked well for years, I wonder if the first serious competitor in the btc exchange space will be from one of those exchanges. (Unlike established financial exchanges they might be willing to risk a reputation hit for getting established in the space.)

I feel I need to clarify some of your points, as they're a little misleading.

> Don't worry, they can't change after about an hour. Well, probably. It would be pretty expensive for an attacker to change them after an hour.

You use the term "pretty expensive" here without qualifying it. Changing a transaction encoded in the blockchain would require outpacing the current hashrate of the bitcoin network. That would require a significant hardware investment, on the order of tens of millions of dollars.

> Well you're already downloading every message ever. Just scan through for one which matches the same from number, to number, and message contents.

You make it sound as if you wouldn't have to do this if you had the transaction hash. You still need to iterate through the transactions regardless. It's just a question of whether you use the transaction hash, or derive your own from the parts of the transaction that are immutable.

Let's make your example a touch more realistic:

Me: "Hey Twilio I created an SMS message but when I try to query it for the results it 404s."

Them: "Has the message been delivered?"

Me: "I don't think so. I'm querying it shortly after I create it."

Them: "How are you querying it?"

Me: "With the message hash."

Them: "Ah, that explains it, then. A pending message may be changed before its delivered, altering the hash. This makes the hash unsuitable for identifying pending messages."

Me: "So how do I identify messages?"

Them: "Ideally you wait until they're delivered, but if you really need to check for pending messages, you can search through them looking for a message that matches on to, from and content."

Me: "That kinda sucks."

Them: "We know, but it's a difficult issue to fix. It's documented in our wiki."

Me: "What if I don't read your wiki, or follow your mailing list?"

Them: "Then should you really be running an exchange handling millions of dollars of transactions?"

Me: "... Good point."

Funnily enough, I've had a similar situation to that in my line of work.

It wasn't twilio, but it turned out that when we submitted a SMS message of over 160 characters, the provider split it into 160 chunks and sent out as multiple SMS.

So far, so normal. But what happened when the first chunk sent successfully and the second chunk failed?

We got back a notification to say "MessageID: 4ACB-etc Result: OK" but the customer never got the message, and scanning the report on the provider's site showed the customer number, time and message as having failed.

But then the representative agreed it was a problem and set out to fix it rather than blaming our dependence on the ID!

This sums up my view on these recent turn of events.

I find it quite ridiculous that people are trying to lay the blame on not reading an obscure wiki page. I remember reading much of the bitcoin wiki myself and never seeing ANYTHING about not relying on transaction IDs. The API list doesn't even warn you about it.

Why bother returning a transaction ID if it is spoofable? That is simply misleading.

I guess it shows you how how biased all the bitcoin backers are.

For those who seek to understand, rather than just mock with exaggerations:

You don't have to scan all transactions: only those from a firm reference-point of available-funds state, essentially the same point that was used to compose the outbound transaction.

Robust software already has to examine all incoming confirmed-in-block transactions for whether those transactions have consumed prior funds. If they have, even if the local software had as its design goal exclusive control of those funds, the local software must adapt to the new information. (Given the possibility of backups/virtualization-clones/private-key-exports, software must always be open to the possibility another node elsewhere has spent pending funds first.)

So safety against this particular mischief is possible with the same practice that's necessary for other reasons: it's not involved extra work.

Also, it's not "an hour" that lets a node know when it can rely on transaction-state, but block-confirmations, a precise and observable transition. One block is almost always enough, but each additional block adds more certainty. Still, all Bitcoin software already needs to handle occasional orphaned blocks and short forks, so being sensitive to periods of uncertainty is a essential part of all implementations, not extra work because of this one gotcha.

A better analogy than Twilio would be commercial payment systems: there you need to systems that are checking for weeks or months for chargebacks or reversals.

But an even better analogy than proprietary pay-per-use payment systems is SMTP or BitTorrent. The system is an emergent mess anyone can plug into. There are a lot of sharp edges, and even with great care, you're going to hit some painful and costly bugs. Those building billion-dollar businesses on such systems need to be experts, and will still take some arrows, but each incident that doesn't kill the software/business stacks only leaves them stronger.

> What they should have done was waited an hour then done an O(n) scan of all transactions globally in history to find the transaction by inspecting for parameters which exactly matched the ones they provided.

Oh, you mean the scanning they have to do already, to verify "all transactions globally in history"? Inspecting all parameters on all transactions since the genesis, like you'd already have to do to verify they are not stealing or creating money from nothing? The inspection you have to do just to locate even the same transaction you submitted to the network yourself, to verify it was accepted? And you have to spend like 10 whole seconds of CPU time doing this, per ~10 minutes that a new block comes out, verifying the transactions from the last 10 minutes? Golly, that is sooooo much more onerous than just running the blockchain securely! /sarcasm

I'll agree that it's embarrassing, misleading, not documented well, and not gracefully handled by the community now that everyone points their fingers at each other. But you are deliberately making it sound worse by re-describing standard parts of the bitcoin protocol, as if they are new requirements in order to get a sane ID. Anyone writing financial software should be more than capable of quickly adding a few function hooks into the existing process to get a deterministic normalized ID, and the amount of extra computing resources is negligible compared to what you already have to do, just to use bitcoin safely.

I keep asking this over and either I'm missing something or no one knows the answer: The bitcoin devs keep saying that the malleability is a known "feature" since 2011 and that it's MtGox/Bitstamp's problem for searching for transactions based on tx ids. But what the fuck is the point of a tx id, practically speaking, how is it useful at all given that it's malleable?

Now THAT is the ELI5 explanation I was looking for. This analogy is so much clearer than all the articles!

btw, why is the transaction ammount a real number in there? Wouldn't it be clearer to use an integer multiple of whatever the lowest denomination of bitcoins would be?

Comment of the year award. Seriously.

I normally enjoy reading your posts here but this one I have to say I find a bit gleefully FUD-tastic. Given that you describe BitCoin as "magic Internet money" [0] I can't help but feel you simply rejoice in BitCoin failures as vindication of your belief that crytocurrency will never work.

There seem to be two prevailing extremes of opinion which appear a lot on Hacker News and many other places, as extremes are wont to do while those in the middle don't feel strongly enough to contribute. Those are 1) BitCoin will replace government control of money and fix freedom, dude! and 2) What fucking morons, can't wait until you crash and burn.

I love this whole thing. It's fascinating, it's an interesting solution to a problem, and watching DogeCoin take off is fun to watch. In my opinion, BitCoin is kind of like when a naïve programmer decides to rewrite an existing library themselves, and comes up against the brutal reality that led the original developers to the compromises and apparently necessary hacks to get the thing working. The analogy here being regulation, insurance, all that jazz. It's educational, and I haven't been this interested in a technology for a while.

I'm picking on your reply here because it is one of many that exemplifies a "haha told you so" rather than really digging into the interesting technical and sociological aspects.

* Message IDs from one API do not equate to IDs from the other, so your example is a bit flawed; there's no way to check with Twilio except the ID.

* Is "ID" even the term used? I don't know for sure, but "Tx Hash" seems to be more widely spread. [Edit: patio11 edited his comment while I was typing mine; I withdraw this point!]

* "It's on our wiki noob" - someone running the 3rd largest exchange should hardly be a "noob"

* "O(n) scan of all transactions globally" - that's not particularly hard, nor is it necessary (why scan all transactions from all time?), nor is it unexpected (the entire thing requires everyone to have the complete ledger, so you have the data anyway)

There are valid points to be made that the BitCoin protocol needs improvements, and these are even acknowledged by the core devs. This whole situation is a bit ludicrous. But I wish we were talking about "what have we learned", not "told you so".

When it comes to BitCoin, the conversation seems to be full of radicals and optimists when success happens, and gloaters when it doesn't. I don't feel either add to the conversation, we could be talking about how to improve this as a currency or (as I believe the long term actual application to be) how this can influence distributed trust, especially important in the current climate.

[0] https://twitter.com/patio11/status/431347845031940096

Hey, at least when there's a bank run I (well not me, since I have no money in US banks) will see my federally insured $20k or whatever, even in the case of collapse.

Politics is often about finding bad solutions to worse problems.

If you have much trust in independent audits, I guess you've never taken part in one!

Auditors generally have no incentive to rock the boat, and might have a disincentive in the form of losing future business. And even if they're really thorough, most auditors are only in for a few days or weeks and don't have time to go through things anything like as thoroughly as people who work on them full time. And even if they're really thorough and have the time to go through everything with a fine-toothed comb, insider threats can be undetectable, like if the guy preparing the cold storage wallet to put in the safety deposit box makes himself a copy.

The only audit of an exchange worth a damn is the audit undertaken by reputable insurers who will guarantee my entire deposit.

Regulation gets me neat little things like, say, the FDIC.

> What you want is an independent audit, not regulation.

Maybe even some regulation requiring such a thing?

Think about what you just said there. Imagine you are talking about governmental regulatory agencies and banks and re-read the same sentence.

The Bitcoin protocol is the Satoshi client; the Satoshi client is the Bitcoin protocol. No Bitcoin protocol exists outside of the single source of truth, which is "how does the Satoshi client actually operate?"

Both exchanges use the JSON/RPC interface to the Satoshi bitcoin client. That is the One True Way to use Bitcoin to develop Bitcoin-consuming applications. To do otherwise is madness. (I've seen explanations that Mt. Gox was using a custom client, but I believe they mean "Mt. Gox was using a custom system which took care of bookkeeping for itself, because the Satoshi client cannot operate thousand of wallets in any sane fashion, but used the Satoshi client for interacting with the Bitcoin network.")

The Bitcoin RPC interface exposes many methods. I don't have intimate knowledge of which one these exchanges were using, but since they all have similar issues, let's assume they used sendtoaddress.

The message signature of sendtoaddress is (pseudo-code):

   #returns transaction_id
   sendtoaddress(from_account, to_bitcoin_address, amount, optional_message)  

The mistake which both exchanges made is they assumed transaction_id is the same transaction_id used for gettransaction(transaction_id). It is. If you send a transaction, wait an hour, and then get it by ID, that will work.

But it isn't. Transaction ID means absolutely nothing. It can be changed by any party, worldwide, for up to one hour after the invocation of sendtoaddress. If you use gettransaction(transaction_id) and it returns nil, that does not prove that the transaction you previously created did not succeed correctly. You should not attempt to retry the transaction until first verifying that you have all the coins you started with and that the recipient does not have some of your coins. You can conveniently do this with an O(n) scan over all Bitcoin transactions ever. (Someone pointed out to me on twitter that it isn't O(n) if you have your database indices set properly. Well, yeah, true.)

You'll need to know what addresses you actually sent from, which is obscured by the sentoaddress API described above, for that scan to succeed, so essentially you're going to reimpliment much of the Satoshi Bitcoin client, particularly around the area of wallet management. Don't reimpliment everything, though -- down that path lies madness. Also, try not to make any bugs anywhere, particularly not the kind which only show up when someone tries to steal from you.

Good luck!

FWIW it's an error in the BTC reference implementation so it's an easy error to make

>(or that a lesser amount was withdrawn)

As I understand it, this is not correct, the new tx must be functionally identical to the old one (same inputs and outputs), just with a different txid.

Someone correct me if I'm wrong

it is nothing like a bank run.

A bank run is where the bank does not hold enough money to cover everyones deposits. Bitstamp have enough BTC to cover everyones deposits they just are delaying withdrawals for 72 hours. Think of it like you rbank telling you you need to wait 3 days for a transaction to go through, not that unlikely and in fact quite common in traditional banking. It seems longer in bitcoin though because of the usually quick transactions.

Well, 2 identical transaction not resulting in the same hash is more a bug in the bitcoin implementation, than a misunderstanding in the protocol, imo

The Coinbase CEO mentioned that this wasn't them being discussed there, which begs the question who else it could have been.

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

>unless you're trading

Not even, since Coinbase is a webwallet not an exchange... People generally keep them there because its an easy way to manage/spend them (esp on a phone)

I stand by that comment. I'm disappointed that Bitstamp didn't take this issue into account when designing their exchange, but unlike Gox, their communication about the issue has been very good, and my confidence in Bitstamp remains unshaken.

Also, it appears that the Bitcoin network is under global attack by some large entity, so blame for the current exchange issues lie ultimately at the hands of some attacker who doesn't like Bitcoin, or wishes to plunge the price.

I know. I'm mocking the ridiculous thread yesterday that was so insistent that was a factor in the Gox problems.