Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <moon@justmoon.de>) id 1RhlPF-0006GK-Uh
	for bitcoin-development@lists.sourceforge.net;
	Mon, 02 Jan 2012 17:10:41 +0000
X-ACL-Warn: 
Received: from sulfur.webpack.hosteurope.de ([217.115.142.104])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1RhlPE-00015Q-Ey for bitcoin-development@lists.sourceforge.net;
	Mon, 02 Jan 2012 17:10:41 +0000
Received: from 84-72-69-153.dclient.hispeed.ch ([84.72.69.153]
	helo=[192.168.0.21]); authenticated
	by sulfur.webpack.hosteurope.de running ExIM with esmtpsa
	(TLSv1:AES256-SHA:256)
	id 1RhlP8-0001VJ-Bh; Mon, 02 Jan 2012 18:10:34 +0100
Message-ID: <4F01E501.3070605@justmoon.de>
Date: Mon, 02 Jan 2012 18:10:25 +0100
From: Stefan Thomas <moon@justmoon.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
	<1325148259.14431.140661016987461@webmail.messagingengine.com>
	<alpine.LRH.2.00.1112291135040.22327@theorem.ca>
	<CALn1vHHjY6Qq0zEUcWaNzm_eP_JekjrK26zMXfcrfPSydwSKig@mail.gmail.com>
	<alpine.LRH.2.00.1112301214380.9419@theorem.ca>
	<4F01C9D8.10107@justmoon.de>
	<CABsx9T3gNNmPen=WtCpG8RCChSwpJ73r7WU2Kz_fP31wAQ+jQg@mail.gmail.com>
In-Reply-To: <CABsx9T3gNNmPen=WtCpG8RCChSwpJ73r7WU2Kz_fP31wAQ+jQg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-bounce-key: webpack.hosteurope.de;moon@justmoon.de;1325524240;19b8f7ba;
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RhlPE-00015Q-Ey
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 02 Jan 2012 17:10:42 -0000

+1. I love this proposal.

It's two less bytes than OP_EVAL even.
It allows static analysis.
It doesn't require any change to the script interpreter. (You can do a 
static replacement step between parsing and execution.)
It allows all urgent use cases.
It doesn't consume a NOP. If we ever want recursion or something else, 
we can still add OP_EVAL,... then.

@roconnor:
> 1. make the script: OP_NOP1 HASH160 <push-20-byte-hash> 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). 

I disagree. If people actually do mean HASH160 <hash> EQUAL, let *them* 
add a NOP. Or better to avoid NOP let them use HASH160 <hash> 
EQUALVERIFY 1. Point is, if you don't want code replacement you can 
easily break the pattern. But code replacement will be overwhelmingly 
more common, so it should be as small as possible. Every byte matters.


On 1/2/2012 4:59 PM, 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<push-20-byte-hash>   EQUAL
>
> Redeemed with the same scriptSig as the OP_EVAL proposal:
> <signatures>  <serialized Script>
>
> Old clients/miners will ignore<signatures>  and just validate that the
> hash of<serialized Script>  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<serialized
> script>".
>