Stammer



Offline



Activity: 9

Merit: 0







NewbieActivity: 9Merit: 0 Mt.Gox technical autopsy February 26, 2014, 05:52:37 AM #1 After browsing the threads about Mt.Gox and the malleability issue here are a couple of questions.



Q1. Is there any way to ascertain that the Mt.Gox bankrupcy was indeed induced by transaction malleability?



I understand that the malleability issue is real. Indeed it has been real and known for more than two years. I still fail to understand how it could be realistically harnessed to heist hundreds of thousands of bitcoins.



Q2. Are we sure that the whole thing wasn't orchestrated with the complicity of Mt.Gox management? Can we ever be sure?



Q3. Consider a Bitcoin maketplace model where major exchanges mysteriously go bankrupt and handwave their alleged losses to some technical issue, previously regarded as minor. Is such a model viable in the long tem?

Cor2



Offline



Activity: 595

Merit: 500







Hero MemberActivity: 595Merit: 500 Re: Mt.Gox technical autopsy February 26, 2014, 09:13:34 AM #2 Quote from: Stammer on February 26, 2014, 05:52:37 AM After browsing the threads about Mt.Gox and the malleability issue here are a couple of questions.



Q1. Is there any way to ascertain that the Mt.Gox bankrupcy was indeed induced by transaction malleability?



I understand that the malleability issue is real. Indeed it has been real and known for more than two years. I still fail to understand how it could be realistically harnessed to heist hundreds of thousands of bitcoins.



Q2. Are we sure that the whole thing wasn't orchestrated with the complicity of Mt.Gox management? Can we ever be sure?



Q3. Consider a Bitcoin maketplace model where major exchanges mysteriously go bankrupt and handwave their alleged losses to some technical issue, previously regarded as minor. Is such a model viable in the long tem?

How do you answer rhetorical questions?... How do you answer rhetorical questions?...

Doge to the moon! D9FGY7Bhwbj2jrnk7v8VR47HTu7vfVu1gV Nut2pools and Steadymining SYNC: Sd3XBRmhrrr39Wj4rtjb3YAkwWvCze44BZ ORB: odyWi677JDQy7Gc6Nv6kCdnajmScqgTkDE Honest pools (payout matching calculation): TransferWise: International money transfer for 1%fee Doge to the moon! D9FGY7Bhwbj2jrnk7v8VR47HTu7vfVu1gV Nut2pools and Steadymining

Stammer



Offline



Activity: 9

Merit: 0







NewbieActivity: 9Merit: 0 Re: Mt.Gox technical autopsy February 26, 2014, 10:08:36 AM #3 Quote How do you answer rhetorical questions?..

I doubt my questions are rhetorical. Let me sketch some tentative answers, although I would obviously prefer to hear something from outside my head



A:Q1+Q2. That largely depends on Mt.Gox. If they release all the data they hold, including all their code and records, we may get an idea of what happened, which techniques were used and how transaction malleability was used in the heist.



I personally believe that insider support must have played a role, but I am less sanguine about wilful involvement of top management. Anyways, IMO there are lessons to be learnt here, both at the technical and at the management level.



A:Q3. Probably not, although some amount fraud may be tolerable. In the current ecosystem, as far as I understand, major exchanges are trust repositories. if trust repositories are necessary, then they should be fully accountable entities. But perhaps trust repositories are not necessary and the Bitcoin ecosystem should move away from them. I doubt my questions are rhetorical. Let me sketch some tentative answers, although I would obviously prefer to hear something from outside my headA:Q1+Q2. That largely depends on Mt.Gox. If they release all the data they hold, including all their code and records, we may get an idea of what happened, which techniques were used and how transaction malleability was used in the heist.I personally believe that insider support must have played a role, but I am less sanguine about wilful involvement of top management. Anyways, IMO there are lessons to be learnt here, both at the technical and at the management level.A:Q3. Probably not, although some amount fraud may be tolerable. In the current ecosystem, as far as I understand, major exchanges are trust repositories. if trust repositories are necessary, then they should be fully accountable entities. But perhaps trust repositories are not necessary and the Bitcoin ecosystem should move away from them.

behindtext



Offline



Activity: 121

Merit: 101







Full MemberActivity: 121Merit: 101 Re: Mt.Gox technical autopsy February 26, 2014, 01:39:25 PM #4 Quote from: Stammer on February 26, 2014, 05:52:37 AM After browsing the threads about Mt.Gox and the malleability issue here are a couple of questions.



Q1. Is there any way to ascertain that the Mt.Gox bankrupcy was indeed induced by transaction malleability?



I understand that the malleability issue is real. Indeed it has been real and known for more than two years. I still fail to understand how it could be realistically harnessed to heist hundreds of thousands of bitcoins.



i am not normally one to speak positively of regulation, but this is one of several reasons that money transmitters and MSBs require licenses in the US: too many unscrupulous people have started up such businesses, then there is a "theft" of funds and all the customers are missing money.



there are numerous ways a tx malleability exploit should have been stopped at mtgox. incompetence is a decent defense in the BTC markets when you consider how little most people know about BTC.



Quote Q2. Are we sure that the whole thing wasn't orchestrated with the complicity of Mt.Gox management? Can we ever be sure?



Q3. Consider a Bitcoin maketplace model where major exchanges mysteriously go bankrupt and handwave their alleged losses to some technical issue, previously regarded as minor. Is such a model viable in the long tem?



if BTC 600K or more has been "stolen", which has not been reliably confirmed by any means, i would bet a large amount of money on it being an inside job. you don't just end up having your cold wallets emptied and not know something is up, even if you're as incompetent as MK. i am not normally one to speak positively of regulation, but this is one of several reasons that money transmitters and MSBs require licenses in the US: too many unscrupulous people have started up such businesses, then there is a "theft" of funds and all the customers are missing money.there are numerous ways a tx malleability exploit should have been stopped at mtgox. incompetence is a decent defense in the BTC markets when you consider how little most people know about BTC.if BTC 600K or more has been "stolen", which has not been reliably confirmed by any means, i would bet a large amount of money on it being an inside job. you don't just end up having your cold wallets emptied and not know something is up, even if you're as incompetent as MK. [ANN][DCR] Decred - Hybrid PoW/PoS | btcsuite Devs | Tons of New Features | Go

btcsuite: an alternative full-node bitcoin implementation in Go

Loozik



Offline



Activity: 378

Merit: 250





Born to chew bubble gum and kick ass







Sr. MemberActivity: 378Merit: 250Born to chew bubble gum and kick ass Re: Mt.Gox technical autopsy February 26, 2014, 06:12:32 PM #5 Quote from: Stammer on February 26, 2014, 05:52:37 AM After browsing the threads about Mt.Gox and the malleability issue here are a couple of questions.



Q1. Is there any way to ascertain that the Mt.Gox bankrupcy was indeed induced by transaction malleability?

Let's say person X (attacker) withdrew e.g. BTC 666.696969 from Gox (or any other exchange). The same person X needed to claim exactly the same amount (BTC 666.696969) from Gox a week or two weeks later, right?



What could be done is to run a query on blockchain data to identify such transaction pairs, initiated from addresses that once had a fairly high value of ''total received'' (indicating they were exchange address) and sent the same amount (BTC 666.696969) twice within a certain period of time.



If someone identifies such pairs, then we might at least get the idea of the maximum possible malleability threshold that went on the Bitcoin network.





Quote from: Stammer on February 26, 2014, 05:52:37 AM Q2. Are we sure that the whole thing wasn't orchestrated with the complicity of Mt.Gox management? Can we ever be sure?

We are not sure and cannot be sure at the moment. The malleability can very well be a real thing or just an excuse. Someone brainy needs to investigate this through blockchain data analysis. Let's say person X (attacker) withdrew e.g. BTC 666.696969 from Gox (or any other exchange). The same person X needed to claim exactly the same amount (BTC 666.696969) from Gox a week or two weeks later, right?What could be done is to run a query on blockchain data to identify such transaction pairs, initiated from addresses that once had a fairly high value of ''total received'' (indicating they were exchange address) and sent the same amount (BTC 666.696969) twice within a certain period of time.If someone identifies such pairs, then we might at least get the idea of the maximum possible malleability threshold that went on the Bitcoin network.We are not sure and cannot be sure at the moment. The malleability can very well be a real thing or just an excuse. Someone brainy needs to investigate this through blockchain data analysis.

npiguet



Offline



Activity: 4

Merit: 0







NewbieActivity: 4Merit: 0 Re: Mt.Gox technical autopsy February 26, 2014, 08:01:18 PM #6 Quote from: Loozik on February 26, 2014, 06:12:32 PM Let's say person X (attacker) withdrew e.g. BTC 666.696969 from Gox (or any other exchange). The same person X needed to claim exactly the same amount (BTC 666.696969) from Gox a week or two weeks later, right?



