TXIDs of unconfirmed transactions can not be trusted to stay the same. <-- We saw what that one did very recently.
If ECDSA requires a RANDOM number, you better make sure you actually use a random one. <-- We had that one too (aka. Android bug).
Any other "long known" wiki articles with things that are likely being overlooked by client implementers or people using the RPC API?
Examples could be some more exotic script types, chain reorg detection, relaying (or not relaying) as well as reporting double-spend attempts, dust spam/collection, some more intricate crypto stuff...
Yes, I have a similar idea that we should list out all these "known problems" and put them on the top of our agenda. If something is exploitable, someone must exploit it (e.g. malleability) If something may go wrong, someone will certainly do it wrong (e.g. random number bug) For the issues you listed, chain reorg could be a big headache with this ongoing malleability attack. In case we have a chain fork like the Mar 2013 one again, many transactions will get orphaned due to their parents are mutated. |
|
|
|
I don't really expect this will be implemented, but I hope people will find this interesting. Transaction structure is the same but an extra field, txSize, is added. Transaction hash is the hash of everything with scriptSig removed, and this is the hash going to the Merkle Root. As the scriptSig will not go to the Merkle Root, it won't be really recorded in the blockchain. People can freely mutate the scriptSig (even after confirmation). Miners will accept a transaction if they see a valid scriptSig and the transaction size is equal to txSize. This will make sure the block size is not mutable. Payer could opt to sign the txSize or not. This could be a hardfork, or a softfork with the auxiliary block: https://bitcointalk.org/index.php?topic=283746.0Any comment? |
|
|
|
|
The malleability attack becomes a DOS attack. We need a quick fix. Before there is a better solution, the bitcoind should not report unconfirmed transactions. Account balance should be solely based on confirmed transactions. Before malleability is fixed (if ever), unconfirmed outputs should not be spent.
|
|
|
|
But isn't that precisely what this proposal is intended to deal with?
so he would have to mutate every possible transaction in order to get a mutant mined instead. This would be much harder/more costly (at least if P2SH were widely used).
This proposal assume that Bob would not take a spray-and-pray strategy. As someone is now randomly mutating transactions on the network, the proposal won't work |
|
|
|
With the ongoing malleability attack, this proposal no longer works. Any hope to safe it (except by fixing malleability)?
Why does it no longer work? Someone is randomly mutating unconfirmed transactions. So the txid of all unconfirmed transactions are not reliable |
|
|
|
|
With the ongoing malleability attack, this proposal no longer works. Any hope to save it (except by fixing malleability)?
|
|
|
|
Gox is doing it wrong. They and everyone need to use inputs to identify a tx.
Obviously the signatures won't authenticate any other signatures. So someone with the private key of inputs can always create another tx (using a new signature) with exactly same inputs/outputs.. there is no way to prevent this.. especially in distributed protocols like coinjoin. So the tx will always be malleable until confirmed.
This is called double-spend attack, not malleability. To distinguish these 2: - Double-spend attack could only be launched by private key holder
- Malleability (attack) could be done by anyone (there is a malleability attack bot running now)
|
|
|
|
Hi, I have problem with connect to ws://websocket.mtgox.com. No data on TCP. I tried to connet from different IP, but without success.
Does anybody have the same problem? And what is solution for receiving lag, trades and also sending my trade commands?
MtSux has nothing to do in this board. Please go to service discussion |
|
|
|
I didn't want to have my account liquidated in the event that bitcoin was actually dying due to irrepairable protocol exploitation or failure.
The so-called bug is known for years. This suggests that you have no idea in what you are investing, and even worse, investing with margin The most recent incident that might really have killed bitcoin was the hardfork in March 2013: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki |
|
|
|
|
For merchants, if they want to record a transaction immediately without waiting for confirmation, what they could do now is to record the inputs (txid:index), outputs (address), and values. These information, altogether, is not malleable and could be an unique identifier for a transaction, even for zero confirmation
|
|
|
|
everytime i send btc to my customer, i also send email notification of the txid. so now this practice should be avoided because huge chance that txid can be altered? and should we store the txid into our database? if not, how we determine each transaction from our end?
what should we do as merchant/developer to anticipate this malleability issue?
Merchants need a way to record transactions immediately. They can't just wait for several confirmations and search the blockchain for a txid. I think gox's proposal should be adopted. |
|
|
|
everytime i send btc to my customer, i also send notification of the txid. so now this practice should be avoided because huge chance that txid can be altered? and we should not store the txid into our database?
what should we do as merchant/developer to anticipate this malleability issue?
You can still rely on txid, but ONLY AFTER SEVERAL CONFIRMATIONS Confirmation is the king: not just for the safety of the fund, but also for the reliability of txid |
|
|
|
Quick answer: don't need to worry. You fund is perfectly safe
what's going on with blockchain? is the whole network effected by malleable attack? Blockchain.info mistakenly thinks those transactions are double-spending but actually they are not. However, these are all cosmetic issue and no real harm could be done. I have pm-ed piuk asking him to stop reporting double-spending on his service for now |
|
|
|
|
Someone is using the malleability to spread FUD. It looks bad but won't lead to any real harm.
|
|
|
|
|
Quick answer: don't need to worry. You fund is perfectly safe
|
|
|
|
So Gox has to manually compare all previous cheques issued with photos to sort out the mess of their cashbook?
It is always not a good practice to compare the photos (transaction hash). They should check the balance of all their bitcoin accounts |
|
|
|
牛B啊,老兄, 你这篇文是目前最简单易明的说明.感谢!
我在MTGOX有30个币,您觉得我应该怎样做? 沽->提现,还是坐等,给个建议吧.
如果你相信Gox仍然持有足夠的幣, 那應該持幣 如果你相信Gox己出現嚴重財政問題, 沽出可能會較好, 因為在法律上比較容易追究 但說到提現 (美元), 你真的能提現嗎...........? |
|
|
|
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 |
|
|
|
有没有人确认下？谢谢！
2010年的漏洞，也就只有MT没技术修复！ 估计Mt Gox太有雄心，自己写钱包，结果出事。不知道火币是不是自己写的钱包，还是用的Bitcoin QT。 火币站出来正面回答下这个问题吧！ 我相信除Gox以外沒有一個主要交易所受影響, 包括Bitstamp, BTC-E, BTCChina, OKCoin, Huobi. 因為如果受影響的話, 以他們的交易量已經出大問題了 |
|
|
|
|
Show Posts
