Bitcoin Exchanges Under ‘Massive and Concerted Attack’
21–30 of 218 posts
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#22It's interesting to watch actually, submit a transaction to the network at the moment and there's a rogue node that will mess with the padding of the signatures and rebroadcast it faster than the original. It confuses the reference client into duplicate display, which is what Gox is relying on for the failed/success display. That they're winning races over the normal related transactions isn't that unnatural as the t…
Not exactly. The buggy wallet software, used by these exchanges, identifies transactions by their hash. Even if one of the duplicates is confirmed, the buggy wallet still thinks the other is a new transaction, because it has a different hash. The fix is checking all inputs/outputs rather than relying on the transaction hash.
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#23I have no proof what so ever, this is just a conjecture: there are powerful government and private entities who profit from manipulating the current monetary system. I have to ask: is it unreasonable that state actors would try to crash Bitcoin out of self interest?
Is it unreasonable? No. Is there any evidence to suggest it? No.
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#24Didn't coindesk just report yesterday that the 'transaction malleability problem' that MtGox was worried about was already known and a non-issue?
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#25It's interesting to watch actually, submit a transaction to the network at the moment and there's a rogue node that will mess with the padding of the signatures and rebroadcast it faster than the original. It confuses the reference client into duplicate display, which is what Gox is relying on for the failed/success display. That they're winning races over the normal related transactions isn't that unnatural as the t…
Not exactly. The buggy wallet software, used by these exchanges, identifies transactions by their hash. Even if one of the duplicates is confirmed, the buggy wallet still thinks the other is a new transaction, because it has a different hash. The fix is checking all inputs/outputs rather than relying on the transaction hash.
Edit: Here is a good explanation of what this latest problem is which is different than the problem MtGox is struggling with http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_activ...
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#26Earlier quoted context omitted.
Quite possible a side benefit for the attackers.
If financial gain is a side benefit. What do you think the primary benefit is?
Just my thoughts
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#27This will make them only stronger. Bitcoin is not going anywhere.
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#28This will make them only stronger. Bitcoin is not going anywhere.
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#29Is the real goal of these attacks perhaps to drive down the price temporarily, so that the attackers can purchase at a discount, and then sell shortly afterwards when the price goes back up?
Re: Bitcoin Exchanges Under ‘Massive and Concerted Attack’
#30I've not bought in to Bitcoin yet. It just seems like a massive, world-wide scam to me. I'm not saying that it is a scam, I'm just saying that Bitcoin is something that I don't really understand, and so I don't entirely trust it. That said, this event is extremely encouraging. Not only is the security and the viability of the currency being tested. But more importantly, the communication and cooperation between the m…
It is a non issue, honestly. This issue was known about as early as 2011. You can only modify non-essential pieces of the transaction, but it does change the overall transaction hash. These poorly coded exchanges were looking for an exact hash match to pop up on the block chain, instead of looking for the deposit/address. The actual security of the system is not really impacted at all, and the core Bitcoin clients co…
That's the thing I don't get. If one is going to allow non-essential changes, shouldn't one _not_ include those data in the hash? Alternatively, should one simply not allow changes, period?
I've not read the Bitcoin paper, just summaries (been too busy, and it's outside my area); perhaps there's a good reason for it.