Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <moon@justmoon.de>) id 1RgM3k-0005DE-MG
	for bitcoin-development@lists.sourceforge.net;
	Thu, 29 Dec 2011 19:54:40 +0000
X-ACL-Warn: 
Received: from sulfur.webpack.hosteurope.de ([217.115.142.104])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1RgM3i-0007ad-QL for bitcoin-development@lists.sourceforge.net;
	Thu, 29 Dec 2011 19:54:40 +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 1RgM3c-0003c8-Im; Thu, 29 Dec 2011 20:54:32 +0100
Message-ID: <4EFCC574.1030901@justmoon.de>
Date: Thu, 29 Dec 2011 20:54:28 +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>
	<CABsx9T06H29R4CpL9hXF_yyB4chko1YdkhbCZ8rdwo1gLmF1BQ@mail.gmail.com>
	<alpine.LRH.2.00.1112291143220.22327@theorem.ca>
	<CABsx9T1Hu7Yg-gWUZsRirpNjzYayySJvaVihKGnuntF2rBdmBA@mail.gmail.com>
In-Reply-To: <CABsx9T1Hu7Yg-gWUZsRirpNjzYayySJvaVihKGnuntF2rBdmBA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------060600040103070108020100"
X-bounce-key: webpack.hosteurope.de;moon@justmoon.de;1325188478;9d2863c7;
X-Spam-Score: 0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RgM3i-0007ad-QL
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: Thu, 29 Dec 2011 19:54:40 -0000

