BIP 12 explained \ stacker news ~bitcoin

What is BIP12? BIP12 stands for Bitcoin Improvement Proposal 12. It describes a new opcode (OP_EVAL) for the Bitcoin scripting system and introduces a new 'standard' transaction type that utilizes this opcode. The main goal of BIP12 is to enable "end-to-end" secure wallets and payments for complex transactions while maintaining backward compatibility for old clients and miners.
Motivation: The motivation behind BIP12 is to allow the receiver of bitcoins to specify the transaction type needed to re-spend them. This eliminates the need for the sender to know the specific details of how the bitcoins may be redeemed. As a result, one new type of bitcoin address can be used to fund arbitrarily complex transactions.
Specification: The proposal introduces the new opcode, OP_EVAL, which redefines the existing OP_NOP1 opcode. Here's how OP_EVAL will function:
- During transaction verification, OP_EVAL pops the item from the top of the stack, deserializes it, and executes the resulting script.
- If there is no item on the top of the stack or if the item is not a valid script, then transaction validation fails.
- If there are any OP_CODESEPARATORs in the deserialized script, then transaction validation fails.
- If there are any OP_EVALs in the deserialized script, they are also executed, but recursion is limited to a depth of 2.
- Transaction verification must fail if interpreting OP_EVAL as a no-op would cause the verification to fail.
The new standard transaction type (scriptPubKey) using OP_EVAL is defined as follows:
```
DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL
```
This new scriptPubKey is redeemed by a standard scriptSig format:
```
...signatures... {serialized script}
```
Transactions that redeem standard OP_EVAL scriptPubKeys are only considered standard if the serialized script is, itself, one of the standard transaction types.
Rationale: OP_EVAL allows the recipient of bitcoins to determine how they can be spent when they are spent. This shift in responsibility from the sender to the receiver enables "end-to-end" secure wallets and complex transactions without the sender needing to know the intricate details. Additionally, this reduces the burden of transaction fees on the sender, as the receiver can specify complex scripts, and the sender only needs to know the hash of the serialized script.

While there are some objections to OP_EVAL due to added complexity and security concerns, the proposal argues that the entire Bitcoin scripting system already involves interpreting data as code, and the existence of OP_EVAL does not make it less secure.
Backwards Compatibility: Surprisingly, because OP_EVAL redefines the OP_NOP1 opcode, standard OP_EVAL transactions will validate with old clients and miners. The old clients will interpret OP_EVAL as a no-op, and as long as the hash is correct, the transaction will be considered valid (no signature checking will be done by old clients and miners).

Old clients will ignore OP_EVAL transactions and transactions that depend on them until they are included in blocks by either old miners that include non-standard transactions or new miners.

To avoid a blockchain split by malicious OP_EVAL transactions, careful handling of invalid cases for both new and old clients/miners is necessary.