Transaction malleability - Revision history

Belcher: added archived link in case of link rot

2018-10-05T11:15:24Z

added archived link in case of link rot

← Older revision		Revision as of 11:15, 5 October 2018
Line 18:		Line 18:
	== BIP62 ==		== BIP62 ==

	[[BIP_0062]] was a bitcoin improvement proposal from early 2014 which aimed to deal with malleability. It aimed to find all possible methods of malleability and fix them one-by-one. The BIP was withdrawn because that was found to be not sufficient for the use cases which malleability prevents (e.g [[payment channels]]).<ref>https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented</ref><ref>https://github.com/bitcoin/bips/commit/916142e742b4256686c26b15a0bf943aea3f5ef9</ref><ref>https://old.reddit.com/r/Bitcoin/comments/3tgmch/bip62_dealing_with_transaction_malleability_has/</ref> The BIP document itself contains all malleability methods that the authors could think of.		[[BIP_0062]] was a bitcoin improvement proposal from early 2014 which aimed to deal with malleability. It aimed to find all possible methods of malleability and fix them one-by-one. The BIP was withdrawn because that was found to be not sufficient for the use cases which malleability prevents (e.g [[payment channels]]).<ref>https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented</ref><ref>https://github.com/bitcoin/bips/commit/916142e742b4256686c26b15a0bf943aea3f5ef9</ref><ref>https://old.reddit.com/r/Bitcoin/comments/3tgmch/bip62_dealing_with_transaction_malleability_has/ [https://archive.is/N5EjB archived link]</ref> The BIP document itself contains all malleability methods that the authors could think of.

	== Segwit ==		== Segwit ==

Belcher: add sections about bip62 and segwit

2018-10-05T11:13:09Z

add sections about bip62 and segwit

← Older revision		Revision as of 11:13, 5 October 2018
Line 15:		Line 15:

	Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin.		Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin.

			== BIP62 ==

			[[BIP_0062]] was a bitcoin improvement proposal from early 2014 which aimed to deal with malleability. It aimed to find all possible methods of malleability and fix them one-by-one. The BIP was withdrawn because that was found to be not sufficient for the use cases which malleability prevents (e.g [[payment channels]]).<ref>https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented</ref><ref>https://github.com/bitcoin/bips/commit/916142e742b4256686c26b15a0bf943aea3f5ef9</ref><ref>https://old.reddit.com/r/Bitcoin/comments/3tgmch/bip62_dealing_with_transaction_malleability_has/</ref> The BIP document itself contains all malleability methods that the authors could think of.

			== Segwit ==

			[[Segregated Witness]] was an update to bitcoin had as one of its aims to fix all forms of malleability. [[Transactions]] which only spend segwit outputs are not vulnerable to malleability.

	==References==		==References==

Taras: Taras moved page Transaction Malleability to Transaction malleability

2017-11-29T19:54:35Z

Taras moved page Transaction Malleability to Transaction malleability

← Older revision		Revision as of 19:54, 29 November 2017
(No difference)

Luke-jr: /* Signature Malleability */ BIP66 does not close all signature malleability

2015-08-18T22:30:47Z

Signature Malleability: BIP66 does not close all signature malleability

