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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RhkHz-0002oS-U6 for bitcoin-development@lists.sourceforge.net; Mon, 02 Jan 2012 15:59:07 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=gavinandresen@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RhkHz-0004cn-9O for bitcoin-development@lists.sourceforge.net; Mon, 02 Jan 2012 15:59:07 +0000 Received: by wibhq7 with SMTP id hq7so12827976wib.34 for ; Mon, 02 Jan 2012 07:59:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.132.219 with SMTP id o69mr13979484wei.4.1325519941167; Mon, 02 Jan 2012 07:59:01 -0800 (PST) Received: by 10.223.156.77 with HTTP; Mon, 2 Jan 2012 07:59:00 -0800 (PST) In-Reply-To: <4F01C9D8.10107@justmoon.de> References: <1325148259.14431.140661016987461@webmail.messagingengine.com> <4F01C9D8.10107@justmoon.de> Date: Mon, 2 Jan 2012 10:59:00 -0500 Message-ID: From: Gavin Andresen To: Stefan Thomas Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1RhkHz-0004cn-9O Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Alternative to OP_EVAL 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, 02 Jan 2012 15:59:08 -0000 Here are my latest thoughts on a safer OP_EVAL alternative, inspired by all the ideas and agitated IRC and email discussions of the last week or so: Goal: Let users publish a short "funding address" that is the hash of an arbitrary redemption Script revealed when they spend the funds, implemented in a backwards-compatible-in-the-blockchain way. Proposal: A new 'standard' transaction type, "pay to Script hash": scriptPubKey: HASH160 EQUAL Redeemed with the same scriptSig as the OP_EVAL proposal: Old clients/miners will ignore and just validate that the hash of matches. New clients/miners will recognize the new type of transaction and will do the following additional validation: 1. Fail validation if there were any operations other than "push data" in the original scriptSig. 2. Deserialize the top (last) item on the scriptSig stack (fail validation if it fails to deserialize properly). 3. Run an additional validation on the deserialized script, using the remaining items on the scriptSig stack and the deserialized script as the scriptPubKey. --------------- As Amir said in IRC chat today, "the idea is a hack.... but I like it." I like it, too-- it is cleaner than OP_EVAL, more straightforward to implement, and pretty much exactly matches the feature I care about (moving code from the scriptPubKey to the scriptSig). There are no special cases like "CODESEPARATORS not allowed in ". -- -- Gavin Andresen