What could be done is to run a query on blockchain data to identify such transaction pairs, initiated from addresses that once had a fairly high value of ''total received'' (indicating they were exchange address) and sent the same amount (BTC 666.696969) twice within a certain period of time.



If someone identifies such pairs, then we might at least get the idea of the maximum possible malleability threshold that went on the Bitcoin network.



You couldn't do that, because only one of the transactions would actually be in the block chain. So you would never actually see the pair of transactions. You can only catch this stuff while neither of the equivalent transactions has entered a valid block. You couldn't do that, because only one of the transactions would actually be in the block chain. So you would never actually see the pair of transactions. You can only catch this stuff while neither of the equivalent transactions has entered a valid block.

roy7



Offline



Activity: 434

Merit: 250







Sr. MemberActivity: 434Merit: 250 Re: Mt.Gox technical autopsy February 26, 2014, 08:04:52 PM #7 Quote from: behindtext on February 26, 2014, 01:39:25 PM i am not normally one to speak positively of regulation, but this is one of several reasons that money transmitters and MSBs require licenses in the US: too many unscrupulous people have started up such businesses, then there is a "theft" of funds and all the customers are missing money.



I'm not either and because of the regulations I would never set up my own exchange of any sort. However, I do benefit from it by only using coinbase for my transactions since they do follow the US regulations and are a US company. I feel much more comfortable doing bank transfers to coinbase for BTC purchases that I would with other random exchanges (be it BTC-E, Cryptsy, Coinex, or someone else). Also getting cash back from them by selling BTC is easy and direct to my bank account. I'm not either and because of the regulations I would never set up my own exchange of any sort. However, I do benefit from it by only using coinbase for my transactions since they do follow the US regulations and are a US company. I feel much more comfortable doing bank transfers to coinbase for BTC purchases that I would with other random exchanges (be it BTC-E, Cryptsy, Coinex, or someone else). Also getting cash back from them by selling BTC is easy and direct to my bank account.

cr1776



Offline



Activity: 2730

Merit: 1105







LegendaryActivity: 2730Merit: 1105 Re: Mt.Gox technical autopsy February 26, 2014, 08:10:29 PM #8 Quote from: npiguet on February 26, 2014, 08:01:18 PM Quote from: Loozik on February 26, 2014, 06:12:32 PM Let's say person X (attacker) withdrew e.g. BTC 666.696969 from Gox (or any other exchange). The same person X needed to claim exactly the same amount (BTC 666.696969) from Gox a week or two weeks later, right?



What could be done is to run a query on blockchain data to identify such transaction pairs, initiated from addresses that once had a fairly high value of ''total received'' (indicating they were exchange address) and sent the same amount (BTC 666.696969) twice within a certain period of time.



If someone identifies such pairs, then we might at least get the idea of the maximum possible malleability threshold that went on the Bitcoin network.



You couldn't do that, because only one of the transactions would actually be in the block chain. So you would never actually see the pair of transactions. You can only catch this stuff while neither of the equivalent transactions has entered a valid block.

You couldn't do that, because only one of the transactions would actually be in the block chain. So you would never actually see the pair of transactions. You can only catch this stuff while neither of the equivalent transactions has entered a valid block.

Both transactions would be in the blockchain - the initial withdrawal and then the re-withdrawl request several weeks later which mtgox would have allowed. This is different than the initial gox withdrawal which had the tx id mutated and eventually made it into the blockchain albeit with this mutated tx id.







Both transactions would be in the blockchain - the initial withdrawal and then the re-withdrawl request several weeks later which mtgox would have allowed. This is different than the initial gox withdrawal which had the tx id mutated and eventually made it into the blockchain albeit with this mutated tx id.

Loozik



Offline



Activity: 378

Merit: 250





Born to chew bubble gum and kick ass







Sr. MemberActivity: 378Merit: 250Born to chew bubble gum and kick ass Re: Mt.Gox technical autopsy February 26, 2014, 08:44:22 PM #9 Quote from: npiguet on February 26, 2014, 08:01:18 PM You couldn't do that, because only one of the transactions would actually be in the block chain.

That would mean that valid transactions do not appear on blockchain - I consider this rubbish.





Quote from: cr1776 on February 26, 2014, 08:10:29 PM Both transactions would be in the blockchain - the initial withdrawal and then the re-withdrawl request several weeks later which mtgox would have allowed.

I agree with this.



