Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 74.125.82.52 as permitted sender)
	client-ip=74.125.82.52; envelope-from=jgarzik@bitpay.com;
	helo=mail-wg0-f52.google.com; 
MIME-Version: 1.0
In-Reply-To: <201307290517.54624.luke@dashjr.org>
References: <CAPaL=UV9ytoDc-0U148QSbtq=QHFAY1N=nV_1h_dRW12F6YVhA@mail.gmail.com>
	<201307290517.54624.luke@dashjr.org>
Date: Mon, 29 Jul 2013 02:00:10 -0400
Message-ID: <CAJHLa0Oe4YT+DnEiVxN_tykMQ8YPtyKTf3K7kb0B-9CHoHSy7g@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Opcode whitelist for P2SH?
Precedence: list

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.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/