20

Bitcoin transactions have a transaction id (txid) formed as a hash over the data involved in the transaction. That suggests that it is a unique identifier for a transaction. However, the tx-id of a transaction is only unique once the exact data in the transaction has been finalized by being incorporated into the blockchain (and confirmed). Until then, there ...


11

Here's a good interview by Gregory Maxwell himself who's a Bitcoin developer: Oh there is a “problem” in the Bitcoin protocol, known since at least 2011 (see the link I gave). But for normal applications, not involving unconfirmed transactions, it shouldn’t cause any severe problems because wallets can handle it locally. This has to do with ...


11

Most of the fixes have been implemented in Bitcoin Core's master branch, or earlier versions, as standard transaction checks that prevent default Bitcoin Core nodes from relaying or mining transactions that break the rules. Here are some details: Non-DER encoded ECDSA signatures These are currently non-standard, so Bitcoin Core nodes (since 0.8.0,...


10

What malleability means is that you can't store the transaction ID that bitcoind returns from its sendtoaddress API call and expect that number to mean anything at all later. Instead, if you want to keep track of a high volume of outgoing transactions, you have to wait for the transactions to be fully confirmed and immune to blockchain reorganizations, and ...


9

Canonical DER signature implemented in BIP 66 fixes issue #1 of BIP 62 ( Non-DER encoded ECDSA signatures ) Amacilin's code exploits issue #5 in BIP 62 ( Inherent ECSDA signature malleability ), and is explained here : https://github.com/bitcoin/bitcoin/commit/a81cd96805ce6b65cca3a40ebbd3b2eb428abb7b This issue was fixed by requiring signatures to have ...


8

There are a variety of different ways to construct a micropayment channel, but there are two designs that I think are particularly relevant to your question about "simple, one-directional, micropayment channels": Spillman-style micropayment channels: this was a commonly-described micropayment channel design prior to BIP65 (OP_CHECKLOCKTIMEVERIFY, CLTV). ...


7

Bitcoin transactions are intentionally malleable. Some forms of malleability are a feature, and by design. Many of the more advanced uses of Bitcoin transactions (see the Contracts wiki page) rely on the ability to modify transactions in specific - and limited - ways. However, the current problems are unrelated, and because of unintentional malleabilities. ...


7

Here is example: https://blockchain.info/tx/683f45578328242a06bc5c54acbcbe6e70a5435b4561fc8b0570a59ab09f8bfa?show_adv=true Look at first input script in raw: ...


7

The only possibility in Bitcoin today is the one described by kaykurokawa. Every signature specifies which inputs and outputs it signs for, so if you want independently-created signatures, it will be obvious to everyone which input and output were created simultaneously. The general practice of combining multiple pieces of transactions into one is called ...


6

Mt.Gox' escrow wallet service only checks transaction hash. If anybody changes transaction hash before transaction is included into block, service considers transaction invalid and returns coins back to the owner's virtual account. But transaction itself is not invalid, it is finally accepted and coins are sent to the owner. It is primary bug in Mt.Gox's ...


6

The blockchain cannot contain malleable transactions. The malleable transactions happen before the transaction is embedded in a block in the blockchain. Essentially, the transaction ID is a hash of everything about the transaction including the signature. The signature signs everything except the signature part (it can't sign its own data). So, two ...


6

Yes. But they require the transaction to be signed a certain way. OP_CHECKSIG has settable flags, which determines which of the inputs and outputs are signed. If SIGHASH_SINGLE and SIGHASH_ANYONECANPAY is used for OP_CHECKSIG , each signature signs for its respective input and outputs, allowing others to add new inputs and outputs to the transaction. ...


6

Alice creates a multisig transaction sending 100btc to a shared Alice-Bob output–one that requires both signatures–and signs it. We’ll call this transaction Tx0. And she only reveals Tx0 to Bob after: Alice and Bob each sign a timelocked transaction for 30 days from now, sending 100btc back to Alice. This is not committed to the blockchain, and opens a “...


5

This is the new issue, the one that's causing all the trouble. You basically have two choices: Don't spend any of your own outputs until you're quite confident they're fully confirmed. For example, you could wait for three confirmations. Be prepared to deal with this problem by monitoring your outstanding transaction chains and re-issuing any orphaned ...


5

In essence, you've replicated the argument that nobody needs to worry about this problem, which we now know is false. It's because of that very belief that we have the mess we have now. One crucial detail you missed is that when spending the outputs of a prior transaction, you must specify its transaction ID in your new transaction. So there are many other ...


5

The signature associated with an input doesn't just sign that input, it signs the entire transaction payload - basically every part of the transaction except the signatures themselves. (Technically, it appears to actually sign a hash of a serialized version of the transaction.) It has to be that way. Otherwise, you could take someone else's signed ...


5

Is there a quick and dirty way to detect all transactions whose tx-id can be found in more than one transaction since the genesis block? There are multiple ways to read your question. Are there cases where the same transaction has been included into the blockchain multiple times? Yes. There is one recorded instance of the same coinbase appearing twice. ...


5

This is an interesting problem, one that has been studied and discuss within the bitcoin community quite a bit. The basic way to do this is to keep track of a normalized TXID alongside of the actual TXID used in the protocol. Then to calculate the normalized ID of a transaction, you serialize it: With the inputs' txids replaced by their normalized ...


5

As far as I know, the malleability issue was fixed with the Segwit soft fork in August 2017. Yes. Was the malleability issue fixed with SIGHASH_NOINPUTor with some other method? No, using SegWit. SegWit stands for segregated witness. It's a generic and backward compatible change that results in signatures no longer contributing to txids. As the txids ...


4

Whilst most of the process you describe is accurate, there are a few details where I believe your assumptions do not match reality, and may hence lead you to be (slightly) more critical of Bob than indeed deserved: The fact that tx 123abc is known to the network does not necessarily mean Bob, even if unaware of 456bca, would have to fear 123abc could be ...


4

You are absolutely right. The only reason why this is done, is because that is not how the consensus rules currently work. Changing it would require a hard fork, updating every node and eventually every wallet.


4

No. It can not under any circumstances be used to steal funds from a Bitcoin-QT wallet.


4

Ripple uses substantially the same signature scheme as Bitcoin does and the server validates signatures similarly using OpenSSL. But Ripple doesn't require you to refer to previous transactions by ID to spend from them. So you can't prevent people from spending funds or jam their transaction chains. The Ripple server will soon enforce fully canonical ...


4

Since none of the answers that were given were fully fleshed enough to properly answer my question, I'm posting my own answer which synthesizes everything that has been said: The best way to track a transaction in a way that will be resistant to transaction malleability, is to actually track only the data that has been signed. To do so, I suggest using a ...


4

The problem is that "transaction" refers to two different things: 1) The actual monetary transaction: address A sends something to address B. 2) The collection of bytes sent to the network expressing the above. Transaction malleability is possible because there isn't a unique way to express 1. You can express it with two different scripts that do the same ...


4

Short answer: no, this is impossible. Longer answer: some transactions allow changing the inputs used (ANYONECANPAY inputs). It is also possible to have inputs which do not sign the outputs being created (SIGHASH_NONE). However, a transaction where all inputs are of this type, are worthless, as anyone could change the outputs to credit themselves instead. ...


4

No, that's completely wrong. There is absolutely no anonymity benefit to third-party transaction malleability. Third-party transaction malleability makes use of a symmetry in ECDSA signatures that allows changing a transaction's id to exactly one alternative id. The alternative signature has been deprecated and non-standard for years, but miners could still ...


4

BIP 62 proposed to make transaction malleability impossible. No it didn't. It would have outlawed a limited number of known and addressable forms of malleability. In particular, it did not prevent multisig transaction participants from just creating a new signature, malleating the transaction without invalidation. This type of malleability is trivial to ...


4

It's important to point out that segwit doesn't prevent malleability: in many ways the actual transaction data can still be changed by third parties. It just makes it harmless for the purposes of dependant transactions/higher level protocols, because when malleated, the resulting transaction will still have the same txid as the original. To get this ...


3

Transaction malleability has a very small effect on a regular user, at most it can mess up some of your bookkeeping if you store the Transaction Id of a transaction before it is confirmed. Transaction malleability only affects unconfirmed transactions. The bug allows an unconfirmed transaction to be duplicated with a new transaction id. Since the two (or ...


Only top voted, non community-wiki answers of a minimum length are eligible