Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rhky6-0004G8-Ob for bitcoin-development@lists.sourceforge.net; Mon, 02 Jan 2012 16:42:38 +0000 X-ACL-Warn: Received: from erdos.theorem.ca ([72.2.4.176] helo=theorem.ca) by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1Rhky5-0000Ae-FS for bitcoin-development@lists.sourceforge.net; Mon, 02 Jan 2012 16:42:38 +0000 Received: (qmail 21282 invoked by uid 603); 2 Jan 2012 16:42:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Jan 2012 16:42:31 -0000 Date: Mon, 2 Jan 2012 11:42:31 -0500 (EST) From: roconnor@theorem.ca To: Gavin Andresen In-Reply-To: Message-ID: References: <1325148259.14431.140661016987461@webmail.messagingengine.com> <4F01C9D8.10107@justmoon.de> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -1.3 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Rhky5-0000Ae-FS 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 16:42:38 -0000 Seems ... acceptable from first glance. Though I propose an ammendent to either (1) make the script: OP_NOP1 HASH160 EQUAL to make it extremely easy to see from the first byte that this is verly likely to be a special transaction (or more accurately if the first byte isn't OP_NOP1 then you immediately know it isn't a special script and can even disregard the token). or (2) If you are feel like spending another byte make the script: OP_NOP1 and assign 1 to this special script, making this case: OP_NOP1 OP_1 HASH160 EQUAL On Mon, 2 Jan 2012, Gavin Andresen wrote: > 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 script>". > > -- Russell O'Connor ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''