Multi-standard blockchain protocol

Abstract

A computer-implemented method for generating blockchain transactions, the transaction for transferring an amount of a digital asset from a first party to a second party. The method includes generating a first transaction including an output that locks the amount of the digital asset, the output including an output script including a plurality of criteria components, each criteria component requiring a respective input data item, and a plurality of counter script components. Each criteria component is associated with one of the counter script components. The output script, when executed together with an input script of a second transaction, is configured to: i) increment a counter whenever each criteria component is satisfied by a respective input data item of the input script; and ii) require the counter to be incremented to at least a predetermined number in order to be unlocked by the input script.

Description

[Technical field]

[0001] The present disclosure relates to methods and transactions implementing a blockchain protocol that requires that an m-of-n criterion be met to unlock a transaction. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which a duplicate copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain contains a chain of blocks of data, with each block containing one or more transactions. Each transaction may point to a previous transaction in the sequence, which may span one or more blocks. Transactions can be contributed to the network and included in new blocks through a process known as "mining." "Mining" involves each of multiple mining nodes competing to perform a "proof-of-work," i.e., solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Traditionally, transactions in a blockchain are used to transfer digital assets, i.e. data that acts as a store of value. However, blockchains can also be used to stack additional functionality on top of the blockchain. For example, blockchain protocols may allow additional user data to be stored in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing more complex data to be incorporated. For example, this may be used to store electronic documents, or even audio or video data, on the blockchain.

[0004] Each node in the network can have any one, two, or all three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions through the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store a copy of the mined blocks of the blockchain. To have a transaction recorded in the blockchain, a party sends the transaction to one of the nodes of the network for propagation. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to follow the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated and are not mined into blocks. Assuming the transaction is verified and thereby accepted into the blockchain, the additional user data therefore remains stored in each node of the P2P network as an immutable public record.

[0005] Some blockchain protocols use scripting languages ​​that give parties the ability to generate sophisticated criteria for when a transaction's outputs can be used by potential recipients. Some scripting languages ​​include functions (sometimes called opcodes) that check whether a sufficient number of valid digital signatures are present among the transaction's inputs. If the required m-of-n signatures are available, the output can be used. Summary of the Invention

[0006] While useful, the m-of-n signature check is limited to checking only whether a required threshold number of digital signatures have been met. However, there may be situations where a threshold for other criteria, not necessarily signatures, is required. As an example, a potential payee may be asked to generate "at least a specified number of hash pre-images" in order to use a transaction output.

[0007] According to one aspect of the present disclosure, there is provided a computer-implemented method for generating a blockchain transaction, the transaction being for transferring an amount of a digital asset from a first party to a second party, the method being performed by the first party: generating a first transaction including an output that locks the amount of the digital asset; the output includes an output script including a plurality of criteria components, each of which requires a respective input data item; and a plurality of counter script components, each of which is associated with one of the counter script components; The output script, when executed together with the input script of a second transaction, i) incrementing a counter each time each criterion component is satisfied by each input data item of said Input Script; ii) A method is provided in which, in order to be unlocked by the Input Script, the counter must be incremented to at least a predetermined number.

[0008] Thus, a binary threshold protocol (BTP) is provided, where threshold constraints can be applied to any kind of criteria. The output script condition defines multiple criteria that can be met by an input data item included in a transaction that seeks to use the digital asset. Each time a criterion is met, a counter is incremented (e.g., by one). If the counter reaches a predefined number (the binary threshold) by which time all of the input data items are used up, the first script condition may be unlocked. If the input script meets any other condition of the protocol (e.g., the transaction is a valid transaction), the amount of the digital asset will be transferred to the second party. The protocol is binary in the sense that if the threshold is reached, the amount of the digital asset can be transferred (e.g., used), but if the threshold is not reached, the amount of the digital asset cannot be transferred.

[0009] While BTP provides advantages, it may be desirable if the amount of digital assets transferred to the second party is based on the number of criteria that are met (e.g., the more criteria that are met, the more digital assets are transferred). For example, it may be desirable to transfer a first amount if the intended recipient can provide 1-of-n pre-images, a larger amount if 2-of-n pre-images are provided, and an even larger amount if 3-of-n pre-images are provided.

[0010] According to another aspect disclosed herein, a computer-implemented method for generating a blockchain transaction, the transaction being for transferring an amount of a digital asset from a first party to a second party, the first and second parties each associated with the blockchain, the method being performed by the first party; generating a first transaction including a plurality of outputs; each output locks a respective amount of said digital asset and includes a respective first script condition; Each first script condition includes a plurality of criteria components, each of which requires a respective input data item, and a plurality of counter components, each of which is associated with one of the counter components; Each first output script condition, when executed together with the second transaction's input script, i) incrementing a counter each time each criterion component is satisfied by each input data item of said Input Script; ii) in order to be unlocked by said input script, said counter must be incremented to at least each predetermined number; A method is provided in which one, some, or all of the first script conditions require the counter to be incremented to different predetermined numbers.

[0011] Similar to BTP, the method provides a spectrum threshold protocol (STP), where threshold constraints can apply to any type of criteria. The first transaction has multiple outputs, each of which can transfer an amount of the digital asset when unlocked. For example, each output can transfer a different amount of the digital asset, with the first output transferring a first amount and the second output transferring a different (e.g., larger) amount, etc. Each output has a first output script condition, each of which has multiple criteria that can be satisfied by an input data item included in the transaction that seeks to use the digital asset. Each time a criterion is satisfied, a counter is incremented (e.g., by one). Some of the first output script conditions require the counter to reach different predefined numbers in order to be unlocked. That is, at least one output script is unlocked by having a smaller number of criteria satisfied compared to another output script. This creates a spectrum threshold. For example, satisfying a smaller number of criteria may unlock an output that locks a smaller amount of the digital asset, while satisfying a greater number of criteria may unlock an output that locks a greater amount of the digital asset.

[0012] Each individual output of the first transaction according to the STP protocol is similar to the outputs of the first transaction according to the BTP protocol, and the predetermined number (threshold) required by the STP outputs varies among some or all of the outputs.

[0013] Per threshold protocol, a set of transactions is utilized to allow a recipient (second party) to access a digital asset based on the number of criteria the recipient meets. STP is applicable when the amount of digital asset (reward) is proportional to the number of criteria the recipient can meet, as well as when the reward is not proportional to the number of criteria met. For example, there may be an upper limit on rewards such that having more criteria beyond a certain threshold does not increase the rewards available. [Brief description of the drawings]

[0014] To aid in the 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] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] 1 illustrates diagrammatically some examples of transactions that may be recorded on a blockchain. [Diagram 3] FIG. 1 is a schematic block diagram of another system for implementing a blockchain. [Figure 4] FIG. 1 is a schematic block diagram of the output-based model node protocol; the piece of node software that processes transactions. [Diagram 5] FIG. 2 is a simplified version of FIG. 1 , which illustrates a schematic representation of a system implementing general criteria threshold blockchain transactions. [Figure 6] FIG. 1 is a schematic diagram of a set of Spectrum Pay transactions. [Figure 7] FIG. 13 is a schematic diagram of the output of a Spectrum Pay transaction. [Figure 8] FIG. 2 is a schematic diagram of a set of Cancel transactions. [Figure 9] FIG. 2 is a schematic diagram of a set of Refund transactions. [Figure 10]FIG. 2 is a schematic diagram of a set of Collect transactions. [Figure 11] 1 illustrates a schematic diagram of an exemplary sequence of time-staggered transactions. [Figure 12] 1 illustrates a schematic timeline showing an exemplary sequence of steps taken by different parties to implement a general criteria threshold blockchain protocol. [Figure 13] OP_CHECKMULTISIG is a schematic representation of an implementation of checking m-of-n signatures using the blockchain protocol. [Figure 14] A schematic representation of an implementation of checking m-of-n signatures using a general criteria threshold blockchain protocol. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Example System Overview FIG. 1 illustrates an exemplary system 100 for generally implementing a blockchain 150. The system 100 includes a packet-switched network 101, which is typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a number of nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computing device with different nodes 104 belonging to different peers. Each node 104 includes a processing device including 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). Each node also includes a memory, i.e., a computer-readable storage device in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using 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), a flash memory or an EEPROM, and / or an optical medium such as an optical disk drive.

[0016] The blockchain 150 includes a chain of blocks of data 151, each copy of which is maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain includes one or more transactions 152, where transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount that represents the amount of digital assets belonging to a user 103 that are cryptographically locked (requiring that user's signature to unlock and thereby redeem or spend). Each input points to an output of a preceding transaction 152, thereby linking the transactions.

[0017] At least some of the nodes 104 assume the role of forwarding nodes 104F, which forward and thereby propagate transactions 152. At least some of the nodes 104 assume the role of miners 104M, which mine blocks 151. At least some of the nodes 104 assume the role of storage nodes 104S (also called "full-copy" nodes), with each node storing a respective copy of the same blockchain 150 in its respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a forwarding node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0018] For a given current transaction 152j, the input (or each of them) includes a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the pool 154 or any block 151. The previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or sent to the network 106, but the previous transaction 152i must exist and be verified for the current transaction to be valid. Thus, "preceding" in this specification refers to something that precedes in a logical sequence linked by a pointer, and not necessarily to a time of creation or transmission in the chronological order. Thus, it does not necessarily exclude transactions 152i, 152j from being created or sent out of order (see the discussion of orphan transactions below). A preceding transaction 152i may equally be referred to as an antecedent or predecessor transaction.

[0019] The input of the current transaction 152j also includes the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the preceding transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amount among multiple users (one of which may be the original user 103a to give change). In some cases, a transaction may have multiple inputs and collect amounts (money amounts) from multiple outputs of one or more preceding transactions and reallocate them to one or more outputs of the current transaction.

[0020] This is sometimes called an "output-based" transaction protocol, and sometimes also called an "unspent transaction output (UTXO) type protocol" (where the outputs are called UTXOs). A user's total balance is not defined by one number stored in the blockchain, instead, the user needs a special "wallet" application 105 to collate the values ​​of all of the user's UTXOs, which are distributed across many different transactions 152 in the blockchain 151.

[0021] As part of the account-based transaction model, another type of transaction protocol is sometimes called an "account-based" protocol. In the account-based case, each transaction transfers by referencing an absolute account balance, rather than defining the amount to be transferred by referencing back to the UTXO of the preceding transaction in the past sequence of transactions. The current state of every account is stored and constantly updated by miners, separate from the blockchain. In such a system, transactions are ordered using the successive transaction records (so-called "positions") of the accounts. This value is signed by the senders as part of their cryptographic signatures and hashed as part of the transaction reference calculation. Additionally, an optional data field can also sign the transaction. This data field may point back to a previous transaction, for example if a previous transaction ID is included in the data field.

[0022] In both types of transaction protocols, when a user 103 wants to execute a new transaction 152j, he sends the new transaction from his computer terminal 102 to one of the nodes 104 of the P2P network 106 (currently usually a server or a data center, but in principle it could be another user terminal). This node 104 checks whether the transaction is valid according to a node protocol applied to each node 104. The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 in question and together form an overall transaction model. The node protocol typically requires the nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may include checking that the cryptographic signature of the user included in the input of the new transaction 152j matches a condition defined on the output of the previous transaction 152i that the new transaction consumes, which typically includes at least checking that the cryptographic signature on the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, the condition may be defined, at least in part, by a custom script included in the input and / or output. Alternatively, it may be fixed solely in the node protocol, or it may be a combination of these. In any case, if the new transaction 152j is valid, the current node forwards the new transaction to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, and forwarding the new transaction 152j to one or more further nodes 104, etc.In this manner, the new transaction is propagated throughout the network of nodes 104.

