For an arbitrary nonempty set M, we denote the concatenation of two elements A, B ∈ M as A ⋅ B, and naturally extend this notion to any finite number of elements. By M∗ we denote all finite concatenations of elements of M, including the empty string ɛ, and with M ⁺ we denote M∗ without ɛ. A stack over M is any element A ₀ ⋅ A ₁⋯A _k ∈ M∗. Intuitively, this string over M represents a stack containing A ₀ as the top element, A ₁ as the element below the top one, etc. Notice that we allow the empty stack, which is denoted by the empty string ɛ.

Script has two stacks at its disposal: the main stack, denoted by φ _M , and an alternate stack, denoted by φ _A , that can be accessed by a few of the operators. Hence, the stacks of Script shall be denoted as the pair (φ _M , φ _A ). To manipulate these stacks, we use functions top and tail, defined as follows: top: M ⁺ → M is used to return the top of the stack, that is top(A ₀⋅A ₁⋅…⋅A _k ) = A ₀, while tail: M ⁺ → M∗ is used to return the stack below the first element, that is, tail(A ₀⋅A ₁⋅…⋅A _k ) = A ₁⋅…⋅A _k . Notice that the result of tail can be the empty stack ɛ.

For simplicity, we assume that data items in Script come from the set Z . ⁴ This is a natural generalization when studying the complexity of the unlockability problem for Script.

Script has a precisely defined set of allowed operations (Bitcoin Wiki, 2021), which can be thought of as transforming the two stacks, or giving an error that terminates the execution. We denote the set of Script operators with O. Formally, every Script command f, apart from those used for flow control (see Section 3.2.3), can be understood as a function which takes the main and the alternate stack as its inputs, and transforms them in some way, or produces an error (denoted by □): f : ( Z ∗ × Z ∗ ) ∪ { □ } → ( Z ∗ × Z ∗ ) ∪ { □ } . (1)

Thus, scripts–as functions–can be composed, which naturally allows us to define the semantics of a sequence of operators. In particular, to handle errors, we impose the restriction that all of Script operators return an error when the input is an error itself, that is, f(□) = □.

With this notation at hand, we define how each operator f ∈ O works. We start by introducing in Section 3.2.1 a group of basic operators, and defining how a sequence of them is executed. Then we describe in Section 3.2.2 how the operators associated with cryptographic primitives work. Finally, we introduce in Section 3.2.3 the flow control operators and the control stack, which determine when an operator should or should not be executed. A summary of the operators used in this paper, without including the control flow operators, is given in Table 1. Readers familiar with the Script syntax as given in (Bitcoin Wiki, 2021) may note that a small number of the operators are not included in this table. For space reasons we have left out several operators that are similar to or can be simulated by applying instead a constant number of other operators. This includes, as explained bellow, merging all push operators into a single family of operators, arithmetic operators OP_1ADD and OP_1SUB for adding or subtracting one from the top of the stack, OP_NEGATE to flip the sign of the top of the stack, OP_ABS for the absolute value, binary operations OP_NOT, OP_0NOTEQUAL, OP_BOOLAND and OP_BOOLOR, number comparison operators OP_NUMEQUAL, OP_NUMEQUALVERIFY, OP_NUMNOTEQUAL, which are not useful under the assumption that elements in the stack are numbers, and comparison operators OP_LESSTHAN, OP_GREATERTHAN, OP_LESSTHANOREQUAL, OP_GREATERTHANOREQUAL, OP_MIN, OP_MAX and OP_WITHIN. Reserved words are not included because they immediately make transactions invalid, and similarly for pseudo words OP_PUBKEYHASH, OP_PUBKEY and OP_INVALIDOPCODE. An operator-by-operator check allows one to verify that none of these operators alter the results presented in this paper, and in particular the PTIME upper bound shown later on in the paper continues to hold. Furthermore, we have also left out locktime-related operators OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY, because they require checking the nLockTime field of transactions and this is not part of our model. Finally, we will comment on the cryptographic operators on Section 3.2.2; we have also left out some of them but once again the complexity analysis does not change.

The evaluation problem for Script is defined as follows:

As explained in Section 2, the unlocking script u, and the locking script l are executed separately in order to strengthen the security of Script. That is, we first run the unlocking script with a triple of empty stacks. Provided that this execution is successful, the content of the main stack at the end of this execution, denoted by φ M u , is transferred to the locking script, whose execution starts with an empty alternate stack and an empty control stack. In fact, as per the current specification (Bitcoin Wiki, 2021), and implementation (Github, 2010) of Script, the alternate stack content is erased when starting the execution of the locking script. Recall from Section 3 the fact that a successful execution also requires the script to start and finish with an empty control stack, to validate that flow control commands are properly nested and completed within both the locking and the unlocking script. From now on, when the answer to the previous question is positive, then we say that the pair of scripts u and l executes successfully.

Moreover, the unlockability of Script problem is defined as follows:

While the main objective of this paper is studying unlockability of Script, we will start by proving the folklore result saying that any script can be evaluated in polynomial time. We do this to show that our formalization of Script conforms with the intuitive understanding of the language. It is important to note that if we were to add some simple operators to Script that may seem unassuming, this property could cease to be true. In fact, previous versions of the language were able to produce scripts that could not be evaluated in polynomial time. To illustrate this notion we introduce the currently disabled O P_MUL operator. Let φ M = A 0 ⋅ … ⋅ A k , φ A ∈ Z ∗ and φ _I ∈ {1}∗. We define the semantics of OP_MUL as follows. If |φ _M |≥ 2, then OP _ MUL ( φ M , φ A , φ I ) = ( A 0 ∗ A 1 ⋅ A 2 ⋅ … ⋅ A k , φ A , φ I ) , where ∗ signifies the multiplication of integer numbers. Now we can prove that using OP_MUL we can create scripts that can not be evaluated in polynomial time. The following lemma gives an insight as to how this is possible.

Lemma 4.1

There exists a script S = f 0 ⋅ … ⋅ f n ∈ ( { OP _ PUSH 2 , OP _ MUL , OP _ DUP } ) ∗ , such that ( f n ◦ … ◦ f 0 ) ( ε , ε , ε ) = ( A , ε , ε ) and A ≥ 2 2 cn , for some c > 0.

Proof

For this, consider the script S = OP _ PUSH 2 ⋅ OP _ DUP ⋅ OP _ MUL ⋅ OP _ DUP ⋅ OP _ MUL ⋅ … ⋅ OP _ DUP ⋅ OP _ MUL .

The main idea of the proof is that this script will end its execution with 2 2 m at the top of the main stack, where m is the number of repetitions of the OP_DUP⋅OP_MUL sequence of operators.

More formally, let m ∈ N be an arbitrary number and S_m = OP_PUSH₂⋅(OP_DUP⋅OP_MUL)^m. Then: S m ( ε , ε , ε ) = ( 2 2 m , ε , ε ) .

This can be easily shown by mathematical induction on m.

Base case. Consider S₀ = OP_PUSH₂. Then we trivially have S 0 ( ε , ε , ε ) = ( 2 , ε , ε ) = ( 2 1 , ε , ε ) = ( 2 2 0 , ε , ε ) .

Inductive step. Suppose that for an arbitrary number i ∈ N , we have that S i ( ε , ε , ε ) = ( 2 2 i , ε , ε ) . Now, we can note that S_i+1 = S_i⋅(OP_DUP⋅OP_MUL). Thus, we have that S i + 1 ( ε , ε , ε ) = ( OP _ MUL ◦ OP _ DUP ) ( S i ( ε , ε , ε ) ) = ( OP _ MUL ◦ OP _ DUP ) ( 2 2 i , ε , ε ) = ( 2 2 i ∗ 2 2 i , ε , ε ) = ( 2 2 i + 1 , ε , ε ) .

From Lemma 4.1 we can conclude that it is possible to construct a stack that has an element that is double exponential in magnitude and therefore exponential in size compared to the amount of operators in the script that is being executed ⁵ . Moreover, as each used operator is constant in size, the size of the constructed element is also exponential in the size of the script. This means that it is not possible to write, save or use such an element in polynomial time compared to the size of our script. Thus, such a script could not be evaluated in polynomial time. A similar result can be obtained for some other operators that were supported in the original proposal of Script, such as for instance OP_CAT. In light of this result, disabling some operators seems well justified [see (Bitcoin Wiki, 2021) for the full list of disabled operators].

Taking this result into consideration, it is important to prove that with the current definition of Script, any script can be evaluated in polynomial time. Letting Ptime be the class of problems that can be solved in polynomial time, we have the following:

Theorem 4.2

The problem Evaluation of Script is in Ptime.

Proof

The proof proceeds in four steps. First, we show that Script operators, by themselves, do not introduce transformations that produce drastic changes in the stack. We then show that this remains true when analyzing sequences of operators. This, in turn, allows us to show that the execution time of a script over an empty stack is actually in polynomial time, from which the proof of this theorem readily follows.

We start by defining three auxiliary functions that will help us establish some properties over the execution of operators: function maxelem : Z ∗ × Z ∗ → N obtains the size of the biggest element in a stack (independent of its sign), function elemnr : Z ∗ → N obtains the amount of elements in a stack, and maxpush : O ∗ → N provides the maximum element pushed by a script, independent of its sign.

Let S = f₀⋅…⋅f_n ∈ O∗, φ M = A 0 ⋅ … ⋅ A k ∈ Z ∗ and φ A = B 0 ⋅ … ⋅ B ℓ ∈ Z ∗ . We define the values of these functions as follows; maxelem ( φ M , φ A ) = max A ∈ { A 0 , … , A k } ∪ { B 0 , … , B ℓ } | A | elemnr ( φ ) = k + 1 maxpush ( S ) = max { | C | : OP _ PUSH C ∈ { f 0 , … , f n } }

As the reader might have already noticed, empty stacks provides for edge cases in which maxelem is not defined, and likewise for maxpush, and so they must be accounted for separately. To that extent, let S′ = g₀⋅…⋅g_m ∈ O∗ such that { g 0 , … , g m } ∩ { OP _ PUSH C ∣ C ∈ Z } = ∅ . Then we have that: maxelem ( ε , ε ) = 0 maxpush ( S ′ ) = 0

As we mentioned in our proof strategy, our first task is to show that none of the operators in Script produces a stack that explodes in size. In formal terms, this translates to restrictions for the auxiliary functions introduced previously.

Lemma 4.3

Let f ∈ O, φ M ∈ Z ∗ , φ A ∈ Z ∗ and φ_I ∈ {0,1}∗ such that f ( φ M , φ A , φ I ) = ( φ M ′ , φ A ′ , φ I ′ ) . Then we have that: elemnr ( φ M ′ ) ≤ elemnr ( φ M ) + 3

Moreover, assume that f ∉ { OP _ DEPTH , OP _ HASH 160 } ∪ { OP _ PUSH C ∣ C ∈ Z } . Then we have maxelem ( φ M ′ , φ A ′ ) ≤ 2 ⋅ maxelem ( φ M , φ A ) + 1

Proof

For this proof one needs a one-by-one analysis showing that each of the operators of Script satisfies these bounds. We give a few examples of how this is proved for some particular operators, the full details for the entire Script language are provided as Supplemental Material.

We show how to prove the bound on elemnr using the OP_3DUP operator. For an arbitrary pair of stacks φ M = A 0 ⋅ … ⋅ A k ∈ Z ∗ and φ A ∈ Z ∗ , φ I ∈ { 1 } ∗ , if these stacks fulfill the conditions for the OP_3DUP operator, then we have that OP _ 3 DUP ( φ M , φ A , φ I ) = ( φ M ′ , φ A ′ , φ I ′ ) = ( A 0 ⋅ A 1 ⋅ A 2 ⋅ φ M , φ A , φ I ) , or, in other words, OP_3DUP pushes elements A₀, A₁ and A₂ onto φ_M. This means that elemnr ( φ M ′ ) = elemnr ( φ M ) + 3 , which was to be shown.

For the bound on the size maxelem of elements in the stack, we use the OP_ADD operator to illustrate the proof. Again, for an arbitrary pair of stacks φ M = A 0 ⋅ … ⋅ A k ∈ Z ∗ , φ A ∈ Z ∗ , φ I ∈ { 1 } ∗ , if these stacks fulfill the conditions for the OP_ADD operator, then we have that OP _ ADD ( φ M , φ A , φ I ) = ( φ M ′ , φ A ′ , φ I ′ ) = ( ( A 0 + A 1 ) ⋅ A 2 ⋅ … ⋅ A k , φ A , φ I ) .

It is clear that |A₀|, …, |A_k| ≤ maxelem(φ_M), hence we have that | A 0 | + | A 1 | ≤ 2 ⋅ maxelem ( φ M ) ≤ 2 ⋅ maxelem ( φ M ) + 1 .

By combining both results we can conclude that maxelem ( φ M ′ ) ≤ 2 ⋅ maxelem ( φ M ) + 1 , which was to be shown. ■ □

Our next step is to use the bounds presented above to provide upper bounds on the values of these functions over the execution of complete scripts. These bounds must take into account the size of the stacks, so we need to discuss how these are encoded. For our complexity results, we assume that stacks are represented as arrays of integer elements. Assuming that the elements in the stacks are represented in binary notation, and that we use one extra bit to represent the sign of each number, we define the size ‖φ‖ of a stack φ = A 0 ⋅ … ⋅ A k ∈ Z ∗ as: ‖ φ ‖ = ∑ i = 0 k log 2 ( | A i | + 1 ) .

From this definition, we can derive the following bounds: log 2 ( maxelem ( φ , ε ) + 1 ) ≤ ‖ φ ‖ (3) elemnr ( φ ) ≤ ‖ φ ‖ (4)

These bounds will help us in relating several results that make use of the auxiliary functions with the size of the representation of the stack. This is useful because we will be interested in establishing a relationship between the runtime of executing a script with an initial stack and the sizes of the inputs.

Let us now turn to (upper) bound the values of the auxiliary functions. In particular, we need to prove that the different elements of the stacks, during the execution of a script, are of polynomial-size in the sizes of the script and the initial stack. This idea is formalized in the following lemma; the proof is once again by a direct examination of each operator.

Lemma 4.4

Let S = f₀⋅…⋅f_n ∈ O∗ and φ M ∈ Z ∗ . After any partial execution (f_i◦…◦f₀)(φ_M, ɛ, ɛ), the following conditions hold.

1. The amount of elements that can appear in the main stack is bounded by elemnr(φ_M) + 3(n + 1).

We finally have all the ingredients to provide the upper bound on the execution time of script evaluation. For this result we consider a naïve algorithm that receives as input a script S = f₀⋅…⋅f_n ∈ O∗ and a stack φ ∈ Z ∗ and executes each operator in sequence over the stack. This is without loss of generality, as using faster, more involved algorithms can only decrease the total running time of the operations. In what follows we use T to denote the execution time of said algorithm, having in mind that the full execution involves working over a trio of stacks (the main stack, the alt-stack and the auxiliary stack for the IF-ELSE control flow). Therefore, we treat T as a function T : O ∗ × Z ∗ × Z ∗ × { 0,1 } ∗ → N .

Lemma 4.5

Let S = f₀⋅…⋅f_n ∈ O∗ and φ ∈ Z ∗ . Then we have that T ( S , φ , ε , ε ) ≤ p T ( n , ‖ φ ‖ , log 2 ( maxpush ( S ) + 1 ) ) for some fixed polynomial p_T (independent of S and φ).

The proof of this lemma is by induction, using Lemma 4.4 and Lemma 4.3 for the inductive and base cases.

Having established that the execution time of the algorithm that applies a script to an initial stack can be executed in polynomial time, we can move on to prove that script evaluation is in Ptime. As we have previously discussed, an algorithm that performs script evaluation starts by executing an unlocking script over a trio of empty stacks and then, if the final control stack is empty, it executes a locking script over the previous final main stack and two empty stacks. Thus, all we need to do is to show that both of these operations take polynomial time when executed sequentially. This is shown in the following lemma. Note that we only have consider the case in which the unlocking script that the algorithm receives does not result in an error and that finishes with an empty control stack; the remaining cases imply an early stop in the algorithm so they are also captured by the bounds for a complete execution.

Lemma 4.6

Let S_L = f₀⋅…⋅f_n ∈ O∗ and S_U = g₀⋅…⋅g_m ∈ O∗, such that ( g m ◦ … ◦ g 0 ) ( ε , ε , ε ) = ( φ M , φ A , ε ) .

Then, there is a fixed polynomial p_emp (independent of S_L and S_U) such that: T ( S U , ε , ε , ε ) + T ( S L , φ M , ε , ε ) ≤ p e m p ( m , n , log 2 ( maxpush ( S U ) + 1 ) , log 2 ( maxpush ( S L ) + 1 ) )

Proof

Let S_L = f ₀⋅…⋅f _n ∈ O∗ and S_U = g ₀⋅…⋅g _m ∈ O∗, such that ( g m ◦ … ◦ g 0 ) ( ε , ε , ε ) = ( φ M , φ A , ε ) .

From Lemma 4.5 there is a fixed polynomial p_T and the following bound on T(S_U, ɛ, ɛ, ɛ): T ( S U , ε , ε , ε ) ≤ p T ( m , ‖ ε ‖ , log 2 ( maxpush ( S U ) + 1 ) ) ≤ p U ( m , log 2 ( maxpush ( S U ) + 1 ) ) , where p_U is again a fixed polynomial. We can also bound T(S_L, φ_M, ɛ, ɛ) in the same way: T ( S L , φ M , ε , ε ) ≤ p T ( n , ‖ φ M ‖ , log 2 ( maxpush ( S L ) + 1 ) ) .

Moreover, from Lemma 4.4 we can also bound ‖φ_M‖: ‖ φ M ‖ ≤ p size ( m , ‖ ε ‖ , log 2 ( maxpush ( S U ) + 1 ) ) .

