MtGox blames Bitcoin protocol problem for BTC withdrawal issue

[wolongong]

So, then how do I easily spot this with a reasonably recent standard client?

Using QT client.  0.8.0+ works fine, probably older clients as well.
[snip rpc stuff]

That sounds doable indeed, thx! Never thought of saving more than just a txid, then again, I'm not running a shop worth stealing from (yet).

[1714936709]

1714936709

[1714936709]

1714936709

[1714936709]

1714936709

[1714936709]

1714936709

[1714936709]

1714936709

[DeathAndTaxes]

So, then how do I easily spot this with a reasonably recent standard client?

Using QT client.  0.8.0+ works fine, probably older clients as well.
[snip rpc stuff]

That sounds doable indeed, thx! Never thought of saving more than just a txid, then again, I'm not running a shop worth stealing from (yet).

In theory you don't need to save more than just the txid, you should be able to look it up the rest as/when needed.  However I didn't code bitcoind, I don't know every event which could result in it repository changing.  As someone with a background in enterprise "database/backend stuff" (official title) that doesn't leave me with a happy feeling.  I don't like the idea of relying on data which a third party (bitcoind) has direct access to.  If I put the data in a repository and strictly control access then it makes for a more controlled environment and that makes me more confident that there will not be any unexpected changes.

It may not be necessary, I just have never traced every possible condition that might result in the bitcoind changing information in the wallet that I may be unaware of.

[wolongong]

So, then how do I easily spot this with a reasonably recent standard client?

Using QT client.  0.8.0+ works fine, probably older clients as well.
[snip rpc stuff]

That sounds doable indeed, thx! Never thought of saving more than just a txid, then again, I'm not running a shop worth stealing from (yet).

In theory you don't need to save more than just the txid, you should be able to look it up the rest as/when needed.  However I didn't code bitcoind, I don't know every event which could result in it repository changing.  As someone with a background in enterprise "database/backend stuff" (official title) that doesn't leave me with a happy feeling.  I don't like the idea of relying on data which a third party (bitcoind) has direct access to.  If I put the data in a repository and strictly control access then it makes for a more controlled environment and that makes me more confident that there will not be any unexpected changes.

It may not be necessary, I just have never traced every possible condition that might result in the bitcoind changing information in the wallet that I may be unaware of.

Maybe this can help a little if there are no gaping holes in it https://github.com/sipa/bitcoin/commit/1173eef630783a822d9a709cfbc22ba91880231e
Now sendtoaddress just returns an id for what you did that might be altered by the distributed bookkeepers before being fixed into the ledger.
This getnormalizedtxid seems to give you something short to recognise your tx back no matter how long someone put in on an anvil and banged at it.

 

[mb300sd]

I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.

[phzi]

I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.

The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

[mb300sd]

I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.

The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.

[phzi]

I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.

The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.

Ah yes, using the actual txouts, sure.  Still, maintaining this extra database is unneccesary.  The BTC protocol already provides the means to do with without extra data.  MtGox has also acknowledged your suggested technique as a possibility, and is trying to avoid that overhead.

[mb300sd]

I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.

The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.

Ah yes, using the actual txouts, sure.  Still, maintaining this extra database is unneccesary.  The BTC protocol already provides the means to do with without extra data.  MtGox has also acknowledged your suggested technique as a possibility, and is trying to avoid that overhead.

1 more column in a table and a couple extra lines of code is overhead? Instead they cause a massive crash by blaming it on the bitcoin protocol.

But knowing gox they would have implemented it wrong on their production server and screwed things up worse.

[phzi]

I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.

The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.

Ah yes, using the actual txouts, sure.  Still, maintaining this extra database is unneccesary.  The BTC protocol already provides the means to do with without extra data.  MtGox has also acknowledged your suggested technique as a possibility, and is trying to avoid that overhead.

1 more column in a table and a couple extra lines of code is overhead? Instead they cause a massive crash by blaming it on the bitcoin protocol.

But knowing gox they would have implemented it wrong on their production server and screwed things up worse.

Heh, not saying their claim of overhead is reasonable, just re-stating it.

And yes... Gox seems full of fail right now.  I mean come on, throw a fix together and get your business going again, and then work on core protocol changes.

[jl2012]

I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.

The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.

So this is essentially what gox is proposing

[il--ya]

I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.

The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol.

It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal.

So this is essentially what gox is proposing

They are not even using reference client, why the hell they are fucking everybody's brain? Your system failed to track transactinos - so go and fix your system, and then go ahead and propose a patch in the reference client if you believe this is necessary/reasonable. I don't understand why core developers even take this seriously. That's like negotiating with terrorists - just encouraging them.

[hostmaster]

Basically they are saying "We are not to blame. There is huge security issue in Bitcoin protocol!!! affecting whole bitcoin network"

Why to blame they make tons of money they can fix it by themself???

[mp420]

