Topic: MtGox blames Bitcoin protocol problem for BTC withdrawal issue (Read 15226 times)
Its quite amazing the amount of denial a forum post can generate. Qoutes of supposed expertise in subject areas that clearly now the posters whom many you might expect some level of expertise had no info to go on are rampart here. Without the increased trade support synthesizing value at a higher confidence level, I image this issue would have driven the price down to under $200. The resilience of the value at the moment is astounding but seeing the denial this forum go figure. At what point will this real issue within bitcoin tarnish the short term potential value perspective of the holders when it does $200-400 range if that.
February 12, 2014, 03:07:47 PM
I just hope issues are really being worked on. From both sides Bitcoin and Gox/exchanges.
If it was just Gox I would say what the hell let them die. But now all exchanges are closing BTC withdrawals. And what I am afraid of is stubborn attitude from both sides. Gox saying Bitcoin guys need fix their stuff. Bitcoin guys saying Gox need fix their stuff when obviously blame is on both sides. This is very damaging for Bitcoin reputation and I think only way to save this terrible situation is cooperation... Fix transaction malleability on one side and exchanges fix their stuff too.
Otherwise this is going nowhere and we will watch Bitcoin die just when it gained wider acceptance, trust and people outside tech. circles started treating it seriously.
If it was just Gox I would say what the hell let them die. But now all exchanges are closing BTC withdrawals. And what I am afraid of is stubborn attitude from both sides. Gox saying Bitcoin guys need fix their stuff. Bitcoin guys saying Gox need fix their stuff when obviously blame is on both sides. This is very damaging for Bitcoin reputation and I think only way to save this terrible situation is cooperation... Fix transaction malleability on one side and exchanges fix their stuff too.
Otherwise this is going nowhere and we will watch Bitcoin die just when it gained wider acceptance, trust and people outside tech. circles started treating it seriously.
February 12, 2014, 06:21:04 AM
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.
Agreed. Undoing is often quite problematic, when it is possible at all.
February 12, 2014, 06:12:57 AM
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.
February 12, 2014, 06:05:18 AM
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.
February 12, 2014, 04:49:14 AM
Lets hope future advanced functionality (custom scripts output, multisigs, colored coins, micropayments, contracts, Agents, ...) will not be obstructed while dealing with the malleability problem.
February 12, 2014, 03:37:06 AM
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.
February 11, 2014, 10:56:29 AM
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.
On the other hand, I do not trust their (or actually, Mark's) overall technical or business competence at all.
+1 to that
February 11, 2014, 10:15:21 AM
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.
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.
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.
February 11, 2014, 09:59:54 AM
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.
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.
but i begin to think that they lost so much btc to this issue that they need to buy coins.
seems so..
February 11, 2014, 09:29:22 AM
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.
February 11, 2014, 09:23:05 AM
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??? February 11, 2014, 09:16:44 AM
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.
February 10, 2014, 11:47:05 PM
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
February 10, 2014, 10:58:56 PM
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.
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.
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.
February 10, 2014, 10:24:59 PM
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.
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.
February 10, 2014, 10:05:45 PM
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.
February 10, 2014, 09:55:32 PM
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.
February 10, 2014, 09:46:44 PM
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. February 10, 2014, 09:24:52 PM
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.
Jump to: