(a and b) OR c transactions | Bitcointalksearch.org

Quote from: Gavin Andresen on December 01, 2011, 08:57:52 PM

If you make them a 2-of-3-to-redeem, is that the same as an (a and b) OR c transaction?

If I recall correctly, the impediment to implementing (a AND b) OR c transactions is that it should be spendable if you have c, even if you have lost all knowledge of a and/or b. So the knowledge of c has to make the knowledge of a and b redundant. In standard OP_EVAL solutions, all the information identifying a,b and c have to be contained in the transaction. If a or b are changed or forgotten then recreating the hash of the script is impossible and hence the transaction will fail.

So when redeeming an (a and b) transaction, the scriptPubKey is the standard DUP HASH160 EQUALVERIFY EVAL.
The client start off the scriptSig with 0 and then complete it with a stored serialized script "[2 2 OP_CHECKMULTISIG]" which hashes to scriptHash.

To get the (a and b) or c functionality, we keep the same scriptPubKey and when redeeming using both a and b keys, the client fills it in the normal way with 0 . However the stored script is "[2 2 CHECKMULTISIG][ DROP CHECKSIGVERIFY EVAL]" so in this case it's two chunks of serialized script on both sides of a signature. The scriptHash in this case is the hash of "[ DROP CHECKSIGVERIFY EVAL]" and is calculated so that CHECKSIGVERIFY will succeed when called on "0 [2 2 OP_CHECKMULTISIG] "

So the total script executed in normal circumstances is

0 [2 2 CHECKMULTISIG][ DROP CHECKSIGVERIFY EVAL] DUP HASH160 EQUALVERIFY EVAL

If all trace of keys a and b have been forgotten then the transaction is redeemed in a different way by using the knowledge of the private key for key c to generate a new signature such that CHECKSIGVERIFY succeeds when called on "[TRUE] "

So the total script executed in the event that keys a and b are lost is

[TRUE] [ DROP CHECKSIGVERIFY EVAL] DUP HASH160 EQUALVERIFY EVAL

It's unfortunate that the private key for c needs to be kept around to create the sandwiched signature which is different for different pubkeys a or b but I doubt there is a way round that without considerably increasing the complexity of the transaction (or scripting language). Fortunately, if a range of pubkeys and are known in advance, the signatures for each pair can be generated at the time and stored in the wallet. The private key for c can then be erased from the computer and kept in a safe.

The DROPed parameter is intended to be an easily bruteforced number which serves to make different for different or otherwise a transaction requiring or c would have the same address as

or c. If the wallet is lost then the stored scripts which tie the to the pairs are lost. To redeem the transactions using the secret key for in the safe, the value of must be searched until the hash of "[ DROP CHEKCSIGVERIFY EVAL]" matches the address of the transaction to be redeemed.

So, indeed, recursive EVALs have their uses.

ByteCoin

Topic: (a and b) OR c transactions (Read 997 times)