Opcode whitelist for P2SH?

Peter Todd recently came up with two related, and IMO very good, uses for non-standard transactions to implement both oracles and one-time-password protection of wallet funds. While the wallet fund case could be implemented as only a single standard type, at the cost of generality, the oracle case would be most useful with more arbitrary rules. More generally it is also useful to be able to have scriptPubKeys like the following:

    n <pubkey>...<pubkey> m CHECKMULTISIG <master pubkey> CHECKSIG BOOLOR

and many other similar constructions.

What are your thoughts on creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH, retaining the existing standard whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set)

I'm thinking it should contain the following opcodes, picked for either being already used, or having simple semantics:

0 to 75 byte pushdata PUSHDATA1

1NEGATE OP 1 to OP16 (numbers are allowed through pushdata anyway)

IF NOTIF ELSE ENDIF VERIFY RETURN

TOALTSTACK FROMALTSTACK (the alt-stack makes stack manipulation in complex ways possible) DROP DUP SWAP

EQUAL EQUALVERIFY

0NOTEQUAL BOOLAND BOOLOR

RIPEMD160 SHA1 SHA256 HASH160 HASH256

CHECKSIG CHECKSIGVERIFY CHECKMULTISIG CHECKMULTISIGVERIFY

Note how this list allows for complex logic, but does not allow for arithmetic, thus not exposing us to a source of problems in the past.

On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote:

> What are your thoughts on creating a whitelist for specific opcodes that
> would apply to scripts serialized using P2SH, retaining the existing
> standard whitelist for scriptPubKeys? (I would still recommend dropping
> pay-to-pubkey and pay-to-multisig due to their potential for dumping data
> in the UTXO set)

This would be reasonable for miners, but for interoperability between wallets, some specific standard forms would still be necessary without a much smarter solver (which would then expand the code required to implement a wallet, which is unfortunate if not entirely necessary).

On Mon, Jul 29, 2013 at 1:17 AM, Luke-Jr <luke@dashjr•org> wrote:

> On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote:
>> What are your thoughts on creating a whitelist for specific opcodes that
>> would apply to scripts serialized using P2SH, retaining the existing
>> standard whitelist for scriptPubKeys? (I would still recommend dropping
>> pay-to-pubkey and pay-to-multisig due to their potential for dumping data
>> in the UTXO set)
>
> This would be reasonable for miners, but for interoperability between wallets,
> some specific standard forms would still be necessary without a much smarter
> solver (which would then expand the code required to implement a wallet, which
> is unfortunate if not entirely necessary).

Indeed. Current designs are all based around pattern matching a script template. Satoshi even described lightweight clients as needing no script engine at all, only the ability to match patterns.

On Mon, Jul 29, 2013 at 02:00:10AM -0400, Jeff Garzik wrote:

> On Mon, Jul 29, 2013 at 1:17 AM, Luke-Jr <luke@dashjr•org> wrote:
> > On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote:
> >> What are your thoughts on creating a whitelist for specific opcodes that
> >> would apply to scripts serialized using P2SH, retaining the existing
> >> standard whitelist for scriptPubKeys? (I would still recommend dropping
> >> pay-to-pubkey and pay-to-multisig due to their potential for dumping data
> >> in the UTXO set)
> >
> > This would be reasonable for miners, but for interoperability between wallets,
> > some specific standard forms would still be necessary without a much smarter
> > solver (which would then expand the code required to implement a wallet, which
> > is unfortunate if not entirely necessary).
>
> Indeed.  Current designs are all based around pattern matching a
> script template.  Satoshi even described lightweight clients as
> needing no script engine at all, only the ability to match patterns.

We're talking about two use-cases here: wallets protected by authorization tokens for multi-factor security, and allowing funds to be controlled by oracles that attest that events have happened allowing the funds to move.

The latter application especially demands a specialized wallet, yet can only possibly work with non-standard script formats.

IMO bringing the issue of wallet standardization into this discussion is kinda silly and premature; if you don't want to use those features, then you're wallet can ignore them. As for the people that are, they can come up with appropriate standards for their needs.

After all John's suggesting only allowing the loosened IsStandard() rules within P2SH, so until the txout is spent all *any* wallet sees is a P2SH address with no information as to what scriptPubKey is needed to spend it.

On Sun, Jul 28, 2013 at 07:39:08PM +0000, John Dillon wrote:

> Peter Todd recently came up with two related, and IMO very good, uses for
> non-standard transactions to implement both oracles and one-time-password
> protection of wallet funds. While the wallet fund case could be implemented as
> only a single standard type, at the cost of generality, the oracle case would
> be most useful with more arbitrary rules. More generally it is also useful to
> be able to have scriptPubKeys like the following:
>
>     n <pubkey>...<pubkey> m CHECKMULTISIG <master pubkey> CHECKSIG BOOLOR
>
> and many other similar constructions.
>
> What are your thoughts on creating a whitelist for specific opcodes that would
> apply to scripts serialized using P2SH, retaining the existing standard
> whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pubkey
> and pay-to-multisig due to their potential for dumping data in the UTXO set)

One subtlety of what you are proposing is that we should still retain the IsStandard() check, or to be exact the AreInputsStandard() check, if a P2SH serialized script follows a standard form.

The reason is transaction mutability. Right now other than BIP11 CHECKMULTISIG only miners can mutate transactions because any change to the scriptSig will render the transaction non-standard. As you know this is a good thing because it means unconfirmed transaction chains don't get broken in flight.

BIP11 is an interesting case because CHECKMULTISIG consumes one extra stack item, so when you spend a BIP11 n <pubkey>...<pubkey> m CHECKMULTISIG scriptPubKey you have to provide an additional item prior to the signatures; usually OP_0 is used.

But we don't actually check that! You can put anything there provided it doesn't make the scriptSig go over the standard allowed scriptSig size of 500 bytes; for instance I (ab)used that feature just now to timestamp my Litecoin v0.8.3.6 audit report SHA256 hash:

d0dfe270e8e8e4c0196f780d42e34d8a1121f2f8a249586aa1a2c5ebcada10b1

in transaction:

15bb08318335f94a8de154dc39b03db2cdebcc7a96ab6cec0379978676d00301

It's been suggested that we consider transactions non-standard, or just now allowed at all in a future soft-fork, if at the end of execution there is more than one stack item left; a opcode whitelist should probably do this. On the other hand I've come up with some soft-fork upgrade mechanisms that would leave extra items on the stack for non-upgraded nodes, suggesting a soft-fork imposing this is a bad idea. (though note how it suggests considering such tx's non-standard is reasonable in a few ways)

CHECKMULTISIG isn't helped here because the value really is ignored - a soft-fork to force it to always be zero might not be a bad idea, though it's far from the only example of mutability.

I'd be interested if you can come up with an example where imposing a one stack item at the end of execution rule causes problems.

More generally, and getting a bit off topic, I think Bitcoin should have been designed so that CHECKSIG signed hashes of scriptPubKeys, rather than txid:vout outputs, so that malleability wouldn't affect the validity of a signature. Of course, this would mean that signatures could be reused if scriptPubKeys were reused, but address re-use is a bad thing anyway! Not that I'll fault Satoshi here, type 2 deterministic wallets were unknown back then. (though we should be careful that a future CHECKSIG design can go back to txid:vout references - ECC is unique in allowing for type 2 wallets)