[0023] In an output-based model, the definition of whether a given output (e.g., UTXO) is spent is whether it has already been validly spent by an input of another onward transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of a preceding transaction 152i that it attempts to spend or redeem has not yet been spent / redeemed by another valid transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double-spending, where a payer attempts to spend the same transaction output multiple times. On the other hand, an account-based model prevents double-spending by maintaining account balances. Again, because of the defined order of transactions, an account balance has a single defined state at a time.

[0024] In addition to validating, at least some of the nodes 104M compete to be the first to create a block of transactions in a process called mining, which is backed by a "proof of work." At the mining nodes 104M, new transactions are added to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. This typically involves searching for a "nonce" value such that when the nonce is concatenated with the pool of transactions 154 and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a predefined number of leading zeros. A property of a hash function is that it has an output that is unpredictable with respect to the input. This search can therefore only be performed by brute force, and therefore consumes a significant amount of processing resources at each node 104M trying to solve the puzzle.

[0025] The first miner node 104M to solve the puzzle announces this to the network 106 and provides its solution as a proof. This solution can be easily checked by other nodes 104 in the network (given the solution to the hash, it is easy to verify that the hash output satisfies the condition). The pool 154 of transactions for which the winner solved the puzzle is recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's published solution at each node. The new block 151n is also assigned a block pointer 155, which points to the previously created block 151n-1 in the chain. The proof-of-work helps to reduce the risk of double spending, since it takes a lot of effort to create a new block 151, and blocks containing double spending are likely to be rejected by other nodes 104, thus providing an incentive for mining nodes 104M not to include double spending in their blocks. Once created, blocks 151 cannot be modified because they are known and maintained at each of the storage nodes 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on blocks 151. This provides an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106.

[0026] Note that different miners 104M, who are constantly competing to solve the puzzle, may be solving the puzzle based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they started looking for a solution. Whoever solves the puzzle first defines the transactions 152 to be included in the next new block 151n, and the current pool of unmined transactions 154 is updated. Miners then continue to compete to produce blocks from the newly defined pending pool. There is also a protocol to resolve possible "forks", which are cases when two miners 104M solve the puzzle within a very short time of each other and inconsistent views of the blockchain propagate. In essence, whenever a branch of a fork grows, the longest one becomes the final blockchain 150.

[0027] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of nothing (a normal transaction transfers an amount of digital assets from one user to another). Thus, the winning node is said to have "mined" an amount of digital assets. This special type of transaction is sometimes called a "generation" transaction. It automatically forms part of a new block 151n. This reward motivates miners 104M to participate in the proof-of-work competition. A normal (non-generation) transaction 152 often specifies an additional transaction fee for one of its outputs, further rewarding the winning miner 104M who produced the block 151n that contained the transaction.

[0028] Due to the computational resources involved in mining, typically at least each of the miner nodes 104M takes the form of a server including one or more physical server units, or an entire data center. Each transfer node 104M and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 may include a user terminal or a group of user terminals networked together.

[0029] The memory of each node 104 stores software configured to run on the processing unit of the node 104 to perform one or more of its roles and to process transactions 152 according to the node protocol. It will be appreciated that any operation attributed to a node 104 may be performed by software executing on the processing unit of each computing device. Additionally, the term "blockchain" as used herein is a general term referring to a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0030] Also connected to the network 101 are computing devices 102 of a number of parties 103 acting as consumer users. These act as payers and payees in transactions, but do not necessarily participate in mining or propagating transactions on behalf of other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computing device 102a, and a second party 103b and its respective computing device 102b. It will be understood that many more such parties 103 and their respective computing devices 102 may exist and participate in the system, but for convenience they are not shown. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a is referred to herein as Alice and the second party 103b is referred to herein as Bob, although it will be understood that this is not limiting and that references herein to Alice or Bob can be interchangeably referred to as the "first party" and the "second party," respectively.

[0031] The computing equipment 102 of each party 103 comprises a respective processing device comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises a memory, i.e., a computer readable storage device in the form of a non-transitory computer readable medium or media. This memory may include, for example, one or more memory units using magnetic media such as hard disks, electronic media such as SSDs, flash memories or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 arranged to operate on the processing device. It will be understood that any action attributed to a party 103 given herein may be performed using software executed on the processing device of each computing device 102. The computing 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 smart watch. The computing device 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

[0032] The client application or software 105 may be initially provided to the computing equipment 102 of any given party 103 on one or more suitable computer readable storage media, for example downloaded from a server, or on a removable storage device such as a removable SSD, a flash memory key, a removable EEPROM, a removable magnetic disk drive, a magnetic floppy disk or tape, an optical disk, for example a CD or DVD ROM, or a removable optical drive.

[0033] The client application 105 has at least a "wallet" functionality, which has two main functions. One of these is to allow each user party 103 to create, sign and send transactions 152 that are propagated throughout the network of nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, this second function involves reconciling amounts defined among the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

[0034] An instance of the client application 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet function of the client 105 to transmit the transaction 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions in which the respective party 103 is a recipient (or, in an embodiment, actually inspect the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust of transactions in part through its public visibility). The wallet function on each computing device 102 is configured to form and transmit the transaction 152 according to a transaction protocol. Each node 104 executes software configured to validate the transaction 152 according to the node protocol and, in the case of a forwarding node 104F, forward the transaction 152 for propagation throughout the network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol implements a given transaction model together with a given node protocol. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although a transaction protocol may allow different subtypes of transactions). The same node protocol is used by all nodes 104 in the network 106 (although many nodes process different transaction subtypes differently according to rules defined for that subtype, and different nodes may take on different roles and thus implement different corresponding aspects of the protocol).

[0035] As described above, the blockchain 150 includes a chain of blocks 151, each of which includes a set of one or more transactions 152 created by the proof-of-work process, as described above. Each block 151 also includes a block pointer 155 back to a previously created block 151 in the chain, so as to define a sequential order to the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the creation transaction) includes a pointer to a previous transaction, so as to define an order to the sequence of transactions (note: the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to the genesis block (Gb) 153, which was the first block in the chain. Early in the chain 150, one or more original transactions 152 pointed to the genesis block 153, but not to a preceding transaction.

[0036] When a given party 103, for example Alice, wants to send a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. Then, from the client application 105, she sends the transaction 152 to one of one or more transfer nodes 104F to which she is connected. For example, this may be the transfer node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions to be "valid", examples of which will be detailed shortly. In some transaction protocols, the conditions for validation may be configurable per transaction by a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol, or may be defined by a combination of the script and the node protocol.

[0037] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "valid"), any storage node 104S that receives the transaction 152j adds the newly validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained at that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j propagates the validated transaction 152 to one or more other nodes 104 in the P2P network 106. Because each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be propagated throughout the P2P network 106.

[0038] Once in the pool 154 in the copy of the blockchain 150 maintained in one or more storage nodes 104, the miner nodes 104M start competing to solve the proof-of-work puzzle of the latest version of the pool 154 that contains the new transaction 152 (other miners 104M are still trying to solve the puzzle based on their old view of the pool 154, but whoever gets there will first define where the next new block 151 ends and the new pool 154 begins, and eventually someone will solve the puzzle for the part of the pool 154 that contains Alice's transaction 152j). Once the proof-of-work has been done for the pool 154 that contains the new transaction 152j, it becomes part of one of the blocks 151 in the blockchain 150. Since each transaction 152 consists of a pointer to the previous transaction, the order of the transactions is also immutably recorded.

[0039] Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible implementations.

[0040] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies an amount of a digital asset (store of value). It includes, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also include a header 201, which may include an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash of the transaction data (minus the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0041] Suppose Alice 103a wants to create a transaction 152j that transfers the amount of the digital asset in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1". It takes the amount of the digital asset locked to Alice into the output 203 of the preceding transaction 152i in the sequence and transfers at least a portion of it to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0042] The preceding transaction Tx0 may already be validated and included in the blockchain 150 by the time Alice creates her new transaction Tx1, or at least by the time she sends it to the network 106. It may already be included in one of the blocks 151 at that point, or it may still be waiting in the pool 154, in which case it will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be generated and sent to the network 102, or Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "preceding" and "following" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified in the transaction (such as which transaction points to which other transaction). They may equally be replaced by "preceding" and "inheriting" or "ancestor" and "descendant", "parent" and "child", etc. This does not necessarily mean the order in which they are created, sent to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (descendant transaction or "child") that points to a preceding transaction (ancestor transaction or "parent") will not be validated unless the parent transaction is validated. A child that arrives at node 104 before its parent is considered an orphan. It may be discarded or buffered for a certain amount of time to wait for its parent, depending on the node protocol and / or miner behavior.

[0043] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled herein as UTXO0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO, and a locking script that defines the conditions that must be met by an unlocking script in the input 202 of the following transaction for the following transaction to be validated, and thus for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script typically defines the unlocking conditions as follows: the unlocking script in the input of the following transaction includes a cryptographic signature of the party to whom the preceding transaction was locked.

[0044] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "script" (Script, capital S). A lock script specifies the information needed to consume a transaction output 203, e.g., the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the lock script. For example, it may include Bob's signature. An unlock script appears in the transaction's inputs 202.

[0045] In the example shown, UTXO0 of output 203 of Tx0 is A ], which means that Alice's signature SigP must be present in order for UTXO0 to be redeemed (or, more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid). A[ChecksigPA] contains the public key PA from Alice's public / private key pair. Input 202 of Tx1 contains a pointer to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Input 202 of Tx1 contains an index that identifies UTXO0 in Tx0, in order to identify it among any other possible outputs of Tx0. Input 202 of Tx1 further contains an unlock script that contains Alice's cryptographic signature, created by Alice applying her private key from her key pair to a given portion of data (sometimes called a "message" in cryptography). <sigpa>The data (or "message") that Alice needs to sign in order to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0046] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check if the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenation of the two scripts.

number

[0047] The details of authentication using public-private cryptography will be well known to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then with Alice's public key and the message in the clear (unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message must have been signed by Alice. Signatures typically allow the holder of the public key to authenticate the signature by hashing the message, signing the hash, and tagging this with the plaintext version of the message as the signature.

[0048] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (in the example shown, Alice's signature is provided and authenticated in Tx1), the node 104 considers Tx1 valid. If it is a mining node 104M, this means adding it to the pool 154 of transactions waiting for proof-of-work. If it is a forwarding node 104F, it forwards the transaction Tx1 to one or more other nodes 104 in the network 106, which will cause it to be propagated throughout the network. Once Tx1 is validated and included in the blockchain 150, this defines it as having spent UTXO0 from Tx0. Note that Tx1 is only valid if it uses unspent transaction outputs 203. If it tries to spend an output that has already been spent by another transaction 152, Tx1 becomes invalid even if all other conditions are met. Therefore, node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been spent (already formed a valid input to another valid transaction). This is one of the reasons why it is important for blockchain 150 to impose a defined order on transactions 152. In practice, a given node 104 may maintain a separate database that marks UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0049] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it is not possible to "leave" an amount defined in a UTXO while another amount is spent. However, an amount from a UTXO can be split into multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 of Tx0 can be split into multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

[0050] In practice, Alice should usually also include a fee for the winning miner, because nowadays the reward of the generating transaction alone is usually not enough to motivate mining. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner's node 104M, and thus, although technically valid, it will still not be propagated and included in the blockchain 150 (the miner's protocol does not force the miner 104M to accept the transaction 152 if the miner does not want to). In some protocols, the mining fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total amount indicated by the input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to the winning miner 104. For example, suppose that a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference automatically goes to the winning miner 104M. However, nothing in this document precludes that a miner's fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0051] Note that if the total amount specified in all of a given transaction 152's outputs 203 is greater than the total amount pointed to by all of its inputs 202, this is another basis for invalidity in most transaction models. Thus, such a transaction will not be propagated or mined into a block 151.

[0052] Alice and Bob's digital assets consist of the unspent UTXOs locked to them in any transaction 152 in the blockchain 150. Thus, typically, the assets of a given party 103 are distributed across the UTXOs of various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of the wallet function in the client application 105 to aggregate the value of all the various UTXOs locked to each party that have not yet been spent in another onward transaction. This can be done by querying the copy of the blockchain 150 stored in any of the storage nodes 104S, for example, the storage node 104S that is closest or best connected to each party's computer device 102.

[0053] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, A ] to [Checksig P A ]=OP_DUPOP_HASH160<H(Pa)> It may be written to mean OP_EQUALVERIFYOP_CHECKSIG. "OP_..." represents a specific opcode in a scripting language. OP_CHECKSIG (also called "Checksig") is a scripting opcode that takes in two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, the occurrence of the signature ("sig") is removed from the script, but additional requirements such as a hash puzzle remain for transactions to be verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for generating an unspent output of a transaction that may store metadata within the transaction, thereby immutably recording the metadata to the blockchain 150. For example, the metadata may include a document that is desirable to store on the blockchain.

[0054] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs specific data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs, and all or some of the transaction outputs. The specific portion of the signed outputs depends on the SIGHASH flag, which is a 4-byte code included at the end of the signature that selects which outputs are signed (and thus fixed at the time of signing).

[0055] The lock script is sometimes referred to as a "scriptPubKey" to indicate that each transaction includes the public key of the party being locked. The unlock script is sometimes referred to as a "scriptSig" to indicate that it provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions under which a UTXO is redeemed include authenticating a signature. More generally, the scripting language may be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" are preferred.

[0056] <Optional Side Channel> FIG. 3 illustrates a further system 100 for implementing a blockchain 150. The system 100 is substantially the same as described in connection with FIG. 1, except that an additional communication function is included. The client applications present on each of Alice's and Bob's computing devices 102a, 102b each include the additional communication function. That is, it allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the solicitation of either party or a third party). The side channel 301 allows for the exchange of data apart from the P2P network. Such communication is sometimes referred to as "off-chain". For example, it may be used to exchange transactions 152 between Alice and Bob without the transaction being (yet) published to the network P2P 106 or on the chain 150 until one of the parties chooses to broadcast the transaction to the network 106. Alternatively or in addition, the side channel 301 may be used to exchange other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0057] The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a local area network, such as a mobile cellular network, or a local wireless network, or a direct wired or wireless link between Alice and Bob's devices 1021, 102b. In general, the side channel 301 referred to anywhere in this specification may include any one or more links over one or more networking technologies or communication media for exchanging data "off-chain", i.e., separately from the P2P overlay network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, it is noted that when Alice and Bob are said to exchange certain information or pieces of data, etc., over the side channel 301, this does not necessarily mean that all of these pieces of data need to be transmitted over exactly the same links or the same type of network.

[0058] <Node software> FIG. 4 illustrates an example of node software 400 that may be executed by each node 104 of the P2P network 106 in the example UTXO or output based model. The node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application level decision engine 404, and a set of one or more blockchain related functional modules 405. For any given node 104, these may include any one, two, or all three of the mining module 405M, the forwarding module 405F, and the storage module 405S (depending on the node's role or roles). The protocol engine 401 is configured to recognize different fields of a transaction 152 and process them according to the node protocol. Transaction 152m (Tx m ) is received, and another preceding transaction 152m-1 (Tx m-1 ), the protocol engine 401 executes Tx m The protocol engine 401 then identifies the unlock script in the Tx m Based on the pointer in the input of Tx m-1 It identifies and searches for Tx m-1 If Tx is not already on the blockchain 150, each node can choose to use it from its own pool of pending transactions 154, or m-1 If Tx is already on the blockchain 150, then the node can obtain Tx from a copy of the block 151 in the blockchain 150 stored in the node or another node 104. m-1 In either case, the script engine 401 may search for Tx m-1 The script engine 402 then identifies the lock script in the output pointed to by the script.

[0059] The script engine 402 therefore m-1 Lock script and Tx m 4, but the same is true for any pair of transactions such as Tx0 and Tx1, etc. The script engine 402 executes the two scripts together as described above, which includes putting data on the stack 403 and retrieving data according to the script language (e.g., Script) based on the stack being used.

[0060] By executing the scripts together, the script engine 402 determines whether the unlock script meets one or more criteria defined in the lock script, i.e., whether it "unlocks" the output in which the lock script is included. The script engine 402 returns the result of this determination to the protocol engine 401. If the script engine 402 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, it returns the result "false".

[0061] In the output-based model, the result "true" from the script engine 402 is one of the conditions for the validity of the transaction. Typically, there are one or more further protocol-level conditions evaluated by the protocol engine 401 that must also be satisfied, and Tx m the total amount of Digital Assets specified in the Outputs of Tx does not exceed the total amount pointed to by the Inputs; m-1 The output pointed to by the transaction Tx has not yet been consumed by another valid transaction, etc. The protocol engine 401 evaluates the result from the script engine 402 together with one or more protocol-level conditions, and if all of them are true, the transaction Tx m The protocol engine 401 outputs an indication of whether the transaction is valid to the application level decision engine 404. m Only if the block is actually verified, the decision engine 404 may then trigger one or both of the mining module 405M and the transfer module 405F to perform their respective blockchain-related functions as Tx m , which is the time when the mining module 405M mines the block 151. m 4 to the pool 154 of each of the nodes, and / or the forwarding module 405F m to another node 104 in the P2P network 106. Note, however, that in embodiments, the decision engine 404 does not choose to forward or mine an invalid transaction, but conversely, this does not necessarily mean that it must trigger mining or forwarding of a valid transaction simply because it is valid. Optionally, in embodiments, the decision engine 404 may apply one or more additional conditions before triggering either or both functions. For example, if the node is a mining node 104M, the decision engine may choose to mine a transaction only if the transaction is valid and if there are sufficient mining fees remaining.

[0062] It is noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can represent any state that indicates a successful or positive outcome, and "false" can represent any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model (not shown in FIG. 4), a "true" outcome can be indicated by a combination of an implicit protocol-level validation of the signature by node 104 and an additional positive output of the smart contract (the overall outcome is considered to convey true if both individual outcomes are true).

[0063] script Blockchain protocols may use scripting languages ​​for transactions. A script is essentially a list of elements, which may be data or instructions. Instructions are referenced in the document as script words, opcodes, commands, or functions. Opcodes (short for operation code) perform a given operation on the data in the script. The data in the script may be, for example, numbers, public keys, signatures, hash values, etc. Opcodes are functions that operate on the data in the script. In scripting languages, scripts are executed end-to-end (usually from left to right) and utilize a data structure commonly known as a "stack." Data is always pushed onto (i.e., placed on) the stack. Opcodes pop data off the stack (i.e., take data from the stack), perform operations on the data, and then optionally "push" new data onto the stack. A stack-based scripting language commonly used in many blockchains is simply called Script. The following is described in terms of the opcodes of the Script language.

[0064] Stack-based scripting languages ​​are familiar to those skilled in the art. The following example describes an exemplary script implementation. In particular, an exemplary validation and unlock process is shown.

[0065] An example script is:<Bob’s signature><Bob’s public key> OP_DUP OP_HASH<Bob’s public address> OP_EQUALVERIFY OP_CHECKSIG. The script is executed from left to right.

[0066] Step 1:<Bob’s signature> Push onto the stack.

number

[0067] Step 2:<Bob’s public key> Push onto the stack (this is now the top element of the stack).

number

[0068] Step 3: The OP_DUP opcode operates on the top element of the stack,<Bob’s public key> Duplicate.

number

[0069] Step 4: The OP_HASH opcode is<Bob’s public key> Pop out the , run it through a hash algorithm (followed by one or more optional operations),<Bob’s public address> Get and put it on the stack.

number

[0070] Step 5:<Bob’s public address> Push onto the stack (this is now the top element of the stack).

number

[0071] Step 6: The OP_EQUALVERIFY opcode pops the last two elements off the stack (<Bob’s public address> and<Bob’s public address> ), checks to see if the two addresses are identical. If they are not identical, the execution is considered unsuccessful. If the condition is TRUE, the next command is executed.

number

[0072] Step 7: The OP_CHECKSIG opcode is<Bob’s public key> and<Bob’s signature> and checks them to see if they are valid. Once this process is complete, Bob will be able to unlock the transaction and access the specified amount of digital assets.

number

[0073] Briefly, the opcodes used herein are those of the Script language, e.g., "OP_CHECKSIG". However, the present disclosure is not limited to opcodes of scripting languages. More generally, although the embodiments are described in terms of opcodes of a particular blockchain scripting language (Script), the same teachings can be implemented using any opcode of any scripting language that performs a particular function when called by a scripting engine (e.g., a script interpreter). Also, although the following embodiments may be illustrated in terms of an elliptic curve digital signature algorithm (ECDSA), it will be understood that other cryptographic signature schemes, such as RSA, are known in the art and may be equally utilized herein.

[0074] BINARY THRESHOLD PROTOCOL An example of a threshold-based unlocking system is that of the multi-signature feature of some blockchain protocols. In some blockchain protocols, it is possible to construct a transaction locking script that can be unlocked by providing any m-of-n ECDSA signatures corresponding to m pre-specified public keys. The locking script condition of such a multi-signature transaction can be written as follows:

number

[0075] The unlock script may be in the following format:

number

[0076] An embodiment of the present disclosure provides a technique for constructing a transaction locking script (synonymously called an output script or scriptPubKey) that can be unlocked by providing a data item that meets any m-of-n criteria in a subsequent transaction's unlocking script (synonymously called an input script in scriptSig). Similar to OP_CHECKMULTISIG, the criteria may require a signature corresponding to a public key. However, the following techniques are not limited to requiring a signature. In general, any criteria may be defined. For example, there may be a requirement to provide a pre-image for a hash, a solution to a formula, an answer to a quiz question, etc.

[0077] The embodiment will be described first with reference to FIG. 5. FIG. 5 is a simplified version of FIG. 1 and shows an example system 500 implementing the Binary Threshold Protocol (BTP). A first party (Alice) 103a generates a transaction Tx1 and sends the transaction Tx1 to the blockchain network 106. Assuming that the blockchain protocol is satisfied, the first transaction Tx1 will be included in the blockchain 150. Note that a different party can alternatively send Alice's transaction to the blockchain network 106 on Alice's behalf. The first transaction Tx1 includes an output that specifies an amount of digital assets. The digital assets are locked by an output script (or lock script). To be unlocked and transferred to a second party (Bob) 103b, Bob must send a second transaction Tx2 to the blockchain network 106. The second transaction Tx2 has an input script (or unlock script) that can unlock the output script of the first transaction Tx1.

[0078] When constructing the output script, Alice 103a includes multiple criteria components. Each criteria component includes one or more opcodes (or functions in general), such as OP_CHECKSIGVERIFY. The criteria components may also include one or more data elements, such as hash values. Each criteria component defines a criterion that a particular input data item must meet; that is, each criteria component returns a value, such as , that, when executed against the input script of a subsequent transaction, indicates that the criteria component has been successfully executed, i.e., is "TRUE." <1> For example, some or all of the criteria components may require that different digital signatures be provided as input data items. Preferably, each criteria component may define different criteria. Alternatively, one or more of the criteria components may define the same criteria.

[0079] Alice 103a also includes a number of counter script components in the output script. Each counter script component is associated with a respective one of the criteria components. For example, each counter script component may follow a respective one of the criteria components in the case of a scripting language in which the script is executed from left to right. Each counter component includes one or more opcodes (or functions) and, optionally, one or more data items. Each counter component is configured to increment a counter if its associated criteria component is met. That is, if the first criteria component is met, the first counter component increments the counter. Note that "increment" here can be interpreted to mean to increase or decrease. For example, the counter may be incremented in an increasing manner (e.g., 1, 2, 3, etc.) or the counter may be incremented in a decreasing manner (e.g., 3, 2, 1, etc.). In some examples, each counter component may increment the counter by the same amount, i.e., the same numerical value. For example, a counter may be incremented by one each time a criteria component is met. Alternatively, the counter components may be weighted, i.e., some counter components may increment the counter by different amounts, i.e., different numerical values. As an example, a first counter component may increment the counter by one, while a second counter component may increment the counter by two.

[0080] Alice 103a configures the output script such that the counter must reach at least a predetermined number (or threshold) for the output to be unlocked. That is, the output script is configured to determine if the counter has been incremented to a predetermined number. If so, the output is unlocked and may be redeemed by Bob 103b. If the threshold is not reached, the output is not unlocked. If the counter is incremented in an upward manner, the output script is configured to determine if the counter is greater than or equal to the threshold. Conversely, if the counter is incremented in a downward manner, the output script is configured to determine if the counter is less than or equal to the threshold. The counter script includes one or more opcodes and, optionally, one or more data elements that, when executed together, perform a check against the counter and successfully evaluate as "TRUE" if the threshold has been reached.

[0081] In some instances, the total number of criteria components may be greater than a threshold number. In other words, satisfying a criteria component may increment a counter to a number greater than a predetermined number required to unlock an output. Alternatively, each criteria component must be satisfied for an output to be unlocked.

[0082] Optionally, a given criteria component may be composed of two or more sub-criteria components. Like a criteria component, a sub-criteria component includes an opcode and, optionally, a data element, which together require the input data item of a subsequent transaction to evaluate successfully. As an example, a criteria component may be composed of multiple sub-criteria components. Each of the sub-criteria components applies a hash function to the respective input data item and compares the resulting hash value with a predefined hash value. If the resulting hash value and the predefined hash value match, the sub-criteria component, and thus the criteria component, is satisfied. Even if the criteria component includes multiple sub-components, the counter is only incremented once when the criteria component as a whole is satisfied, and not once for each sub-criteria component.

[0083] As shown in Figure 5, Alice 103a has a standard Q n may be sent to Bob 103b. n Note that the criteria Q defines what is required as an input data item to satisfy the criteria component, not the data items themselves. For example, a criteria component may require a digital signature, but does not include the digital signature itself. n By providing the criteria, Alice 103a can know what data items he needs to provide. Alternatively, Alice 103a may not provide the criteria to Bob 103b. In this case, Bob may need to interpret the criteria components (e.g., a sequence of opcodes) to determine what should be provided as the corresponding data items.

[0084] The output script may include n criteria components. If the recipient (Bob) meets at least m of n criteria formalised in the lock script, he can redeem the full amount of the digital asset provided by Alice 103a. If he does not meet at least m criteria, he cannot redeem any of the digital asset. BTP represents an m-of-n criteria threshold, where m is fixed and recipients can access the digital asset only if they meet at least m criteria. The protocol is detailed below for two individuals Alice 103a and Bob 103b, where Alice 103a pays Bob 103b if Bob is able to meet at least m of n criteria. Alice 103a creates a "binary-pay" transaction (referred to as bPay), in which there is an output that includes an output script that locks the digital asset contained in the output until Bob 103b can provide the input script for the payment transaction. A payment transaction contains content that satisfies at least m of the n criteria (in some instances, the Input Script must also contain Bob's digital signature). The content of Bob's Input Script may be composed of multiple subunits of Input Data Items, where each data item serves as a solution to a particular criterion.

[0085] This protocol achieves its objectives by means of an output script in a bPay transaction, where a counter is incremented (e.g., initialized to zero and incremented by one) if an input (from Bob) satisfies the corresponding criteria in the bPay output script. The criteria are described as "corresponding" by the fact that the intended recipient (Bob) is expected to place the target input in a position in the input transaction, so that the input is compared to the appropriate criteria in the bPay output script of the bPay transaction. The value of the counter may be stored on a stack, for example the ALT stack in the Script language. When the input succeeds with respect to that criterion, the current state of the counter is removed (popped) from the ALT stack, put (pushed) on the main stack, incremented, and then popped from the main stack and pushed back onto the ALT stack. If the final value of the counter is at least m, the recipient Bob 103b can unlock the bPay output.

[0086] Examples of output and input scripts that can meet the desired characteristics of BTP are shown below, with TxID bPay and TxID spend As shown within.

[0087] The subsection [Criterion_1] of the lock(output) script represents the criteria (i.e., conditions) that the recipient Bob 103b is being asked to meet. This could, for example, be asking for a pre-image of the hash, as shown below:

number

[0088] Criteria can also represent a "grouped set of sub-criteria" that, when combined, must evaluate to true.

number

[0089] If [Criterion_i] consists of multiple sub-criteria, the counter is still incremented by one unit if the combination of all these sub-criteria evaluates to true.

number

[0090] Note that the text in brackets is a comment and does not actually have to be included in the transaction.

[0091] To unlock a bPay output, Payee Bob 103b may provide n pieces of input in the payment transaction's input script, where at least m of these inputs satisfy at least m of the aforementioned criteria. bPay was shown earlier.

number

[0092] These sets of n inputs are placed in the required order so that when the input and output scripts are combined and executed in a stack, each piece of input matches and is evaluated against the intended criteria. For example,

number

[0093] As with the standard subscript,<input_i> may also represent a grouped set of inputs.

number

[0094] Given the user's ability to define arbitrary criteria, this achieves the goal of a binary threshold protocol, where a threshold of common criteria must be met in order for a transaction's output to be spent.

[0095] SPECTRUM THRESHOLD PROTOCOL BTP sets binary thresholds for redeeming amounts of digital assets, while spectrum threshold protocol (STP) sets a range of thresholds, where the amount of digital assets that can be received by a recipient depends on the number of criteria that are successfully met.

[0096] The exemplary systems of Figures 1 and 5 may be used to implement the techniques described below. A first party (Alice) 103a constructs a first transaction (called an "sPay transaction") having multiple outputs. Alice 103a constructs each output in a manner similar to BTP. That is, each output has an output script, each output script includes multiple criteria components and multiple counter components, each counter component being associated with a respective one of the criteria components. Each criteria component defines a criteria that may be met by an input data item from an input script of a later transaction. Each counter component is configured to increment a counter if its associated criteria component is met. Each counter component may increment the counter by the same amount (e.g., 1). Alternatively, some of the counter components may increment the counter by different amounts. The multiple criteria components and the corresponding counter components are defined in a first script condition of each output script. Here, the first script condition is simply a label for the portion of the output script that includes the criteria component and the counter component. Note that each output includes the same criteria component.

[0097] Similar to BTP, in STP, Alice 103a configures each output script such that a counter must reach at least a predetermined number (or threshold) in order for the output to be unlocked. That is, each output script is configured to determine whether a counter has been incremented to a predetermined number. If so, the associated output is unlocked and may be redeemed by Bob 103b. If the threshold is not reached, the output is not unlocked. Unlike BTP, in STP at least one output script requires the counter to reach a different predetermined number. That is, some of the output scripts require different thresholds to be met in order to be unlocked.

[0098] In some examples, each output script requires a different threshold to be met. In other examples, one or more output scripts may share the same threshold. In some examples, each output may lock a different amount of the digital asset. In other examples, one or more output scripts may lock the same amount of the digital asset. The amount of the digital asset may increase with the threshold, i.e., a larger amount of the digital asset can be redeemed when more criteria are met. The increment may or may not be proportional to the number of criteria met.

[0099] Like BTP, in STP the total number of criteria components may be greater than a threshold number. Alternatively, each criteria component must be satisfied for the output to be unlocked. Also like BTP, in STP one or more of the criteria components may be composed of multiple sub-criteria components.

[0100] 6 shows an exemplary representation of a first transaction Tx1. The first transaction Tx1 has multiple Outputs i. In the example shown, each Output represents an amount y i That is, output 1 locks the quantity y1, output 2 locks the quantity y2, and output π locks the quantity y π As shown, transaction Tx1 locks at least y i The Ethereum network includes an Input that contains an amount of digital assets equal to the sum of

[0101] Note that Figure 6 illustrates what must be provided within the input script to unlock each output, not what is contained in the output itself. Looking at Output 1 in Figure 6, we can see that in order to unlock Output 1, enough input data items ( <input> y1, y2, and y3 may be provided. The second transaction Tx2 is referred to below as a “Collect transaction” because it allows Bob 103b to collect the digital asset y1 locked by Output 1. Each of the first script conditions (hereinafter referred to as a “Collect condition”) may be provided such that the Collect transaction includes the digital signature σ Alice and σ Bob As another optional feature, the collection condition may require that the collection transaction Tx2 includes a secret value k of Bob's choosing. The secret value is secret in the sense that it is known only to Bob 103b until the collection transaction is sent and included in the blockchain 150. To request the secret value for a collection transaction, Bob 103b must send a hash of the secret value to Alice 103a. The collection condition can then hash the secret value and compare the resulting value to the hash in the collection condition obtained from Bob 103b. Note that there are other ways to unlock the output of Tx1. These are discussed below with reference to the "Refund Transaction" and "Cancel Transaction".

[0102] For convenience, Collect, Refund, and Cancel transactions are sometimes written in upper case herein, but this does not necessarily imply any particular characteristics or formal names. The terms may equally be written in lower case elsewhere in this specification.

[0103] In some examples, Alice 103a may herself construct part of the collection transaction Tx2. For example, Alice 103a may send her digital signature σ to Bob 103b via a side channel (e.g., side channel 301 shown in FIG. 3). Alice Alice 103a may provide a partial transaction including: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 12

[0104] When composing the first transaction Tx1, Alice 103a may include a second script condition in each output script. The second script condition is referred to below as a "Refund condition". Similar to a collect condition, a refund condition is a label for a portion of an output script and includes one or more opcodes (or functions in general). A refund condition may also include one or more data elements. A refund condition is configured to require that the input script of a subsequent transaction includes Alice's digital signature and Bob's digital signature. That is, the refund condition determines whether Alice's signature and Bob's signature are provided in the input script of the "refund transaction", and if so, the refund condition is set to TRUE (or YES) on the stack, for example. <1> ) is evaluated.

[0105] Each output is constructed such that an input script in a later transaction can only satisfy one script condition. That is, any given input script cannot satisfy both a collect condition and a refund condition. This is because the collect condition and the refund condition require different input data items to be unlocked. For example, a collect condition requires an input data item that satisfies a criteria component, but a refund condition does not.

[0106] In some examples, Alice 103a may compose a portion of the refund transaction herself. For example, Alice 103a may provide Bob 103b a partial transaction including her digital signature σAlice via a side channel (e.g., side channel 301 shown in FIG. 3). Alice 103a may compose such a partial transaction for each output in the first transaction. Alice 103a may include a lock time in the partial refund transaction that she composes and sends to Bob via the side channel. Bob 103b may then provide his signature σ Bob in the partial refund transaction and send the signed refund transaction back to Alice 103a. It will be appreciated that in an alternative example, Bob 103b may first sign the partial refund transaction and send it to Alice for Alice to sign.

[0107] Similar to collect transactions, Alice 103a may set a lock time for each refund transaction. The lock time may be set before Alice and / Bob sign the transaction with their respective signatures. For each output that has an associated collect transaction and refund transaction, the lock time of the refund transaction is later than the lock time of the collect transaction. This means that the collect transaction can be included in a block of blockchain 150 before its associated refund transaction.

[0108] The refund terms and refund transactions together are intended to allow Alice 103a to redeem the amount of digital assets in each output that was not claimed by Bob 103b. As an example, if Bob is unable to provide an input that meets a threshold criteria for any output (e.g., within a given period of time), Alice 103a needs to be able to recover (or refund) the digital assets tied to the output.

[0109] When composing the first transaction Tx1, Alice 103a may include a third script condition in some or all of the output script. The third script condition is referred to below as the "Cancel condition". Similar to the collect and refund conditions, the cancel condition is a label for a portion of the output script and includes one or more opcodes (or functions in general). The cancel condition may also include one or more data elements. The cancel condition is configured to require that the input script of the subsequent transaction includes Alice's digital signature. That is, the cancel condition determines whether Alice's digital signature is provided in the input script of the "cancel transaction", and if so, the cancel condition is set to TRUE (or YES) on the stack, for example. <1> ). The revocation condition may also require a secret value k.

[0110] The revocation condition and the revocation transaction together are intended to allow Alice 103a to redeem the amount of the digital asset in each output that was not claimed by Bob 103b. As an example, if one output requires two criteria to be met and another output requires three criteria to be met, and Bob 103b can only meet two criteria, then Alice 103a needs to be able to withdraw (or refund) outputs that have an output script that specifies the three-criterion threshold. By requiring that the revocation transaction contain a secret value (known only to Bob 103b until it is disclosed on the blockchain), Bob 103b can ensure that Alice 103a cannot revert any of the transactions until Bob 103b attempts to claim one of the outputs using a collect transaction.

[0111] Spectral thresholding is used in the context of STP, where a recipient Bob 103b is paid based on the number of criteria he is able to meet. With binary thresholding, it does not matter "which criteria" are met, but rather how many criteria are met.

[0112] To achieve the spectral threshold function, STP uses transactions (called sPay transactions) that contain at least π ≤ n outputs. Each output i is a set of outputs m that Bob is asked to meet. i Based on a certain amount y i Pay.m i The value of the asset is defined as follows:

number

[0113] The intention is that the recipient i If the criteria can be met, the payee can receive the dedicated output, y, from the output of the sPay transaction, i. i The payout amount does not necessarily have to be proportional to the number of criteria met, although the protocol lends itself to such examples. As a non-proportional example, Bob 103b could redeem 10 units of the digital asset if he meets at least one criterion, 15 units of the digital asset if at least two criteria are met, and 25 units of the digital asset if at least three criteria are met.

[0114] Furthermore, the threshold payment criteria for a set of outputs can be "arbitrary" and therefore do not necessarily have to be an arithmetic progression and / or follow a predefined pattern. a Regarding the criteria for "at least m b Regarding the criteria for "at least m c Regarding the criteria for "at least m d For each criterion, consider including outputs in sPay transactions, where m a <m b and m c <m d and the threshold m x ,m y ,m z There is no output for in the sPay transaction, where

number

[0115] "It is not an arithmetic progression" is y b -y a But not necessarily y d -y c In light of the adjustment of the "arbitrary threshold" criterion for the outputs, recall that there are n criteria that can be satisfied, but there are π ≤ n outputs.

[0116] In some examples, each output of an sPay transaction includes multiple script conditions, such as collect, refund, and cancel conditions. Each output must include a collect condition and can optionally include a refund condition and / or a cancel condition. As shown in Figure 6, output 1 includes a collect condition and a refund condition, which can be satisfied by a collect or refund transaction. Output 2 includes a collect, refund, and cancel condition, which can be satisfied by a collect, refund, or cancel transaction.

[0117] The different payment transactions and a description of each transaction are given below.

[0118] Collection Transaction - Collection Transaction i ) is the profit (y i ) to a payee (Bob). The input script of a collect transaction may require one, some, or all of the following: the signature of the payer (Alice), the signature of the payee (Bob), and a secret value k. This secret value is only known to Bob initially and is only revealed when Bob uses the collect transaction. The collect transaction may be time-locked. For example, if the nLockTime field / parameter is set to a value of t i The value t i prevents the collection transaction from being successfully submitted to the blockchain 150 before that point.

[0119] Cancel Transaction i ) is the profit (y i ) to the payer (Alice), where j ≠ i. The input script of the revert transaction requires the signature of the payer (Alice) and optionally a secret value k. This secret may be retrieved by Alice from a collect transaction previously submitted by Bob to the blockchain 150. The revert transaction may be submitted at any time as long as Alice knows k.

[0120] Refund Transaction i ) is the time when the recipient (Bob) t,i+1 , where t i <t i,i+1 <t i+1 If you do not submit a collection transaction (for that output) to the blockchain 150 before i ) to the payer (Alice). The input script of the reversal transaction requires a signature from the payer (Alice) and a signature from the payee (Bob). Refund transactions may be time-locked, i.e., a refund transaction is issued with a value of t i,i+1 Only after this can it be successfully submitted to the blockchain 1150.

[0121] As mentioned above, the design of an sPay transaction is shown in FIG. 6. The information shown in the figure focuses on the various outputs of the transaction and what is required to successfully use each output. In this example, each output i>1 is locked by an output script. The output script allows the recipient to use the output with three different options. Each of these unlock options corresponds to a transaction (refund, collect, or cancel). Note that, as mentioned above, output 1 can only be used with two options (refund and collect). Furthermore, although not required, STP is built on the assumption or expectation that the more criteria a recipient can meet, the more they should be paid. Accordingly, in the sPay transaction shown in FIG. 6, outputs are ordered (top to bottom) with respect to the amount being paid out (which corresponds to the number of criteria to be met for that output). In the figure, larger outputs (and therefore the number of required criteria) are above outputs with lower outputs.

[0122] Figure 7 shows an example output of an sPay transaction where output i:i ≠ 1. This output can be used with a void, collect, or refund transaction.

[0123] FIG. 8 illustrates an example revocation transaction 800. To use the revocation transaction 800 to use the output shown in FIG. 7, the payer (hopefully the payer (Alice)) must generate her signature and a secret value k. The secret value is thought of and is initially known only to the payee Bob 103b. The blockchain scripting language implements the request for the (ECDSA) signature and the request for the secret value. A hash puzzle may be used to request the secret value k. An example of such a lock script that requests both a secret value and a signature could be the following:

number

[0124] This script checks the cancellation condition (Condition: i ]). The unlock script (in the undo transaction) can be:

number

[0125] This script uses the undo input ( <Input: Can i >).

[0126] Figure 9 illustrates an exemplary refund transaction 900. In order to use the refund transaction 900 to utilize the output shown in Figure 7, the payer (Alice) must generate her signature, sigA, and the payee (Bob) must also provide his signature, sigB. The refund transaction 900 must be signed by both the payer and the payee. This ensures mutual agreement that the refund transaction should be constructed, with particular attention paid to the required inclusion of a nLockTime value (i.e., lock time 901) that prevents the refund transaction 900 from taking effect until after an agreed upon point in time. An example of a script that may require both signatures could be the following:

number

[0127] This script checks the refund condition ([Condition:Ref i ]). A 2-of-2 (m-of-n) multisig script can be used instead.

[0128] The unlock script (in the refund transaction 900) may be:

number

[0129] This script uses the refund input ( <Input:Ref i >).

[0130] Figure 10 shows an example of a collect transaction 1000. In order to use the collect transaction 1000 using the outputs of Figure 7, at least four items must be provided. The payer (Alice) must generate her signature (sigA) and the payee (Bob) must provide his signature (sigB) and a secret value k. Additionally, Bob 103b must provide the following inputs:

number

[0131] From now on, we will need the m i It is expected that there are enough "correct" input data items to satisfy this criteria. The collection transaction 1000 includes a nLockTime value (i.e., lock time 1001) that prevents the collection transaction 1000 from taking effect until after an agreed upon point in time. An example of a script that may request four pieces of data might be the following:

number

[0132] This script uses the collection condition (Condition: i ]). 2-of-2 (m-of-n) multisig scripts can be used instead. See section [TEST m i ] acts as an expression of a script subsection, which defines the entire set of criteria that the user must satisfy, increments a counter each time a criterion is satisfied, and checks that the correct number of criteria has been satisfied (≧m i ) is verified. This [TEST m i ] Script subsections are TxID bPay The output script may be similar to that shown in and is reproduced below, where: <m i > denotes the threshold for output i.

[0133] Note that the locktime constraint is not expressed in the script, but in the nLockTime field of the collection transaction 1000 .

number

[0134] The unlock script (the input script for the collection transaction 1000) may be:

number

[0135] This script collects input ( <Input: Col i >). This script contains the signatures of both parties and a secret value k. Also in the script is the value <answers>This is shown in the output script section of the sPay transaction output i by [TEST m i At least m in the ] section i A section of the Input Script containing multiple data items that are expected to result in a solution satisfying certain criteria.

number

[0136] <answers>Each of the sub-elements of is arranged in a particular order.<input_i> is evaluated according to the intended criterion_i found in the TEST script.<input_i> is expected to be the payee's (Bob's) solution to the puzzle criterion defined by the payer Alice in [criterion_i]. Note that, similar to BTP, a criterion can have sub-criteria, and an input value can consist of multiple sub-inputs.

[0137] To use output i of an sPay transaction with at least three different payment options (collect, refund, cancel), the locking (output) script for that output must incorporate the script elements necessary to realize the selection of the payment transaction. To do this, the locking script may make use of conditional elements, e.g., OP_IF, OP_ELSE, etc. An example of such a locking script is given below:

number

[0138] Note that the text in brackets is a comment and does not actually have to be included in the transaction.

[0139] Here, the script checks the three conditions: i ], [Condition: REF i ] and [Condition:Can i ], with each condition controlling a particular payment transaction. These conditions are the locking scripts described above. To successfully use the sPay output, the payee Bob 103b must include the correct inputs required for their intended payment transaction type. The input script that determines the payment transaction type may have at least three subsections (see cells below). These inputs correspond to those described above and are shown in the cells below.

number

[0140] If payee Bob 103b is submitting a particular type of payment transaction, say collection 1000, Bob 103b will call the appropriate script subsection <Input: Col i > into the three-part input script and replace the other two input elements with "dummy data". <dummy>and dummy data is defined as input data that intentionally evaluates to "incorrect" when evaluated against the [Condition]. Thus, if Bob 103b wants to submit a collection transaction 1000, the input script for the collection transaction would look similar to the following:

number

[0141] FIG. 11 shows an example time lag for a transaction that follows STP. A transaction with multiple outputs, where each output is m out of n that can be satisfied by a proposed recipient. i The potential vulnerability of "paying on a per-item basis" is that "payees are at least m out of n i If m solutions are known, the proposed recipient i -1 solution, m i This is captured in the statement "-knows 2 solutions, ..., 2 solutions, or 1 solution." This can be interpreted as meaning that the payee can use multiple outputs of an sPay transaction, which is of course highly undesirable. Lock times and time lags can be used to thwart such abuse. This time lag may be enabled by the transaction's nLockTime field, and acts to ensure that the payee can only submit a collect transaction to one and only one output of an sPay transaction.

[0142] The time lag of payment transactions is explained using the diagram shown in FIG. 11. Time is shown on the horizontal axis, from left to right. Payment transactions are shown as full-bodied arrows, and the tail of the arrow starts at (or after) the time at which the transaction can be successfully submitted to the blockchain 150, as limited by the lock time placed on the transaction. As an example, a collect transaction Collect1 must be submitted after time=t1, while a collect transaction Winning2 must be submitted after time=t2. The intended recipient of the payment transaction is shown at the head of the arrow. Retraction transactions are not time-dependent (in this context, this means that the submission of a retraction transaction is not limited by the nLockTime value). Retraction transactions can be submitted to the blockchain 150 at any time, as long as the secret value of k (and Alice's signature) is known by the submitter. Output i=1 does not have a retraction transaction. A retraction transaction for any output j is sent to Alice 103a via the Collect j Used to give the ability to immediately "undo" a transaction. j can be submitted only after the collect transaction for output i has been submitted. Collect1 is the "previous" Collect j , the Refund1 transaction for output i=1 cannot be applied because Bob does not have k. Note that if Bob does not submit his Collect1 transaction, a Refund1 transaction will exist for output i=1. Note that the submission of the collect transaction to the blockchain 150 discloses the value k to any interested parties.

[0143] According to Figure 11, one transaction Tx1 that can be submitted is Collect1 for output i=1. It can be submitted by Bob after time t1. j is the time t 1,2 (which is a time after time t1 but before time t2). Thus, after time t1, Bob has a time span Δt1=t 1,2 It has a time unit of -t1. This time span is represented by a double arrow.

[0144] The next collect transaction 1000 that may be submitted is Collect2, which may only be submitted after time t2. This means that if Bob 103b wants to collect the proceeds of this second output i=1, he must submit this transaction at (or after) time t2, which is the time that Alice 103a may submit a refund transaction Refund1 for output i=1. 1,2 It can only be submitted after t2, which is after t1.

[0145] This provides protection against Bob 103b collecting multiple outputs of an sPay transaction. The person who funds the payment transaction sPay (Alice) is responsible for executing a refund transaction Refund1 before the payee has the ability to submit a collect transaction Collect2. Thus, t i,i+1 After that, Alice will collect i+1 Δ i,i+1 =t i+1 -t i,i+1 It has a time unit of

[0146] Output i=1 is an exception that does not have a cancel transaction. To examine the cancel transaction, see Figure 11 for general outputs i:i>1. Cancel Transaction i executes the Refund function and throws an exception during the Refund transaction i Unlike this, the submission of a cancellation transaction to the blockchain 150 of the refund transaction is restricted by the knowledge (or lack thereof) of the secret value, rather than by the nLockTime value. As long as the secret value is known to be k, Alice 103a can submit this cancellation version of the "refund" transaction. In some examples, it may also be required to include Alice's signature in this transaction. When Bob 103b submits the collection transaction, if this secret value is disclosed, all cancellation submissions in the resulting output j: j > i may be immediately submitted by Alice 103a. This makes all subsequent outputs inaccessible to Bob 103b. i If Bob 103b submits the collection transaction Collect

[0147] The proposed recipient Bob 103b thus has the responsibility to (off-chain) evaluate which of the outputs he can successfully use and which he wishes to submit. The selected output is expected to reward Bob with the maximum amount of the digital asset. If Bob 103b selects output i, Bob needs to keep the value k secret until he submits the transaction Collect i For any previous output (j < i), Alice would have submitted (or at least had the opportunity to submit) the refund transaction Refund j Preferably, lock time and time drift are not essential. Instead, Alice 103a can simply submit the cancellation and / or refund transactions at the appropriate time. Similarly, Bob 103b can be trusted to submit only a single collection transaction.

[0148]

[0149] Figure 12 shows an exemplary sequence of STP, with time progressing from top to bottom. The sequence is as follows. 1. Bob selects a secret value k. 2. Bob sends the hash of the secret value to Alice. 3. Alice generates an sPay transaction. 4. Alice generates a refund and collection transaction. 5. Alice sends a set of criteria and a lock time to Bob. 6. Alice signs the refund transaction and the collection transaction and sends them to Bob. 7. If Bob agrees, Bob signs the refund transactions and sends them back to Alice. 8. Alice submits the sPay transaction to the blockchain. 9. Bob determines solutions for as many criteria as possible. 10. Bob determines the output he can unlock that pays the maximum amount of digital assets. 11. At this point, Alice may submit a refund to the blockchain for any output j < i. 12. Bob submits the collection transaction for output i to the blockchain. 13. Here, the secret value is disclosed and Alice submits a cancellation transaction for output j > i.

[0150] The above sequence is one specific example and other orders are possible. For example, there is some flexibility when the criteria are presented to Bob.

[0151] As mentioned above, in some implementations of binary and spectral threshold protocols, successfully meeting a criterion increments a counter by one, or in other implementations the counter may be incremented by another value. The implementation of "weighted criteria" may be necessary in certain contexts where certain criteria are more "important" than other criteria. Weighted criteria may be used when the amount given as a reward for meeting a criterion is not forced to be uniform, but depends on what the criterion is.

[0152] Satisfying criterion i sets the counter to w i where

number

[0153] In such implementations, reaching the threshold is not only limited by the number of criteria that are met, but also by what criteria are met. Bob 103b may reach the threshold by meeting a different number of criteria. As an example, if the threshold is set as 6, Bob 103b may reach the threshold by meeting 3 criteria, where the weight of each criterion is worth 2 units. Alternatively, Bob 103b may reach the threshold by meeting 2 criteria, where the weight of each criterion is worth 3 units.

[0154] For both BTP and STP, a counter is incremented in the [TEST] script by a value stored in the alt stack, and for each criterion i, i A design can be made to incorporate this weighted consideration by simply changing the threshold <m i > remains the payer's choice and is selected taking into account the criteria and their weighting.

number

[0155] The previous version of the [TEST] script and the corresponding set of inputs for the unlock script are based on the idea that the recipient Bob 103b may or may not know which of the inputs are capable of satisfying the input's corresponding criteria. Thus, the lock script determines which are correct and updates the counters accordingly. However, it is possible for Bob 103b to know which m of the n criteria he can satisfy before submitting the collect transaction. The [TEST] script can be reworked to ask Bob 103b to specify the criteria that he requires to run the I-CA.

number

[0156] Note that in the revised [TEST] script, an OP_IF element is introduced before each criterion. This if statement checks the input value from Bob (value 0 or 1) to determine if Bob wants I-CA to be performed for that criterion (1 for YES, 0 for NO). The OP_IF opcodes may be replaced by equivalent functions that check for a particular data element. In general, a [TEST] script may contain a "check" component that is configured to check if the input contains one of two possible data elements. If a first data element is provided, the following script executes, and vice versa for a second, different data element.

[0157] Also note the introduction of OP_VERIFY. This can be a separate opcode after the previous element of the reference script, or it can utilize the verify opcode altogether.

number

[0158] Note that the VERIFY script element marks the transaction as invalid if the top stack value is not true. Also, the top stack value is removed. If the criteria fails, the VERIFY component immediately invalidates the entire transaction and no further script execution takes place. Considering the revised [TEST] in the lock script, the unlock script in the collection transaction also needs to be revised. The unlock script mentioned above is modified in the section shown below. <answers>Includes.

number

[0159] An efficient revised version of this section of the Input Script would feature a first or second data element (e.g., a value of 0 or 1) indicating whether Bob wants I-CA to be performed for a particular criterion. An example of such a version is shown below:

number

[0160] Now, Bob 103b knows that he can reach the required threshold by only providing solutions for criteria 1, 4, and n. Therefore, <1> The value of is<input_1> ,<input_4> , and<input_n> It is placed after the element. <0> teeth, <answers>All the other stuff that was in the script<input_i> Replace the value with the revised <answers>Using this, the total number of I-CAs performed is 3 instead of n. Therefore, the weight <w1>If is equal to 1 for all i, then only m I-CAs are performed for the m-of-n thresholds.

[0161] 13 and 14 show an exemplary use case of the [TEST] script with improved efficiency. The use case is an alternative use case to the current implementation of the m-of-n multisig feature of some blockchain protocols. In the existing implementation of the m-of-n multisig feature, with OP_CHECKMULTISIG, the lock script contains a set of n public keys, while the unlock script contains m digital (ECDSA) signatures. The determination of whether the signatures meet the threshold is made in the following manner: The OP_CHECKMULTISIG opcode compares the first signature with each public key until an ECDSA match is found. Starting with the next public key, it compares the second signature with each remaining public key until an ECDSA match is found. The process is repeated until all signatures have been checked or when there are not enough public keys remaining to generate a successful result. Not all signatures need to match the public keys. Since public keys are not checked again if any signature comparison fails, signatures MUST be replaced in scriptSig using the same order that their corresponding public keys were replaced in scriptPubKey. If all signatures are valid, 1 is returned, 0 otherwise.

[0162] Consider the 3-of-5 multisig example shown in Figure 13. Each public key P i can be considered as a standard, and each signature Sig i can be considered as inputs. Note that dashed arrows represent failed I-CAs and non-dashed arrows represent successful I-CAs. (Similarly for Sig3) We see that there are two I-CAs to evaluate Sig3. In the script, we see the public key P against which Sig3 should be evaluated. i Due to the fact that there is no representation of Sig3, in the ordered sequence, P i must be evaluated against the set until one of the following occurs: a) Matching P i reach; b) No match was found and all P i Exhaust value; or c) No match was found and there was not enough P i value, resulting in P i Even if we eventually find a match in the remaining set of P i The remaining Sig i Even if the remaining P is not enough to meet the required threshold (even if the i does not exist.

[0163] Finally, the key point is that in OP_CHECKMULTISIG, each Sig i The m-of-n ECDSA signature [TEST] script is a multi-part script that is used to encrypt and ciphertext. ...

number

[0164] The corresponding unlock script is as follows: where Bob103b has three signatures, Sig1, Sig4, and Sig5: n to provide.

number

[0165] Due to the fact that Bob uses values ​​0 and 1 to indicate the public key against which the signature is evaluated, this reduces the number of I-CAs involved in each signature, as shown in FIG. 14, with the maximum being 1 (as opposed to OP_CHECKMULTISIG, which is 1 or more).

[0166] An additional benefit of using the [TEST] function (both the version described above and the more efficient version) is increased privacy. By using the [TEST] function for m-of-n multisig instead of OP_CHECKMULTISIG, Bob 103b does not need to reveal the public key. This is due to the fact that the OP_CHECKMULTISIG lock script contains the public key, but the [TEST] lock script contains a hash of the public key.

[0167] <Conclusion> It will be understood that the above-described embodiments have been described by way of example only.

[0168] More generally, according to a first example of the teachings disclosed herein, there is provided a computer-implemented method for generating a blockchain transaction, the transaction being for transferring an amount of a digital asset from a first party to a second party, the method being performed by the first party, the method comprising: generating a first transaction including an output that locks the amount of the digital asset; the output includes an output script including a plurality of criteria components, each of which requires a respective input data item; and a plurality of counter script components, each of which is associated with one of the counter script components; The output script, when executed together with the input script of a second transaction, i) incrementing a counter each time each criterion component is satisfied by each input data item of said Input Script; ii) A method is provided in which, in order to be unlocked by the Input Script, the counter must be incremented to at least a predetermined number.

[0169] According to a second optional instance of the teachings disclosed herein, there is provided the method according to the first instance, wherein a total number of the plurality of reference components is greater than or equal to a predetermined number.

[0170] According to a third optional instance of the teachings disclosed herein, there is provided a method according to the first or second instance, wherein one, some or all of the plurality of criteria components define respective criteria that are different.

[0171] According to a fourth optional instance of the teachings disclosed herein, there is provided a method according to any of the first to third instances, wherein one, some or all of the plurality of criteria components includes a plurality of sub-criteria components, each sub-criteria component requiring a respective sub-input data item.

[0172] According to a fifth optional instance of the teachings disclosed herein, there is provided a method according to any of the first to fourth instances, wherein one, some or all of the plurality of criteria components and / or one, some or all of the plurality of sub-criteria components each require as an input or sub-input data item a respective blockchain signature corresponding to a given blockchain public key.

[0173] According to a sixth optional instance of the teachings disclosed herein, there is provided a method according to any of the first to fifth instances, wherein one, some or all of the plurality of criteria components are associated with a counter script component configured to increment the counter by different numbers.

[0174] According to a seventh optional instance of the teachings disclosed herein, the method according to any of the first through sixth instances, wherein each input data item in the Input Script includes a first or second element, and one, some or all of the plurality of criteria components are associated with a respective check component, each check component, when executed in conjunction with the Input Script, performs: i) determining whether each input data item includes said first element; ii) executing the associated criteria component only if the input data item includes the first element; It is provided that the device is configured to:

[0175] According to an eighth optional instance of the teachings disclosed herein, there is provided a method according to any of the first to seventh instances, wherein each output script is configured to invalidate the first transaction if an executed criteria component is not satisfied by input data of the input script.

[0176] According to a ninth optional instance of the teachings disclosed herein, there is provided a method according to any of the first to eighth instances, comprising a step of transmitting each of the criteria and / or sub-criteria to the second party.