One needs to pair those two transactions (find them in the blockchain). There would be a few non-complex criteria for finding such malleable-looking transactions:

- amount of both must match

- date range should not be broad, e.g. the second transaction cannot be older than 1 day / week / month than the first one

- both transactions must be spent from an exchange address (not sure how to find such addresses but my guess is that such addresses generated a huge number of transactions for a short time)

- others



------------------------------



It is a perfect research project for applicants who want grants from TBF. That would mean that valid transactions do not appear on blockchain - I consider this rubbish.I agree with this.One needs to pair those two transactions (find them in the blockchain). There would be a few non-complex criteria for finding such malleable-looking transactions:- amount of both must match- date range should not be broad, e.g. the second transaction cannot be older than 1 day / week / month than the first one- both transactions must be spent from an exchange address (not sure how to find such addresses but my guess is that such addresses generated a huge number of transactions for a short time)- others------------------------------It is a perfect research project for applicants who want grants from TBF.

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: Mt.Gox technical autopsy February 27, 2014, 03:09:45 AM #10 Quote from: Loozik on February 26, 2014, 06:12:32 PM Quote from: Stammer on February 26, 2014, 05:52:37 AM After browsing the threads about Mt.Gox and the malleability issue here are a couple of questions.



Q1. Is there any way to ascertain that the Mt.Gox bankrupcy was indeed induced by transaction malleability?

Let's say person X (attacker) withdrew e.g. BTC 666.696969 from Gox (or any other exchange). The same person X needed to claim exactly the same amount (BTC 666.696969) from Gox a week or two weeks later, right?



What could be done is to run a query on blockchain data to identify such transaction pairs, initiated from addresses that once had a fairly high value of ''total received'' (indicating they were exchange address) and sent the same amount (BTC 666.696969) twice within a certain period of time.



If someone identifies such pairs, then we might at least get the idea of the maximum possible malleability threshold that went on the Bitcoin network.

Let's say person X (attacker) withdrew e.g. BTC 666.696969 from Gox (or any other exchange). The same person X needed to claim exactly the same amount (BTC 666.696969) from Gox a week or two weeks later, right?What could be done is to run a query on blockchain data to identify such transaction pairs, initiated from addresses that once had a fairly high value of ''total received'' (indicating they were exchange address) and sent the same amount (BTC 666.696969) twice within a certain period of time.If someone identifies such pairs, then we might at least get the idea of the maximum possible malleability threshold that went on the Bitcoin network.

This assumes that they were replacing transactions, not balances. This assumption may not be valid. This assumes that they were replacing transactions, not balances. This assumption may not be valid. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

Loozik



Offline



Activity: 378

Merit: 250





Born to chew bubble gum and kick ass







Sr. MemberActivity: 378Merit: 250Born to chew bubble gum and kick ass Re: Mt.Gox technical autopsy February 27, 2014, 03:53:07 AM #11 Quote from: kjj on February 27, 2014, 03:09:45 AM Quote from: Loozik on February 26, 2014, 06:12:32 PM Quote from: Stammer on February 26, 2014, 05:52:37 AM After browsing the threads about Mt.Gox and the malleability issue here are a couple of questions.



Q1. Is there any way to ascertain that the Mt.Gox bankrupcy was indeed induced by transaction malleability?

Let's say person X (attacker) withdrew e.g. BTC 666.696969 from Gox (or any other exchange). The same person X needed to claim exactly the same amount (BTC 666.696969) from Gox a week or two weeks later, right?



What could be done is to run a query on blockchain data to identify such transaction pairs, initiated from addresses that once had a fairly high value of ''total received'' (indicating they were exchange address) and sent the same amount (BTC 666.696969) twice within a certain period of time.



If someone identifies such pairs, then we might at least get the idea of the maximum possible malleability threshold that went on the Bitcoin network.

Let's say person X (attacker) withdrew e.g. BTC 666.696969 from Gox (or any other exchange). The same person X needed to claim exactly the same amount (BTC 666.696969) from Gox a week or two weeks later, right?What could be done is to run a query on blockchain data to identify such transaction pairs, initiated from addresses that once had a fairly high value of ''total received'' (indicating they were exchange address) and sent the same amount (BTC 666.696969) twice within a certain period of time.If someone identifies such pairs, then we might at least get the idea of the maximum possible malleability threshold that went on the Bitcoin network.

This assumes that they were replacing transactions, not balances. This assumption may not be valid.

This assumes that they were replacing transactions, not balances. This assumption may not be valid.

Okay, this assumption may not be valid, but at least we might start to try assessing the damage done to exchanges from here.



I am not the expert on bitcoin. I think a geek should conduct a study on this subject to arrive at a methodology of assessing the scale of malleability exploit.



If a good methodology is devised and a proper study run, someone might at least be able to confirm or debunk claims that were written in the ''leaked'' ''document'' that says +700k coins are gone. Okay, this assumption may not be valid, but at least we might start to try assessing the damage done to exchanges from here.I am not the expert on bitcoin. I think a geek should conduct a study on this subject to arrive at a methodology of assessing the scale of malleability exploit.If a good methodology is devised and a proper study run, someone might at least be able to confirm or debunk claims that were written in the ''leaked'' ''document'' that says +700k coins are gone.

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: Mt.Gox technical autopsy February 27, 2014, 12:23:24 PM #14 Quote from: Stammer on February 27, 2014, 06:14:45 AM



I found this



By the way, Maged writes:



Quote from: Maged on February 18, 2014, 12:19:47 AM

Quote from: pythonscript on February 17, 2014, 09:55:25 PM This means that it's not possible for both transactions to be in the blockchain, so people/organizations affected by this won't have to go through the blockchain to find people who double-withdrew, right? Yes. Only one can ultimately exist in the blockchain.

...Yes. Only one can ultimately exist in the blockchain. I would like to read more about this. AFAIU transaction malleability is still an open wound in the Bitcoin protocol. Understanding its implications is important.I found this thread , Maged's post about the Mt.Gox mess in particular, quite instructive.By the way, Maged writes:

He mentions that SR2 was a scam using this as cover. It is quite possible that gox is the same.



This is my understanding, the best that I've been able to put together.



Gox's custom software doesn't always strip leading zero bytes from signature values. Sipa estimated (on IRC) that only ~1% of gox transactions had excessive padding.



A while back, this was no big deal because the network would happily relay both forms, so any attempt at changing the transaction would result in a race. Later, the default node behavior changed to not relay the padded version. Once this changed, the original would pretty much always lose the race, if there was one.



Next, someone made a bot to "fix" transactions on the fly. Quite possibly this person was sick of waiting for their money and/or was just being helpful.



So, we have 3 eras.



First, all transactions confirm normally.

Second, 1% of transactions never confirm.

Third, 1% of transactions confirm in modified form.



Only the third era is vulnerable, but it is a relatively short era. I don't think anyone knows exactly how long it has been going on, but it can't have been years because the second era isn't that old either.



Now, to exploit this, you'd need to get lucky, or you'd need to keep up a massive circular flow out of and then back into gox. Remember that each transaction has about a 1% chance. So, 99% of the time that you withdraw your balance, it works fine. And you have to wait 6 or 7 confirmations (minimum) before you can try again. You'd get about 85 chances per year, so if we assume the third era was about a year long, figure the average attacker could have doubled their money about once in that time.



It just doesn't add up. Someone is lying, or there are very important things that we don't know yet. He mentions that SR2 was a scam using this as cover. It is quite possible that gox is the same.This is my understanding, the best that I've been able to put together.Gox's custom software doesn't always strip leading zero bytes from signature values. Sipa estimated (on IRC) that only ~1% of gox transactions had excessive padding.A while back, this was no big deal because the network would happily relay both forms, so any attempt at changing the transaction would result in a race. Later, the default node behavior changed torelay the padded version. Once this changed, the original would pretty much always lose the race, if there was one.Next, someone made a bot to "fix" transactions on the fly. Quite possibly this person was sick of waiting for their money and/or was just being helpful.So, we have 3 eras.First, all transactions confirm normally.Second, 1% of transactions never confirm.Third, 1% of transactions confirm in modified form.Only the third era is vulnerable, but it is a relatively short era. I don't think anyone knows exactly how long it has been going on, but it can't have been years because the second era isn't that old either.Now, to exploit this, you'd need to get lucky, or you'd need to keep up a massive circular flow out of and then back into gox. Remember that each transaction has about a 1% chance. So, 99% of the time that you withdraw your balance, it works fine. And you have to wait 6 or 7 confirmations (minimum) before you can try again. You'd get about 85 chances per year, so if we assume the third era was about a year long, figure the average attacker could have doubled their money about once in that time.It just doesn't add up. Someone is lying, or there are very important things that we don't know yet. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

Loozik



Offline



Activity: 378

Merit: 250





Born to chew bubble gum and kick ass







Sr. MemberActivity: 378Merit: 250Born to chew bubble gum and kick ass Re: Mt.Gox technical autopsy February 27, 2014, 12:45:45 PM #15 kjj,



Thanks for your thoughts. I can't fully understand them (I have a language barrier and no knowledge of bitcoin mechanics / technicalities / jargon). But at least you came up with some grounds for methodology of calculating / estimating the level of malleability exploit used to trick exchanges.



I have funds at Gox (or ''had'' in case they are gone). I really want to find out what is going on / what was going on. While trying to find it out I want NOT to rely on leaked recovery plans (which may or may not represent the reality).



Any help will be appreciated that will lead to discovery of the amount that was extracted from exchanges through malleability bug.

mistfpga



Offline



Activity: 86

Merit: 13







MemberActivity: 86Merit: 13 Re: Mt.Gox technical autopsy February 27, 2014, 05:01:07 PM #16



This is my understanding of how bitcoin works. If i am misunderstanding how transactions work, please someone correct me. Also this is only about mtgox... not how malleability works in general.



Quote from: Stammer on February 27, 2014, 06:14:45 AM I would like to read more about this. AFAIU transaction malleability is still an open wound in the Bitcoin protocol. Understanding its implications is important.



I agree that more users should be fully aware as to the implications of malleability, but they are documented and somewhat limited. Developers have no excuse for not being fully aware.



I think "an open wound" is a bit excessive. this is not bitcoins fault. bitcoin gives you the rope to hang yourself, it is up to you if you do that or not. irreversible transactions and accidentally large transaction fees are other examples of things that could be seen by some as a 'bug' or flaw in the bitcoin code. they are not.



Trusting unsigned inputs (like transaction ID, whilst not directly controllable it is certainly modifiable.) as signed inputs is such a basic mistake - I mean really really basic. like not pulling your trousers and underwear down before you go for a shit.



Block chain bloat, overly complex legacy that needs to be supported, almost obfuscated reference code and a very steep learning curve are open wounds. (that are healing, slowly...)



Quote from: kjj on February 27, 2014, 12:23:24 PM

Quote from: Maged on February 18, 2014, 12:19:47 AM

Quote from: pythonscript on February 17, 2014, 09:55:25 PM This means that it's not possible for both transactions to be in the blockchain, so people/organizations affected by this won't have to go through the blockchain to find people who double-withdrew, right? Yes. Only one can ultimately exist in the blockchain.

...Yes. Only one can ultimately exist in the blockchain.



Yeah, but that is missing the point, there has to be 3 transactions for gox's story to hold true (even though two of them spend the same funds/are the same transaction)

- the initial transaction,

- the double spend (which must be mined before transaction 1.)

