Re: [Bitcoin-development] Opcode whitelist for P2SH?

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

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.

-- 
'peter'[:-1]@petertodd.org
00000000000000220b76f98fc9414043f765ec48dba3fb556e096caffbaae8ec

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]