<div>I haven&#39;t been much a part of these brainstorming discussions, and so I&#39;m really looking at this from a bird&#39;s eye view, without any bias towards any particular idea. </div><div><br></div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
I do see what appears to be relevant concerns, brought up just before new, powerful functionality is injected into 50%+ of the nodes on the network.  I cannot tell from my position if there is/has been consistent concern for OP_EVAL proposal, or if it&#39;s mostly a transient response to hearing about recursion in the scripting engine, etc (like myself, originally).  I haven&#39;t debated this topic much, so I&#39;m not in a position to personally comment on any proposals.  (Though, this all feels very similar to the problem of <a href="http://www.securityweek.com/hash-table-collision-attacks-could-trigger-ddos-massive-scale">hash-table collisions in HTTP POST</a>). </div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>However, I would like to remind everyone that we/you are messing with a $20+ million dollar <i>thing</i>.  There&#39;s more than just a piece of software at stake -- whatever goes in needs to be as hard as diamond.  If we open up a hole that allows someone to satisfy arbitrary scripts, or create one-packet DoS/crash attacks, that could be devastating for Bitcoin.  Roconner is persuasive enough to make <b>me</b> think that not all corners of this functional space has been explored properly.  And while my opinion doesn&#39;t matter, I&#39;m concerned that others may feel too invested in the current design path to want to &quot;go backwards.&quot;  Again, I don&#39;t know one way or another, I just want to warn against pride getting priority over security.   </div>
<div><br></div><div>At the very least, you should consider consequences and recovery path of such unanticipated problems.  If the things that could go wrong are devastating, let&#39;s lean towards a more conservative solution (like sandboxing the sub-scripting engine).   Remember, the network is working just fine <b>without </b>OP_EVAL, and while OP_EVAL provides some really nice benefits, I don&#39;t think the benefits over regular multi-sig are worth the consequences of making a mistake in this multi-million dollar beast.</div>
<div><br></div><div>Okay, back to your regularly-scheduled debating...</div>
-Alan<br><br><div class="gmail_quote">On Thu, Dec 29, 2011 at 2:08 PM, Pieter Wuille <span dir="ltr">&lt;<a href="mailto:pieter.wuille@gmail.com" target="_blank">pieter.wuille@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Thu, Dec 29, 2011 at 01:55:03AM -0500, <a href="mailto:roconnor@theorem.ca" target="_blank">roconnor@theorem.ca</a> wrote:<br>
&gt; Gavin asked me to come up with an alternative to OP_EVAL, so here is my<br>
&gt; proposal.<br>
&gt;<br>
&gt; OP_CODEHASH Initial Proposal<br>
<br>
</div>If we&#39;re again brainstorming about alternatives for OP_EVAL, I&#39;ll do my own.<br>
<br>
It is called OP_CHECKEDEVAL, and is specified as follows:<br>
* It looks at the two elements most recently (in code position) pushed by a literal,<br>
  and not yet consumed by another OP_CHECKEDEVAL. These are S (the serialized script),<br>
  and H (its hash). This implies it defines its own literal-only stack, where all<br>
  literals push to, and only OP_CHECKEDEVAL pops from. This special stack has the<br>
  advantage of allowing static analysis - one does not need to execute any operations<br>
  to find out which data will end up on it. Note that &quot;skipped&quot; code (inside the<br>
  ignored part of an IF-THEN-ELSE) can still push to the literal stack.<br>
* For the &quot;outer script&quot;, it does not have any effect at all, except for:<br>
  * 2 elements popped from the literal-only stack<br>
  * potentially causing failure<br>
  It does not touch the main stack, alt stack or any other part of the execution state<br>
  not listed above.<br>
* Failure is caused when either of these conditions hold:<br>
  * No two elements remain on the literal-only stack<br>
  * The Hash(S) != H<br>
  * The inner script execution caused failure<br>
* For the execution of the inner script:<br>
  * It is executed in a completely new and independent execution environnement<br>
  * It executes the deserialized S<br>
  * It inherits the main stack and alt stack (without the serialized script and the hash<br>
    themselves) from the outer execution.<br>
<br>
This requires OP_CHECKEDEVAL to immediately follow the push of script and hash,<br>
so the code in the pair &lt; &lt;script&gt; OP_CHECKEDEVAL &gt; can be parsed and interpreted as code,<br>
allowing static analysis.<br>
<br>
As OP_CHECKEDEVAL has absolutely no effects except for potentially causing failure, it<br>
is very similar to the OP_NOPx it would replace, and guarantees that interpreting<br>
OP_CHECKEDEVAL as OP_NOPx can never cause the script to become invalid if it wasn&#39;t<br>
already.<br>
<br>
A basic pay-to-script-hash scriptPubKey is very short:<br>
<br>
  &lt;scriptHash&gt; OP_CHECKEDEVAL<br>
<br>
And it is redeemed using:<br>
<br>
  &lt;script inputs&gt; &lt;script&gt;<br>
<br>
Furthermore, the implementation is very similar to what was already done for<br>
OP_EVAL. Modifications:<br>
* EvalScriptInner needs less by-ref arguments, as it cannot modify the parent&#39;s state.<br>
* A literal-only stack needs to be maintained.<br>
<br>
<br>
I believe this combines all advantages:<br>
* Easy spend-to-script-hash (shorter than OP_EVAL)<br>
* Backward compatible (guaranteed by construction, instead of separately enforced like with OP_EVAL)<br>
* Statically analyzable (though it requires deserializing the script data).<br>
* Possibility to introduce a new language inside (not done in this proposal)<br>
<br>
Only disadvantages:<br>
* Slightly less flexible than OP_EVAL, as it disallows dynamic interation with serialized scripts.<br>
* Static code analyzers need to deserialize script data.<br>
<br>
Credits: gmaxwell for the idea of a literal-only stack<br>
<span><font color="#888888"><br>
--<br>
Pieter<br>
</font></span><div><div><br>
------------------------------------------------------------------------------<br>
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don&#39;t need a complex<br>
infrastructure or vast IT resources to deliver seamless, secure access to<br>
virtual desktops. With this all-in-one solution, easily deploy virtual<br>
desktops for less than the cost of PCs and save 60% on VDI infrastructure<br>
costs. Try it free! <a href="http://p.sf.net/sfu/Citrix-VDIinabox" target="_blank">http://p.sf.net/sfu/Citrix-VDIinabox</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div></div></blockquote></div><br>