Topic: Transaction malleability and conflicted transactions (Read 180 times)
OK, thank you.
Most transactions aren't getting mutated for now, as far as I can tell but its definitely possible.
Bitcoin Core's default behavior is to ignore any transactions that spends the same input as in their mempool. This means that if the transaction that is mutated confirms, then the client will be able to see both the non-mutated (original) and mutated transactions. The one that is not in the blockchain (original TXN) will be given a -1.
Bitcoin Core's default behavior is to ignore any transactions that spends the same input as in their mempool. This means that if the transaction that is mutated confirms, then the client will be able to see both the non-mutated (original) and mutated transactions. The one that is not in the blockchain (original TXN) will be given a -1.
Hi there,
Hope you can clarify an issue regarding Transaction Malleability for me.
Lets suppose I will issue a transaction with a hash 1111 , then someone utilises transaction malleability and changes my transaction, so it will have a new hash: 222.
As far as I understand, only 1 of these 2 transactions will be eventually confirmed in the blockchain.
The question is: will the second transaction become conflicted one with the confirmations value equal to -1, according to this API docs:
https://bitcoin.org/en/developer-reference#listtransactions
Thank you in advance.
Hope you can clarify an issue regarding Transaction Malleability for me.
Lets suppose I will issue a transaction with a hash 1111 , then someone utilises transaction malleability and changes my transaction, so it will have a new hash: 222.
As far as I understand, only 1 of these 2 transactions will be eventually confirmed in the blockchain.
The question is: will the second transaction become conflicted one with the confirmations value equal to -1, according to this API docs:
https://bitcoin.org/en/developer-reference#listtransactions
Thank you in advance.
Jump to: