Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XleBE-0007US-S9 for bitcoin-development@lists.sourceforge.net; Tue, 04 Nov 2014 13:29:52 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.173 as permitted sender) client-ip=209.85.213.173; envelope-from=pieter.wuille@gmail.com; helo=mail-ig0-f173.google.com; Received: from mail-ig0-f173.google.com ([209.85.213.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XleBD-0004Il-Vd for bitcoin-development@lists.sourceforge.net; Tue, 04 Nov 2014 13:29:52 +0000 Received: by mail-ig0-f173.google.com with SMTP id r10so6657769igi.12 for ; Tue, 04 Nov 2014 05:29:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.162.16 with SMTP id l16mr9602037ioe.54.1415107786711; Tue, 04 Nov 2014 05:29:46 -0800 (PST) Received: by 10.50.98.40 with HTTP; Tue, 4 Nov 2014 05:29:46 -0800 (PST) Date: Tue, 4 Nov 2014 05:29:46 -0800 Message-ID: From: Pieter Wuille To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 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 (pieter.wuille[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 X-Headers-End: 1XleBD-0004Il-Vd Subject: [Bitcoin-development] BIP62 and future script upgrades 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: Tue, 04 Nov 2014 13:29:53 -0000 Hi all, one of the rules in BIP62 is the "clean stack" requirement, which makes passing more inputs to a script than necessary illegal. Unfortunately, this rule needs an exception for P2SH scripts: the test can only be done after (and not before) the second stage evaluation. Otherwise it would reject all spends from P2SH (which rely on "superfluous" inputs to pass data to the second stage). I submitted a Pull Request to clarify this in BIP62: https://github.com/bitcoin/bips/pull/115 However, this also leads to the interesting observation that the clean-stack rule is incompatible with future P2SH-like constructs - which would be very useful if we'd ever want to deploy a "Script 2.0". Any such upgrade would suffer from the same problem as P2SH, and require an exception in the clean-stack rule, which - once deployed - is no longer a softfork. Luke suggested on the pull request to not apply this rule on every transaction with nVersion >= 3, which indeed solves the problem. I believe this can easily be generalized: make the (non mandatory) BIP62 rules only apply to transaction with strict nVersion==3, and not to higher ones. The higher ones are non-standard anyway, and shouldn't be used before there is a rule that applies to them anyway - which could include some or all of BIP62 if wanted at that point still. Opinions?