← Older revision		Revision as of 22:30, 18 August 2015
Line 6:		Line 6:

	As of block 363724<ref>[http://bitcoin.stackexchange.com/a/38438/21052 When did BIP66 switch from activation to enforcement?], answer by StephenM347, 6 July 2015, Bitcoin.StackExchange</ref>, the [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 soft fork] has made it mandatory for all new transactions in the block chain to strictly follow the DER-encoded ASN.1 standard.		As of block 363724<ref>[http://bitcoin.stackexchange.com/a/38438/21052 When did BIP66 switch from activation to enforcement?], answer by StephenM347, 6 July 2015, Bitcoin.StackExchange</ref>, the [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 soft fork] has made it mandatory for all new transactions in the block chain to strictly follow the DER-encoded ASN.1 standard.
			Further efforts are still under way to close other possible malleability within DER signatures.

	Signatures can still be changed by anyone who has access to the corresponding private keys.		Signatures can still be changed by anyone who has access to the corresponding private keys.

Harding: Added Bitcoin Core documentation navbox

2015-08-17T16:07:03Z

Added Bitcoin Core documentation navbox

← Older revision		Revision as of 16:07, 17 August 2015
Line 20:		Line 20:
	[[Category:Technical]]		[[Category:Technical]]
	[[Category:Developer]]		[[Category:Developer]]

			{{Bitcoin Core documentation}}

Harding: /* Signature Malleability */ add info about BIP66 enforcement

2015-08-17T12:46:57Z

Signature Malleability: add info about BIP66 enforcement

← Older revision		Revision as of 12:46, 17 August 2015
Line 5:		Line 5:
	The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but OpenSSL does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted.<ref>https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410</ref> In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.<ref>https://bitcointalk.org/index.php?topic=8392.msg1245898#msg1245898</ref>		The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but OpenSSL does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted.<ref>https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410</ref> In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.<ref>https://bitcointalk.org/index.php?topic=8392.msg1245898#msg1245898</ref>

	~~Efforts are underway~~ to ~~first make~~ Bitcoin ~~nodes not relay non~~-standard ~~signatures, and eventually disallow them from being included in new blocks entirely~~.		As of block 363724<ref>[http://bitcoin.stackexchange.com/a/38438/21052 When did BIP66 switch from activation to enforcement?], answer by StephenM347, 6 July 2015, Bitcoin.StackExchange</ref>, the [https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki BIP66 soft fork] has made it mandatory for all new transactions in the block chain to strictly follow the DER-encoded ASN.1 standard.

			Signatures can still be changed by anyone who has access to the corresponding private keys.

	== scriptSig Malleability ==		== scriptSig Malleability ==

Jayemar: Cleaned up the grammar a bit in the opening paragraph

2015-07-26T02:46:15Z

Cleaned up the grammar a bit in the opening paragraph

← Older revision		Revision as of 02:46, 26 July 2015
Line 1:		Line 1:
	While [[transaction]]s are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash, the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block (and potentially even after a confirmation if the block chain is reorganized). In addition clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe.		While [[transaction]]s are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus, while uncommon, it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash; the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block (and potentially even after a confirmation if the block chain is reorganized). In addition, clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe.

	== Signature Malleability ==		== Signature Malleability ==

Nayuki: Added link, corrected spelling

2015-04-12T19:43:15Z

Added link, corrected spelling

← Older revision		Revision as of 19:43, 12 April 2015
Line 1:		Line 1:
	While ~~transactions~~ are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash, the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block. (and potentially even after a confirmation if the block chain is reorganized) In addition clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe.		While [[transaction]]s are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash, the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block (and potentially even after a confirmation if the block chain is reorganized). In addition clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe.

	== Signature Malleability ==		== Signature Malleability ==

	The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but ~~openssl~~ does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted.<ref>https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410</ref> In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.<ref>https://bitcointalk.org/index.php?topic=8392.msg1245898#msg1245898</ref>		The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but OpenSSL does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted.<ref>https://bitcointalk.org/index.php?topic=8392.msg122410#msg122410</ref> In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.<ref>https://bitcointalk.org/index.php?topic=8392.msg1245898#msg1245898</ref>

	Efforts are underway to first make Bitcoin nodes not relay non-standard signatures, and eventually disallow them from being included in new blocks entirely.		Efforts are underway to first make Bitcoin nodes not relay non-standard signatures, and eventually disallow them from being included in new blocks entirely.

Proofer: in "because the latter transactions will depend on the previous transactions": latter -> later

2014-02-11T15:11:30Z

in "because the latter transactions will depend on the previous transactions": latter -> later

← Older revision		Revision as of 15:11, 11 February 2014
Line 1:		Line 1:
	While transactions are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash, the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the ~~latter~~ transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block. (and potentially even after a confirmation if the block chain is reorganized) In addition clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe.		While transactions are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated. Note that this just changes the hash, the output of the transaction remains the same and the bitcoins will go to their intended recipient. However this does mean that, for instance, it is not safe to accept a chain of unconfirmed transactions under any circumstance because the later transactions will depend on the hashes of the previous transactions, and those hashes can be changed until they are confirmed in a block. (and potentially even after a confirmation if the block chain is reorganized) In addition clients must always actively scan for transactions to them; assuming a txout exists because the client created it previously is unsafe.

	== Signature Malleability ==		== Signature Malleability ==

Petertodd: Fix references, add categories

2013-01-21T02:49:51Z

Fix references, add categories

← Older revision		Revision as of 02:49, 21 January 2013
Line 12:		Line 12:

	Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin.		Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin.

			==References==
			<references/>

			[[Category:Technical]]
			[[Category:Developer]]