Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V3g6c-0008Pa-4S for bitcoin-development@lists.sourceforge.net; Mon, 29 Jul 2013 05:34:50 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V3g6a-0001eI-A2 for bitcoin-development@lists.sourceforge.net; Mon, 29 Jul 2013 05:34:50 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:222:4dff:fe50:4c49]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 6D67B27A2965 for ; Mon, 29 Jul 2013 05:17:57 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Mon, 29 Jul 2013 05:17:53 +0000 User-Agent: KMail/1.13.7 (Linux/3.7.10-gentoo; KDE/4.10.4; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307290517.54624.luke@dashjr.org> 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 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1V3g6a-0001eI-A2 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 05:34:50 -0000 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).