[0177] According to a tenth optional instance of the teachings disclosed herein, there is provided a method according to any of the first to ninth instances, comprising sending the first transaction to one or more nodes associated with the blockchain for inclusion in the blockchain.

[0178] According to an eleventh instance of the teachings disclosed herein, a first party computing device, comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device is provided, wherein the memory stores code configured to execute on the processing device, the code configured to execute the method of any of the first to tenth instances.

[0179] According to a twelfth instance of the teachings disclosed herein, there is provided a computer program embodied on a computer readable storage device and configured to perform the method of any of the first to tenth instances when executed on a first party computing device.

[0180] According to a thirteenth instance of the teachings disclosed herein, a first transaction for inclusion in a blockchain, the first transaction for transferring an amount of a digital asset from a first party to a second party, the first transaction embodied on one or more computer readable data media and including executable code, the code including: a plurality of criteria components, each criteria component requiring a respective input data item; and a plurality of counter components, each criteria component associated with one of the counter components; The code, when executed at a node of a blockchain network together with an input script of a second transaction, incrementing a counter stored in a memory of said node each time a respective criterion component is satisfied by a respective input data item of said Input Script; transferring the amount of the digital asset to the second party based on the counter being incremented to at least a predetermined number. A first transaction is provided, the first transaction being configured to:

[0181] According to a fourteenth instance of the teachings disclosed herein, there is provided a computer-implemented method for generating a blockchain transaction, the transaction being for transferring an amount of a digital asset from a first party to a second party, the first and second parties each associated with the blockchain, the method being performed by the first party; generating a first transaction including a plurality of outputs; each output locks a respective amount of said digital asset and includes a respective first script condition; Each first script condition includes a plurality of criteria components, each of which requires a respective input data item, and a plurality of counter components, each of which is associated with one of the counter components; Each first output script condition, when executed together with the second transaction's input script, i) incrementing a counter each time each criterion component is satisfied by each input data item of said Input Script; ii) in order to be unlocked by said input script, said counter must be incremented to at least each predetermined number; A method is provided in which one, some, or all of the first script conditions require the counter to be incremented to different predetermined numbers.

[0182] According to a fifteenth optional instance of the teachings disclosed herein, there is provided a method according to the fourteenth instance, wherein one, some, or all of the outputs lock different respective amounts of the digital asset.

[0183] According to a sixteenth optional instance of the teachings disclosed herein, there is provided a method according to the fifteenth instance, wherein the respective amounts of the digital assets locked by the respective outputs are based on the respective predetermined numbers that the respective first script conditions require to increment the counter.

[0184] According to a seventeenth optional instance of the teachings disclosed herein, there is provided a method according to any of the fourteenth to sixteenth instances, wherein, to be unlocked by the input script, each first script condition is configured to require that the input script include a digital signature of the first party and / or a digital signature of the second party.

[0185] According to an eighteenth optional instance of the teachings disclosed herein, the method according to the seventeenth instance may include the steps of: generating, for each output, a respective second transaction, the input script of each second transaction including the predetermined signature of the first party; transmitting each second transaction to the second party; It is provided that the present invention includes:

[0186] According to a nineteenth optional instance of the teachings disclosed herein, there is provided a method according to the eighteenth instance, wherein each second transaction includes a different lock time; It is provided that each lock time is configured to prevent each second transaction from being included in the blockchain until after a respective predetermined time.

[0187] According to a twentieth optional instance of the teachings disclosed herein, there is provided a method according to any one of the fourteenth to nineteenth instances, wherein each first script condition includes a hash of a secret value; It is provided that, in order to be unlocked by said input script, each first script condition is configured to require that said input script contains said secret value.

[0188] According to a twenty-first optional instance of the teachings disclosed herein, there is provided a method according to any of the fourteenth to twentieth instances, wherein each output includes a respective second script condition, the second script condition, when executed together with an input script of a third transaction, requiring that the input script of the third transaction include a predetermined digital signature of the first party and a predetermined digital signature of the second party in order to be unlocked by the input script.

[0189] According to a twenty-second optional instance of the teachings disclosed herein, the method according to the twenty-first instance may further include the steps of: for each output, receiving a respective third transaction from the second party, the input script of each third transaction including the predetermined signature of the first party and the predetermined digital signature of the second party; It is provided that the present invention includes:

[0190] For example, the first party may sign the third transaction and send the signed third transaction to the second party, which may then send the third transaction to the first party.

[0191] According to a twenty-third optional instance of the teachings disclosed herein, there is provided a method according to the twenty-second instance, wherein each third transaction includes a different lock time; It is provided that each lock time is configured to prevent each second transaction from being included in the blockchain until after a respective predetermined time.

[0192] According to a twenty-fourth optional instance of the teachings disclosed herein, a method according to the twenty-third instance dependent on at least the nineteenth instance, wherein each output is associated with a different one of the second transactions and a different one of the third transactions; For each output, a lock time for each of the third transactions is provided that prevents the third transaction from being included in the blockchain until a time after the time that the second transaction can be included in the blockchain.

[0193] According to a twenty-fifth optional instance of the teachings disclosed herein, the method according to any of the fourteenth to twenty-fourth instances, wherein one, some, or all of the outputs include a respective third script condition; It is provided that each third script condition is configured, when executed together with an input script of a fourth transaction, to require that the input script of the fourth transaction include a predetermined digital signature of the first party in order to be unlocked by the input script.

[0194] According to a twenty-sixth optional instance of the teachings disclosed herein, a method according to the twenty-fifth instance depending on at least the twentieth instance, wherein each third script condition includes a hash of a secret value; It is provided that, in order to be unlocked by an input script of the fourth transaction, each third script condition is configured to require that the input script includes the secret value.

[0195] According to a twenty-seventh optional instance of the teachings disclosed herein, a method according to the twenty-sixth instance, comprising the steps of obtaining the secret value; generating a respective fourth transaction for one, some, or all of the outputs, the input script of each fourth transaction including the predefined signature of the first party and the secret value; sending each fourth transaction to one or more nodes associated with the blockchain for inclusion in the blockchain; It is provided that the present invention includes:

[0196] According to a 28th optional instance of the teachings disclosed herein, there is provided a method according to any of the 14th to 27th instances, wherein a total number of the plurality of reference components is greater than or equal to each of the predetermined numbers.

[0197] According to a twenty-ninth optional instance of the teachings disclosed herein, there is provided a method according to any of the fourteenth to twenty-eighth instances, wherein one, some or all of the plurality of criteria components define respective criteria that are different.

[0198] According to a 30th optional instance of the teachings disclosed herein, there is provided a method according to any of the 14th to 29th instances, wherein one, some or all of the plurality of criteria components includes a plurality of sub-criteria components, each sub-criteria component requiring a respective sub-input data item.

[0199] According to a thirty-first optional instance of the teachings disclosed herein, there is provided a method according to any of the fourteenth to thirtieth instances, wherein for one, some or all of the first script conditions, one, some or all of the plurality of criteria components and / or one, some or all of the plurality of sub-criteria components each require, as an input or sub-input data item, a respective blockchain signature corresponding to a predefined blockchain public key.

[0200] According to a thirty-second optional instance of the teachings disclosed herein, there is provided a method according to any of the fourteenth to thirty-first instances, wherein for one, some, or all of the first script conditions, one, some, or all of the plurality of criteria components are associated with a counter script component configured to increment the counter by different numbers.

[0201] According to a thirty-third optional instance of the teachings disclosed herein, the method according to any of the fourteenth through thirty-second instances, wherein each input data item in the input script includes a first or second element, and one, some or all of the plurality of criteria components are associated with a respective check component, each check component, when executed in conjunction with the input script, performs: i) determining whether each input data item includes said first element; ii) executing only the criteria components corresponding to the input data items that include the first element; It is provided that the device is configured to:

[0202] According to a thirty-fourth optional instance of the teachings disclosed herein, there is provided a method according to the thirty-third instance, wherein each first script condition is configured to invalidate the first transaction if an executed reference script is not satisfied by input data of the input script.

[0203] According to a thirty-fifth optional instance of the teachings disclosed herein, there is provided a method according to any of the fourteenth to thirty-fourth instances, comprising a step of transmitting each of the criteria and / or sub-criteria to the second party.

[0204] According to a thirty-sixth optional instance of the teachings disclosed herein, there is provided a method according to any of the fourteenth to thirty-fifth instances, comprising sending the first transaction to one or more nodes associated with the blockchain for inclusion in the blockchain.

[0205] According to a thirty-seventh instance of the teachings disclosed herein, a first party computing device, comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device is provided, wherein the memory stores code configured to run on the processing device, the code configured to perform the method of any of the fourteenth to thirty-sixth instances.

[0206] According to a 38th instance of the teachings disclosed herein, there is provided a computer program embodied on a computer readable storage device and configured to perform the method of any of the 14th to 36th instances when executed on a first party computing device.

[0207] According to a thirty-ninth optional instance of the teachings disclosed herein, there is provided a computer-implemented method for generating a blockchain transaction, the transaction for transferring an amount of a digital asset from a first party to a second party, the first and second parties each associated with the blockchain, the blockchain including a first transaction, the first transaction including an output that locks the amount of the digital asset, and a first script condition, the first script condition including a plurality of criteria components, each criteria component including a respective input data item, the method being executed by the second party; generating a second transaction including a first InputScript component, the first InputScript component comprising: i) a plurality of input data items, each input data item corresponding to a respective criteria component of the first script condition; ii) a secret value; iii) a predetermined digital signature of the first party; and iv) signing the second party's signature; sending the second transaction to one or more nodes associated with the blockchain for inclusion in the blockchain; A method is provided that includes:

[0208] According to a fortieth optional instance of the teachings disclosed herein, there is provided a method according to the thirty-ninth instance, wherein the first transaction includes second and third script conditions; The second transaction is a second input script component configured to evaluate the second script condition as false when executed; a third input script component configured to evaluate the third script condition as false when executed; It is provided that the present invention includes:

[0209] According to a forty-first optional instance of the teachings disclosed herein, the method according to the thirty-ninth or fortieth instance, wherein the first script condition includes a plurality of check components, each check component being associated with a respective one of the plurality of criteria components; Each check component, when executed with the input script, i) determining whether each input data item includes said first element; ii) executing only the reference script components that correspond to input data items that include the first element; It is provided that each input data item comprises said first data element or a second different data element.

[0210] According to a 42nd optional instance of the teachings disclosed herein, there is provided a method according to any of the 39th to 41st instances, wherein one, some or all of the input data items include respective digital signatures.

[0211] According to a forty-third instance of the teachings disclosed herein, a second party computing device, comprising: a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device is provided, wherein the memory stores code configured to run on the processing device, the code configured to perform the method of any of the thirty-ninth to forty-second instances.

[0212] According to a 44th instance of the teachings disclosed herein, there is provided a computer program embodied on a computer readable storage device and configured to perform the method of any of the 39th to 42nd instances when executed on a second party computing device.

[0213] According to a forty-fifth optional instance of the teachings disclosed herein, a first transaction for inclusion in a blockchain, the first transaction for transferring an amount of a digital asset from a first party to a second party, the first transaction embodied on one or more computer readable data media and including executable code, the code including a plurality of output scripts, each output script locking a respective amount of the digital asset, and each first, second, and third script condition, each first script condition comprising: i) a plurality of criteria components, each of which requires a respective input data item; ii) a plurality of counter components, each reference component being associated with one of the counter components; The code, when executed at a node of a blockchain network, includes: incrementing a counter stored in a memory of the node each time a respective criteria component is satisfied by a respective input data item of the input script when the respective first script condition is executed, and transferring the amount of the digital asset to the second party based on the counter being incremented to at least a predetermined number; determining whether the input script includes a predetermined digital signature of the first party and a predetermined digital signature of the second party when each second script condition is executed; and transferring the amount of the digital asset to the first party; determining whether the input script includes the predetermined digital signature and secret value of the first party when each third script condition is executed, and transferring the amount of the digital asset to the first party. A first transaction is provided, the first transaction being configured to:

[0214] According to a forty-sixth optional instance of the teachings disclosed herein, there is provided a computer-readable storage medium storing a first transaction according to the forty-fifth instance.

[0215] According to a forty-seventh optional instance of the teachings disclosed herein, there is provided a computer-readable storage medium storing a first transaction according to the thirteenth instance.

[0216] According to another instance of the teachings disclosed herein, a method may be provided that includes operations of the first party and the second party.

[0217] According to another instance of the teachings disclosed herein, a system may be provided that includes the first party and the second party computing devices.

[0218] According to another instance of the teachings disclosed herein, a set of transactions may be provided that includes the first and second transactions.

[0219] Other variations or uses of the disclosed technology may become apparent to those skilled in the art upon review of this specification, and the scope of the present disclosure is not limited by the described embodiments, but only by the scope of the appended claims. < / answers> < / answers> < / answers> < / dummy> < / answers> < / answers> < / sigpa>

Claims

1. 1. A computer-implemented method for generating a blockchain transaction, the transaction being for transferring an amount of a digital asset from a first party to a second party, the method being performed by the first party; generating a first transaction including an output that locks the amount of the digital asset; the output includes an output script, the output script including a plurality of criteria components, each criteria component requiring a respective input data item, and a plurality of counter script components, each criteria component associated with one of the counter script components; The output script, when executed together with the input script of a second transaction, i) incrementing a counter each time each criterion component is satisfied by each input data item of said Input Script; ii) the counter must be incremented to at least a predetermined number in order to be unlocked by the input script.

2. 2. The method of claim 1, further comprising: transmitting the first transaction to one or more nodes associated with the blockchain for inclusion in the blockchain.

3. The method according to claim 1 or 2, wherein a total number of the plurality of reference components is equal to or greater than the predetermined number.

4. The method of any of claims 1 to 3, wherein one, some or all of the plurality of criteria components define different respective criteria.

5. The method according to any one of claims 1 to 4, wherein one, some or all of the plurality of criteria components comprises a plurality of sub-criteria components, each sub-criteria component requiring a respective sub-input data item.

6. 6. The method of claim 5, wherein one, some, or all of the plurality of criteria components and / or one, some, or all of the plurality of sub-criteria components each require as an input or sub-input data item a respective blockchain signature corresponding to a given blockchain public key.

7. The method of any preceding claim, wherein one, some or all of the plurality of criteria components are associated with a counter script component configured to increment the counter by different numbers.

8. Each input data item in the Input Script includes a first or second element, and one, some or all of the criteria components are associated with a respective check component, each check component, when executed with the Input Script, i) determining whether each input data item includes said first element; ii) executing the associated criteria component only if the input data item includes the first element; The method according to any one of claims 1 to 7, wherein the method is configured to:

9. The method of claim 8 , wherein each output script is configured to invalidate the first transaction if an executed criteria component is not satisfied by input data of the input script.

10. A method according to claim 5 or any of claims 6 to 9 when dependent on claim 5, comprising the step of transmitting each said criteria and / or sub-criteria component to said second party.

11. a first party computing device, a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device, wherein the memory stores code configured to run on the processing device, the code configured to perform a method according to any of claims 1 to 10.

12. A computer program embodied on a computer readable storage device and arranged to carry out the method of any of claims 1 to 10 when executed on a first party computing device.

13. A first transaction for inclusion in a blockchain, the first transaction for transferring an amount of a digital asset from a first party to a second party, the first transaction embodied on one or more computer readable data media and comprising executable code, the code comprising: a plurality of criteria components, each criteria component requiring a respective input data item; and a plurality of counter components, each criteria component associated with one of the counter components; The code, when executed at a node of a blockchain network together with an input script of a second transaction, incrementing a counter stored in a memory of said node each time a respective criterion component is satisfied by a respective input data item of said Input Script; transferring the amount of the digital asset to the second party based on the counter being incremented to at least a predetermined number. The first transaction is configured as follows:

14. 1. A computer-implemented method of generating a blockchain transaction, the transaction being for transferring an amount of a digital asset from a first party to a second party, the first and second parties each associated with the blockchain, the method being performed by the first party; generating a first transaction including a plurality of outputs; each output locks a respective amount of said digital asset and includes a respective first script condition; each first script condition includes a plurality of criteria components, each criteria component requiring a respective input data item, and a plurality of counter components, each criteria component being associated with one of the counter components; Each first output script condition, when executed together with the input script of the second transaction, i) incrementing a counter each time each criterion component is satisfied by each input data item of said Input Script; ii) in order to be unlocked by said input script, said counter must be incremented to at least each predetermined number; A method wherein one, some, or all of the first script conditions require the counter to be incremented to different predetermined numbers.

15. 15. The method of claim 14, comprising sending the first transaction to one or more nodes associated with the blockchain for inclusion in the blockchain.

16. 16. The method of claim 14 or 15, wherein one, some, or all of the outputs lock different respective amounts of the digital asset.

17. A method according to any of claims 14 to 16, wherein each amount of the digital asset locked by each output is based on a respective predetermined number that each first script condition requires to increment the counter.

18. 18. The method of claim 14, wherein, in order to be unlocked by the input script, each first script condition is configured to require that the input script includes a digital signature of the first party and / or a digital signature of the second party.

19. generating, for each output, a respective second transaction, the input script of each second transaction including a predefined digital signature of the first party; transmitting each second transaction to the second party; 20. The method of claim 18, comprising:

20. Each second transaction includes a different lock time; 20. The method of claim 19, wherein each lock time is configured to prevent each second transaction from being included in the blockchain until after a respective predetermined time.

21. Each first script condition includes a hash of a secret value; A method according to any of claims 14 to 20, wherein, in order to be unlocked by said input script, each first script condition is configured to require that said input script contains said secret value.

22. 22. A method according to any of claims 14 to 21, wherein each output includes a respective second script condition which, when executed together with an input script of a third transaction, requires that the input script of the third transaction include a pre-defined digital signature of the first party and a pre-defined digital signature of the second party in order to be unlocked by the input script.

23. for each output, receiving a respective third transaction from the second party, the input script of each third transaction including a predetermined digital signature of the first party and the predetermined digital signature of the second party; 23. The method of claim 22, comprising:

24. Each third transaction includes a different lock time; 24. The method of claim 23, wherein each lock time is configured to prevent each second transaction from being included in the blockchain until after a respective predetermined time.

25. each output is associated with a different one of the second transactions and a different one of the third transactions; 25. The method of claim 24 when dependent on at least claim 20, wherein for each output, a lock time of each of the third transactions prevents the third transaction from being included in the blockchain until a time after the time the second transaction can be included in the blockchain.

26. one, some, or all of the outputs include a respective third script condition; 26. A method according to any one of claims 14 to 25, wherein each third script condition is configured, when executed together with an input script of a fourth transaction, to require that the input script of the fourth transaction includes a predefined digital signature of the first party in order to be unlocked by the input script.

27. Each third script condition includes a hash of the secret value; 27. A method according to claim 26 when dependent on claim 21, wherein each third script condition is configured to require that the input script include the secret value in order to be unlocked by the input script of the fourth transaction.

28. obtaining the secret value; generating a respective fourth transaction for one, some, or all of the outputs, the input script of each fourth transaction including a predefined digital signature of the first party and the secret value; sending each fourth transaction to one or more nodes associated with the blockchain for inclusion in the blockchain; 28. The method of claim 27, comprising:

29. A method according to any one of claims 14 to 28, wherein a total number of the plurality of reference components is equal to or greater than the respective predetermined numbers.

30. A method according to any of claims 14 to 29, wherein one, some or all of the plurality of criteria components define different respective criteria.

31. A method according to any of claims 14 to 30, wherein one, some or all of the plurality of criteria components comprises a plurality of sub-criteria components, each sub-criteria component requiring a respective sub-input data item.

32. 32. The method of claim 31 , wherein one, some, or all of the first script conditions, one, some, or all of the criteria components, and / or one, some, or all of the sub-criteria components each require a respective blockchain signature corresponding to a predefined blockchain public key as an input or sub-input data item.

33. 33. The method of any of claims 14 to 32, wherein one, some or all of the first script conditions and one, some or all of the plurality of criteria components are associated with a counter script component configured to increment the counter by different numbers.

34. Each input data item in the Input Script includes a first or second element, and one, some or all of the criteria components are associated with a respective check component, each check component, when executed with the Input Script, i) determining whether each input data item includes said first element; ii) executing only the criteria components that correspond to the input data items that include the first element; The method according to any one of claims 14 to 33, wherein the method is configured to:

35. 35. The method of claim 34, wherein each first script condition is configured to invalidate the first transaction if an executed criteria component is not satisfied by input data of the input script.

36. A method according to any of claims 14 to 35, comprising the step of transmitting each said criteria and / or sub-criteria component to said second party.

37. a first party computing device, a memory including one or more memory units; a processing device including one or more processing units; Including, A computing device, wherein the memory stores code configured to run on the processing device, the code being configured to perform a method according to any one of claims 14 to 36 when executed on the processing device.

38. A computer program embodied on a computer readable storage device and arranged to carry out the method of any of claims 14 to 36 when executed on a first party computing device.

39. 1. A computer-implemented method for generating a blockchain transaction, the transaction for transferring an amount of a digital asset from a first party to a second party, the first and second parties each associated with the blockchain, the blockchain comprising a first blockchain transaction, the first blockchain transaction comprising an output that locks the amount of the digital asset and comprising an output script, the output script comprising a plurality of criteria components, each criteria component requiring a respective input data item, and a plurality of counter script components, each criteria component associated with one of the counter script components, the output script, when executed together with an input script of a second transaction, i) increments a counter each time a respective criteria component is satisfied by a respective input data item of the input script, and ii) the counter must be incremented to at least a predetermined number in order to be unlocked by the input script, the method being executed by the second party; generating a second transaction including a first input that references a first output of the first blockchain transaction, the first input including a first input script component, the first input script component comprising: i) a plurality of input data items, each input data item corresponding to a respective reference component of the output script; ii) a secret value; iii) a predetermined digital signature of the first party; and iv) a predetermined signature of the second party; sending the second transaction to one or more nodes associated with the blockchain for inclusion in the blockchain; The method includes:

40. a second party computing device, a memory including one or more memory units; a processing device including one or more processing units; Including, 40. A computing device, wherein the memory stores code configured to execute on the processing device, the code configured to execute the method of claim 39 when executed on the processing device.

41. 40. A computer program embodied on a computer readable storage device and configured to perform the method of claim 39 when executed on a second party computing device.

42. A first transaction for inclusion in a blockchain, the first transaction for transferring an amount of a digital asset from a first party to a second party, the first transaction embodied on one or more computer readable data media and including executable code, the code including a plurality of output scripts, each output script locking a respective amount of the digital asset, and each first, second, and third script condition, each first script condition: i) a plurality of criteria components, each of which requires a respective input data item; ii) a plurality of counter components, each reference component being associated with one of the counter components; The code, when executed at a node of a blockchain network, includes: incrementing a counter stored in a memory of the node each time a respective criteria component is satisfied by a respective input data item of the Input Script when the respective first script condition is executed, and transferring the amount of the digital asset to the second party based on the counter being incremented to at least a predetermined number; determining whether the input script includes a predetermined digital signature of the first party and a predetermined digital signature of the second party when each second script condition is executed; and transferring the amount of the digital asset to the first party; determining whether the input script includes the predetermined digital signature and secret value of the first party when each third script condition is executed, and transferring the amount of the digital asset to the first party. The first transaction is configured as follows:

43. 43. A computer readable storage medium storing the first transaction of claim 42.

44. 14. A computer readable storage medium storing the first transaction of claim 13.

Images