Bitcoin Script Engineering part IV
There has long been a belief that Bitcoin is lacking one crucial fundamental feature to perform smart-contracts that Ethereum has:

The ability to carry forward conditions/states (through its script) from one transaction output into the next one (of the transaction spending it).

OP_PUSH_TX — is the technique that makes it possible (a method, invented by nChain).

Below is a proper implementation of Bitcoin script-template of this part.

Namely, a one that has been heavily tested and has no redundancies.

In the generic template below, for a variable sighash any 4 constant values from ECDSA signing formula (corresponding a particular pair of ephemeral k and private key) may be used (and various sighash flags):

1) “r*privateKey” => Private key multiplied by r.

2) “inverse k” — inverse of ephemeral k value, used in ECDSA formula.

3) “r for DER” — Part of the DER format including r value prepended by “02” and the length of the r and appended with additional “02”.

4) “Public Key”.

5) “sighash flag”.

A working example of the template with 4 constants corresponding to specific pair of ECDSA ephemeral k and private key (and “ALL | FORKID” flags):

Its size is 612 bytes and it’s published on Bitcoin’s global ledger here (and another version of the same size here).

Another size reduction could be achieved through a use of a specific k and private key values.

Making it possible to substitute ”< r*privateKey > OP_ADD < inverse k > OP_MUL” code part with just single ”OP_1ADD” command.

It results in 512 bytes script size -100 bytes reduction. Published on the ledger here.

Note, other choices of “r” could result in a substitution with commands of addition of any other desired value to sighash, e.g. “OP_2 OP_ADD” or “FFFFFFFF OP_ADD” etc., but will only increase script size relatively to the template posted above (doing it with only one command).

This code may be used for any type of stateful smart-contracts.

It went through thorough optimization and any further non-negligible size reduction is not expected to be feasible (e.g. removing modulo operation for its low probability of failure and as a result removing the division of n by 2 is not optimization worth of bothering).

For any change of terms, license or contact details, this output will be spent and all the updated information will be found in the spending transaction’s new output.
[]
['Script Engineering', 'Stateful Smart Contracts', 'Smart Contracts', 'Op Push Tx', 'Bitcoin Script']