OP CHECKSIGEX DRAFT BIP - Revision history

Taras at 05:14, 10 January 2015

2015-01-10T05:14:40Z

← Older revision		Revision as of 05:14, 10 January 2015
Line 144:		Line 144:

	[[Category:BIP\|D]]		[[Category:BIP\|D]]
			{{displaytitle:OP_CHECKSIGEX DRAFT BIP}}

Luke-jr: moved BIP 0022 to OP CHECKSIGEX DRAFT BIP

2012-03-04T02:13:03Z

moved BIP 0022 to OP CHECKSIGEX DRAFT BIP

← Older revision		Revision as of 02:13, 4 March 2012
(No difference)

Casascius: In deference to Gavin, I am marking this as rejected/abandoned

2012-02-03T15:48:40Z

In deference to Gavin, I am marking this as rejected/abandoned

← Older revision		Revision as of 15:48, 3 February 2012
Line 3:		Line 3:
	Title: OP_CHECKSIGEX		Title: OP_CHECKSIGEX
	Author: Mike Caldwell <mcaldwell@swipeclock.com>		Author: Mike Caldwell <mcaldwell@swipeclock.com>
	Status: ~~Draft~~		Status: Rejected/Abandoned
	Type: Standards Track		Type: Standards Track
	Created: 31-01-2012		Created: 31-01-2012

Casascius at 17:06, 1 February 2012

2012-02-01T17:06:39Z

← Older revision		Revision as of 17:06, 1 February 2012
Line 125:		Line 125:

	The inner evaluation script processing loop SHOULD NOT contain any references or use any pointers to the stacks belonging to the outer loop. The inner evaluation script processing loop MUST NOT provide any access whatsoever to the stacks used by the outer loop - not read access, not write access. The inner processing loop MUST receive as its sole inputs a dedicated copy of the two binary blob parameters (''sigs'' and ''pubKeyEx'') that were popped off the stack, along with any information incidental to validating signatures (i.e. the computed hash of the transaction script). The inner processing loop MUST NOT be able to return any data to the outer loop that invoked it - other than transaction failure or validation success (identical in behavior to the current implementation of OP_CHECKSIG returning success, which is to push a 0 or 1 to the outer stack).		The inner evaluation script processing loop SHOULD NOT contain any references or use any pointers to the stacks belonging to the outer loop. The inner evaluation script processing loop MUST NOT provide any access whatsoever to the stacks used by the outer loop - not read access, not write access. The inner processing loop MUST receive as its sole inputs a dedicated copy of the two binary blob parameters (''sigs'' and ''pubKeyEx'') that were popped off the stack, along with any information incidental to validating signatures (i.e. the computed hash of the transaction script). The inner processing loop MUST NOT be able to return any data to the outer loop that invoked it - other than transaction failure or validation success (identical in behavior to the current implementation of OP_CHECKSIG returning success, which is to push a 0 or 1 to the outer stack).

			==OP_CHECKSIGVERIFY would follow==
			OP_CHECKSIGVERIFY would also be renamed to OP_CHECKSIGVERIFYEX and would remain backwards compatible, but would acquire the functionality added to OP_CHECKSIGEX. This actually keeps the Bitcoin code base simpler and smaller.

			The current implementation in Bitcoin's ''script.cpp'' of both OP_CHECKSIG and OP_CHECKSIGVERIFY are the same, sharing the same "case" block in the Bitcoin code. They do exactly the same thing, except that OP_CHECKSIGVERIFY has a single extra if-statement which completely fails the transaction if the signature check fails, and leaves behind no result on the stack upon success. This if-statement would be preserved so OP_CHECKSIGVERIFYEX does the same thing.

	==Notes==		==Notes==

Casascius: /* Avoiding Turing completeness surprises */

2012-02-01T17:00:42Z

Avoiding Turing completeness surprises

← Older revision		Revision as of 17:00, 1 February 2012
Line 124:		Line 124:
	The implementation of the evaluation script processor MUST be implemented as a simple nested loop within the outer script processor. The evaluation script processing MUST NOT be implemented as a recursive call to the same loop that handles the outer script operations.		The implementation of the evaluation script processor MUST be implemented as a simple nested loop within the outer script processor. The evaluation script processing MUST NOT be implemented as a recursive call to the same loop that handles the outer script operations.

	The inner evaluation script processing loop SHOULD NOT contain any references or use any pointers to the stacks belonging to the outer loop. The inner evaluation script processing loop MUST NOT provide any access whatsoever to the stacks used by the outer loop - not read access, not write access. The inner processing loop MUST receive as its sole inputs a dedicated copy of the two binary blob parameters (''sigs'' and ''pubKeyEx'') that were popped off the stack, along with any information incidental to validating signatures (i.e. the computed hash of the transaction script). The inner processing loop MUST NOT be able to return any data to the outer loop that invoked it - other than transaction failure ~~(which terminates script processing)~~ or validation success (identical in behavior to the current implementation of OP_CHECKSIG returning success).		The inner evaluation script processing loop SHOULD NOT contain any references or use any pointers to the stacks belonging to the outer loop. The inner evaluation script processing loop MUST NOT provide any access whatsoever to the stacks used by the outer loop - not read access, not write access. The inner processing loop MUST receive as its sole inputs a dedicated copy of the two binary blob parameters (''sigs'' and ''pubKeyEx'') that were popped off the stack, along with any information incidental to validating signatures (i.e. the computed hash of the transaction script). The inner processing loop MUST NOT be able to return any data to the outer loop that invoked it - other than transaction failure or validation success (identical in behavior to the current implementation of OP_CHECKSIG returning success, which is to push a 0 or 1 to the outer stack).

	==Notes==		==Notes==

Dooglus: /* Backwards Compatibility */ typo, confirmed in https://bitcointalk.org/index.php?topic=62037.msg725518#msg725518

2012-02-01T06:48:07Z

Backwards Compatibility: typo, confirmed in https://bitcointalk.org/index.php?topic=62037.msg725518#msg725518

← Older revision		Revision as of 06:48, 1 February 2012
Line 117:		Line 117:
	Importantly, transactions in the new format still look at best like regular transactions in the old format to old clients. There is no foreseen way to trick an old client into redeeming a new transaction (for example, by exploiting a deprecated interpretation of OP_NOP as meaning "do nothing").		Importantly, transactions in the new format still look at best like regular transactions in the old format to old clients. There is no foreseen way to trick an old client into redeeming a new transaction (for example, by exploiting a deprecated interpretation of OP_NOP as meaning "do nothing").

	A suggested implementation is to program the client such that the functionality is enabled only on Testnet, and on the main Bitcoin network once a certain level of voting consensus has been established into the block chain. So long as the functionality is disabled, OP_CHECKSIG shall ~~fail~~ so long as the expected parameters of one single signature and one single private key are provided.		A suggested implementation is to program the client such that the functionality is enabled only on Testnet, and on the main Bitcoin network once a certain level of voting consensus has been established into the block chain. So long as the functionality is disabled, OP_CHECKSIG shall succeed so long as the expected parameters of one single signature and one single private key are provided.

	==Avoiding Turing completeness surprises==		==Avoiding Turing completeness surprises==

Casascius: /* Avoiding Turing completeness surprises */

2012-02-01T05:05:31Z

Avoiding Turing completeness surprises

← Older revision		Revision as of 05:05, 1 February 2012
Line 120:		Line 120:

	==Avoiding Turing completeness surprises==		==Avoiding Turing completeness surprises==
	In order to minimize the possibility of a later discovery of a Turing complete script engine, the following ~~implementation~~ details are recommended and/or required for implementers.		In order to minimize the possibility of a later discovery that the proposal resulted in the accidental implementation of a Turing complete script engine, the following details are recommended and/or required for implementers.

	The implementation of the evaluation script processor MUST be implemented as a simple nested loop within the outer script processor. The evaluation script processing MUST NOT be implemented as a recursive call to the same loop that handles the outer script operations.		The implementation of the evaluation script processor MUST be implemented as a simple nested loop within the outer script processor. The evaluation script processing MUST NOT be implemented as a recursive call to the same loop that handles the outer script operations.

Casascius: /* Avoiding Turing completeness surprises */

2012-02-01T05:05:01Z

Avoiding Turing completeness surprises

← Older revision		Revision as of 05:05, 1 February 2012
Line 124:		Line 124:
	The implementation of the evaluation script processor MUST be implemented as a simple nested loop within the outer script processor. The evaluation script processing MUST NOT be implemented as a recursive call to the same loop that handles the outer script operations.		The implementation of the evaluation script processor MUST be implemented as a simple nested loop within the outer script processor. The evaluation script processing MUST NOT be implemented as a recursive call to the same loop that handles the outer script operations.

	The inner evaluation script processing loop SHOULD NOT contain any references or use any pointers to the stacks belonging to the outer loop. The inner evaluation script processing loop MUST NOT provide any access whatsoever to the stacks used by the outer loop - not read access, not write access. The inner processing loop MUST receive as its sole inputs the two binary blob parameters (''sigs'' and ''pubKeyEx'') that were popped off the stack, along with any information incidental to validating signatures (i.e. the computed hash of the transaction script). The inner processing loop MUST NOT be able to return any data to the outer loop that invoked it - other than transaction failure (which terminates script processing) or validation success (identical in behavior to the current implementation of OP_CHECKSIG returning success).		The inner evaluation script processing loop SHOULD NOT contain any references or use any pointers to the stacks belonging to the outer loop. The inner evaluation script processing loop MUST NOT provide any access whatsoever to the stacks used by the outer loop - not read access, not write access. The inner processing loop MUST receive as its sole inputs a dedicated copy of the two binary blob parameters (''sigs'' and ''pubKeyEx'') that were popped off the stack, along with any information incidental to validating signatures (i.e. the computed hash of the transaction script). The inner processing loop MUST NOT be able to return any data to the outer loop that invoked it - other than transaction failure (which terminates script processing) or validation success (identical in behavior to the current implementation of OP_CHECKSIG returning success).

	==Notes==		==Notes==

Casascius: /* Backwards Compatibility */

2012-02-01T05:03:45Z

Backwards Compatibility

← Older revision		Revision as of 05:03, 1 February 2012
Line 112:		Line 112:

	New transactions are non-standard to old implementations. But old implementations will generate transactions that are fully compatible with the new format. Sending Bitcoins to multisignature addresses as defined in this proposal will not break old clients, but redeeming them will. Regardless, old implementations will be rendered incompatible once such extended transactions appear on the network.		New transactions are non-standard to old implementations. But old implementations will generate transactions that are fully compatible with the new format. Sending Bitcoins to multisignature addresses as defined in this proposal will not break old clients, but redeeming them will. Regardless, old implementations will be rendered incompatible once such extended transactions appear on the network.

			Old implementations would fail gracefully as they built their own fork of the chain that continued to include regular transaction but would omit multisig spends as well as respends of those same coins. Old clients would see and record Bitcoins paid to multisig addresses normally (since the transactions are standard and look just like non-multisig transactions), but would not be able to see those Bitcoins ever come back from multisig addresses to regular ones. The most likely failure mode an old client would see is an inability to see received Bitcoins from a new client if those coins had participated in a previous multisig transaction.

	Importantly, transactions in the new format still look at best like regular transactions in the old format to old clients. There is no foreseen way to trick an old client into redeeming a new transaction (for example, by exploiting a deprecated interpretation of OP_NOP as meaning "do nothing").		Importantly, transactions in the new format still look at best like regular transactions in the old format to old clients. There is no foreseen way to trick an old client into redeeming a new transaction (for example, by exploiting a deprecated interpretation of OP_NOP as meaning "do nothing").

Casascius: /* Backwards Compatibility */

2012-02-01T04:11:26Z

Backwards Compatibility

← Older revision		Revision as of 04:11, 1 February 2012
Line 111:		Line 111:
	==Backwards Compatibility==		==Backwards Compatibility==

	New transactions are non-standard to old implementations. But old implementations will generate transactions that are fully compatible with the new format. Regardless, old implementations will be rendered incompatible once such extended transactions appear on the network.		New transactions are non-standard to old implementations. But old implementations will generate transactions that are fully compatible with the new format. Sending Bitcoins to multisignature addresses as defined in this proposal will not break old clients, but redeeming them will. Regardless, old implementations will be rendered incompatible once such extended transactions appear on the network.

	Importantly, transactions in the new format still look at best like regular transactions in the old format to old clients. There is no foreseen way to trick an old client into redeeming a new transaction (for example, by exploiting a deprecated interpretation of OP_NOP as meaning "do nothing").		Importantly, transactions in the new format still look at best like regular transactions in the old format to old clients. There is no foreseen way to trick an old client into redeeming a new transaction (for example, by exploiting a deprecated interpretation of OP_NOP as meaning "do nothing").