Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RgNZH-0004t3-9P for bitcoin-development@lists.sourceforge.net; Thu, 29 Dec 2011 21:31:19 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=etotheipi@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RgNZG-0002R4-2a for bitcoin-development@lists.sourceforge.net; Thu, 29 Dec 2011 21:31:19 +0000 Received: by wibhq7 with SMTP id hq7so9917367wib.34 for ; Thu, 29 Dec 2011 13:31:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.139.25 with SMTP id b25mr26242125wej.41.1325194271870; Thu, 29 Dec 2011 13:31:11 -0800 (PST) Received: by 10.180.101.131 with HTTP; Thu, 29 Dec 2011 13:31:11 -0800 (PST) In-Reply-To: <20111229190838.GA29609@ulyssis.org> References: <20111229190838.GA29609@ulyssis.org> Date: Thu, 29 Dec 2011 16:31:11 -0500 Message-ID: From: Alan Reiner To: Pieter Wuille Content-Type: multipart/alternative; boundary=0016e6d59d69d54dbe04b541d5c8 X-Spam-Score: -0.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 (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 0.0 LOTS_OF_MONEY Huge... sums of money X-Headers-End: 1RgNZG-0002R4-2a 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: Thu, 29 Dec 2011 21:31:19 -0000 --0016e6d59d69d54dbe04b541d5c8 Content-Type: text/plain; charset=ISO-8859-1 I haven't been much a part of these brainstorming discussions, and so I'm really looking at this from a bird's eye view, without any bias towards any particular idea. 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's mostly a transient response to hearing about recursion in the scripting engine, etc (like myself, originally). I haven't debated this topic much, so I'm not in a position to personally comment on any proposals. (Though, this all feels very similar to the problem of hash-table collisions in HTTP POST ). However, I would like to remind everyone that we/you are messing with a $20+ million dollar *thing*. There'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 *me* think that not all corners of this functional space has been explored properly. And while my opinion doesn't matter, I'm concerned that others may feel too invested in the current design path to want to "go backwards." Again, I don't know one way or another, I just want to warn against pride getting priority over security. 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's lean towards a more conservative solution (like sandboxing the sub-scripting engine). Remember, the network is working just fine *without *OP_EVAL, and while OP_EVAL provides some really nice benefits, I don't think the benefits over regular multi-sig are worth the consequences of making a mistake in this multi-million dollar beast. Okay, back to your regularly-scheduled debating... -Alan On Thu, Dec 29, 2011 at 2:08 PM, Pieter Wuille wrote: > On Thu, Dec 29, 2011 at 01:55:03AM -0500, roconnor@theorem.ca wrote: > > Gavin asked me to come up with an alternative to OP_EVAL, so here is my > > proposal. > > > > OP_CODEHASH Initial Proposal > > If we're again brainstorming about alternatives for OP_EVAL, I'll do my > own. > > It is called OP_CHECKEDEVAL, and is specified as follows: > * It looks at the two elements most recently (in code position) pushed by > a literal, > and not yet consumed by another OP_CHECKEDEVAL. These are S (the > serialized script), > and H (its hash). This implies it defines its own literal-only stack, > where all > literals push to, and only OP_CHECKEDEVAL pops from. This special stack > has the > advantage of allowing static analysis - one does not need to execute any > operations > to find out which data will end up on it. Note that "skipped" code > (inside the > ignored part of an IF-THEN-ELSE) can still push to the literal stack. > * For the "outer script", it does not have any effect at all, except for: > * 2 elements popped from the literal-only stack > * potentially causing failure > It does not touch the main stack, alt stack or any other part of the > execution state > not listed above. > * Failure is caused when either of these conditions hold: > * No two elements remain on the literal-only stack > * The Hash(S) != H > * The inner script execution caused failure > * For the execution of the inner script: > * It is executed in a completely new and independent execution > environnement > * It executes the deserialized S > * It inherits the main stack and alt stack (without the serialized script > and the hash > themselves) from the outer execution. > > This requires OP_CHECKEDEVAL to immediately follow the push of script and > hash, > so the code in the pair <