- the reissue of funds in transaction 1 by the original issuer. it is this reissue that would set alarm bells off. (and why not reissue the _same_ funds they claim not to have received? maybe you'd have to run a multimillion dollar business and have a track record for successful technical ventures to check for that sort of thing.)



makes me wonder why the accountants did not flag the discrepancies between the sale of coins, transaction reissues and actual stock levels. they must have been doing zero stock checking for their story to hold true. (or the 'attack' was spotted very quickly) This is not even a technical thing, it is a bean counter thing. (the stock checks will not show what the issue is, just their is a major problem... _everything_ is accountable it is all right there in the block chain - bitcoin is an accountants wet dream.)



Quote He mentions that SR2 was a scam using this as cover. It is quite possible that gox is the same.



Not in the thread you linked, he even specifically states they are not connected. interesting idea though. (you would probably make more money just selling drugs...)



Quote Depends on the "issue" you are referring to. You see, in the past week, the three major stories you've heard in the media (MtGox, SR 2.0, DDoS) were all unrelated.



Quote Gox's custom software doesn't always strip leading zero bytes from signature values. Sipa estimated (on IRC) that only ~1% of gox transactions had excessive padding.



I think the not relaying of transactions is a distraction technique. same for the unsticking of transactions, anyone could verbatim supply the transaction to a pool they know will mine it. Mining rules are different to passing of transaction rules. There is no reason not to mine nonstandard transactions if you see them.



Quote A while back, this was no big deal because the network would happily relay both forms, so any attempt at changing the transaction would result in a race. Later, the default node behavior changed to not relay the padded version. Once this changed, the original would pretty much always lose the race, if there was one.



maybe, however even now it shouldnt be a big deal. gox's custom code would relay the transactions, so gox would have to be not connected to the major mining pools... this seems absurd at best. the padded transactions will be included in the next block. there is no reason not to mine them, just not to transmit them.



The best an attacker could hope for would be to connect to the same pools, but they are still massively disadvantaged because they have to see the transaction second, modify it, and get it into the transaction pool ahead of the transaction they got from the transaction pool... for gox's account to be true the attacker would have to see the broadcast before the pools. That is until anyone can up the fees on a transaction... but that is a different can of worms. (and a really bad idea.)



So the attacker is left with having to see the transaction in memory at a major pool then modify it and pass it to another pool that gox is not connected too and hope that pool hits a block first. Unless the pools decide not to mine nonstandard transactions (not rational)



gox would never have a transaction propagation issue no matter how nonstandard yet valid their transactions are. However this changes when we get the ability to pay for fees on other peoples transactions, making the attack easier. (assuming higher fees are more likely to appear in blocks)



Quote Next, someone made a bot to "fix" transactions on the fly. Quite possibly this person was sick of waiting for their money and/or was just being helpful.



I would be tempted to think this was Gox implementing a 'fix'. A good willed person does not need to modify the transaction to be helpful, just relay it to the pools that gox doesnt talk too (okay if you arent up on bitcoin attacks, unless gox hasnt heard of a sybil attack



Quote So, we have 3 eras.



First, all transactions confirm normally.

Second, 1% of transactions never confirm.

Third, 1% of transactions confirm in modified form.



Only the third era is vulnerable, but it is a relatively short era. I don't think anyone knows exactly how long it has been going on, but it can't have been years because the second era isn't that old either.



I am not sure what you mean by era's but the issue isnt as passive as it seems. there is a difference between the rules for relaying transactions and the rules for including a transaction in a block. the attack relies on the attacker being able to send the modified transaction to the mining pools before they see the original transaction. the network propagation rules only apply to people without custom software to craft the transactions and direct connections to the major pools. technically it could have been going on the whole time. the original transaction most likely never made it to the network if they really were attacked.



Quote Now, to exploit this, you'd need to get lucky, or you'd need to keep up a massive circular flow out of and then back into gox. Remember that each transaction has about a 1% chance. So, 99% of the time that you withdraw your balance, it works fine. And you have to wait 6 or 7 confirmations (minimum) before you can try again. You'd get about 85 chances per year, so if we assume the third era was about a year long, figure the average attacker could have doubled their money about once in that time.



It just doesn't add up. Someone is lying, or there are very important things that we don't know yet.



I agree completely. the story as told (have gox given an official response? I saw gesticulating and general flapping on their blog but nothing concrete.) cannot be possible.



There is a lot less than 1% chance. so much so it puts it out of the hands of even medium players.



There are other methods to take advantage of the coding error that I can think of, but they all need more access... the only semi reasonable answer is either someone

1) MITM the connections to the major pools and rewrote every transaction, and dropping the original ones thus guaranteeing your transaction is seen first.

2) Own the transaction server, rewriting every transaction and dropping the original before it is even broadcast.



I cant wait for them to have thier solution implemented (it would seem that they have passed the trust to block explorer and block explorer say yay or nay. lol. idiots.)



Hope this helps? sorry if it goes on a bit. but as far as I know you cannot 'update' a transaction. Hi,This is my understanding of how bitcoin works. If i am misunderstanding how transactions work, please someone correct me. Also this is only about mtgox... not how malleability works in general.I agree that more users should be fully aware as to the implications of malleability, but they are documented and somewhat limited. Developers have no excuse for not being fully aware.I think "an open wound" is a bit excessive. this is not bitcoins fault. bitcoin gives you the rope to hang yourself, it is up to you if you do that or not. irreversible transactions and accidentally large transaction fees are other examples of things that could be seen by some as a 'bug' or flaw in the bitcoin code. they are not.Trusting unsigned inputs (like transaction ID, whilst not directly controllable it is certainly modifiable.) as signed inputs is such a basic mistake - I mean really really basic. like not pulling your trousers and underwear down before you go for a shit.Block chain bloat, overly complex legacy that needs to be supported, almost obfuscated reference code and a very steep learning curve are open wounds. (that are healing, slowly...)[/quote]Yeah, but that is missing the point, there has to be 3 transactions for gox's story to hold true (even though two of them spend the same funds/are the same transaction)- the initial transaction,- the double spend (which must be mined before transaction 1.)- the reissue of funds in transaction 1 by the original issuer. it is this reissue that would set alarm bells off. (and why not reissue the _same_ funds they claim not to have received? maybe you'd have to run a multimillion dollar business and have a track record for successful technical ventures to check for that sort of thing.)makes me wonder why the accountants did not flag the discrepancies between the sale of coins, transaction reissues and actual stock levels. they must have been doing zero stock checking for their story to hold true. (or the 'attack' was spotted very quickly) This is not even a technical thing, it is a bean counter thing. (the stock checks will not show what the issue is, just their is a major problem... _everything_ is accountable it is all right there in the block chain - bitcoin is an accountants wet dream.)Not in the thread you linked, he even specifically states they are not connected. interesting idea though. (you would probably make more money just selling drugs...)I think the not relaying of transactions is a distraction technique. same for the unsticking of transactions, anyone could verbatim supply the transaction to a pool they know will mine it. Mining rules are different to passing of transaction rules. There is no reason not to mine nonstandard transactions if you see them.maybe, however even now it shouldnt be a big deal. gox's custom code would relay the transactions, so gox would have to be not connected to the major mining pools... this seems absurd at best. the padded transactions will be included in the next block. there is no reason not to mine them, just not to transmit them.The best an attacker could hope for would be to connect to the same pools, but they are still massively disadvantaged because they have to see the transaction second, modify it, and get it into the transaction pool ahead of the transaction they got from the transaction pool... for gox's account to be true the attacker would have to see the broadcast before the pools. That is until anyone can up the fees on a transaction... but that is a different can of worms. (and a really bad idea.)So the attacker is left with having to see the transaction in memory at a major pool then modify it and pass it to another pool that gox is not connected too and hope that pool hits a block first. Unless the pools decide not to mine nonstandard transactions (not rational)gox would never have a transaction propagation issue no matter how nonstandard yet valid their transactions are. However this changes when we get the ability to pay for fees on other peoples transactions, making the attack easier. (assuming higher fees are more likely to appear in blocks)I would be tempted to think this was Gox implementing a 'fix'. A good willed person does not need to modify the transaction to be helpful, just relay it to the pools that gox doesnt talk too (okay if you arent up on bitcoin attacks, unless gox hasnt heard of a sybil attack https://en.bitcoin.it/wiki/Weaknesses they are connected to well over 75% of the mining power, hence me banging on about it. if 1% have an issue, it is an infinitesimally small chance you will be able to out race it.) you dont need to strip the zeros.I am not sure what you mean by era's but the issue isnt as passive as it seems. there is a difference between the rules for relaying transactions and the rules for including a transaction in a block. the attack relies on the attacker being able to send the modified transaction to the mining pools before they see the original transaction. the network propagation rules only apply to people without custom software to craft the transactions and direct connections to the major pools. technically it could have been going on the whole time. the original transaction most likely never made it to the network if they really were attacked.I agree completely. the story as told (have gox given an official response? I saw gesticulating and general flapping on their blog but nothing concrete.) cannot be possible.There is a lot less than 1% chance. so much so it puts it out of the hands of even medium players.There are other methods to take advantage of the coding error that I can think of, but they all need more access... the only semi reasonable answer is either someone1) MITM the connections to the major pools and rewrote every transaction, and dropping the original ones thus guaranteeing your transaction is seen first.2) Own the transaction server, rewriting every transaction and dropping the original before it is even broadcast.I cant wait for them to have thier solution implemented (it would seem that they have passed the trust to block explorer and block explorer say yay or nay. lol. idiots.)Hope this helps? sorry if it goes on a bit. but as far as I know you cannot 'update' a transaction.

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: Mt.Gox technical autopsy February 28, 2014, 06:07:53 AM #18 Oh, right. I forgot about another confounding factor.



Apparently gox's software didn't properly age coins before spending them. Not normally a problem, but when the hot wallet is low, things can get interesting. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

Stammer



Offline



Activity: 9

Merit: 0







NewbieActivity: 9Merit: 0 Re: Mt.Gox technical autopsy February 28, 2014, 07:49:13 AM #19 Surmising a brief sum up.



a) Only one transaction gets registered in the blockchain -> no blockchain-based autopsy is possible.



b) There have been some interesting contributions discussing the Gox software. I wonder whether it is available and can be inspected. Perhaps it would be reasonable to require exchanges to make their software available to public scrutiny. If a chunk of the Bitcoin ecosystem is a black hole it's hardly surprising that it swallows money.