Basically they are saying "We are not to blame. There is huge security issue in Bitcoin protocol!!! affecting whole bitcoin network"

Why to blame they make tons of money they can fix it by themself???

I expect it to take a while for the reality to sink in and MK to swallow his pride and pay someone to fix/rewrite their custom client.

It's the same thing all over again as it was with the trading engine last year.

[il--ya]

I expect it to take a while for the reality to sink in and MK to swallow his pride and pay someone to fix/rewrite their custom client.

It's the same thing all over again as it was with the trading engine last year.

I believe the reason they are doing that is because they simply don't have enough coins, and they are trying to win time under a false pretext and force their users to sell bitcoins cheaply (to them). They can then sell those coins somewhere else, and buy more, until they become solvent. No matter how shitty their developers are, they should still be able to fix their bug in some shitty way, which would be enough to restart "normal" operation. Also they could provide manual withdrawal option at a premium - but they don't do that. They simply don't have enough coins.

i hope i am wrong.
but i begin to think that they lost so much btc to this issue that they need to buy coins.

seems so..

[mp420]

I expect it to take a while for the reality to sink in and MK to swallow his pride and pay someone to fix/rewrite their custom client.

It's the same thing all over again as it was with the trading engine last year.

I believe the reason they are doing that is because they simply don't have enough coins, and they are trying to win time under a false pretext and force their users to sell bitcoins cheaply (to them). They can then sell those coins somewhere else, and buy more, until they become solvent. No matter how shitty their developers are, they should still be able to fix their bug in some shitty way, which would be enough to restart "normal" operation. Also they could provide manual withdrawal option at a premium - but they don't do that. They simply don't have enough coins.

i hope i am wrong.
but i begin to think that they lost so much btc to this issue that they need to buy coins.

seems so..

I don't think the insolvency explanation holds any water. Even if they have less money than their all deposits are worth, they still have huge amounts of BTC and fiat. And there's no way their day-to-day operations would lose money. They're actually still making a lot of money from the trading fees. And they would make even more money if they'd be wise enough to fix their buggy software.

On the other hand, I do not trust their (or actually, Mark's) overall technical or business competence at all.

[underhood]

I don't think the insolvency explanation holds any water. Even if they have less money than their all deposits are worth, they still have huge amounts of BTC and fiat. And there's no way their day-to-day operations would lose money. They're actually still making a lot of money from the trading fees. And they would make even more money if they'd be wise enough to fix their buggy software.

On the other hand, I do not trust their (or actually, Mark's) overall technical or business competence at all.

+1 to that

[fairglu]

A small exchange doesn't need an automated system to deal with tx mutability.  We don't.  That is because 99.9%+ of the tx will never be mutated.

We'll see who sinks and floats as other exchanges pick up the slack and grow.

I wish you and them all well, but I would be surprised if there aren't other noteworthy casualties.

Damn, looks like it happened

http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/

MtGox was just the first (and biggest) victim. And the wallet is vulnerable due to bugs as well

https://bitcoinfoundation.org/blog/?p=422

Looks like the devs and foundation finally decided to step on it and work together. Which is great.

As an aside, bitcoin is technology, not religion, it's not about what's right or wrong or who is to blame.
Technology is about moving forward, fixing bugs and delivering, once you get entrenched in finger pointing, you're losing the plot.

[ZephramC]

Lets hope future advanced functionality (custom scripts output, multisigs, colored coins, micropayments, contracts, Agents, ...) will not be obstructed while dealing with the malleability problem.

[fairglu]

Lets hope future advanced functionality (custom scripts output, multisigs, colored coins, micropayments, contracts, Agents, ...) will not be obstructed while dealing with the malleability problem.

I hope they'll leave advanced scripts and automation out, those will likely introduce a lot more problems than they'll solve.

I'd rather see the focus on the basic "everyday" issues first: malleability, blockchain bloat, micro-payments / fees from dust, low performance of wallets with many transactions, etc.

At the current rate, blockchain bloat alone is enough to menace the distributed nature of the network.
Every time someone switches to a MultiBit-like wallet, the network loses a node and becomes more vulnerable.

[ZephramC]

Lets hope future advanced functionality (custom scripts output, multisigs, colored coins, micropayments, contracts, Agents, ...) will not be obstructed while dealing with the malleability problem.

I hope they'll leave advanced scripts and automation out, those will likely introduce a lot more problems than they'll solve.

I'd rather see the focus on the basic "everyday" issues first: malleability, blockchain bloat, micro-payments / fees from dust, low performance of wallets with many transactions, etc.

At the current rate, blockchain bloat alone is enough to menace the distributed nature of the network.
Every time someone switches to a MultiBit-like wallet, the network loses a node and becomes more vulnerable.

Well, me too. I'd also rather see more pressing issues focused on first. But with keeping long time development in mind. It is easy to make some change now that will have to be undone in the future.