[–]nullc 14 Punkte 3 Stunden zuvor
Because the quotes are irreparably messed up I'll write up a long form explanation:
Some background: MtGox runs custom wallet software.
This is a reasonable and common practice for a service of its size and nature.
Getting a wallet implementing right isn't easy as there is very little room for error, much like the rest of the Bitcoin system.
Some have criticized their use of custom software here but it is a reasonable and common practice for a service of its size and nature. The reference client's wallet is basically suitable for small scale single party use. I would not recommend something like MtGox use the reference node wallet, at least not without a healthy layer of abstraction on top of it— relieving it of duties harder than key management and chain monitoring— or otherwise improving it greatly.
(For that matter, MtGox's wallet software has caused them fewer concerning problems than some other companies. (E.g. some have completely re-implemented the Bitcoin protocol, incorrectly, and exposed it to the outside world and suffered numerous local blockchain rejecting glitches). Though its certainly taken Gox a fair amount of time to sort things out.)
I first heard people reporting stuck transactions back in ~September. I looked into it and determined that Mtgox was spending immature coins. Freshly generated Bitcoins (from mining) can not be spend until they are at least 100 blocks deep in the blockchain. This prevents the funds from vanishing forever if the chain reorgs. I pinged magicaltux and after a couple tries got ahold of him. I think they also wasted some time on dead ends trying to resolve this before the actual nature of the problem was brought to their attention, e.g. raising their transaction fees with a mistaken belief that their fees weren't high enough.
Mtgox wasn't tracking if the coins were freshly generated or what their height was in their software. Including this data would apparently be a non-trivial change, and for high risk finance software even a trivial change takes a lot of work. I suggested a workaround (basically, just try to spend the oldest coins), and as far as I know they implemented it and it was effective.
They continued to have problems with stuck transactions after, and further analysis revealed that they were producing transactions with excessively padded signatures. A minor tangent is required here:
There is a design flaw in the Bitcoin protocol where its possible for a third party to take a valid transaction of yours and mutate it in a way which leaves it valid and functionally identical but with a different transaction ID. This greatly complicates writing correct wallet software, and it can be used abusively to invalidate long chains of unconfirmed transactions that depend on the non-mutant transaction (since transactions refer to each other by txid).
This issue arises from several sources, one of them being OpenSSL's willingness to accept and make sense of signatures with invalid encodings. A normal ECDSA signature encodes two large integers, the encoding isn't constant length— if there are leading zeros you are supposed to drop them.
It's easy to write software that assumes the signature will be a constant length and then leave extra leading zeros in them.
In order to eventually remove this malleability flaw we've been gradually tightening the rules that govern what transactions nodes in the network will consider valid when they relay them or mine them. In Bitcoin 0.8— after months of work chasing down software authors to get them to fix their bugs transactions with these invalid encodings were no longer relayed.
This caused some problems for a few things.. For example bc.i's iphone app— BC.i itself had been fixed long before but they couldn't update the Iphone app without fear of triggering another review by Apple. Eventually this was just worked around on the server side by mutating the transactions produced by the iphone wallets. (And is moot now, I guess!).
MtGox also had problems with occasionally producing invalid signatures. This would normally be a simple fix. E.g. here is an example where I fixed this type of issue in some python wallet code I've never used (but saw a lot of people were copying):
https://github.com/jgarzik/python-bitcoinlib/commit/4c64603ab60b0fa23c51090b3112be2f163aeeacBut as I said before, in high value systems like Mtgox, even simple fixes aren't simple and it took them quite some time to deploy a fix. However, I believe that it is actually fixed now.
My current understanding and inference is that the remaining issues are because while MtGox was producing transactions of the bad form that the network won't relay anymore— some people decided to help out by 'fixing' these transactions like BC.i did for iphone users— making the signatures normal and broadcasting them. Of course, the new transactions— while functionally identical— have different TXIDs.
The difference here is that the MtGox wallet software appears to have not handled this case gracefully at all, and apparently simply wouldn't notice transactions that it "didn't make" spending its own coins.
As a result the Mtgox wallet believed some coins were available for spending which really had already been spent and it began double spending those inputs. This may have interacted particularly poorly with the earlier workaround I mentioned— trying to always use the oldest available coins— if they did implement that workaround.
Worse, some of this may have resulted in users getting paid multiple times and could have been intentionally triggered with that end in mind if someone helpfully fixed some transactions and then noticed they got paid twice. (I think this is unlikely to have caused large losses, before people run off worrying about that, both because of the reuse of the oldest inputs and because of the hot wallet/cold wallet split).
At this point they likely have an accounting mess to clean up— figuring out who did and didn't get paid now with none of the txids matching. Cleaning that up will be somewhat tricky E.g. say there were three payments of MtGox coins to 1Apple in the block chain... and three users that attempted to pay 1Apple, and MtGox's records thinks that only one went through.. etc. So software will have to be written that matches up transactions with their mutants in order to figure out what went where.
I am not personally concerned— at least not by any of the details here. MtGox's slow speed at resolving these sorts of issues and poor communications are not terribly inspiring. They seem to be horribly short staffed— but competent and trustworthy people in this space may be hard to find: The regulatory morass of that business is sure to make many steer clear.
The claims that the delays indicate insolvency strike me as just hysteria: the technical background doesn't support this conclusion, and there may be a bit of opportunism at play from people who want to manipulate the market too. Don't get me wrong: I have not seen their books: Gox may well have financial problems— though with their income its hard for me to see how— but if any problems like that exist they're not being indicated here.
Of course, none of this suggests anyone should be happy with the service MtGox has been providing, but our anger should at least be well informed.