By combining both of these bounds we can conclude that T ( S L , φ M , ε , ε ) ≤ p L ( m , n , log 2 ( maxpush ( S U ) + 1 ) , log 2 ( maxpush ( S L ) + 1 ) ) , for some polynomial p_L. Furthermore, adding equations for both executions over S_L and S_U, we obtain: T ( S U , ε , ε , ε ) + T ( S L , φ M , ε , ε ) ≤ p U ( m , log 2 ( maxpush ( S U ) + 1 ) ) + p L ( m , n , log 2 ( maxpush ( S U ) + 1 ) , log 2 ( maxpush ( S L ) + 1 ) ) ≤ p e m p ( m , n , log 2 ( maxpush ( S U ) + 1 ) , log 2 ( maxpush ( S L ) + 1 ) ) , where p_emp is a fixed polynomial independent of S_L and S_U. ■ □

Note that we have not included the validity checks that need to be performed between the executions of both scripts and also at the end of the execution of the locking script to determine whether the execution was successful. This is because these checks can be performed in constant time and do not impact the complexity analysis of the problem. This concludes the proof of the Theorem.

The evaluation of a pair of scripts can be done efficiently, but what about checking whether a script is unlockable? Recall that the Unlockability of Script problem receives a locking script l, and consists of checking whether there exists any unlocking script u such that l and u result in a positive answer when evaluated together.

Unfortunately, the following result tells us that this problem cannot be solved efficiently.

Theorem 4.7

The problem Unlockability of Script is NP-hard.

Proof

To prove the theorem, we provide a polynomial-time reduction from 3SAT, which is a well-known NP-complete problem. Let ψ = C₀ ∧ C₁ ∧…∧C_m be a formula in CNF, where each clause C_i is the conjunction of three literals: C i = u i , 0 ∨ u i , 1 ∨ u i , 2 , that is, each u_i,j is either a propositional variable x or the negation of a propositional variable ¬x. Besides, assume that {x₀, x₁, …, x_k} is the set of variables occurring in ψ. Next, we show how to construct in polynomial-time a script l_ψ that can be used to check whether ψ is satisfiable.

By definition of the problem Unlockability of Script, the script l_ψ has to be executed over the main stack resulting from the execution of an unlocking script. Thus, l_ψ interprets such a stack as a truth assignment for the formula ψ, and verifies whether such an assignment satisfies this formula. In this way, an unlocking script for l_ψ represents a truth assignment satisfying ψ, so that ψ is satisfiable if and only if l_ψ is unlockable. More precisely, we define l_ψ as follows: l ψ ≔ l length ⋅ l binary ⋅ l sat ⋅ l end where each script l_length, l_binary, l_sat, l_end are as defined below.

• The script l_length checks whether the stack that it receives as input contains k + 1 elements (which is the number of variables occurring in ψ):

Thus, l val i , 0 puts the value assigned to the propositional variable x_r in the top of the stack. On the other hand, if u_i,0 = ¬x_r for some r ∈ {0, …, k}, then l val i , 0 ≔ OP _ PUSH 1 ⋅ OP _ PUSH r + 1 ⋅ OP _ PICK ⋅ OP _ SUB .

Hence, l val i , 0 puts the value assigned to ¬x_r in the top of the stack (this value is obtained by subtracting the value assigned of x_j from 1). Similarly, if u_i,1 = x_s for some s ∈ {0, …, k}, then l val i , 1 ≔ OP _ PUSH s + 1 ⋅ OP _ PICK .

Thus, l val i , 1 puts the value assigned to x_s in the top of the stack. Notice that the operator OP_PUSH_s+1 has to be used as the stack contains the extra value computed by the script l val i , 0 . In the same way, if u_i,1 = ¬x_s for some s ∈ {0, …, k}, then l val i , 1 ≔ OP _ PUSH 1 ⋅ OP _ PUSH s + 2 ⋅ OP _ PICK ⋅ OP _ SUB , so that the value assigned to ¬x_s is put in the top of the stack by l val i , 1 . Moreover, l val i , 2 is defined in the same way but considering that the stack contains the extra values computed by the scripts l val i , 0 and l val i , 1 . Finally, l add ≔ OP _ ADD ⋅ OP _ ADD ⋅ OP _ VERIFY , which allows us to add the values for the three literals in the clause. If at least one of them is positive, the result is greater than 0 and the execution of OP_VERIFY is successful. Otherwise, the result is 0 and the execution of OP_VERIFY fails.

• Finally, we have that:

From the definition of l_ψ, it is straightforward to prove that ψ is satisfiable if and only if l_ψ is unlockable, and that l_ψ can be constructed in polynomial time in the size of ψ. Hence, we have provided a polynomial-time reduction form 3SAT to the problem Unlockability of Script, thus showing that the latter is NP-hard.