Multi-signature transactions

Abstract

Generating a first blockchain transaction Tx1 comprising a first script having a sequence of signature verification sub-scripts each comprising a public key representation. The first script is configured to, when executed with a second script of a second transaction Tx2, output a value per signature verification sub-script indicating whether the second script comprises a signature corresponding one, some or each of the respective public key representations & evaluate a function on the output to determine whether one or more conditions have been satisfied.

Description

TECHNICAL FIELD The present disclosure relates to multi-signature transactions, i.e. blockchain transactions that require multiple signatures in order to be unlocked. BACKGROUND Standard transactions on the blockchain network are sometimes referred to as "singlesignature transactions" because transfers require only one signature — from the owner of the private key associated with the address to which the transaction (e.g. transaction output) is locked. In this context, multi-signature (multisig) refers to the requirement to provide more than one signature to authorize a transaction, e.g. to unlock an output of the transaction. These are often referred to as M-of-N transactions, where any N out of M predetermined participants can sign to unlock a transaction. Accumulator multisig refers to a technique that enables more complex spending conditions utilising OP_IF and OP_ELSE statements, as described in PCT application WO2021 / 053425. SUMMARY The present disclosure describes a multi-signature scheme which may be used to implement more complex (e.g. hierarchical) and / or flexible structures than existing schemes. According to one aspect disclosed herein, there is provided a computer-implemented method of generating a blockchain transaction, wherein the method is performed by a first party and comprises: generating a first transaction, wherein the first transaction comprises a first script, the first script comprising a sequence of respective signature verification subscripts, wherein each respective signature verification sub-script comprises one or more respective public key representations, and wherein the first script is configured to, when executed with a second script of a second transaction: i) produce an output comprising a sequence of respective values, one respective value per respective signature verification sub-script, wherein each respective value indicates whether the second script comprises a respective signature corresponding one, some or each of the one or more respective public key representations of the respective signature verification sub-script, and ii) evaluate a function on the output to determine whether one or more conditions have been satisfied. According to another aspect disclosed herein, there is provided a computer-implemented method of generating a blockchain transaction, wherein the method is performed by a second party and comprises: obtaining a first transaction, wherein the first transaction comprises a first script, the first script comprising a sequence of respective signature verification sub-scripts, wherein each respective signature verification sub-script comprises one or more respective public key representations, and wherein the first script is configured to, when executed with a second script of a second transaction: i) produce an output comprising a sequence of respective values, one respective value per respective signature verification sub-script, wherein each respective value indicates whether the second script comprises a respective signature corresponding one, some or each of the one or more respective public key representations of the respective signature verification sub-script, and i) perform a function on the output to determine whether one or more conditions have been satisfied; and providing, as part of the second transaction, a respective signature corresponding to at least one of the one or more respective public key representations. The first party (e.g. Alice) creates a locking script of a first transaction that evaluates a function which takes the output of the validation of signatures as variables. That is, the locking script validates signatures provided in an unlocking script of a second transaction that references the first transaction. The locking script performed a function (i.e. operation) on the outcome of the validation to determine if a set of conditions are met. The set of conditions must be met in order to unlock the locking script. The locking script enables more flexible and more complex conditions to be imposed when requiring multiple parties to sign, as compared to existing techniques. Boolean functions can be used to capture complex relations and logic between various signing parties, where each variable in a circuit corresponds to a signing party. In this way, Boolean functions may be used to describe transactions where the signing parties have different signing power, and in particular, depending on with who they are signing. Furthermore, monotone Boolean functions may be used to ensure that no party can invalidate a transaction by simply adding their signature, as could be the case for nonmonotone functions. For example, a party could change the output from TRUE to FALSE by adding their signature. That is, an input to the function can be changed from FALSE to TRUE by a party providing a signature, i.e. the input is FALSE when no signature is provided but TRUE when a signature is provided. Whilst examples are primarily described in terms of monotone Boolean functions to prevent a new signer from invalidating a transaction, the process can be generalized to arbitrary functions. The locking script is divided (at least conceptually) into two parts. A vectorization script takes some signatures as input and creates a (Boolean) vector. An evaluation script evaluates a given (Boolean) function on the (Boolean) vector produced by the vectorization script. Whilst examples are primarily described in terms of locking and unlocking scripts of UTXO-based blockchains, the techniques described herein may also be implemented by scripts of account-based blockchains. BRIEF DESCRIPTION OF THE DRAWINGS To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which: Figure 1 is a schematic block diagram of a system for implementing a blockchain, Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain, Figure 3 schematically illustrates an example system for implementing embodiments of the present disclosure, and Figures 4 and 5 show sequence diagrams for implementing example token protocols using hierarchical transactions. DETAILED DESCRIPTION OF EMBODIMENTS 1. MULTI-SIGNATURE TRANSACTIONS Embodiments of the present disclosure relate to multi-signature blockchain transactions. Figure 3 illustrates an example system 300 for implementing the embodiments described herein. As shown, the system 300 includes a first party (Alice 103a) and one or more second parties (Bob 103b, Charlie 103c and Deborah 103d). The system 300 also includes one or more nodes 104 of a blockchain network 106. In general the system 300 may include any number of first parties 103a, second parties 103b, 103c, 103d, and blockchain nodes 104. The system 300 may also include one or more third parties (not shown). Examples of the embodiments will be described in terms of the first party being Alice 103a and the second party being Bob 103b. However this is for convenience and in general the first party and the second party may be configured to perform any action described as being performed by Alice 103a and / or Bob 103b with reference to Figures 1 and 2 below. Alice 103a generates a first transaction. The first transaction includes a locking script that locks an output of the transaction. The locking script includes a first sub-script (referred to below as a "vectorization script") and a second sub-script (referred to below as an "evaluation script"). The first and second sub-scripts are not necessarily separate (i.e. one followed by the other), though that is an option. The locking script may contain additional sub-scripts, either before, between, within, or after the first and second sub-scripts. The first sub-script includes a sequence of signature verification sub-scripts. Each signature verification sub-script comprises one or more public keys and / or one or more public key hashes. A public key or a public key hash is each a form of a "public key representation". Each signature verification sub-script is configured to take, as inputs, one or more signatures, and verify whether the one or more signatures correspond to the one or more public keys and / or one or more public key hashes. Here, "correspond" means whether a signature can be validated using the public key. Each signature verification sub-script may comprise a dedicated function (e.g. opcode) for performing said verification such as, for example, OP_CHECKSIG or OP_CHECKMULTISIG. In the case of a signature verification script verifying multiple signatures corresponding to multiple public key representations, the signature verification script may require that a valid signature is supplied for each public key representation, or for at least a minimum number of public key representations. Each signature verification script is configured to output a value based on its verification operation. The value either indicates that the required signature(s) have been supplied as inputs or that the required signature(s) have not been supplied as inputs. The value may take any binary form and may or may not be a numerical value (e.g. 1 or 0). The value may be referred to as an indication instead, such as TRUE or FALSE, YES or NO, PASS or FAIL, etc. Once each signature verification script has executed, a sequence of binary values are output, e.g. a sequence of Is and Os, or a sequence of TRUEs and FALSEs. The second sub-script is configured to perform an operation on the sequence of values to determine whether conditions have been met. That is, the second sub-script performs a function which checks whether certain required signatures have been supplied to the locking script. Any suitable conditions may be checked for. For instance, the second subscript may check that the required signature(s) have been supplied for one, some or all of the signature verification sub-scripts, and / or for one or more predetermined signature verification sub-scripts, and / or for a predetermined number of the signature verification sub-scripts, and / or a predetermined combination of the signature verification sub-scripts. The second sub-script may use any function that can be expressed in the blockchain scripting language. For example, the function may be a Boolean function, such as a monotone Boolean function. Alice 103a may use the algorithm described in Subsection 1.3.4 to convert the function to blockchain script. Similarly, Alice 103a may use any of the techniques described in Subsection 1.4 to minimise the function so as to reduce the size of the locking script and consequentially, the transaction. Alice 103a sends the first transaction to the blockchain network 106 and / or to one or more second parties, e.g. Bob 103b. Bob 103b obtains the first transaction, e.g. directly from Alice 103a or from the blockchain 150. Bob 103b generates a signature corresponding to his public key or public key hash and provides his signature in an unlocking script of a second transaction. Depending on the requirements set by the function of first transaction, Bob 103b may submit the second transaction to the blockchain network 106 or send the second transaction to one or more additional parties (e.g. Charlie 103c) for them to provide respective signatures. Once the required signatures have been provided, Bob 103b, Charlie, or a different party, submits the second transaction to the blockchain network 106. The second transaction may instead be sent to Alice 103a for her to submit to the network 106. 1.1 Monotone Boolean Functions The following notation is followed herein: Boolean functions and truth values are capitalized and written in plain text (for instance, logic conjunction is denoted by AND). Boolean functions can describe any type of relationship between the signers. However, in this work we focus our attention on monotone Boolean functions, a subset of Boolean functions. The fundamental property that describes monotone functions is that switching any input from FALSE to TRUE cannot switch the output from TRUE to FALSE. A reason for using monotone functions is that it ensures that no party can invalidate a transaction that had all the necessary authorization by adding their signature, either by accident or on purpose. DEFINITION. Let n be a positive integer, a Boolean function is a function f\ Z2 -> Z2, the integer n is called the arity of the function. Since we can interpret 0 as FALSE and 1 as TRUE, Boolean functions can be interpreted as logic functions. The truth table of some common ones is showed in Subsection 1.6. For historical reasons, functions with arity values from 0 to 3 are called respectively nullary, unary, binary, and ternary functions; higher arity values are usually denoted by n-ary. The set (%2>XOR,AND) is a field isomorphic to the field (Z2, +, x). Under this isomorphism, we have that X OR Y = X + Y + XY and NOT X = 1 + X. Let x = (x^,..., xn~) G 1^, and y = (y1(..., yn) G 1^, we say that x < y if and only if xt < y for each i, where < is the order induced by 0 < 1. DEFINITION. A monotone Boolean function is a Boolean function f with the additional property that if x < y, then f(x) < f(y). As a consequence, switching an input value from FALSE to TRUE cannot modify the output from TRUE to FALSE. REMARK. We provide some examples of monotone Boolean functions. • The nullary functions that always return TRUE or FALSE. • the binary functions AND and OR. • the unary identity. • the projections on one variable (i.e., the functions of the form f(XQ, —.Xn) = Xt for some i.) The functions AND and OR are the only binary monotone Boolean functions, and the identity is the only unary monotone function. LEMMA. A Boolean function f is monotone if and only if it can be written using only AND, OR, and projections. We sketch a proof of this result in Appendix 0. There is no uniqueness in the representation of a Boolean function. Based on the requirement, optimal equivalent functions can be produced (optimality depends on the precise metric considered). Some algorithms to achieve minimization are listed in Subsection 1.4.2. 1.2 Reverse Polish Notation Reverse polish notation (RPN) is a mathematical notation to write n-ary operations that do not require the use of parentheses. It is used in stack-oriented programming languages such as Forth and Bitcoin Script. In RPN, the operators follow their operands. • The expression to add 1 and 2 is 1 2 + rather than 1 + 2. • The expression 3 * 4 + 5 is converted to 3 4 * 5 +. The Shunting yard algorithm can convert expressions written in the usual notation into RPN. 1.3 Locking script creation In this section, we describe how to produce a locking script that reflects the logic of a monotone Boolean function. To make reading more accessible, we divide the locking script into two parts. • The first evaluates the signatures provided in the unlocking script, creating a binary vector that reflect whether the signature has been verified (vectorization script). • The second evaluates the monotone function on the input vector (evaluation script), the locking script is unlocked once enough signatures are collected (enough here refers to the logic expressed in the Boolean function and not necessarily a minimum number of signatures). The locking script is the vectorization script, followed by the evaluation script. We remark that while our attention focuses on the monotone function, we can use vectorization and execution scripts to represent and evaluate any function. Let PQ,..., Pn be the public key of n + 1 parties 40,..., An. The unlocking script of the transaction is / n ... / 0, wheredenotes either of the following two options. • the byte 0x00; • a signature associated to Pt followed by the value 0x01. The byte 0x00 in the first option and the byte 0x01 in the second one are needed to evaluate an if statement present in the vectorization script. 1.3.1 Vectorization script We introduce the following notation: • ifSig(x) := OP_IF < x > OP_CHECKSIG OP_ELSE OP_0 OP_ENDIF; • fromAlt^. = OP_FROMALTSTACK and fromAltn\ = fromAltn_^ ° fromAl^ The function in the first bullet point is a conditional version of a normal P2PK locking script, if there is a 0x01 at the top of the stack, the signature is checked against the public key x and the result is pushed at the top of the stack. Otherwise, 0x00 is pushed to the top of the stack. The second bullet point describes a family that pulls data from the alt-stack. The subscript denotes how many data are pulled from the alt-stack. The vectorization script is: ifSig(Po) OP_TOALTSTACK ifSigf^P-f) OP_TOALTSTACK ... ifSigiPj fromAltn . After the execution of the vectorization script, the alt-stack will be empty, while the stack contains n + 1 values Bo, with Bo at the top. The value Bt is TRUE ifwas pushing a valid signature for the public key Pt followed by 0x01 and FALSE otherwise. We complete this subsection with two remarks. • The vectorization script can be written without needing to store values on the alt-stack. This can be done by using multiple permutation opcodes. • While we described if Sig as a P2PK transaction, it can easily be reshaped to resemble a P2PKH transaction instead. This requires adapting the unlocking script as well. 1.3.2 Evaluation script We evaluate the function on the vector produced by the vectorization script above. Example opcodes that may be used are listed below: • OP_2DUP: duplicate the two top stack items. • OP_DUP: duplicate the top stack item. • OP_OVER: add the second to the top stack item to the top of the stack. • OP_PICK: copies the n-th element from the top of the stack and pushes it to the top. • OP_BOOLAND: Boolean AND of two top stack elements. • OP_BOOLOR: Boolean OR of two top stack elements. • OP_NIP: remove the second element of the stack. We count the stack elements starting from 0, so OP_DUP corresponds to OP_0 OP_PICK and OP_OVER to OP_1 OP_PICK. The first four opcodes are needed to pull the relevant inputs. The following two are the logic operations we want to perform. OP_NIP cleans the stack after evaluating the function so that only the output remains, in case the clean stack rule is not required, they can be omitted. Before generating the evaluation script, we may rewrite the function RPN. We first describe the evaluation script with some examples and then present a general algorithm for generation of the script. 1.3.3 Examples Example 1 Assume that after vectorization we have 5 values in the stack: <X0XX1XX2 xx4>, where Xo is on the top of the stack. We consider the function: ((X0AND XJ OR (X2AND X3)) OR (X3AND X4). In RPN, the function becomes: Xo X^ AND X2 X3 AND OR X3X4 AND OR. And the associated evaluation script is: OP_2DUP OP_BOOLAND OP_3 OP_PICK OP_5 OP_PICK OP_BOOLAND OP_BOOLOR OP_4 OP_PICK OP_6 OP_PICK OP_BOOLAND OP_BOOLOR OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP Notice that we shortened the script by replacing the OP_0 OP_PICK OP_2 OP_PICK at the beginning with OP_2DUP. To clarify the example, we describe the script in step, showing the structure of the stack after each: 1. OP_2DUP OP_BOOLAND < Xi AND X0XX0XX1XX2XX3XX4>, 2. OP_3 OP_PICK OP_5 OP_PICK <X3XX2XX1 AND X0XX0XX1XX2XX3XX4>, 3. OP_BOOLAND < X3 AND X2XX1 AND Xo X Xo X X4 X X2 X X3 X X4 >, 4. OP_BOOLOR < (X3 AND X2) OR (Xi AND X^ X Xo X X4 X X2 X X3 X X4 >, 5. OP_4 OP_PICK OP_6 OP_PICK < X4 > < X3 > < (X3 AND X2) OR (Xi AND Xo) > < Xo > < Xx > < X2 > < X3 > < X4 6. OP_BOOLAND OP_BOOLOR < (X4 AND X3) OR ((X3 AND X2) OR (Xx AND Xo)) X Xo X Xt X X2 X X3 > < X4 > 7. OP_NIP OP_NIP OP_NIP OP_NIP OP_NIP < (X4 AND X3) OR ((X3 AND X2) OR (Xx AND Xo)) >, Example 2 Assume that after vectorization we have 5 values in the stack: <X0XX1XX2XX3XX4>. We consider the function ((Xo OR X3) AND X4) OR AND (X2 AND X^ In RPN, the function becomes: X0X3 OR X4 AND XrX2X3AND AND OR The associated script is: OP_DUP OP_4 OP_PICK OP_BOOLOR OP_5 OP_PICK OP_BOOLAND OP_2 OP_PICK OP_4 OP_PICK OP_6 OP_PICK OP_BOOLAND OP_BOOLAND OP_BOOLOR OP_NIP OP_NIP OP_NIP OP_NIPOP_NIP As in the previous example, we shorted the script by replacing the initial OP_0 OP_PICK with OP_DUP. 1.3.4 General script generating algorithm We describe the algorithm to generate the script associated to a Boolean monotone function. The input of the algorithm is: • an integer nVar, corresponding to the length of the vector created in vectorization scripts which corresponds to the number of variables in the formula. • a list formula containing a Boolean formula written in RPN. The entries of the list The push function below is a function that takes a value X as input and outputs formula are either variables "X_0",..., "X_n", numerated starting from 0, or Boolean operations "OR" and "AND". As an example, for the Boolean expression Xo X± AND, we use the inputs nVar = 2 and formula = ["X_0", "X_l", "AND"]. The function push used in the script below takes a value x as input and outputs the script required to push the value X as a piece of data to the stack. For example, if X is 3, it outputs " OP_3". If X is 178, it outputs "OP_1 b2", and so on. Monotone Boolean Function In Rpn To Bitcoin Script: stackSize = 0 code = "" For element in formula: if element == "OR" or element == "AND": code = code + " OP_BOOL" + element stackSize = stackSize - 1 else: number = int(element[2:]) + stackSize code = code + push(number) + " OP_PICK" # i # the output # add the Boolean op_code # update stackSize # element == X_i # position of X_i put of the OP_PICK stackSize = stackSize + 1 code = code code = code + " OP_NIP"*nVar code = code[l:] # update stackSize # add the pick # remove the variables # remove a blank value We can improve this locking script; this is the topic of the following subsection. 1.4 Minimizing the locking script Minimizing the length (measured in bytes) of the locking script reduces transaction fees as well as storage and bandwidth. We can achieve this minimization by opcode optimization or Boolean function minimization. A four-step protocol may be used to achieve this: 1. Introduce bound variables that can reduce the total length of the script. 2. Minimize the resulting Boolean function as discussed in Subsection 0. 3. Rewrite the function relying on the ring structure of Boolean algebras. 4. Adjust the vectorization script so it maintains the relative order of the function. Any combination of one or more of the streps may be used instead. 1.4.1 Introducing bound variables Assume that the monotone Boolean function / (Xo, ■■■ > Xn) can be rewritten as g(XQ, — ,Xn, Y), where Y = 0(^,..., Yk~) for some Boolean function 0 and such that for all i, Yt = Xj for some j. We call such variable Y a bound variable because it is only a symbol replacing the function 0. The vectorization script can then be rewritten to also include the bound variable Y (since 0 is a Boolean function itself, we can do this by creating vectorization and evaluation script for 0). Using bound variables can exploit repetitive structures in the transaction's logic scheme to reduce the locking script's total length. We discuss a specific example where this can be extremely convenient. 1.4.1.1 The case of OP CHECKMULTISIG The vectorization script we described relied only on OP_CHECKSIG, but in some cases it is possible to group some variables in a bound variable and use OP_CHECKMULTISIG instead. Let Tk h(Yi, — ,Yh~) be the monotone function that is TRUE if and only if at least k of the h variables are TRUE, and assume that 0 = T^fY^ — .Yb). We can write down Tkh as combination of AND and OR as follows: we take the disjunction (OR) of the conjunction (AND) of all subsets with k variables. Then the vectorization script needed for the bound variable Y is particularly easy to describe since we only have to replace the function ifSig(x) described in Subsection 1.3.1 with: ifMultiSigfy^ ...,yh,k,h) = OP_IF< k > <   > ■■■ < yh > < h > OP_CHECKMULTISIG OP_ELSEOP_OOP_ENDIF. We conclude the discussion on this topic with two remarks. • Notice that, in principle, the function g may not look like a monotone Boolean function, for instance, if f = (Xo AND %! ) OR (%! AND X2), we can have g = Y AND (nOT[Xo AND X2 AND (NOT X^, for Y = 7^3(^0,^1,^2) ■ This apparent paradox is solved by noticing that Y is not a free variable but a bound one. While we discussed only the case where the bound variable is of the form 7^3(^0,^1,^2), we are not restricted to this. An example is the function: (Y OR Xo) OR (Y AND XJ, where Y is any complex relation between a set of variables, for instance Y = X2 OR (X3 AND X4y Put another way, a problem with Boolean functions is that they can result in very large scripts. E.g. if there are 20 people and we want to cover lots of possibilities, it could result in 1 million terms in the function. This can be avoided by using bound variables. This involves recognising a pattern in the Boolean function, e.g. whenever there is A there is also B. This means that A and B can be replaced with C, e.g. using a multisig. For example, there may be a requirement for one signature from a 1st department or three signatures from a 2nd department. This can be implemented using a multisig for the 1st department and a multisig for the 2nd department. 1.4.2 Minimization algorithms The second step to minimize the length of the locking script is to use a combination of one or more of the following algorithms to simplify the Boolean function: An overview of common techniques to minimize Boolean functions is provided below. 1. Karnaugh map: suitable for minimal amounts of variables, the truth values are written in a table and grouped by clusters of TRUE. These clusters correspond to subexpressions in the primary expression. 2. Quine-McCluskey algorithm: generalization of Karnaugh map to an arbitrary number of variables. While less visually impactful, it is more suitable for implementation. 3. Algebraic manipulation: Boolean formulas satisfy many identities; these can be used to simplify more complex expressions. 4. Modulo arithmetic formulation: using the isomorphism between (%2,X0R,AND) and (JL2, +< x), Boolean expression can be rewritten in algebraic form, which is unique and may be shorter than other representations. 5. Heuristic-based algorithms: algorithms that exploit expert-suggested heuristics to improve the function representation. This approach can reduce the length of the function but may fail to produce the minimal one. 6. ML-based algorithms: researchers in ML are studying techniques to approach various NP problems, including Boolean minimization. There is not yet an established Al for this, but the situation can change rapidly. As with the heuristic algorithms, this approach can reduce the length but fail at producing a minimal representation. Note that these algorithms may produce formulas that are minimal by some standards but not produce optimized script. For instance (XQ AND X} AND X2) OR (Xo AND X} AND X3) is a valid output produced by Quine-McCluskey algorithm but creates a longer locking script than its equivalent formulation: Xo AND X} AND (X2 OR X3). 1.4.3 Grouping common variables By de Morgan's law, we know that AND and OR are distributive with respect to each other. Moreover, they are commutative and associative. These properties can be used to group terms together, reducing the number of variables called and Boolean operations required. For instance, (Xo AND XJ OR (X2 AND Xo) can be grouped as XQ AND (X} OR X2~). 1.4.4 Variables ordering Once the final formula has been decided and has been converted in RPN, we ensure that the variables in the formula appear in the correct order in the vectorization script (the first variable appearing in the formula in RPN should correspond to the first variable in the vectorization script and so on). This allows us to access some of the variables using OP_DUP, OP_2DUP, and OP_OVER. 1.5 Use Cases In this section, we present some use-cases where monotone Boolean functions can provide locking scripts that respect a hierarchical structure. 1.5.1 Hierarchical transaction structures Hierarchical transaction structures can be used by organizations to implement signature schemes that require the authorization of multiple parties (employees, departments, or other structures), and that respect the internal hierarchy and structure of the organization. Moreover, the presence of back-up signers may be preferable in case one party cannot sign anymore. The hierarchical transaction can be used also to authorize transactions in an overlay network. Tokens can be used, for instance, to grant access privileges. Each token can be customised to add specific and limited access privileges so that only the authorized ones can be accessed. 1.5.1.1 Authorization tokens We present two different ways tokens can be used to selectively grant access privileges. In both examples, we have three actors: 1. A service Star 403 that can grant employees access upon them proving they are authorized. 2. An employee Erica 402 who wants access. 3. The hierarchical structure Hector 401 that grants Erica 402 access. Hector 401 represents multiple parties. We first describe a protocol where access tokens are spent to get access. 1. Erica 402 asks Hector 401 access authorization. She creates a hierarchical transaction (representing Hector 401) and broadcasts it. 2. The various actors in Hector 401 decide whether they want to grant access. a. If they do not want to provide access, the process stops here. b. Otherwise, it continues to point 3. 3. Hector 401 signs the transaction, and the access token is sent to Erica 402. 4. Erica 402 sends the token to Star 403. 5. Upon receiving the token, Star 403 checks what access privileges the token grants. 6. Star 403 grants access to Erica 402. The above process is shown in Figure 4. The dotted lines denote the steps that are performed only if enough signatures are collected. The main advantage of this protocol is that it allows more control over what each user access. We now describe a protocol where tokens are kept and shown to provide proof of the access. 1. Erica 402 asks Hector 401 for access authorization. She creates a hierarchical transaction (compatible with Hector 401) and broadcasts it. 2. The various actors in Hector 401 decide whether they want to grant access, a. If they do not want to provide access, the process stops here. b. Otherwise, it continues to point 3. 3. Hector 401 signs the transaction, and the access token is sent to Erica 402. 4. Erica 402 asks access from Star 403 by providing the transaction ID. 5. Star 403 checks that Erica's token has not been spent. 6. Star 403 grants the required access. The above process is shown in Figure 5. The dotted lines denote the steps that are performed only if enough signatures are collected. The main advantage of this protocol is that Hector can revoke Erica's access immediately, without communicating with Star. 1.5.2 Further Examples We provide examples of hierarchical structures and how an organization may use them. When doing examples, we fix this naming of the actors: Alice is the boss of Bob and Carl, all of them are in the department Dungeon; Erica and Finn work in the department Dragon and have equal decision powers. Garp is the head of the organization. 1.5.2.1 Simple Hierarchical structure The transaction can be authorized by Alice (alone) or by Bob and Carl (both signatures required). The monotone Boolean function is: Alice OR (Bob AND Carl) 1.5.2.2 Multi-department hierarchical structure The transaction needs authorization from both the department Dungeon and Dragon in a way that respects the different internal structures of the two. The Boolean function is: (Alice OR (Bob AND Carl)) AND (Erica OR Finn) 1.5.2.3 Necessary signer structure In addition to all the various signatures in the departments, Garp has to authorize the transaction. [(Alice OR (Bob AND Carl)) AND (Erica OR Finn)^ AND Garp 1.5.2.4 Back-up signers Since Garp authorization is required, a back-up may be helpful. [(Alice OR (Bob AND Carl)) AND (Erica OR Finn)^ AND (Garp± OR Garp2) 1.5.2.5 Departmental Multi-signature We may not need to respect the hierarchy of the department Dungeon, but we may require two out of three signatures. We can also rewrite the function to add supporting variables. (T23(Alice,Bob, Carl) AND T12(Erica, Finn)) AND T±2(Garp1,Garp2) 1.5.2.6 Limited n-of-m transactions We may require a signature scheme that needs three out of the six signatures but does not want all three coming from the same department. Rewriting the function using supporting variables, we obtain (we use only the initials for brevity): T3>6(A, B, 0, E, F, G) AND N0T{(A AND B AND C) AND NOT (E OR F OR G)) This is a monotone Boolean function (despite not looking like one). This expression is preferable to the expanded formula since it has only two terms and four variables against the nineteen terms and six variables of the expanded version. 1.6 Truth table of some Boolean functions We remind the reader the truth table for AND, OR, XOR (binary), and NOT (unary). X Y X AND Y X OR Y X XOR Y NOT X TRUE TRUE TRUE TRUE FALSE FALSE TRUE FALSE FALSE TRUE TRUE FALSE FALSE TRUE FALSE TRUE TRUE TRUE FALSE FALSE FALSE FALSE FALSE TRUE We can obtain any other Boolean function by combining the ones described above. 1.7 Structure theorem for monotone Boolean functions This subsection provide a proof to the Structure theorem for monotone Boolean functions. LEMMA. A Boolean function f is monotone if and only if it can be written using only AND, OR, and projections. PROOF. The composition of monotone functions is monotone, which is enough to prove that if a function is written using only the mentioned functions, then it is monotone. For the other implication, we proceed by induction on the arity: we have already seen the induction base up to arity 2, assume it is valid for arity n — 1, and let f\ Z2 -> Z2 be a monotone Boolean function and Xo 6 Z2-1, let X represent a variable in Z2-1 and Y a variable in Z2. Since f is monotone, we know that if f(XQ, FALSE) evaluates to TRUE, then f(X0,TRUE) does as well. Moreover, f(X,TRUE) and f(X, FALSE) are monotone; thus, we have f(X, Y) = (f(X, TRUE) AND Y) OR f(X, FALSE). 1.8 Key Hash instead of public key We discuss how we can introduce key hash instead of public key in some of the script we described in the main sections. In all of the examples, we use OP_HASH160 as hashing function, however we are not restricted to use that one. 1.8.1 Single signature We describe a script that modifies the function ifSig(x) described in Subsection 1.3.1 to support P2PKH-type transactions. ifSigHash^xy. = OP_IF OP_DUP OP_HASH160 < x > OP_EQUALVERIFY OP_CHECKSIG OP_ELSE OP_0 OP_ENDIF The variable x is replaced by the hash of the public key. As unlocking script, we should the value / that can be either of the following two options. • The byte 0x00 (in case we cannot sign it). • The following three values: a signature, a public key, and the byte 0x01. The byte 0x01 being the last one being pushed on the stack, the public key needed to hash to the value x and the signature need to be associated with that public key. 1.8.2 Multi-signature We have already explained how bound variables can be used for multi-signature. In this part, we describe two scripts that can be used to have key hash in a m-of-n multi-signature. Multiple similar implementations are possible. Using multiple OP_CHECKSIG. Let fromAltAdd^. = OP_FROMALTSTACK OP_ADD and fromAltAddk\ = fromAltAddk_1 ° fromAltAdd^. We can write the multi-signature script as: multiSigHash^y^ ...,yn,m) = ifSigHash^y^) OP TOALTSTACK ifSigHash(y2) OP_TOALTSTACK ... ifSigHash(yn~) fromAltAdd^ < m > OP_GREATERTHANOREQUAL. The unlocking script is the one described in Subsection 1.8.1 repeated once per public key. If we want this script to create a bound variable, we can use: if MultiSig Hastily ...,yn,m) = OP_IF multiSig Hash^ (y1; ...,yn,m) OP_ELSE OP_0 OP_ENDIF. The unlocking script of multiSigHas^ has to be preceded by 0x01 in case we want to evaluate it, and replaced by 0x00 otherwise. Using one OP_CHECKMULTISIG It is possible to implement this using only one OP_CHECKMULTISIG instead of multiple OP_CHECKSIG. Assume that there are s keys that correspond to the key hash in the locking script. dropOrRoll(x) := OP_DUP OP_HASH160 < x > OP_EQUAL OP_NOTIF OP_DROP OP_DROP OP_FROMALTSTACK OP_1SUB OP_1SUB OP_TOALTSTACK OP_ELSE OP_FROMALTSTACK OP_SWAP OP_TOALTSTACK OP_1SUB OP_DUP OP_TOALTSTACK OP_ROLL OP_ENDIF. Let takeAndSwapi ■= OP_FROMALTSTACK OP_SWAP, and takeAndSwapk ■= takeAndSwap]^ ° takeAndSwapk We can write the multi-signature script as: multiSigHash2(yv ...,yn,m,n) := < 2n — 1 > OP_TOALTSTACK dropOrRoUfyf)... dropOrRoUfyn) OP_0 OPFROMALTSTACK OP_1ADD OP_DUP OP_TOALTSTACK OP_ROLL < m > OP_FROMALTSTACK takeAndSwaps OP_CHECKMULTISIG. To use it as bound variable, we can create if MultiSig Hash2 similarly as we did in the previous section. • In case we want to ensure the element in the stack is correct before starting the execution, we can start the script with OP_DEPTH < 2n> OP_EQUALVERIFY. • We can use OP_DEPTH to deduce the number of elements to rotate at each step, reducing marginally the opcodes in the script. This is more prone to human errors. • In some cases, it is possible to further optimize the permutations described in our solutions to reduce the numbers of stack operations. • The unlocking script for multiSigHash2{H{K1),                is < sign > < Kn > ■■■ < sig± > < K±>. In case we do not have access to the signature sigt (or to a public key KJ, we can reduce the number of bytes in the unlocking script by pushing 0x00 instead of both the public key and the signature. Details of dropOrRoll We provide a step-by-step description of dropOrRoll. 1. OP_DUP OP_HASH160 < x > OP_EQUAL: check the public key match the key hash. 2. OP_NOTIF OP_DROP OP_DROP OP_FROMALTSTACK OP_1SUB OP_1SUB OP_TOALTSTACK: if the check fails, we delete the public key and the associated signature from the stack, we then update the number of elements in the stack (this number is required to rotate the stack). 3. OP_ELSE OP_FROMALTSTACK OP_SWAP OP_TOALTSTACK OP_1SUB OP_DUP OP_TOALTSTACK OP_ROLL OP_ENDIF: if the check succeeds, we take the number of elements of the stack from the alt-stack, we push the verified public key to the alt-stack, we push the updated number of elements to the alt-stack and rotate the stack to move to the next public key / signature pair. Details of multiSigHash2 We provide a step-by-step description of multiSig Has h2. 1. < 2n — 1 > OP_TOALTSTACK: push the number of elements that should be in the stack (minus one) to the alt-stack, it is not strictly needed since it can be replaced by uses of OP_DEPTH. 2. dropOrRoll^yJ ... dropOrRoll(yn): check which public keys corresponds to a public key hash. 3. OP_0 OP_FROMALTSTACK OP1ADD OP_DUP OP_TOALTSTACK OP_ROLL: a bug in OP_CHECKMULTISIG requires to push an additional value in the stack, we push it and put it at the bottom of the stack. 4. < m >: push the desired number of signatures on the stack. 5. OP_FROMALTSTACK: get the number of available keys / signature pair. This in principle can be less than n, but all the pairs are allowed pairs. In case this is less than m, the OP_CHECKMULTISIG will fail. 6. takeAndSwapy the public keys are pushed in the stack in the correct order from the alt stack. 7. OP_CHECKMULTISIG: the signatures are verified. Hybrid version The scripts described in both sections above can be adapted to support hybrid combinations of keys, where in some cases we have public keys and in others we have public key hashes. 1. In the case of multiSigHash} this requires only to replace some of the ifSigHash with if Sig. The unlocking script has to be modified accordingly. 2. In the case of multiSigHash2, some additional care has to be taken: a. The first value pushed in the stack should be the number of elements expected to be in the stack. b. Some of the dropOrRoll should be replaced with the function: newKey(x) := OP_FROMALTSTACK < x > OP_TOALTSTACK OP_DUP OP_TOALTSTACK OP_ROLL 1.9 Comparison with multi-signature Monotone Boolean functions generalize both multi-signature and weighted multi-signature (WO2021 / 053425). 1.9.1 Multi-signature In Subsection 1.4.1.1 we describe how any normal multi-signature can be written using monotone Boolean functions. An example of monotone Boolean function that cannot be expressed using a single multi-signature is the following: (Xo AND XJ OR (X1 AND X2). Notice that in theory, we can write it as a disjunction of two 2-of-2 multi-signature transactions, but this is far from optimal. 1.9.2 Weighted multi-signature Weighted multi-signatures are a generalization of m-of-n multi-signatures where a weight is assigned to each signer. The signature is validated if the total weight of the signatures surpasses the threshold. To see that any weighted multi-signature scheme can be written using monotone Boolean functions, we proceed as follows: 1. We write all the combinations of signers that surpass the threshold. 2. For each of these valid combinations, we take the conjunction of the signers (AND). 3. We take the disjunction (OR) of all the formula created in the previous step. Since the algorithm above create formula using only AND and OR, the resulting function is monotone. An example of monotone Boolean function that cannot be expressed using a single weighted multi-signature is the following: (Xo AND XJ OR (X2 AND X3). Let k be the threshold and wt the weight associated to Xt. We have: w0 +   > k w2 +w3 > k From which it follows w0 +   + w2 + w3 > 2k, which implies that w0 + w2 > k or + w3 > k. In both cases, we have a couple of signers that has enough weight to authorize the transaction but should not be allowed to do that. 2. EXAMPLE SYSTEM OVERVIEW A blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network") and widely publicised. The blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions. Each transaction, other than so-called "coinbase transactions", points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions that are submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining", which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers. The transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and / or to timeorder index pointers. A blockchain can also be exploited in order to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for storage of additional user data or indexes to data in a transaction. There is no pre-specified limit to the maximum data capacity that can be stored within a single transaction, and therefore increasingly more complex data can be incorporated. For instance this may be used to store an electronic document in the blockchain, or audio or video data. In an "output-based" model (sometimes referred to as a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions. The spendable output is sometimes referred to as a UTXO ("unspent transaction output"). The output may further comprise a locking script specifying a condition for the future redemption of the output. A locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e. a reference) to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. So consider a pair of transactions, call them a first and a second transaction (or "target" transaction). The first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output. The second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction. In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be that the output of the first transaction has not already been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain. An alternative type of transaction model is an account-based model. In this case each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored by the nodes separate to the blockchain and is updated constantly. Figure 1 shows an example system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 (often referred to as "miners") that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Whilst not illustrated, the blockchain nodes 104 may be arranged as a near-complete graph. Each blockchain node 104 is therefore highly connected to other blockchain nodes 104. Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other equipment such as application specific integrated circuits (ASICs). Each node also comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or EEPROM; and / or an optical medium such as an optical disk drive. The blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout. A blockchain node 104 may be configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106. A blockchain node 104 may be configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory. A blockchain node 104 may also maintain an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151. The ordered pool 154 is often referred to as a "mempool". This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output. In a given present transaction 152j, the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j. Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction. In general, the preceding transaction could be any transaction in the ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist at the time the present transaction 152j is created or even sent to the network 106, though the preceding transaction 152i will need to exist and be validated in order for the present transaction to be valid. Hence "preceding" herein refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction. Due to the resources involved in transaction validation and publication, typically at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even whole a data centre. However in principle any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together. The memory of each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment. The node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these. Any given blockchain node may be configured to perform one or more of the following operations: validating transactions, storing transactions, propagating transactions to other peers, performing consensus (e.g. proof-of-work) / mining operations. In some examples, each type of operation is performed by a different node 104. That is, nodes may specialise in particular operation. For example, a nodes 104 may focus on transaction validation and propagation, or on block mining. In some examples, a blockchain node 104 may perform more than one of these operations in parallel. Any reference to a blockchain node 104 may refer to an entity that is configured to perform at least one of these operations. Also connected to the network 101 is the computer equipment 102 of each of a plurality of parties 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and recipients in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or recipients. For instance, some parties may act as storage entities that store a copy of the blockchain 150 (e.g. having obtained a copy of the blockchain from a blockchain node 104). Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e. communicating with) a blockchain node 106. Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his / her respective computer equipment 102a, and a second party 103b and his / her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated. Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and "second "party" respectively. The computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media. This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and / or an optical medium such as an optical disc drive. The memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus. It will be understood that any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102. The computer equipment 102 of each party 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal. The client application 105 may be initially provided to the computer equipment 102 of any given party 103 on suitable computer-readable storage medium or media, e.g. downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or a removable optical drive, etc. The client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to the respective party the amount of the digital asset that he or she currently owns. In an output-based system, this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question. Note: whilst the various client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting. The instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 is also able to contact blockchain nodes 104 in order to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility). The wallet function on each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol. As set out above, each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all the nodes 104 in the network 106. An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance. The current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly. In such a system, transactions are ordered using a running transaction tally of the account (also called the "position" or "nonce"). This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field. Some account-based transaction models share several similarities with the output-based transaction model described herein. For example, as mentioned above, the data field of an account-based transaction may point back to a previous transaction, which is equivalent to the input of an output-based transaction which references an outpoint a previous transaction. Thus both models enable linking between transactions. As another example, an account-based transaction contains a "recipient" field (in which a receiving address of an account is specified) and a "value" field (in which an amount of digital asset may be specified). Together the recipient and value fields are equivalent to the output of an outputbased transaction which may be used to assign an amount of digital asset to a blockchain address. Similarly, an account-based transaction has a "signature" field which includes a signature for the transaction. The signature is generated using the sender's private key and confirms the sender has authorized this transaction. This is equivalent to an input / unlocking script of an output-based transaction which, typically, includes a signature for the transaction. When both types of transaction are submitted to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and can be recorded on the blockchain. On an account-based blockchain, a "smart contact" refers to a transaction that contains a script configured to perform one or more actions (e.g. send or "release" a digital asset to a recipient address) in response to one or more inputs (provided by a transaction) meeting one or more conditions defined by the smart contact's script. The smart contract exists as a transaction on the blockchain, and can be called (or triggered) by subsequent transactions. Thus, in some examples, a smart contract may be considered equivalent to a locking script of an output-based transaction, which can be triggered by a subsequent transaction, and checks whether one or more conditions defined by the locking script are met by the input of the subsequent transaction. 3. UTXO-BASED MODEL Figure 2 illustrates an example transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks. In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203. The header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104. Say Alice 103a wishes to create a transaction 152j transferring an amount of the digital asset in question to Bob 103b. In Figure 2 Alice's new transaction 152j is labelled "Txi". It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob. The preceding transaction 152i is labelled “Txo" in Figure 2. Tat? and Txi are just arbitrary labels. They do not necessarily mean that Txo is the first transaction in the blockchain 151, nor that Txi is the immediate next transaction in the pool 154. Txi could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice. The terms "preceding" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with "predecessor" and "successor", or "antecedent" and "descendant", "parent" and "child", or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or "child") which points to a preceding transaction (the antecedent transaction or "parent") will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and / or node behaviour. One of the one or more outputs 203 of the preceding transaction Txo comprises a particular UTXO, labelled here UTXOo. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called "Script" (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output 203, for example the requirement of Alice's signature. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain Bob's signature. Unlocking scripts appear in the input 202 of transactions. So in the example illustrated, UTXOoin the output 203 of Tat? comprises a locking script [Checksig Pa] which requires a signature Sig Pa of Alice in order for UTXOo to be redeemed (strictly, in order for a subsequent transaction attempting to redeem UTXOo to be valid). [Checksig Pa] contains a representation (i.e. a hash) of the public key Pa from a publicprivate key pair of Alice. The input 202 of Txi comprises a pointer pointing back to Txi (e.g. by means of its transaction ID, TxIDo, which in embodiments is the hash of the whole transaction Txo]. The input 202 of Txi comprises an index identifying UTXOo within Txo, to identify it amongst any other possible outputs of Txo. The input 202 of Txi further comprises an unlocking script <Sig Pa> which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data (sometimes called the "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these. When the new transaction Txi arrives at a blockchain node 104, the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria). Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_..." refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150. E.g. the data could comprise a document which it is desired to store in the blockchain. Typically an input of a transaction contains a digital signature corresponding to a public key Pa. In embodiments this is based on the ECDSA using the elliptic curve secp256kl. A digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs. The particular parts of the outputs it signs depends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed (and thus fixed at the time of signing). The locking script is sometimes called "scriptPubKey" referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked. The unlocking script is sometimes called "scriptSig" referring to the fact that it typically supplies the corresponding signature. However, more generally it is not essential in all applications of a blockchain 150 that the condition for a UTXO to be redeemed comprises authenticating a signature. More generally the scripting language could be used to define any one or more conditions. Hence the more general terms "locking script" and "unlocking script" may be preferred. 4. FURTHER REMARKS Other variants or use cases of the disclosed techniques may become apparent to the person skilled in the art once given the disclosure herein. The scope of the disclosure is not limited by the described embodiments but only by the accompanying claims. For instance, some embodiments above have been described in terms of a bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104. However it will be appreciated that the bitcoin blockchain is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively. The blockchain, blockchain network and / or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes 104 as described above. In preferred embodiments of the invention, the blockchain network 106 is the bitcoin network and bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (recall that these entities are not considered nodes of the preferred bitcoin network 106). In other embodiments of the invention, the blockchain network 106 may not be the bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. For instance, on those other blockchain networks a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and / or propagate those blocks 151 to other nodes. Even more generally, any reference to the term "bitcoin node" 104 above may be replaced with the term "network entity" or "network element", wherein such an entity / element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same way described above with reference to a blockchain node 104. Some embodiments have been described in terms of the blockchain network implementing a proof-of-work consensus mechanism to secure the underlying blockchain. However proof-of-work is just one type of consensus mechanism and in general embodiments may use any type of suitable consensus mechanism such as, for example, proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a particular example, proof-of-stake uses a randomized process to determine which blockchain node 104 is given the opportunity to produce the next block 151. The chosen node is often referred to as a validator. Blockchain nodes can lock up their tokens for a certain time in order to have the chance of becoming a validator. Generally, the node who locks the biggest stake for the longest period of time has the best chance of becoming the next validator. It will be appreciated that the above embodiments have been described by way of example only. More generally there may be provided a method, apparatus or program in accordance with any one or more of the following Statements. Statement 1. A computer-implemented method of generating a blockchain transaction, wherein the method is performed by a first party and comprises: generating a first transaction, wherein the first transaction comprises a first script, the first script comprising a sequence of respective signature verification sub-scripts, wherein each respective signature verification sub-script comprises one or more respective public key representations, and wherein the first script is configured to, when executed with a second script of a second transaction: i) produce an output comprising a sequence of respective values, one respective value per respective signature verification sub-script, wherein each respective value indicates whether the second script comprises a respective signature corresponding one, some or each of the one or more respective public key representations of the respective signature verification sub-script, and ii) evaluate a function on the output to determine whether one or more conditions have been satisfied. Statement 2. The method of statement 1, wherein one or more of the respective public key representations is a respective public key. Statement 3. The method of statement 1 or statement 2, wherein one or more of the respective public key representations is a respective public key hash. Statement 4. The method of any preceding statement, wherein one or more of the respective signature-verification sub-scripts comprises a single public key representation. Statement 5. The method of any preceding statement, wherein one or more of the respective signature-verification sub-scripts comprises multiple public key representations. Statement 6. The method of any preceding statement, wherein the function is a Boolean function. Statement 7. The method of statement 6, wherein the function is a monotone Boolean function. Statement 8. The method of any preceding statement, wherein the one or more conditions comprise one or more of: a first condition that the second script comprises respective signatures corresponding to at least one respective public key representation of one, some or each respective signature verification sub-script; a second condition that the second script comprises respective signatures corresponding to at least one respective public key representation of a predetermined number and / or combination of respective signature verification sub-scripts; a third condition that the second script comprises respective signature corresponding to each respective public key representation of one, some or each respective signature verification sub-script; a fourth condition that the second script comprises respective signatures corresponding to a predetermined number of respective public key representations of one, some, or each respective signature verification sub-script, a fifth condition that the second script comprises a respective signature corresponding to a respective public key representation of a specific signature verification sub-script. Statement 9. The method of any preceding statement, comprising sending the first transaction to a second party and / or one or more blockchain nodes of a blockchain network. Statement 10. A computer-implemented method of generating a blockchain transaction, wherein the method is performed by a second party and comprises: obtaining a first transaction, wherein the first transaction comprises a first script, the first script comprising a sequence of respective signature verification sub-scripts, wherein each respective signature verification sub-script comprises one or more respective public key representations, and wherein the first script is configured to, when executed with a second script of a second transaction: i) produce an output comprising a sequence of respective values, one respective value per respective signature verification sub-script, wherein each respective value indicates whether the second script comprises a respective signature corresponding one, some or each of the one or more respective public key representations of the respective signature verification sub-script, and i) perform a function on the output to determine whether one or more conditions have been satisfied; and providing, as part of the second transaction, a respective signature corresponding to at least one of the one or more respective public key representations. Statement 11. The method of statement 10, comprising sending the second transaction to at least one of: one or more parties for providing respective signatures, the first party, and one or more blockchain nodes of a blockchain network. Statement 12. The method of statement 10 or statement 11, comprising generating the second transaction. Statement 13. The method of statement 10 or statement 11, comprising receiving the second transaction, wherein the second transaction comprises one or more respective signatures corresponding to one or more of the respective public key representations. Statement 14. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of statements 1 to 13. Statement 15. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 1 to 13. 5 According to another aspect disclosed herein, there may be provided a method comprising the actions of the first party and the second party. According to another aspect disclosed herein, there may be provided a system comprising the computer equipment of the first party and the second party.

Claims

1. A computer-implemented method of generating a blockchain transaction, wherein the method is performed by a first party and comprises:generating a first transaction, wherein the first transaction comprises a first script, the first script comprising a sequence of respective signature verification sub-scripts, wherein each respective signature verification sub-script comprises one or more respective public key representations, and wherein the first script is configured to, when executed with a second script of a second transaction:i) produce an output comprising a sequence of respective values, one respective value per respective signature verification sub-script, wherein each respective value indicates whether the second script comprises a respective signature corresponding one, some or each of the one or more respective public key representations of the respective signature verification sub-script, andii) evaluate a function on the output to determine whether one or more conditions have been satisfied.

2. The method of claim 1, wherein one or more of the respective public key representations is a respective public key.

3. The method of claim 1 or claim 2, wherein one or more of the respective public key representations is a respective public key hash.

4. The method of any preceding claim, wherein one or more of the respective signature-verification sub-scripts comprises a single public key representation.

5. The method of any preceding claim, wherein one or more of the respective signature-verification sub-scripts comprises multiple public key representations.

6. The method of any preceding claim, wherein the function is a Boolean function.

7. The method of claim 6, wherein the function is a monotone Boolean function.

8. The method of any preceding claim, wherein the one or more conditions comprise one or more of:a first condition that the second script comprises respective signatures corresponding to at least one respective public key representation of one, some or each respective signature verification sub-script;a second condition that the second script comprises respective signatures corresponding to at least one respective public key representation of a predetermined number and / or combination of respective signature verification sub-scripts;a third condition that the second script comprises respective signature corresponding to each respective public key representation of one, some or each respective signature verification sub-script;a fourth condition that the second script comprises respective signatures corresponding to a predetermined number of respective public key representations of one, some, or each respective signature verification sub-script,a fifth condition that the second script comprises a respective signature corresponding to a respective public key representation of a specific signature verification sub-script.

9. The method of any preceding claim, comprising sending the first transaction to a second party and / or one or more blockchain nodes of a blockchain network.

10. A computer-implemented method of generating a blockchain transaction, wherein the method is performed by a second party and comprises:obtaining a first transaction, wherein the first transaction comprises a first script, the first script comprising a sequence of respective signature verification sub-scripts, wherein each respective signature verification sub-script comprises one or more respective public key representations, and wherein the first script is configured to, when executed with a second script of a second transaction: i) produce an output comprising a sequence of respective values, one respective value per respective signature verification sub-script, wherein each respective value indicates whether the second script comprises a respective signature corresponding one, some or each of the one or more respective public keyrepresentations of the respective signature verification sub-script, and i) perform a function on the output to determine whether one or more conditions have been satisfied; andproviding, as part of the second transaction, a respective signature corresponding to at least one of the one or more respective public key representations.

11. The method of claim 10, comprising sending the second transaction to at least one of: one or more parties for providing respective signatures, the first party, and one or more blockchain nodes of a blockchain network.

12. The method of claim 10 or claim 11, comprising generating the second transaction.

13. The method of claim 10 or claim 11, comprising receiving the second transaction,wherein the second transaction comprises one or more respective signatures corresponding to one or more of the respective public key representations.

14. Computer equipment comprising:memory comprising one or more memory units; andprocessing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 13.

15. A computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of claims 1 to 13.

Images