This is a multi-part message in MIME format.
--------------060600040103070108020100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> RE: delaying EVAL rollout:  I could live with rolling out just BIP 11
> (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and
> delaying EVAL rollout on the main network, but I worry that will just
> encourage people to delay thoroughly reviewing/testing for a couple of
> months, and we'll be right back here at the beginning of March.

How about releasing it on testnet first? If you want "less smart" people 
such as myself to help test, well I don't think I would get anywhere if 
I tried to abstractly reason about every possibility. Low-level testing 
is certainly important, but for me "thorough testing" requires an actual 
network of nodes (running different clients) and applications capable of 
creating and verifying real OP_EVAL transactions.

My suggestion would be: Deploy OP_EVAL on testnet quickly, let's build 
some real-life applications and if it works well, /then /let's pull the 
trigger for mainnet. If some issues or improvements arise, we'll have a 
chance to adjust it and try again.

I don't think this is too conservative or paranoid. I think this is a 
textbook use case for testnet.


On 12/29/2011 7:00 PM, Gavin Andresen wrote:
> RE: preventing OP_EVAL from executing the result of calculations:
>
>> This is not adequate:<data>  OP_SHA256 OP_EVAL runs random code that is more>  than 5 bytes.
> Good point, the rule should be "OP_EVAL shall fail if asked to execute
> 8 or fewer bytes."
>
> RE: this minor disadvantage:
>
>>>   OP_EVALs are not executed, and so the code associated with them does
>>> not have to be part of the transaction, if they are in the
>>> non-executed branch of an OP_IF. That could be good for privacy, and
>>> could be good for reducing block-chain size.
>> I don't understand the above paragraph.
> It is the "Either This or That can redeem" case that motivated me to
> allow 2-deep EVAL recursion.
>
> Start with the most straightforward code for doing "this or that" (in
> pseudocode):
>
> scriptSig:<sigs>  <either the code for This or the code for That>
> scriptPuKey:
>    IF<hash of code>  EQUALS hash of This or hash of That:
>      EVAL
>    ELSE
>      fail validation
>    ENDIF
>
> That can be done with CODESEPARATOR/CODEHASH.
>
> But if you want to then bundle that up so the scriptPubKey is a
> standard 'pay to script', you get:
>
> scriptSig:<sigs>  <either the code for This or the code for That>
> <serialized IF... code from above>
> scriptPubKey:  ... standard DUP HASH160<>  EQUALVERIFY EVAL
>
> To be backwards compatible with old clients the scriptSig would have to be:
>
> <hash1>  <hash2>  <sigs>  CODESEPARATOR this_or_that_code
>   CODEHASH
>   CODESEPARATOR
>   IF<hash of code>  does not equal hash2:
>     fail verification
>   ENDIF
>
> That could only be done if the definition of CODEHASH was modified to
> hash only the stuff between CODESEPARATORS instead of hashing from
> CODESEPARATOR to the end of the scriptSig.
>
> RE: static analysis:
>
>> Yes, but maybe there is other static analysis miners may want to do.  I
>> can't imagine every scenario.
> The vast majority of miners are "discouraging" (not relaying or
> putting into blocks) anything besides 'standard' transaction types.
>
> Until somebody smarter than me (like Russell) has done a deep analysis
> of Script and all of its opcodes, I don't think that should change.
> The standard transaction types are easy to reason about, and the
> standard types extended with OP_EVAL are also easy to reason about--
> you can template-match them to find out how many ECDSA operations a
> CHECKMULTISIG will do, etc.
>
> Again, in practice, I don't think EVAL as proposed is a danger.
>
> RE: delaying EVAL rollout:  I could live with rolling out just BIP 11
> (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and
> delaying EVAL rollout on the main network, but I worry that will just
> encourage people to delay thoroughly reviewing/testing for a couple of
> months, and we'll be right back here at the beginning of March.
>


--------------060600040103070108020100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <blockquote type="cite">
      <pre wrap="">RE: delaying EVAL rollout:  I could live with rolling out just BIP 11
(up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and
delaying EVAL rollout on the main network, but I worry that will just
encourage people to delay thoroughly reviewing/testing for a couple of
months, and we'll be right back here at the beginning of March.</pre>
    </blockquote>
    <br>
    How about releasing it on testnet first? If you want "less smart"
    people such as myself to help test, well I don't think I would get
    anywhere if I tried to abstractly reason about every possibility.
    Low-level testing is certainly important, but for me "thorough
    testing" requires an actual network of nodes (running different
    clients) and applications capable of creating and verifying real
    OP_EVAL transactions.<br>
    <br>
    My suggestion would be: Deploy OP_EVAL on testnet quickly, let's
    build some real-life applications and if it works well, <i>then </i>let's
    pull the trigger for mainnet. If some issues or improvements arise,
    we'll have a chance to adjust it and try again.<br>
    <br>
    I don't think this is too conservative or paranoid. I think this is
    a textbook use case for testnet.<br>
    <br>
    <br>
    On 12/29/2011 7:00 PM, Gavin Andresen wrote:
    <blockquote
cite="mid:CABsx9T1Hu7Yg-gWUZsRirpNjzYayySJvaVihKGnuntF2rBdmBA@mail.gmail.com"
      type="cite">
      <pre wrap="">RE: preventing OP_EVAL from executing the result of calculations:

</pre>
      <blockquote type="cite">
        <pre wrap="">This is not adequate: &lt;data&gt; OP_SHA256 OP_EVAL runs random code that is more&gt; than 5 bytes.
</pre>
      </blockquote>
      <pre wrap="">Good point, the rule should be "OP_EVAL shall fail if asked to execute
8 or fewer bytes."

RE: this minor disadvantage:

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">&nbsp;OP_EVALs are not executed, and so the code associated with them does
not have to be part of the transaction, if they are in the
non-executed branch of an OP_IF. That could be good for privacy, and
could be good for reducing block-chain size.
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">I don't understand the above paragraph.
</pre>
      </blockquote>
      <pre wrap="">
It is the "Either This or That can redeem" case that motivated me to
allow 2-deep EVAL recursion.

Start with the most straightforward code for doing "this or that" (in
pseudocode):

scriptSig:  &lt;sigs&gt; &lt;either the code for This or the code for That&gt;
scriptPuKey:
  IF &lt;hash of code&gt; EQUALS hash of This or hash of That:
    EVAL
  ELSE
    fail validation
  ENDIF

That can be done with CODESEPARATOR/CODEHASH.

But if you want to then bundle that up so the scriptPubKey is a
standard 'pay to script', you get:

scriptSig:  &lt;sigs&gt; &lt;either the code for This or the code for That&gt;
&lt;serialized IF... code from above&gt;
scriptPubKey:  ... standard DUP HASH160 &lt;&gt; EQUALVERIFY EVAL

To be backwards compatible with old clients the scriptSig would have to be:

&lt;hash1&gt; &lt;hash2&gt; &lt;sigs&gt; CODESEPARATOR this_or_that_code
 CODEHASH
 CODESEPARATOR
 IF &lt;hash of code&gt; does not equal hash2:
   fail verification
 ENDIF

That could only be done if the definition of CODEHASH was modified to
hash only the stuff between CODESEPARATORS instead of hashing from
CODESEPARATOR to the end of the scriptSig.

RE: static analysis:

</pre>
      <blockquote type="cite">
        <pre wrap="">Yes, but maybe there is other static analysis miners may want to do. &nbsp;I
can't imagine every scenario.
</pre>
      </blockquote>
      <pre wrap="">
The vast majority of miners are "discouraging" (not relaying or
putting into blocks) anything besides 'standard' transaction types.

Until somebody smarter than me (like Russell) has done a deep analysis
of Script and all of its opcodes, I don't think that should change.
The standard transaction types are easy to reason about, and the
standard types extended with OP_EVAL are also easy to reason about--
you can template-match them to find out how many ECDSA operations a
CHECKMULTISIG will do, etc.

Again, in practice, I don't think EVAL as proposed is a danger.

RE: delaying EVAL rollout:  I could live with rolling out just BIP 11
(up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and
delaying EVAL rollout on the main network, but I worry that will just
encourage people to delay thoroughly reviewing/testing for a couple of
months, and we'll be right back here at the beginning of March.

</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------060600040103070108020100--