I'm not saying Mt. Gox are the good guys here (they clearly screwed up), but shouldn't Gavin Andresen have accepted some responsibility?
How could he? The flaw is in MtGox's closed-source implementation and customer service policies. Not Bitcoin. It does show the power of open source. Had MtGox's "Gox Special Wallet" been an open source project it is very likely someone would have caught the numerous implementation errors. Nobody knew except MtGox how incredibly flawed their wallet was, and they didn't have the competence to realize it was flawed. I am not just talking about the tx hash malleability issue but a host of other flaws as well. |
|
|
|
The silver lining is, if we get enough of these messages, we can make a decent sum of money at the expense of the distrubitors.
No, because they will never be confirmed. By the way, do these get thrown out of the mempool after a while? Each node maintains its own memory pool if it runs out of room it will discard the oldest. So yes, although there is no set time and the "network" doesn't coordinate it. |
|
|
|
Thanks for the link and the offer price i thought i would have to sell them cheap to get the money faster. I bought the BTC on ebay for cheaper than im selling so im trying to flip and make a profit im signing up for the site tonight thanks BitSimple usually stops PayPal payment around 8PM EST, but I will be coding late tonight so I for you and you only I will process your withdrawal manually to ensure you get it within minutes! Just drop me a message once you complete the transaction. Best of luck on your new business venture, glad I could get you a better price than $450 ea. |
|
|
|
No chargebacks allowed? That should keep the scammers away. On edit: Actually on looking at the listing my guess is you are the scammer. Nobody sell money for 20% off. Nobody ... unless they have no intention on paying. Still you can't be a scammer, you are a nice guy looking to start a webhosting company so I tell you what, I am going to help you out. I will pay you not $450 per BTC but >$650 per BTC for your Bitcoin (actually price based on market prices at the time of transfer and available at link below). https://bitsimple.com/Pro tip: Pro tip: When trying to start a business it is always better to take $650 per coin then $450 per coin. You have 12 BTC for sale? Well this gets you ~$8,000 closer to your funding for the new company. |
|
|
|
|
Someone is having fun modifying (just the signature not the amount, fee, source, or receiver) and rebroadcasting your tx due to signature malleability. Not sure if it is just to be an ass, or to prove a point.
However each tx in the pair uses the same inputs so only one can be confirmed in a block and the network will then drop the other as a double spend.
|
|
|
|
I disagree.
Its one of bitcoins strength that the price reflects the market immidiately, and nobody can change it happening.
In fact, this particular property of bitcoin is the closest you will ever get to devine intervention
The stock markets do this as well. At least in today's age. Not always. News after hours isn't reflected immediately. "Circuit breakers" will halt trading for a "cool off period". Exchange regulators will often freeze trading if there are unsubstantiated rumors. Bitcoin markets are probably the closest thing to a "free" market in the world. That might not last long though but you can tell your grandkids about how you traded when the exchange rate was set solely by supply and demand. |
|
|
|
I think a lot depend on what happens next. If MtGox sticks to it is false statements and claims they "can't" enable withdraws until the fatally flawed bitcoin protocol is hard forked to be more secure well that means at a minimum 6 to 12 months of no withdraws on MtGox. I can't possible see how that is bullish. The fact that a few "crypto nerds" know that isn't true isn't going to do much with month after month of news stories about the broken bitcoin protocol and the largest exchange unable to pay users millions of dollars in currency and bitcoins owed.
The foundation could sue them for slander? I am not a laywer but I don't think so. The foundation doesn't "own" Bitcoin. In a sad case of irony, it is actually MtGox who owns the trademark for "Bitcoin". That trademark is probably worth more than the rest of the company combined at this point so maybe they will do the right thing in order to protect the value of their property. Incompetence could be a valid defense anyways. It isn't slander to make an incorrect statement. It is slander to make a statement you know is incorrect. So if they are too incompetent to understand their claim is false, they can't be guilty. I don't think it would be that hard for their lawyer to prove their incompetence in court. See there are advantages to being dumb. |
|
|
|
|
I think a lot depend on what happens next. If MtGox sticks to it is false statements and claims they "can't" enable withdraws until the fatally flawed bitcoin protocol is hard forked to be more secure well that means at a minimum 6 to 12 months of no withdraws from MtGox. I can't possible see how that is bullish. The fact that a few "crypto nerds" know that isn't true isn't going to do much with month after month of news stories about the broken bitcoin protocol and the largest exchange unable to pay users millions of dollars in currency and bitcoins owed.
On the other hand if MtGox quiety retracts their false claims, slinks of into a corner and re-enables withdraws then it could be bullish.
|
|
|
|
|
It won't ruin the system. If this could kill Bitcoin, then Bitcoin was never worth anything to begin with. It might cause a short term drop in the exchange rate and even still the attacker still comes out ahead.
Some people will kill you for the cash in your wallet, and you don't think a hacker would exploit a door MtGox left wide open, to instantly double or quadruple (or more) their wealth with little to no risk, just because it might cause a short term drop in the exchange rate? Really?
|
|
|
|
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. |
|
|
|
That's effort though, it's not even a big project.
Um I already have a copy of every single address which has ever been used and it is continually kept up to date. So do you, so do over a hundred thousand other people on the planet. |
|
|
|
I wonder where are they getting the addresses?
Probably some distributed database containing a list of used Bitcoin addresses. Anyone have an idea of a project that does that? Maybe the dredged em from this forum. Not sure if serious? |
|
|
|
I wonder where are they getting the addresses?
Probably some distributed database containing a list of used Bitcoin addresses. Anyone have an idea of a project that does that? |
|
|
|
Might be off topic but - when you say miner, do you meaning mining pool (and solo miners) or miners within the pool itself?
As far as the protocol is concerned only the entity creating the block (and deciding on which tx to include) is the "miner". That would be p2pool users, pool operators, solo miners, etc. If you are "mining" for a traditional pool you really aren't even a miner, you are a hashpower provider. You send the pool hashes, and they pay you for them. You have no input, the protocol has no idea you even exist. |
|
|
|
Someone explain something to me. Why would the attackers do this knowing that they would cause the price to tank? If it causes BTC to be worthless then they're also SOL. Maybe they didn't think they would get caught somehow? Sometimes smart people can be so damn dumb...
Worthless would imply that the value went to zero which it hasn't. Say you had 100 BTC at MTGox and you withdrew, modified, reported not getting paid, and got paid again. You now have 200 BTC. Your break even if if you can sell those 200 BTC at half the price you could have sold the 100 BTC at. But wait this has been going on for a month now. So say you deposit the 200 BTC back to your MtGox account ,withdraw it, modify it, report it not being paid, get paid again and now you have 400 BTC. The price would have to fall 75% before you sold it to take a loss. Now 400 BTC to 800 BTC the price would have to fall 87% for you to not profit. It is also possible the attacker(s) sold their "doubled" coins weeks ago long before the price ever tanked. Hell they might have even sold, waited for the price to tank, and then bought back near the lows to make even more profit on their double. |
|
|
|
The payment to the user was made using two inputs:
"txid" : "acd552f807f0eeb3c0a3ddd852c5042c9b354b73b5c547310808be7825837a6b", "vout" : 1
"txid" : "e87eefbcfb9530de343044464cf38e4d0d287ad9719cee03063868d00217a157", "vout" : 1
Note this is all we care about. The amount of the inputs are not needed. If these inputs are in are found in a tx to the user in a block regardless of the tx hash then the user has been paid. One can simply record this information and wait until he gets complaints. Agreed. There is no "one solution". What works best will depend on the business needs and available resource. The only way you get "robbed" is if you just look to see if a tx confirmed based on the tx id, and if it doesn't show then you pay the user again. Even beyond mutability there are other (harder) ways this could be exploited. A tx which doesn't get relayed to all nodes for example could get relayed to the attacker who saves a copy and once MtGox pays them again, directly broadcasts the tx to miners. If one of them picks it up then the user could get paid twice. The simplest method would be as you said, to manually review tx which don't confirm and not assume that no confirmation when looking up by txid means it is safe to pay again.Another way to prevent this would be for MtGox to pay THEMSELVES before paying the user "again". If the user in this tx reported they hadn't been paid. MtGox could create a new tx spending these inputs back to an address they (MtGox) controls. If the complaint was legit then MtGox would be able to spend those coins back to themselves and then after that "refund" confirms would they pay the user again (or return funds back to the user's account). If the user was lying and the had mutated the signature then MtGox attempt transfer the coins back to their hotwallet would fail. Why? because it would be rejected by the network as a double spend of a outputs already spent in a tx in a block. Although this method provides less "automatic information" it would have prevent a single satoshi from being stolen. Yet another way would be for MtGox to delete the "missing tx" from their wallet and then check the unspent outputs list. With the tx gone, in this case those two inputs should return to the unspent output list. If they don't then it is because the attacker has already been paid in a modified transaction (Note I don't recommend using this method without testing). Yet another way would be to have a business rule of only using the same inputs when making a duplicate payment attempt. This would ensure the user couldn't possibly be paid twice as that would mean both copies of a double spend were included in a block. So there are a lot of ways (with differing degrees of reporting, complexity to code, and advantages). The only thing you absolutely can't do is to naively "check tx id, yup not confirmed let me make a new payment to the user". |
|
|
|
ok got it, but supposedly we will fix the Malleability issue today, how will this fix all their issues ? It won't and it won't be "fixed". It is a limitation of the system that we have to deal with. The reference client does a good job of handling it. Those who can't do a better job shouldn't attempt to do so. Even if it was going to be "fixed" by a hard fork that would be months if not years. From proposal to final release P2SH took 10+ months. This would be a much more radical change to the core protocol. IMHO it will NEVER happen but if it did, do you honestly think MtGox just holding on to the coins for 10 months is a viable solution? With a small amount of competence malleability can be detected. they will still have ton of other issues on their side, this is what I really don't get, do they take us for idiots ? I don't what they take "us" for but yes this wouldn't affect the half dozen other critical flaws in the client. It also won't "undo" the unknown number of bitcoins they double paid to attackers. |
|
|
|
I feel I am missing something here, so gox halted BTC withdrawals claiming that its is the protocol fault, we all agree on the bug and it has been known for a long time now, what I cant understand is how users are effected.
ok take a moment and hear me out, or in other words try to explain to me how this works:
1- I request a BTC withdraw
2- Gox hot wallet is empty
3- now 1000 user requests BTC withdrawals.
4- gox fill up the hot wallet to make it possible to withdraw or at the mean time they get enough deposits to proceed with the withdrawals.
5- the attacker is one of those users who did request a withdraw.
6- gox send TX1.
7- attacker change the TX1 to TX2
8- everyone get their Bitcoins regardless which tx is.
9- attacker claims that he didn't receive the BTC so they check their DB for TX1 and they agree on his claim and credit his account ( but again why, what about the other 999 user).
10- all the 999 user got their bitcoins and no one complains.
if we agree on the 10 steps above, then there is something fishy here, now when I see thousands of customers complaining about not getting Bitcoin withdrawals it makes me wonder how is this possible !!? because my logic tells me the 999 user shouldn't be effected, only the attacker who can claim on being "effected".
but for the last couple of weeks some people got their bitcoins when others didn't, how do we explain this ? anyone try to explain this to me ?
MtGox had other issues which resulted in payments failing, being delayed, and needing to be resent. The attackers took advantage of this to "camouflage" their actions. Your right if you send out payments to 50,000 users and 49,999 report no issue but one user over and over reports not getting paid well then "hmm maybe this user is running a scam" however if you send payments to 50,000 users and 30,000 of them report non-payment due to a variety of reasons (caused by Gox) then it becomes easier for the attacker to hide. MtGox wrote their own client, and they did so horribly bad. Their client isn't worthy of being used by a hobbyist experimenting on testnet but they used it in production for a systme involving millions of dollars of assets. We have no idea how many things they got wrong but looking at the failed transaction we know at a minimum these things were wrong: a) MtGox double spent their own coins. b) MtGox paid insufficient fees on tx which were low priority meaning they would not be relayed to miners by most nodes. c) MtGox created tx which violated the "anti-spam" rules which caused tx to be dropped (not relayed) by some nodes. d) MtGox attempted to spend immature newly mined coins (newly mined coins can't be spent for 120 blocks). e) MtGox used non-canonical signatures on transactions which were rejected by newer nodes. and f) MtGox failed to account for mutable hashes. Now if MtGox had done a through e they wouldn't have lost any coins. Yes users would be delayed. Yes it would make them look foolish but had they at least done f right they would have not paid attackers twice. On the other had if MtGox had done a through e right but messed up f, then your scenario in the OP would be correct. Legit users would have seen no issue, attackers would have gotten double paid. However MtGox managed to get a through f wrong so legit users were affected AND attackers were able to trick them into making double payments. Worse the two issues compound on each other. If the attackers were the only ones reporting non-payment then it is likely MtGox would have gotten suspicious relatively quickly however since this has been going on for the better part of a month and involves tens of thousands of transactions who knows how many times attackers were able to get away with a double payment. Moral of the story, a custom bitcoin client must be exactly compliant with other nodes on the network. "Kinda good, most of the time" is not sufficient. It is an undertaking that most people should not attempt. I consider myself moderately knowledgeable about bitcoin, and I don't use a custom bitcoin client. I use a custom backend which communicates with the reference client (i.e. bitcoind) for these exact reasons. MtGox's attempt to build a custom client would be laughably bad if released as an open source alternative client with a warning to be used for testing only. The fact that it was used as a closed source production client borders on criminal negligence. |
|
|
|
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. This will give you the raw tx details in hex. decoderawtransaction <rawtxhex>
This will give you json representation of a tx. You can do your own parsing of the raw hex or you can feed the hext into decoderawtx. Either way you now have the details of your payment. For example (tx pulled randomly from the blockchain) getrawtransaction da38a5fa60993f96a855265e1b6986d8a13eba983edf52992dab558656f45270
01000000026b7a832578be08083147c5b5734b359b2c04c552d8dda3c0b3eef007f852d5ac01000 0008e4d4700304402202e3cc369b33adca49763d3bd2f91f090b8a86117f67bcdb32d0607a5212f 065a02207bfefc91193c23d8a9b43120541d8e9a40bd06c277f064d5dd5805b45d867f31014d410 0049763964852d711f5b230601a9cb081dd71c07d46b589305ebfa46d3f4f2e2c45f26819efe4c5 b0fa2de5af2d4c77acec8eab9f1dec1b5e70438c2f8b943de68cffffffff57a11702d068380603e e9c71d97a280d4d8ef34c46443034de3095fbbcef7ee8010000008e4d4700304402202ada2194c1 f68a6ed2e7712693c7fde823c75223319cbe38a9818503e00d613002200a34637ce86dacc835603 088b3519fb9c419c77b79b4084a554b55487f803e8e014d410004b13e7ae7f4a7a9942c3a2998c8 e427fec24cf2e3f3d3501a7c35ab951b07daaeddd621e0115d0e6291615fed8b3ef67a5a2fc7971 70db7028710d0cdb0e18cb5ffffffff02f0076606000000001976a91472e57193b8672cd0875adc 9c0264ca6fa15e3e4688acf7641800000000001976a91404157cfd60177f4fa31c7572d7f5fe14a 8f7930d88ac00000000
decoderawtx 01000000026b7a832578be08083147c5b5734b359b2c04c552d8dda3c0b3eef007f852d5ac01000 0008e4d4700304402202e3cc369b33adca49763d3bd2f91f090b8a86117f67bcdb32d0607a5212f 065a02207bfefc91193c23d8a9b43120541d8e9a40bd06c277f064d5dd5805b45d867f31014d410 0049763964852d711f5b230601a9cb081dd71c07d46b589305ebfa46d3f4f2e2c45f26819efe4c5 b0fa2de5af2d4c77acec8eab9f1dec1b5e70438c2f8b943de68cffffffff57a11702d068380603e e9c71d97a280d4d8ef34c46443034de3095fbbcef7ee8010000008e4d4700304402202ada2194c1 f68a6ed2e7712693c7fde823c75223319cbe38a9818503e00d613002200a34637ce86dacc835603 088b3519fb9c419c77b79b4084a554b55487f803e8e014d410004b13e7ae7f4a7a9942c3a2998c8 e427fec24cf2e3f3d3501a7c35ab951b07daaeddd621e0115d0e6291615fed8b3ef67a5a2fc7971 70db7028710d0cdb0e18cb5ffffffff02f0076606000000001976a91472e57193b8672cd0875adc 9c0264ca6fa15e3e4688acf7641800000000001976a91404157cfd60177f4fa31c7572d7f5fe14a 8f7930d88ac00000000
{
"txid" : "da38a5fa60993f96a855265e1b6986d8a13eba983edf52992dab558656f45270",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "acd552f807f0eeb3c0a3ddd852c5042c9b354b73b5c547310808be7825837a6b",
"vout" : 1,
"scriptSig" : {
"asm" : "304402202e3cc369b33adca49763d3bd2f91f090b8a86117f67bcdb32d0607a5212f065a02207bf efc91193c23d8a9b43120541d8e9a40bd06c277f064d5dd5805b45d867f3101 049763964852d711f5b230601a9cb081dd71c07d46b589305ebfa46d3f4f2e2c45f26819efe4c5b 0fa2de5af2d4c77acec8eab9f1dec1b5e70438c2f8b943de68c",
"hex" : "4d4700304402202e3cc369b33adca49763d3bd2f91f090b8a86117f67bcdb32d0607a5212f065a0 2207bfefc91193c23d8a9b43120541d8e9a40bd06c277f064d5dd5805b45d867f31014d41000497 63964852d711f5b230601a9cb081dd71c07d46b589305ebfa46d3f4f2e2c45f26819efe4c5b0fa2 de5af2d4c77acec8eab9f1dec1b5e70438c2f8b943de68c"
},
"sequence" : 4294967295
},
{
"txid" : "e87eefbcfb9530de343044464cf38e4d0d287ad9719cee03063868d00217a157",
"vout" : 1,
"scriptSig" : {
"asm" : "304402202ada2194c1f68a6ed2e7712693c7fde823c75223319cbe38a9818503e00d613002200a3 4637ce86dacc835603088b3519fb9c419c77b79b4084a554b55487f803e8e01 04b13e7ae7f4a7a9942c3a2998c8e427fec24cf2e3f3d3501a7c35ab951b07daaeddd621e0115d0 e6291615fed8b3ef67a5a2fc797170db7028710d0cdb0e18cb5",
"hex" : "4d4700304402202ada2194c1f68a6ed2e7712693c7fde823c75223319cbe38a9818503e00d61300 2200a34637ce86dacc835603088b3519fb9c419c77b79b4084a554b55487f803e8e014d410004b1 3e7ae7f4a7a9942c3a2998c8e427fec24cf2e3f3d3501a7c35ab951b07daaeddd621e0115d0e629 1615fed8b3ef67a5a2fc797170db7028710d0cdb0e18cb5"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 1.07350000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 72e57193b8672cd0875adc9c0264ca6fa15e3e46 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a91472e57193b8672cd0875adc9c0264ca6fa15e3e4688ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1BUWttqJ7gNNhqfYF8rjVpYBPj735PVhRQ"
]
}
},
{
"value" : 0.01598711,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 04157cfd60177f4fa31c7572d7f5fe14a8f7930d OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a91404157cfd60177f4fa31c7572d7f5fe14a8f7930d88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1NbSoCQiHQCuJc7jPn4SuNXu2xrkyvrWs"
]
}
}
]
} These RPC call(s) can be made at the time the payment is made and stored. The bolded part is what we are interested. You can save the full output but this is the minimum information you need. Lets imagine tx da38a5fa60993f96a855265e1b6986d8a13eba983edf52992dab558656f45270 was a payment from MtGox to a customer. The payment to the user was made using two inputs: "txid" : "acd552f807f0eeb3c0a3ddd852c5042c9b354b73b5c547310808be7825837a6b", "vout" : 1"txid" : "e87eefbcfb9530de343044464cf38e4d0d287ad9719cee03063868d00217a157", "vout" : 1Note this is all we care about. The amount of the inputs are not needed. If these inputs are in are found in a tx to the user in a block regardless of the tx hash then the user has been paid. So before MtGox pays the user again they need to verify that these outputs don't exist in a tx in any block since the tx was created. How do to that. Well here are two options (there likely are more): Method 1: Scan all tx in all blocks as blocks are received.Pro: you get realtime status of mutated txs. Cons: it is probably more resource intensive then it is worth given the low rate that tx should be mutated in normal operation. When bitcoind reports a block has been received, you pull the block details You can then parse all the raw tx in the block using getrawtransaction and decoderawtransaction. If any of the tx have the same inputs from your payment tx then the tx is confirmed, update your records to reflect that the hash is changed, and also flag the tx as having been "modified" after being sent. Personally I wouldn't even do this because in my experience mutated tx are insanely rare under normal conditions but it is an option. Method 2: Just flag tx which don't confirm. Don't send repayment until you validate flagged transactions.At block time simply update tx based on tx hash. This should get 99.9% of your tx. Tx normally are not going to be modified. Note this will never give false positives. There is no risk in doing this. Now some tx hashes may be modified but they should be rare so we can handle them in batches at periodic intervals (say every 24 hours). Tx which don't confirm in some expected period of time (say 60 blocks) are flagged. Once a day do a "missing tx" check. 1) generate a list of blocks since the last time the check was run. 2) pull the tx hashes from the blocks. 3) get the raw tx and decode (either using internal process or using the decoderawtx RPC). 4) For each decoded raw tx compare the inputs (txin_hash and txin_index) of the decoded block tx to your list of "missing tx". If you get a match the tx is not missing. "Someone" likely the user mutated the hash. So update your records to reflect the correct tx_hash, block#, and confirmation status. Like in method #1 I would also flag the tx that it was mutated. Matching based on raw tx is slower than tx hash. Since most tx are going to have same tx hash this is why I prefer to do this as a periodic job. You can also run this job on a different server so as to not impact the load on the main tx server. The advantage of flagging tx (by eithe rmethod) is it provides you the ability to report on how often this is occurring and with which users. If you have 10,000 tx in a month and only have 20 "missing" txs and of those 20, 18 involve a single user, you might want to drop that user, especially if he keeps reporting to customer support that he isn't "getting paid". |
|
|
|
I'm curious to see if these transactions will confirm. I've never seen so many outputs in a single transaction before (700+).
The tx is compliant, it really comes down to will any miner feel like including a massive, spammy, low fee tx. My guess is no but nothing prevents them from doing it. The tx will be considered free because the fee paid (0.1 mBTC) is less than the min fee required (2.7 mBTC). |
|
|
|
|
Show Posts
