From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V3i5V-0001MC-Tk for bitcoin-development@lists.sourceforge.net; Mon, 29 Jul 2013 07:41:50 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.110 as permitted sender) client-ip=62.13.148.110; envelope-from=pete@petertodd.org; helo=outmail148110.authsmtp.com; Received: from outmail148110.authsmtp.com ([62.13.148.110]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V3i5T-0002oE-6b for bitcoin-development@lists.sourceforge.net; Mon, 29 Jul 2013 07:41:49 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r6T7fb7R044010; Mon, 29 Jul 2013 08:41:37 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6T7fWum047192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 Jul 2013 08:41:34 +0100 (BST) Date: Mon, 29 Jul 2013 03:41:31 -0400 From: Peter Todd To: Jeff Garzik Message-ID: <20130729074131.GA23180@savin> References: <201307290517.54624.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 4b7786b5-f822-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAsUEkAYAgsB AmUbW1xeVFx7WmY7 bAxPbAVDY01GQQRq WVdMSlVNFUsqB3gG UHlbDxl2cARPejBx YUZgVj5fDkN9fUAv R1MCHW8EeGZhPWIC AURRJB5UcAFPdx9C bVB4BXJDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4sBjU7 Sx1KAjUuAUABRj4v ZxIhMBYkRn0xZS0A X-Authentic-SMTP: 61633532353630.1021:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1V3i5T-0002oE-6b Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Opcode whitelist for P2SH? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:41:50 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 29, 2013 at 02:00:10AM -0400, Jeff Garzik wrote: > On Mon, Jul 29, 2013 at 1:17 AM, Luke-Jr wrote: > > On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote: > >> What are your thoughts on creating a whitelist for specific opcodes th= at > >> 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 d= ata > >> in the UTXO set) > > > > This would be reasonable for miners, but for interoperability between w= allets, > > some specific standard forms would still be necessary without a much sm= arter > > solver (which would then expand the code required to implement a wallet= , which > > is unfortunate if not entirely necessary). >=20 > 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. --=20 'peter'[:-1]@petertodd.org 00000000000000220b76f98fc9414043f765ec48dba3fb556e096caffbaae8ec --/04w6evG8XlLl3ft Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9hyrAAoJECSBQD2l8JH76FEH/AuCpPc+tspYn0p4kCJiXwNI BHzHp5Puwy/VNoiLLE81klkn6gwrNuKlKnqhTOfGV3enFFFS18sw3VWYmBJSU0pd O0naU5y72sWtc2/d59diQxKnJuM9gXei5t+M3FJ1HcL6pWA7D0ca0xUvZFR5gWDV EUQeR279A82RKim3KaCBmn5ScJUP1f6S53eRbG3NeDzu/dlKJYgr24J9Z/uGqzqp Z/EsYZSJMvOzt8UGPr3eC+f5P36ql9u65y/Sh7yPgKH690owzQrs/lZl+2zjDFs6 UxjuN8m2LsL8lEtFjX8ahha+KnZ+rnogEPdtO4+Kgn5ytnt1fbeBBuLqpdQ+hEc= =J707 -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft--