From 612c002c65ed438a50f77d12d545f0c801f29a50 Mon Sep 17 00:00:00 2001
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 11 Jan 2018 14:41:45 +0900
Subject: BIP-0117: Change semantics of multi-element tail call to not require
 stack elements to be exactly 520 bytes in size. This allows for more compact
 direct encoding of scripts of the form "pick 2 of 3 spend conditions" without
 enabling witness malleability in expected use cases as the components would
 still be checked against a pre-committed hash tree.

---
 bip-0117.mediawiki | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

(limited to 'bip-0117.mediawiki')

diff --git a/bip-0117.mediawiki b/bip-0117.mediawiki
index c255d97..f4d1b4a 100644
--- a/bip-0117.mediawiki
+++ b/bip-0117.mediawiki
@@ -42,12 +42,8 @@ while the remaining elements of both stacks remain in place as inputs.
 
 If the above conditions hold except for the last one, such that:
 
-* the top-most element ''is'' a single byte within the inclusive range of <code>0x51</code> (<code>OP_1</code>, meaning N=2) to <code>0x60</code> (<code>OP_16</code>, meaning N=17);
-
-and:
-
-* the next N-1 elements on the main stack (continuing on the alt stack if the main stack is exhausted) are 520 byte pushes; and
-* the following Nth element on the main stack (or alt stack, as above) is between 1 and 520 bytes,
+* the top-most element ''is'' a single byte within the inclusive range of <code>0x51</code> (<code>OP_1</code>, meaning N=2) to <code>0x60</code> (<code>OP_16</code>, meaning N=17); and
+* other than this top-most element there are at least N additional elements on the main stack and alt stack combined,
 
 then the top-most element of the main stack is dropped,
 and the N=2 (<code>0x51</code>) to 17 (<code>0x60</code>) further elements are popped from the main stack,
@@ -102,7 +98,7 @@ The global SIGOP limit and per-script opcode limits do not apply to the policy s
 because dynamic selection of the policy script makes it not possible for static analysis tools to verify these limits in general,
 and because performance improvements to libsecp256k1 and Bitcoin Core have made these limits no longer necessary as they once were.
 The validation costs are still limited by the number of signature operations it is possible to encode within block size limits,
-and the maximum script size per input is still limited to 10,000 bytes.
+and the maximum script size per input is limited to 10,000 + 17*520 = 18,840 bytes.
 
 To allow for this drop of global and per-script limits,
 tail-call evaluation cannot be allowed for direct execution of the scriptPubKey,
-- 
cgit v1.2.3

