Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RgKHG-0005Nc-Ce for bitcoin-development@lists.sourceforge.net; Thu, 29 Dec 2011 18:00:30 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=gavinandresen@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RgKHF-0003NI-IX for bitcoin-development@lists.sourceforge.net; Thu, 29 Dec 2011 18:00:30 +0000 Received: by wibhq7 with SMTP id hq7so9726308wib.34 for ; Thu, 29 Dec 2011 10:00:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.139.77 with SMTP id b55mr20443059wej.12.1325181623398; Thu, 29 Dec 2011 10:00:23 -0800 (PST) Received: by 10.223.156.77 with HTTP; Thu, 29 Dec 2011 10:00:23 -0800 (PST) In-Reply-To: References: Date: Thu, 29 Dec 2011 13:00:23 -0500 Message-ID: From: Gavin Andresen To: roconnor@theorem.ca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.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 (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RgKHF-0003NI-IX Cc: Bitcoin Dev 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 18:00:30 -0000 RE: preventing OP_EVAL from executing the result of calculations: > This is not adequate: OP_SHA256 OP_EVAL runs random code that is m= ore> 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: >> =A0OP_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: scriptPuKey: IF 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: scriptPubKey: ... standard DUP HASH160 <> EQUALVERIFY EVAL To be backwards compatible with old clients the scriptSig would have to be: CODESEPARATOR this_or_that_code CODEHASH CODESEPARATOR IF 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. =A0I > 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. --=20 -- Gavin Andresen