Multi-standard blockchain protocols

Abstract

A computer-implemented method for generating transactions for blockchain, the transactions being used to transfer digital asset amounts from a first party to a second party. The method includes: generating a first transaction, the first transaction including an output locking the digital asset amount, the output including an output script, the output script including a plurality of standard components and a plurality of counter script components, each standard component requiring a corresponding input data item. Each standard component is associated with one of the counter script components. The output script is configured to, when executed together with an input script of a second transaction, i) increment a counter whenever a corresponding input data item of the input script satisfies a corresponding standard component, and ii) require the counter to increment to at least a predetermined amount for unlocking by the input script.

Description

Technical Field

[0001] This disclosure relates to methods and transactions for implementing blockchain protocols that require compliance with m / n criteria (m-of-ncriteria) to unlock transactions. Background Technology

[0002] A blockchain is a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain consists of a series of data blocks, where each block contains one or more transactions. Each transaction can refer back to previous transactions in the sequence, and can extend one or more blocks. Through a process called "mining," transactions can be included in new blocks by being submitted to the network.

[0003] Transactions in blockchains are typically used to transfer digital assets, i.e., data used as a store of value. However, blockchains can also be used to implement layered, additional functionalities. For example, blockchain protocols can allow additional user data to be stored in transaction outputs. Modern blockchains are constantly increasing the maximum data capacity that can be stored in a single transaction, enabling the incorporation of more complex data. This can be used, for example, to store electronic documents, or even audio or video data, within the blockchain.

[0004] Each node in the network can have any one, two, or all of the following three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions throughout the network. Mining nodes mine transactions into blocks. Storing nodes each store their own copy of the mined blocks in the blockchain. To record a transaction in the blockchain, one party sends the transaction to one of the nodes in the network for propagation. Mining nodes receiving the transaction can compete to mine it into a new block. Each node is configured to adhere to the same node protocol, which will include one or more conditions for confirming the validity of a transaction. Invalid transactions will not be propagated or mined into blocks. Assuming the transaction has been verified as valid and thus accepted on the blockchain, the attached user data will therefore continue to be stored as an immutable public record at various nodes in the P2P network.

[0005] Some blockchain protocols use scripting languages ​​that enable parties to create high-level standards against which potential recipients can spend the transaction's output. Some scripting languages ​​include functions (sometimes called opcodes) that check if a sufficient number of valid digital signatures exist in the transaction's inputs. If the required m / n signatures are available, the output can be spent. Summary of the Invention

[0006] While useful, m / n signature checks are limited to checking whether a threshold for the requested digital signature is met. However, in some scenarios, a threshold that is not necessarily a signature criterion may be required. For example, a potential recipient might be required to generate 'at least a specified number of hash preimages' to spend the transaction's output.

[0007] According to one aspect disclosed herein, a method for generating a computer implementation for a blockchain transaction used to transfer a digital asset amount from a first party to a second party is provided; the method is implemented by the first party and includes: generating a first transaction, the first transaction including an output that locks a digital asset amount, the output including an output script, the output script including a plurality of standard components and a plurality of counter script components, each standard component requiring a corresponding input data item, each standard component being associated with one of the counter script components, and wherein the output script is configured to, when executed together with an input script of a second transaction, i) increment a counter whenever a corresponding input data item of the input script satisfies a corresponding standard component, and ii) require the counter to increment to at least a predetermined amount for unlocking by the input script.

[0008] Therefore, a Binary Threshold Protocol (BTP) is provided, where threshold restrictions can be applied to any type of criterion. Output script conditions define multiple criteria that the input data items included in a transaction attempting to spend digital assets must satisfy. Each time a criterion is met, a counter is incremented (e.g., by one). If the counter has reached a predetermined amount (the binary threshold) when all input data items have been used up, the first script condition is unlocked. If the input script satisfies any other condition of the protocol (e.g., the transaction is valid), the digital asset amount is transferred to the second party. The protocol is binary; in a sense, if the threshold is reached, the digital assets can be transferred (e.g., spent), and if the threshold is not reached, the digital assets cannot be transferred.

[0009] While BTP offers advantages, in some cases the amount of digital assets that may need to be transferred to a second party may be based on the number of criteria met (e.g., more digital assets are transferred if more criteria are met). For example, if the expected recipient can provide 1 of n preimages, a first amount may need to be transferred; if 2 of n preimages are provided, a larger amount may need to be transferred; and if 3 of n preimages are provided, an even larger amount may need to be transferred.

[0010] According to another aspect disclosed herein, a method for generating a computer implementation of a blockchain transaction for transferring a digital asset amount from a first party to a second party, both parties being associated with a blockchain, is provided; the method is implemented by the first party and includes: generating a first transaction comprising a plurality of outputs, each output locking a corresponding digital asset amount and including a corresponding first script condition, wherein each first script condition includes a plurality of standard components and a plurality of counter components, each standard component requiring a corresponding input data item, each standard component being associated with one of the counter components, and wherein each first output script is configured, when executed together with an input script of a second transaction, i) increment a counter whenever a corresponding input data item of the input script satisfies a corresponding standard component, and ii) require the counter to increment to at least a corresponding predetermined amount for unlocking by the input script, and wherein one, some, or all of the first script conditions require the counter to increment to different predetermined amounts.

[0011] Similar to BTP, this method provides a Spectrum Threshold Protocol (STP), where threshold limits can be applied to any type of criterion. The first transaction has multiple outputs, each of which transfers a digital asset amount upon unlocking. For example, each output can transfer a different digital asset amount, with the first output transferring a first amount, the second output transferring a different (e.g., larger) amount, and so on. Each output has a first output script condition, which has multiple criteria that can be satisfied by the input data items contained in the transaction attempting to spend the digital asset. A counter is incremented (e.g., by one) whenever a criterion is satisfied. Some first output script conditions require the counter to reach different predetermined numbers for unlocking. That is, at least one output script will unlock with a lower number of criteria satisfied compared to another output script. This creates the spectrum threshold. For example, satisfying a smaller number of criteria unlocks an output that locks a smaller amount of digital asset, while satisfying a larger number of criteria unlocks an output that locks a larger amount of digital asset.

[0012] Each individual output of the first transaction following STP is similar to the output of the first transaction following BTP. The predetermined number (threshold) of STP outputs required varies in some or all of the outputs.

[0013] For each threshold protocol, a set of transactions is used to allow the recipient (second party) to access digital assets based on the number of criteria the recipient meets. STP is suitable for situations where the amount of digital asset (reward) is proportional to the number of criteria the recipient can meet, and for situations where the reward is not proportional to the number of criteria met. For example, there may be a reward cap exceeding a certain threshold, where meeting more criteria does not increase the obtainable reward. Attached Figure Description

[0014] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0015] Figure 1 This is a schematic block diagram of a system for implementing blockchain.

[0016] Figure 2 The illustration shows some examples of transactions that can be recorded in the blockchain;

[0017] Figure 3 This is a schematic block diagram of another system used to implement blockchain;

[0018] Figure 4 A schematic block diagram of node software for processing transactions according to a node protocol based on an output-based model is shown.

[0019] Figure 5 yes Figure 1 A simplified version, schematically illustrating a system for implementing blockchain transactions with a common standard threshold.

[0020] Figure 6 This is a schematic representation of a spectrum payment transaction;

[0021] Figure 7 It is a schematic representation of the output of a spectrum payment transaction;

[0022] Figure 8 It is an indication that the transaction has been cancelled;

[0023] Figure 9 It is an illustrative representation of a refund transaction;

[0024] Figure 10 It is an illustrative representation of a payment transaction;

[0025] Figure 11 An exemplary sequence of staggered transactions is illustrated schematically;

[0026] Figure 12 The timeline is also schematically illustrated, showing an exemplary sequence of steps taken by different parties to achieve a common standard threshold blockchain protocol;

[0027] Figure 13 This is an illustrative representation of an implementation for checking m / n signatures using the OP_CHECKMULTISIG blockchain protocol;

[0028] Figure 14 This is an illustrative representation of an implementation of checking m / n signatures using a common standard threshold blockchain protocol. Detailed Implementation

[0029] Exemplary System Overview

[0030] Figure 1 An exemplary system 100 for implementing blockchain 150 is generally illustrated. System 100 includes a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device, and different nodes 104 belong to different peers. Each node 104 includes a processing device containing one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0031] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple nodes in the P2P network 160. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the value of digital assets belonging to user 103 whose output is cryptographically locked (requiring the user's signature to unlock, thereby enabling redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0032] At least some of the nodes in node 104 act as forwarding nodes 104F, forwarding and thus propagating transaction 152. At least some of the nodes in node 104 act as mining nodes 104M, mining block 151. At least some of the nodes in node 104 act as storage nodes 104S (sometimes also called "full copy" nodes), each storage node storing a corresponding copy of the same blockchain 150 in its respective storage. Each mining node 104M also maintains a pool 154 of transactions 152 waiting to be mined into block 151. A given node 104 can be any combination of forwarding nodes 104, mining nodes 104M, storage nodes 104S, or two or all of these nodes.

[0033] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Typically, the current transaction can be any transaction in pool 154 or any block 151. While the existence and verification of the previous transaction 152i are required to ensure the validity of the current transaction, the previous transaction 152i does not necessarily exist when the current transaction 152j is created or even sent to network 106. Therefore, in this context, "previous" refers to the predecessor in the logical sequence linked by the pointer, not necessarily the creation or sending time in the time series, thus not necessarily excluding the possibility of out-of-order creation or sending of transactions 152i or 152j (see the discussion of orphaned transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0034] The input to the current transaction 152j also includes the signature of user 103a to whom the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Therefore, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for modification). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0035] The above can be referred to as an "output-based" transaction protocol, or sometimes as a protocol for unspent transaction outputs (UTXOs) (where the output is called a UTXO). A user's total balance is not defined by any single number stored in the blockchain; instead, the user needs a special "wallet" application 105 to organize all of the user's UTXO values, which are scattered across many different transactions 152 on the blockchain 151.

[0036] As part of the account-based transaction model, another type of transaction protocol can be called an "account-based" protocol. In the account-based case, each transaction's amount is not defined by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the mining nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction history (also known as "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0037] Regardless of the type of transaction protocol used, when user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal 102 to one of the nodes 104 of the P2P network 106 (currently typically a server or data center, but in principle it could be another user terminal). This node 104 checks the validity of the transaction according to the node protocol applied at each node in the node 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the entire transaction model. The node protocol typically requires node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the case of output-based transactions, this may include checking whether the user's cryptographic signature contained in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in 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, conditions may be defined, at least in part, by custom scripts included in the inputs and / or outputs. Alternatively, this may be determined solely by the node protocol, or through a combination thereof. Regardless of the approach, if the new transaction 152j is valid, the current node forwards it 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, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of nodes 104.

[0038] In the output-based model, whether a given output (e.g., a UTXO) is spent is defined as whether it is validly redeemed by the input of another subsequent transaction 152j, according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempted to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if invalid, transaction 152j will not be propagated or recorded in the blockchain. This prevents double-spending, i.e., a spender spending the output of the same transaction more than once. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Because a defined transaction order also exists, the account balance has a single defined state at any given time.

[0039] Besides verification, at least some nodes in node 104M compete to create transaction blocks in a process called mining. At mining node 104M, new transactions are added to a pool of valid transactions that have not yet appeared in the block. The mining nodes then compete to assemble a new valid block 151 of transactions 152 from transaction pool 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "random number" value so that when the random number is concatenated with transaction pool 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a certain predefined number of leading zeros. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs.

[0040] The first mining node 104M to solve the puzzle announces the solution on network 106, providing the solution as proof. Other nodes 104 in the network can then easily check the solution (once a solution with a hash value is provided, it can be directly checked whether the solution makes the output of the hash value satisfy the condition). Based on the winner's announced solution being checked at each of these nodes, the winner's transaction pool 154 for solving the puzzle is subsequently recorded in blockchain 150 as a new block 151 by at least some of the nodes 104 acting as storage nodes 104S. A block pointer 155 is also assigned to a new block 151n pointing to the previously created block 151n-1 in the blockchain. Once created, block 151 is immutable because it is identified and maintained by each storage node 104S in the P2P network 106 according to the same protocol. Block pointer 155 also imposes order on block 151. Since transaction 152 is recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0041] It should be noted that different mining nodes 104M vying to solve the puzzle at any given time may perform this operation based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they begin searching for a solution. The person solving the corresponding puzzle first defines the transactions 152 contained in the new block 151n and updates the current unmined transaction pool 154. Then, mining nodes 104M continue to compete to create blocks from the newly defined unmined pool 154, and so on. Furthermore, there are protocols for resolving any potential "forks," where two mining nodes 104M solve the puzzle for each other in a very short time, thus propagating a conflicted view of the blockchain. In short, the fork with the longest possible direction becomes the final blockchain 150.

[0042] The winning node is considered to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "generating" transaction, which automatically forms part of a new block 151n. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs.

[0043] Due to the computational resources involved in mining, each mining node in at least the mining nodes 104M typically takes the form of a server, which includes one or more physical server units, or even an entire data center. Each forwarding 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 take the form of a single user terminal or a group of user terminals networked together.

[0044] Each node 104's memory stores software configured to run on the node 104's processing device to perform its corresponding role and process transactions 152 according to the node protocol. It should be understood that any action attributed to node 104 herein can be performed via software running on the processing device of the corresponding computer device. Furthermore, the term "blockchain" as used herein refers to a general term for a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0045] Each of the multiple parties 103 acting as consumer users has its computer device 102 connected to network 101. They act as payers and payees in transactions but do not necessarily participate in mining or disseminating transactions on behalf of other parties. They do not necessarily run mining protocols. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system, but for convenience, they are not shown. Each party 103 may be an individual or organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein may be replaced by "first party" and "second party," respectively.

[0046] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0047] The client application or software 105 may initially be provided to any given party 103's computer device 102 via, for example, a suitable computer-readable storage medium downloaded from a server, or via a removable storage device such as a removable SSD, flash key, removable EEPROM, removable disk drive, floppy disk or tape, optical disc such as a CD or DVD ROM, or a removable optical drive.

[0048] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding user 103 to create, sign, and send transactions 152 intended to be propagated throughout the network of nodes 104 and thus included in the blockchain 150. The other function is to report the amount of digital assets currently held by the corresponding party. In an output-based system, this second function involves organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant party scattered across the blockchain 150.

[0049] An instance of client application 105 on each computer device 102 is operatively coupled to at least one forwarding node among forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query in blockchain 150 any transaction for which the corresponding party 103 is the recipient (or actually check transactions of other parties in blockchain 150, since in this embodiment, blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify the validity of transaction 152 according to a node protocol and, in the case of forwarding node 104F, forward transaction 152 to propagate such transactions throughout network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes within it). All nodes 104 in network 106 use the same node protocol (although they may distinguish and process different transaction subtypes according to rules defined for that subtype, and different nodes may also play different roles, thus implementing different corresponding aspects of the protocol).

[0050] As described above, blockchain 150 includes a series of blocks 151, each block 151 comprising a set of one or more transactions 152. Each block 151 also includes a block pointer 155, which points to previously created blocks 151 in the blockchain to define the order of blocks 151. Blockchain 150 also includes a pool of valid transactions 154, awaiting inclusion in new blocks. Each transaction 152 (except for a generating transaction) includes pointers to previous transactions to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 in the early stages of blockchain 150 point to the genesis block 153, not to previous transactions.

[0051] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet functionality in her client application 105). She then sends transaction 152j from client application 105 to one of one or more forwarding nodes 104F that it is connected to. For example, this could be a forwarding node 104F that is most recently or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it will process it according to the node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets specific conditions to become "valid," specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions can be configured on a per-transaction basis via a script included in transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by combining scripts and the node protocol.

[0052] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "valid"), any storage node 104S that receives transaction 152j will add the new valid transaction 152 to pool 154 in the replica of blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives transaction 152j will then propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will quickly propagate throughout the P2P network 106.

[0053] Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also recorded immutably.

[0054] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to either an output-based or UTXO-based protocol. However, this is not limited to all possible embodiments.

[0055] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising 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 the amount of digital asset (a store of value). It may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the mining node 104M.

[0056] For example, Alice 103a wants to create transaction 152j to transfer related digital assets to Bob 103b. Figure 2 In the sequence, Alice's new transaction 152j is labeled "Tx1". This new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In this context, the previous transaction 152i is marked as "Tx0". Tx0 and Tx1 are just arbitrary markers, and they do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to the next transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0057] When Alice creates her new transaction Tx1, or at least when she sends it to network 106, the previous transaction Tx0 may already be valid and included in blockchain 150. This transaction may at this point be included in a block of block 151, or it may still be waiting in pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 can be created and sent together to network 102; or, if the node protocol allows buffering “orphaned” transactions, Tx0 may even be sent after Tx1. The terms “previous” and “subsequent” as used in the context of transaction sequences in this paper refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can also be replaced with “predecessor” and “successor,” “preceding” and “descending,” or “parent” and “child,” etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to a previous transaction (preceding transaction or "parent transaction") will not be valid unless the parent transaction is valid. Child transactions that arrive at node 104 before the parent transaction are considered orphaned transactions. Depending on the node protocol and / or the behavior of the mining node, they may be discarded or buffered for a period of time to wait for the parent transaction.

[0058] One of the outputs 203 of a previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script. This locking script defines the conditions that the unlocking script in the input 202 of a subsequent transaction must meet for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following condition: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to whom the previous transaction was locked.

[0059] A locking script (also known as 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" (S capitalized). The locking script specifies the information required for the spend transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0060] Therefore, in the example shown, UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P).A This is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A [Contains the public key P in Alice's public-private key pair] A Input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash of the entire transaction Tx0). Input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0061] When a new transaction Tx1 arrives at node 104, that node applies the node protocol. This includes running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria). In this embodiment, this involves concatenating two scripts:

[0062] <Sig P A > <P A >||[Checksig P A ]

[0063] Here, "||" indicates concatenation, "<...>" indicates placing data on a stack, and "[...]" indicates a function consisting of the unlock script (in this example, a stack-based language). Similarly, scripts can be run one after another using a shared stack, instead of concatenating them. Regardless of the method used, when run together, the scripts use Alice's public key P. A (Included in the locking script at the output of Tx0) to authenticate whether the locking script at the input of Tx1 contains the signature when Alice signs the expected portion of the data. The expected portion of the data itself (“message”) also needs to be included in Tx0 in order to perform this authentication. In this embodiment, the signed data includes the entire Tx0 (therefore, it is not necessary to include a separate element to plaintext specify the portion of the signed data, as it already exists on its own).

[0064] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), any entity, such as Node 104, capable of authenticating an encrypted version of the message must have already signed it by Alice. Signing typically involves hashing the message, signing the hash value, and attaching this to the plaintext version of the message as a signature, thus enabling any holder of the public key to authenticate the signature.

[0065] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (therefore, in the example shown, if Alice's signature is provided and authenticated in Tx1), then node 104 considers Tx1 valid. If it is a mining node 104M, this means it will be added to the transaction pool 154. If it is a forwarding node 104F, it will forward transaction Tx1 to one or more other nodes 104 in network 106, thus propagating it throughout the network. Once Tx1 is valid and included in blockchain 150, this defines UTXO0 in Tx0 as spent. Note that Tx1 is only valid if it spends an unspent transaction output 203. If an attempt is made to spend an output that has already been spent by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, node 104 also needs to check if the UTXO referenced in the previous transaction Tx0 has already been spent (has formed a valid input for another valid transaction). This is one of the reasons why the order in which blockchain 150 imposes definitions on transaction 152 is important. In practice, a given node 104 can maintain a separate database that marks the UTXOs 203 of the spent transaction 152, but the final definition of whether a UTXO has been spent depends on whether it forms a valid input to another valid transaction in blockchain 150.

[0066] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined in a UTXO as spent while simultaneously spending another portion. However, the amount in a UTXO can be split across multiple outputs in the next transaction. For example, the amount defined in UTXO0 of Tx0 can be split across multiple UTXOs in Tx1. Therefore, if Alice doesn't want to give Bob all the amount defined in UTXO0, she can use the remaining amount to make change herself in the second output of Tx1, or pay the other party.

[0067] Also note that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another invalidation criterion in most transaction models. Therefore, such a transaction will not be propagated or mined into block 151.

[0068] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere in blockchain 150. Therefore, typically, the assets of the given party 103 are scattered across the various UTXOs of transactions 152 throughout blockchain 150. No single number defining the total balance of the given party 103 is stored anywhere in blockchain 150. The wallet function of the client application 105 serves to consolidate the various UTXO values ​​locked to the respective party and not yet spent in other subsequent transactions. This is achieved by querying a copy of blockchain 150 stored at any storage node 104S (e.g., the storage node 104S most recently or best connected to the respective party's computer device 102).

[0069] Please note that script code is typically represented using diagrams (i.e., non-precise language). For example, it might be written as [ChecksigP A ] indicates [Checksig P A ] = OP_DUP OP_HASH160<H(Pa)> OP_EQUALVERIFY and OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in transactions verified by the 'sig' input. Similarly, OP_RETURN is a scripting language opcode used to create a non-spendable output for a transaction, which can store metadata in the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata may include files that need to be stored in the blockchain.

[0070] Signature P A This is a digital signature. In this embodiment, it is based on ECDSA using elliptic curve secp256k1. The digital signature signs a specific data segment. In this embodiment, for a given transaction, the signature will sign part of the transaction input and all or part of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select the output to be signed (and therefore fixed at the time of signing).

[0071] A locking script, sometimes called a "scriptPubKey," refers to the fact that it includes the public key of the party to whom the corresponding transaction is locked. An unlocking script, sometimes called a "scriptSig," refers to the fact that it provides the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature authentication. Furthermore, scripting languages ​​can be used to define one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0072] Optional side channel

[0073] Figure 3 Another system 100 for implementing blockchain 150 is shown. In addition to additional communication functions, system 100 is connected to… Figure 1 The content shown is essentially the same. The client applications on each of Alice and Bob's computer devices 102a and 120b include additional communication capabilities. That is, this allows Alice 103a to establish a separate side channel 301 from Bob 103b (at the instigation of either party or a third party). Side channel 301 enables data exchange independently of the P2P network. This type of communication is sometimes referred to as "off-chain" communication. For example, when exchanging transaction 152 between Alice and Bob, if they do not want to publish the transaction (yet) to the P2P network 106 or mine it to block 150, they can use this communication until one of them chooses to broadcast the transaction to network 106. Alternatively or additionally, this side channel 301 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0074] Side channel 301 can be established via the same packet-switching network 101 as the P2P overlay network 106. Alternatively, side channel 301 can be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless connection between Alice and Bob's devices 1021, 102b. Generally, side channel 301 as referred to herein may include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain" (i.e., independently of the P2P overlay network 106). When multiple links are used, the entire bundle or set of off-chain links can be referred to as side channel 301. Therefore, it is important to note that while Alice and Bob exchange specific information or data fragments or similar items via side channel 301, this does not necessarily mean that all these data fragments must be sent via the same link or even the same type of network.

[0075] Node software

[0076] Figure 4An example of node software 400 running on each node 104 of a P2P network 106 is shown, in examples of UTXO-based or output-based models. Node software 400 includes a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a collection 405 of one or more blockchain-related functional modules. At any given node 104, these modules may include any one, two, or all of the following three modules: a mining module 405M, a forwarding module 405F, and a storage module 405S (depending on one or more roles of the node). Protocol engine 401 is configured to identify different fields of transaction 152 and process such fields according to the node protocol. When a transaction with a pointer to another previous transaction 152m-1(Tx) is received... m-1 The output (e.g., UTXO) of the input transaction 152m (Tx) m When ), the protocol engine 401 identifier Tx m The unlock script is then passed to script engine 402. Protocol engine 401 is also based on Tx. m The pointer in the input is used to identify and retrieve Tx m-1 If Tx m-1 If it is not yet on blockchain 150, then Tx can be retrieved from the corresponding node's own pending transaction pool 154. m-1 Or, if Tx m-1 If it's already on blockchain 150, it can be retrieved from a copy of block 151 in blockchain 150 stored on the corresponding node or another node 104. Regardless of the method used, script engine 401 will identify Tx. m-1 The pointer points to the locked script in the output and passes it to the script engine 402.

[0077] Therefore, script engine 402 has Tx m-1 The locking script and from Tx m The corresponding input unlock script. For example, Figure 4 The examples shown are Tx1 and Tx2, but the same applies to any trading pair, such as Tx0 and Tx1. As previously mentioned, script engine 402 runs two scripts simultaneously, which will include placing data onto stack 403 and retrieving data from that stack according to the stack-based scripting language being used (e.g., script).

[0078] By running the scripts simultaneously, the script engine 402 determines whether the unlock script meets one or more criteria defined in the locking script, i.e., whether the unlock script unlocks the output including the locking script. The script engine 402 returns this determination to the protocol engine 401. If the script engine 402 determines that the unlock script does indeed meet one or more criteria specified in the corresponding locking script, it returns the result "TRUE". Otherwise, it returns the result "FALSE".

[0079] In the output-based model, the result "TRUE" from script engine 402 is one of the conditions for transaction validity. Typically, one or more further protocol-level conditions evaluated by protocol engine 401 must also be met; for example, Tx m The total amount of digital assets pointed to in the output does not exceed the total amount specified in the input(s), and Tx m-1 The output pointed to by the transaction has not yet been spent by another valid transaction. Protocol engine 401 evaluates the results from script engine 402 along with one or more protocol-level conditions, and only when all of them are TRUE does protocol engine 401 verify transaction Tx. m Valid. Protocol engine 401 outputs an indication of whether the transaction is valid to application-level decision engine 404. Only in Tx m Only when the verification is valid can the decision engine 404 select one or both of the control mining module 405M and the forwarding module 405F to execute their Tx-related functions. m. The corresponding blockchain-related functions. This may include: a mining module 405M, which will mine Tx m Add to the corresponding pool 154 of the node to mine block 151; and / or forwarding module 405F, which forwards Tx m The transaction is forwarded to another node 104 in the P2P network 106. However, it should be noted that in this embodiment, while the decision engine 404 will not choose to forward or mine invalid transactions, this does not necessarily mean that the decision engine must trigger the mining or forwarding of a transaction simply because it is valid. Optionally, in this embodiment, the decision engine 404 may apply one or more additional conditions before triggering one or two of these functions. For example, if the node is a mining node 104M, the decision engine may choose to mine the transaction only if it is valid and sufficient mining fees are reserved.

[0080] Furthermore, it should be noted that in this paper, the terms "TRUE" and "FALSE" are not necessarily limited to returning a result represented only as a single binary number (bit), although this is indeed one possible implementation. More colloquially, "TRUE" can refer to any state indicating a successful or affirmative result, while "FALSE" can refer to any state indicating an unsuccessful or uncertain result. For example, in an account-based model ( Figure 4 In (not shown), the result can be indicated as "TRUE" by a combination of the implicit protocol-level verification of the signature by node 104 and the additional positive output of the smart contract (if both individual results are TRUE, the overall result is considered TRUE).

[0081] script

[0082] Blockchain protocols can use scripting languages ​​for transactions. A script is essentially a list of elements, which can be data or instructions. These instructions are referred to in the literature as script words, opcodes, commands, or functions. An opcode performs a predefined operation on the data within the script. Data within a script can be, for example, numbers, public keys, signatures, hash values, etc. An opcode is a function that performs an operation on the data within the script. In scripting languages, scripts run from one end to the other (usually from left to right) using a data structure called a "stack." Data is always pushed onto the stack. An opcode can pop data from the stack, perform an operation on the data, and then optionally "push" new data onto the stack. Stack-based scripting languages ​​commonly used in many blockchains are called scripts. The following describes the opcodes of scripting languages.

[0083] Those skilled in the art will be familiar with stack-based scripting languages. The following examples illustrate exemplary script implementations. Specifically, the following illustrates an exemplary verification and unlocking process.

[0084] An exemplary script may include <Bob's signature> <Bob's public key> OP_DUP OP_HASH <Bob's public address> OP_EQUALVERIFY OP_CHECKSIG. The script operates from left to right.

[0085] Step 1: Push <Bob's Signature> onto the stack

[0086] <Bob's signature>

[0087] Step 2: Push <Bob's public key> onto the stack (this is now the top element on the stack).

[0088] <Bob's public key> <Bob's signature>

[0089] Step 3: The OP_DUP opcode performs an operation on the top element on the stack to copy <Bob's public key>.

[0090] <Bob's public key> <Bob's public key> <Bob's signature>

[0091] Step 4: Pop the OP_HASH opcode and run <Bob's public key> through a hash algorithm (followed by one or more optional operations) to obtain <Bob's public address> and place it on the stack.

[0092] <Bob's public address> <Bob's public key> <Bob's signature>

[0093] Step 5: Push <Bob's public address> onto the stack (this is now the top element on the stack).

[0094] <Bob's public address> <Bob's public address> <Bob's public key> <Bob's signature>

[0095] Step 6: The OP_EQUALVERIFY opcode pops the last two elements (<Bob's public address> and <Bob's public address>) from the stack and checks if these two addresses are the same. If they are not the same, the execution is considered to have failed. If the condition is TRUE, the next command is executed.

[0096] <Bob's public key> <Bob's signature>

[0097] Step 7: The OP_CHECKSIG opcode pops up <Bob's public key>> and <Bob's signature>>, and checks their validity. After this process is complete, Bob can unlock the transaction and access the specified amount of digital assets.

[0098] TRUE

[0099] For the sake of brevity, the opcodes used herein will be those of a scripting language, such as "OP_CHECKSIG". However, this disclosure is not limited to scripting language opcodes. More generally, while embodiments will be described with reference to opcodes of a specific blockchain scripting language (Script), the same teachings can be implemented using opcodes of any scripting language that execute a specific function when invoked by a scripting engine (e.g., a script interpreter). Furthermore, although the following embodiments are exemplified using the Elliptic Curve Digital Signature Algorithm (ECDSA), it should be understood that other cryptographic signature schemes such as RSA are known in the art and are equally applicable herein.

[0100] Binary threshold protocol

[0101] An example of a threshold-based unlocking system is the multi-signature functionality of some blockchain protocols. In some blockchain protocols, a transaction locking script can be constructed that can be unlocked by providing any m / nECDSA signature corresponding to m previously specified public keys. The locking script conditions for such multi-signature transactions are written as follows:

[0102] <![CDATA[m <p1> <p2>…<P n-1 ><P n >nOP_CHECKMULTISIG]]> < / p1>

[0103] Here, the locking script begins with the required number of valid signatures (m), and then lists the set of n public keys that the m signatures must correspond to, the value of n, and the opcode OP_CHECKMULTISIG, which checks whether all m signatures are valid.

[0104] The unlock script will take the following form:

[0105] <![CDATA[0<sigP a >…<sigP m >]]>

[0106] This includes m signatures and a placeholder value of 0. The placeholder itself is not processed; it is only needed because of vulnerabilities in the existing implementations of a particular blockchain protocol.

[0107] Embodiments of this disclosure provide techniques for constructing a transaction locking script (synonymously referred to as an output script or scriptPubKey) that can be unlocked by providing a data item satisfying any m / n criterion in the unlocking script of a subsequent transaction (synonymously referred to as an input script, scriptSig). Similar to OP_CHECKMULTISIG, this criterion may require a signature corresponding to the public key. However, the following techniques are not limited to requiring a signature. Generally, any criterion can be defined. For example, it may require providing a hash preimage of a hash, a solution to an equation, an answer to a quiz problem, etc.

[0108] First refer to Figure 5 Describe the implementation examples. Figure 5 yes Figure 1 A simplified version illustrates an exemplary system 500 for implementing the Binary Threshold Protocol (BTP). A first party (Alice) 103a generates transaction Tx1 and transmits it to blockchain network 106. Assuming the blockchain protocol is satisfied, transaction Tx1 will be included in blockchain 150. Note that, conversely, a different party may transmit Alice's transaction to blockchain network 106 on her behalf. Transaction Tx1 includes an output specifying the amount of digital assets. The digital assets are locked by an output script (or locking script). To unlock and transfer the assets to a second party (Bob) 103b, Bob must transmit a second transaction Tx2 to blockchain network 106, which has an input script (or unlocking script) that can lock the output script of transaction Tx1.

[0109] When constructing the output script, Alice 103a includes multiple standard components. Each standard component includes one or more opcodes (or, more generally, functions), such as OP_CHECKSIGVERIFY. Standard components may also include one or more data elements, such as hash values. Each standard component defines a criterion that requires certain input data items to be met. That is, when run against the input script of a subsequent transaction, each standard component requires the input script to include specific data items for the standard component to execute successfully, i.e., return a value indicating "TRUE," for example... <1> For example, some or all of the standard components may require different digital signatures as input data items. Preferably, each standard component may define a different standard. Alternatively, one or more standard components may define the same standard.

[0110] Alice 103a also includes multiple counter script components in the output script. Each counter script component is associated with a corresponding standard component. For example, when the script in the scripting language is executed from left to right, each counter script component may follow a corresponding standard in the standard component. Each counter component includes one or more opcodes (or functions) and optionally one or more data items. Each counter component is configured to increment the counter when the associated standard component is satisfied. That is, if the first standard component is satisfied, the first counter component will increment the counter. It should be noted in this document that "increment" can refer to an increasing or decreasing increment. For example, the counter may increment in an incremental manner (e.g., one, two, three, etc.) or the counter may increment in a decreasing manner (e.g., three, two, one, etc.). In some examples, each counter component may increment the counter by the same amount, i.e., by the same number. For example, the counter may increment by one each time the standard component is satisfied. Alternatively, the counter components may be weighted. That is, some counter components may increment the counter by the same amount, i.e., by the same number. For example, the first counter component may increment the counter by one, while the second counter component may increment the counter by two.

[0111] Alice 103a constructs an output script such that the output can only be unlocked if the counter reaches at least a predetermined number (or a threshold). That is, the output script is configured to determine whether the counter has incremented to the predetermined number. If so, the output may be unlocked and redeemed by Bob 103b. If the threshold is not reached, the output will not be unlocked. When the counter increments, the output script is configured to determine whether the counter is equal to or greater than the threshold. Conversely, when the counter increments decrements, the output script is configured to determine whether the counter is less than or equal to the threshold. The counter script may include one or more opcodes and optionally one or more data elements, which together perform a check on the counter and successfully evaluate to "TRUE" when the threshold is reached.

[0112] In some examples, the total number of standard components can exceed the threshold number. In other words, by satisfying the standard components, the counter can be incremented to a number greater than the predetermined number required to unlock the output. Alternatively, every single standard component must be satisfied to unlock the output.

[0113] Optionally, a given standard component may consist of two or more sub-standard components. Like the standard component, a sub-standard component includes an opcode and optional data elements that require input data items from subsequent transactions for successful evaluation. For example, a standard component may consist of multiple sub-standard components, each applying a hash function to its corresponding input data item and comparing the resulting hash value with a predetermined hash value. If the resulting hash value matches the predetermined hash value, the sub-standard component is satisfied, and therefore the standard component is satisfied. It should be noted that even if a standard component includes multiple sub-components, the counter increments only once when the entire standard component is satisfied, not once for each sub-standard component.

[0114] like Figure 5 As shown, Alice 103a will Q n Standard transmission to Bob 103b. Note that Q... n The standard defines the input data items required to satisfy a standard component, not the data items themselves. For example, a standard component may require a digital signature, but not the digital signature itself. This is achieved by providing Q to Bob 103b. n According to the standard, Bob knows the data items that need to be provided. Alternatively, Alice 103a may not provide the standard to Bob 103b, in which case Bob needs to interpret the standard components (e.g., the sequence of opcodes) to determine what needs to be provided as the corresponding data items.

[0115] The output script can include n standard components. If the recipient (Bob) meets at least m of the n standards specified in the locking script, he can redeem the full amount of digital assets provided by Alice 103a. If he does not meet at least m standards, Bob 103b cannot redeem any digital assets. BTP stands for m / n standard threshold, where m is fixed, and the recipient can only access the digital assets if they meet at least m standards. The protocol is detailed below for two people (Alice 103a and Bob 103b), where Alice 103a pays Bob 103b if Bob can meet at least m of the n standards. Alice 103a creates a 'binary payment' transaction (titled bPay) containing an output script that locks the digital assets contained in the output until Bob 103b can provide an input script for a spending transaction that contains content that meets at least m of the n standards (in some examples, the input script must also include Bob's digital signature). Bob's input script will contain a combination of multiple sub-units of the input data items. Each data item is provided as a solution for a specific standard.

[0116] The protocol achieves its goal via an output script in a bPay transaction, where a counter is incremented (e.g., initialized to 0 and incremented by one) given that the input (from Bob) meets its corresponding criterion in the bPay output script. Since the expected receiver (Bob) anticipates placing the relevant input in the input transaction, the criterion is described as "corresponding," thus comparing the input against the appropriate criterion in the bPay transaction's bPay output script. The counter's value can be stored on a stack, such as the ALT stack in a scripting language. When the input is successful relative to its criterion, the counter's current state is removed (popped) from the ALT stack, placed (pushed) onto the main stack, 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 receiver Bob 103b can unlock the bPay output.

[0117] Below is TxID bPay and TxID spend Examples of output and input scripts that meet the characteristics required by BTP are shown below.

[0118] The [Criterion_1] segment of the locked (output) script represents the criteria (i.e., conditions) that receiver Bob 103b needs to meet. For example, this might require a hash preimage as shown below.

[0119] [Criterion_1]=OP_HASH160 H(PreImage)OP_EQUAL

[0120] A standard can also refer to a 'set of sub-standards for a group', which must be evaluated as true during merging.

[0121] <![CDATA[[Criterion_i]=f([Criterion_i a ]Criterion_i b ],…,Criterion_i t ])]]>

[0122] Even if [Criterion_i] is a combination of multiple subcriteria, the counter will still only increment by one unit if the combination of all these subcriteria evaluates to true.

[0123]

[0124] Note that the text in parentheses is a comment and will not actually be included in the transaction.

[0125] To unlock the output of bPay, receiver Bob 103b will provide n inputs in the input script of the spending transaction, where at least m of these inputs satisfy at least m of the aforementioned criteria. Example spending transaction TxID bPay As shown above.

[0126]

[0127] These sets of n inputs are arranged in the necessary order so that when the input and output scripts are merged and executed on the stack, each input fragment is matched and evaluated according to expected criteria, for example:

[0128] [criterion_2] <input_2>

[0129] Similar to standard subscripts,<input_i> It can also represent the input set of a group.

[0130] <![CDATA[<input_i>=<input_i a ><input_i b >…<input_i t >>]]>

[0131] Given that users can define any standard, this achieves the goal of the binary threshold protocol, where thresholds of a universal standard must be met for the output of a spending transaction.

[0132] Spectrum Threshold Protocol

[0133] BTP sets binary thresholds for the amount of digital assets that can be redeemed. The Spectrum Threshold Protocol (STP) sets a series of thresholds, in which the amount of digital assets a recipient can receive depends on the number of criteria successfully met.

[0134] Figure 1 and Figure 5An exemplary system can be used to implement the techniques described below. A first party (Alice) 103a constructs a first transaction (referred to as an "sPay transaction") with multiple outputs. Alice 103a constructs each output in a manner similar to BTP. That is, each output has an output script, and each output script includes multiple standard components and multiple counter components, each associated with a corresponding one of the standard components. Each standard component defines a criterion that can be satisfied by input data items in the input script of a subsequent transaction. Each counter component is configured to increment a counter if the associated standard component is satisfied. Each counter component can cause the counter to increment by the same amount (e.g., one). Alternatively, some counter components can cause the counter to increment by different amounts. The multiple standard components and multiple counter components are defined in a first script condition of each output script. Here, the first script condition is simply a label for a portion of the output script that includes the standard components and the counter components. Note that each output includes the same standard components.

[0135] Similar to BTP, for STP, Alice 103a constructs each output script such that a counter must reach at least a predetermined number (or threshold) to unlock the corresponding output. That is, each output script is configured to determine whether the counter has incremented to the predetermined number. If so, Bob 103b can unlock and redeem the associated output. If the threshold is not reached, the output will not be unlocked. Unlike BTP, at least one output script in STP requires the counter to reach a different predetermined number. That is, some output scripts require different thresholds to be met for unlocking.

[0136] In some examples, each output script requires different thresholds 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 digital assets. In other examples, one or more output scripts may lock the same amount of digital assets. The amount of digital assets can increase as the threshold increases; that is, if more criteria are met, a larger amount of digital assets can be redeemed. The increase may be proportional or disproportionate to the number of criteria met.

[0137] Similar to BTP, for STP, the total number of standard components can exceed the threshold number. Alternatively, every standard component must be satisfied to unlock the output. Also, like BTP, for STP, one or more standard components can consist of multiple sub-standard components.

[0138] Figure 6 An exemplary representation of the first transaction Tx1 is shown. The first transaction Tx1 has multiple outputs i. In the example shown, each output locks digital asset y. iThe amount. That is, output 1 locks the amount y1, output 2 locks the amount y2, and output π locks the amount y. π As shown, transaction Tx1 includes inputs, which include at least equal to y. i The sum of digital assets.

[0139] It should be noted that Figure 6 This shows what must be provided in the input script when unlocking each output, rather than what is contained in the output itself. See... Figure 6 To unlock output 1, a second transaction Tx2 input script can be provided, which includes sufficient input data items (using...). <input> (represented) to satisfy the threshold of output 1. The second transaction Tx2 is referred to below as the "receiving transaction" because it allows Bob 103b to receive the digital asset y1 locked by output 1. Each first script condition (hereinafter referred to as the "receiving condition") may also require the input script of the receiving transaction to include the digital signatures of Alice and / or Bob, respectively, i.e., σ 爱丽丝 and σ 鲍勃 As another optional feature, the receiving conditions may require the receiving transaction Tx2 to include a secret value k chosen by Bob. The secret value is kept confidential; in a sense, only Bob 103b knows the secret value before the receiving transaction is transmitted to and included in blockchain 150. For receiving transactions that require a secret value, Bob 103b must transmit the hash of the secret value to Alice 103a. The receiving conditions can then hash the secret value and compare the resulting value with the hash value obtained from Bob 103b in the receiving conditions. Note that there are other ways to unlock the output of Tx1. These will be described in detail below with reference to "Refund Transactions" and "Cancellation Transactions".

[0140] Although for convenience, payment transactions, refund transactions, and cancellation transactions may be written in uppercase letters here, this does not necessarily imply any specific patent name or proprietary name, and the terms may also be written in lowercase letters anywhere in this document.

[0141] In some examples, Alice 103a itself can construct part of the receiving transaction Tx2. For instance, Alice 103a can do so via a side channel (e.g., Figure 3 The side channel 301 shown provides Bob 103b with her digital signature (σ). 爱丽丝A partial transaction. Alice 103a can construct such partial transactions for each output in the first transaction Tx1. Alice 103a can include a lock time in the partial receiving transaction, which she can construct and send to Bob 103b via a side channel. The lock time prevents the receiving transaction from being successfully included in a block of blockchain 150 before a certain time (e.g., specified by Unix time or block height). The lock time can be implemented using the transaction's "nLocktime" field. nLocktime is a transaction parameter that specifies the shortest time before the transaction is accepted into the block. As described below, each receiving transaction can specify a different lock time.

[0142] When constructing the first transaction Tx1, Alice 103a can include a second script condition in each output script. This second script condition will be referred to below as the "refund condition." Like the payment condition, the refund condition is a label that forms part of the output script and includes one or more opcodes (or, more generally, functions). The refund condition may also include one or more data elements. The refund condition is configured to require that the input script for subsequent transactions include Alice's digital signature and Bob's digital signature. That is, the refund condition determines whether Alice's and Bob's digital signatures have been provided in the input script of the "refund transaction," and if so, the refund condition evaluates to TRUE (or...). <1> For example, on a stack.

[0143] Each output is constructed such that the input script for a subsequent transaction can only satisfy one script condition. That is, no given input script can simultaneously satisfy both the payment and refund conditions. This is because payment and refund conditions require unlocking different input data items. For example, a payment condition requires input data items to meet standard components, while a refund condition does not.

[0144] In some examples, Alice 103a herself can construct part of the refund transaction. For instance, Alice 103a can do so via a side channel (e.g., Figure 3 The side channel 301 shown provides Bob 103b with her digital signature (σ). 爱丽丝 Alice 103a can construct such partial transactions for each output of the first transaction. Alice 103a can include the lock-up time in the partial refund transaction, which she can construct and send to Bob 103b via a side channel. Bob 103b can then use his signature σ 鲍勃 The partial refund transaction is included in the refund transaction, and the signed refund transaction is returned to Alice 103a. It should be understood that, in an alternative example, Bob 103b may first sign the partial refund transaction and send it to Alice for Alice to sign.

[0145] Similar to receiving transactions, Alice 103a allows setting a lock-up period for each refund transaction. The lock-up period can be set before Alice and / or Bob sign the transaction with their respective signatures. For each output with associated receiving and refund transactions, the lock-up period for the refund transaction will be later than that for the receiving transaction, meaning the receiving transaction can be included in a block of blockchain 150 before the associated refund transaction.

[0146] Both the refund conditions and the refund transaction are designed to allow Alice 103a to redeem the amount of digital assets in each output that Bob 103b has not claimed. For example, if Bob fails to provide an input that meets any output criterion threshold (e.g., within a predetermined time period), Alice 103a needs to be able to request the return (or refund) of the digital assets associated with the output.

[0147] When constructing the first transaction Tx1, Alice 103a may include a third script condition in part or all of the output script. This third script condition will be referred to below as the "cancellation condition." Like the payment and refund conditions, the cancellation condition is a label that forms part of the output script and includes one or more opcodes (or, more generally, functions). The cancellation condition may also include one or more data elements. The cancellation condition is configured to require the input script of subsequent transactions to include Alice's digital signature. That is, the cancellation condition determines whether Alice's digital signature has been provided in the input script for "cancelling the transaction," and if so, the cancellation condition evaluates to TRUE (or...). <1> For example, on a stack. The cancellation condition can also require a secret value k.

[0148] Both cancellation conditions and cancellation transactions are designed to allow Alice 103a to redeem the amount of digital assets in each output that Bob 103b has not claimed. For example, if one output requires two criteria to be met, another requires three, and Bob 103b can only meet two, then Alice 103a needs to be able to request the return (or refund) of the output with an output script that specifies the three criterion thresholds. By requiring cancellation transactions to include a secret value (known only to Bob 103b before being revealed on the blockchain), Bob 103b ensures that Alice 103a cannot cancel any transactions before Bob attempts to claim one of the outputs using a receiving transaction.

[0149] In the context of STP, a spectrum threshold is used, where receiver Bob 103b receives payment based on the number of criteria he can meet. According to the binary threshold, it doesn't matter which criteria are met, but rather the number of criteria met.

[0150] To implement the spectrum thresholding function, STP utilizes transactions containing at least π ≤ n outputs (called sPay transactions). Each output i is based on a standard amount m that Bob is required to satisfy.i Pay a certain amount y i .

[0151] m i The set of values ​​is defined as

[0152]

[0153] The purpose of this is that if the receiver can satisfy m i According to the standard, the receiver can receive y from the dedicated output (i.e., output i) of the spay transaction. i Payments. While the agreement applies to these instances, the payment amount is not necessarily proportional to the number of criteria met. As a non-proportional example, Bob 103b can redeem 10 units of digital assets if he meets at least one criterion; 15 units if he meets at least two criters; and 25 units if he meets at least three criters.

[0154] Furthermore, the threshold criterion for payments in the output set can be 'arbitrary' and therefore does not necessarily have to be an arithmetic sequence and / or follow a defined pattern. Consider sPay transactions that include 'at least m'. a Standard, at least m b Standard, at least m c Standard, at least m d The output of ', where m a <m b And m c <m d There is no threshold m in sPay transactions. x ,m y ,m z The output of, where

[0155] m a <m x <m b

[0156] m b <m y <m c

[0157] m c <m z <m d

[0158] 'No arithmetic sequence' means y b -y a It does not necessarily have to be equal to y d -y cGiven the adaptability of the 'arbitrary threshold' criterion for the output, remember that although there are n criteria that can be satisfied, there are π≤n outputs.

[0159] In some examples, each output of an sPay transaction includes multiple script conditions, such as payment conditions, refund conditions, and cancellation conditions. Each output must include payment conditions and may optionally include refund and / or cancellation conditions. Figure 6 As shown, Output 1 includes the payment conditions and refund conditions, as these can be satisfied through either a payment transaction or a refund transaction. Output 2 includes the payment conditions, refund conditions, and cancellation conditions, as these can be satisfied through either a payment transaction, a refund transaction, or a cancellation transaction.

[0160] The following provides the different spending transactions and a description of each transaction.

[0161] Collection transactions - Collection transactions i This means that if Bob meets the required threshold for output i, then a bonus (y) is paid to the receiver (Bob). i The transaction is a collection transaction. The input script for the collection transaction may require one, some, or all of the signatures of the payer (Alice), the recipient (Bob), and a secret value k. This secret value is initially known only to Bob and is only revealed when Bob spends the collection transaction. The collection transaction can be time-locked, for example, by assigning t to the nLockTime field / parameter. i This value prevents the payment transaction from being successfully transmitted to blockchain 150 before that point in time.

[0162] Cancel Transaction - Cancel Transaction i This refers to the bonus (y) of output i if Bob has previously submitted a receiving transaction to any other output j. i The transaction is returned to the payer (Alice), where j ≠ i. The input script for canceling the transaction requires the payer's (Alice's) signature and an optional secret value k. This secret can be retrieved by Alice from previous receipts submitted to blockchain 150 by Bob. As long as Alice knows k, the cancellation transaction can be submitted by Alice at any time.

[0163] Refund Transaction i This refers to the situation where the recipient (Bob) does not submit the receiving transaction to blockchain 150 (for this output), for example, at a specified time t. i,i+1 Previously, the bonus of i (y) would be output. i The transaction is returned to the payer (Alice), where t i <t i,i+1 <t i+1The input script for a refund transaction requires the signatures of both the payer (Alice) and the recipient (Bob). Refund transactions can be time-locked, meaning the refund transaction only occurs when the nLockTime field / parameter value t is reached. i,i+1 Only then can it be successfully transmitted to Blockchain 150.

[0164] As mentioned above, Figure 6 The diagram illustrates the design of an SPay transaction. The information shown in the diagram relates to the various outputs of the transaction and what is required to successfully spend each output. In this example, each output i>1 is locked by an output script that allows the recipient to spend the output using three different schemes. Each of these unlocking schemes corresponds to a transaction (refund, collect, or cancel). Note that, as mentioned earlier, output 1 can only be spent using two schemes (refund and collect). Furthermore, while not mandatory, STP is based on the premise or expectation that the more criteria the recipient meets, the more they will receive. Meanwhile, for Figure 6 The sPay transactions shown in the diagram are sorted (from top to bottom) according to the amount paid (consistent with the standard quantity that the output is intended to satisfy). In the diagram, larger outputs (and therefore the required standard quantity) are higher than those with smaller outputs.

[0165] Figure 7 An exemplary output for an sPay transaction that outputs i:i≠1 is shown. This output can be used for spending with a cancel, collect, or refund transaction.

[0166] Figure 8 An example of canceling transaction 800 is shown. The cost of using canceling transaction 800 is... Figure 7 The output shown requires the payer (presumably Alice) to provide her signature and secret value k. The secret value is conceived and initially known only to the recipient, Bob 103b. A blockchain scripting language facilitates the request for both the (ECDSA) signature and the secret value. A hash puzzle can be used to request the secret value k. An example of such a locking script that requires both a secret value and a signature is as follows:

[0167]

[0168] Where H(k) is the hash value of the secret value k, and PubA is the public key owned by the payer, Alice 103a. A hash value refers to the digest of a one-way cryptographic hash function, such as SHA-256. Standard hash functions take inputs of arbitrary size and produce integers within a fixed range. For example, the SHA-256 hash function gives a 256-bit number as its output hash digest.

[0169] This script is called Cancellation Condition ([Condition:Can iThe unlock script (in the canceled transaction) will be:

[0170] <siga> <puba> <k> < / k> < / puba> < / siga>

[0171] sigA is the (ECDSA) signature of the cancellation transaction using the public key PubA.

[0172] The script is called Cancel Input ( <Input:Can i >).

[0173] Figure 9 An example refund transaction 900 is shown. To utilize refund transaction 900, the following costs... Figure 7 The output shows that the payer (Alice) must generate her signature sigA, and the receiver Bob 103b must also provide his signature sigB. The refund transaction 900 must be signed by both the payer and the receiver; this is to ensure that both parties agree the refund transaction is constructed as it should be, and special attention is paid to the required nLockTime value (i.e., the lock time 901) to prevent the refund transaction 900 from becoming valid before the agreed time. An example script requiring both signatures is shown below:

[0174]

[0175] This script is called Refund Conditions([Condition:Ref i Instead, a 2 / 2 (m / n) multisignature script can be used.

[0176] The unlock script (in refund transaction 900) will be:

[0177] <sigb> <pubb> <siga> <puba> < / puba> < / siga> < / pubb> < / sigb>

[0178] The script is called Refund Input ( <Input:Ref i >).

[0179] Figure 10 An example of receiving transaction 1000 is shown. To utilize receiving transaction 1000, the cost... Figure 7 The output must provide at least four items. The payer (Alice) must generate her signature (sigA), while the receiver, Bob 103b, must provide his signature (sigB) and the secret value k. Additionally, Bob 103b must provide the input.

[0180] <answers>≡<input_n>…<input_2><input_1> < / answers>

[0181] It is expected that there will be enough 'correct' input data items to satisfy the m required for this output. iStandard. Transaction 1000 includes an nLockTime value (i.e., lock time 1001), which prevents transaction 1000 from becoming valid before the agreed-upon time. A script example requiring four data segments is as follows:

[0182]

[0183] This script is called the payment conditions ([Condition:Col) i Instead, a 2 / 2 (m / n) multi-signature script can be used. [TEST m] i The section acts as a representation of script segments, namely: defining the entire set of criteria that the user must meet, incrementing a counter for each criterion met, and verifying that the number of met criteria is correct (≥m). i The [TEST m] i ] Script segmentation will be similar to TxID bPay The output script is shown in the figure and is as follows, where <m i > indicates the threshold for output i.

[0184] Note that the lock time limit is not indicated in the script, but is indicated in the nLockTime field of the receiving transaction 1000.

[0185] [TEST m i ]:

[0186]

[0187] The unlock script (the input script for receiving transaction 1000) will be:

[0188] <answers> <sigb> <pubb> <siga> <puba> <k> < / k> < / puba> < / siga> < / pubb> < / sigb> < / answers>

[0189] This script is called the payment input ( <Input:Col i The script contains the signatures of two participants and the secret value k. The script also shows... <answers>Value. This is the input script section containing multiple data items that are expected to become at least the output script that satisfies the output i of the sPay transaction [TEST m]. i At least m in the part i Standard solution.

[0190] <answers>≡<input_n><input_n-1>…<input_2><input_1> < / answers>

[0191] Each <answers>The child elements will be set in a specific order, so that each<input_i> All are evaluated based on the expected [criterion_i] found in the [TEST] script. Elements<input_i> This is expected to be the solution to the recipient's (Bob's) puzzle standard, defined by the payer Alice in [criterion_i]. Note that, similar to BTP, the standard can have sub-standards, and the input value can consist of multiple sub-inputs.

[0192] Since there are at least three different spending options (receive, refund, cancellation) available for the output i of a spending spay transaction, the locking (output) script for that output must incorporate the necessary script elements to facilitate the selection of the spending transaction. To do this, the locking script can use conditional elements such as OP_IF, OP_ELSE, etc.

[0193]

[0194] Note that the text in parentheses is a comment and will not actually be included in the transaction.

[0195] Here, the script contains three conditions, namely [Condition:Col i ]、[Condition:Ref i ] and [Condition:Can i Each manages a specific spending transaction. These conditions are the locking script described earlier. For a successful spending sPay output, the proposing receiver Bob 103b must contain the correct input required for its expected spending transaction type. The input script that determines the spending transaction type will have at least three segments (see the cells below). As shown in the cells below, these inputs correspond to the inputs described earlier.

[0196] <![CDATA[<Input:Can i ><Input:Ref i ><Input:Col i >]]>

[0197] If the recipient, Bob 103b, submits a specific type of spending transaction, such as receiving transaction 1000, then Bob 103b is expected to segment the appropriate script. <Input:Col i The input script consists of three parts, and the other two input elements are replaced with 'dummy data'. In this invention, it is represented as... <dummy>The virtual data is defined as input data that is intentionally evaluated as 'incorrect' when assessed according to [Condition]. Therefore, if Bob 103b wants to submit a receiving transaction 1000, the input script for the receiving transaction will be similar to...

[0198] <![CDATA[ <dummy> <dummy><Input:Col i >]]> < / dummy> < / dummy>

[0199] Figure 11 An example transaction staggering time is shown according to STP. "If the recipient knows at least m of the n solutions..." i The solution, then the recipient of the proposal knows m i -1 solution, m i The statement "-2 solutions...2 solutions or 1 solution" captures the fact that the transaction has multiple outputs, where each output is based on m out of n criteria that the proposer's recipient can satisfy. i This reveals a potential vulnerability in the 'standard payment' mechanism. It allows the recipient to spend multiple outputs of a sPay transaction. This is, of course, highly undesirable. Lock times and staggered times can be used to prevent such abuse. The staggered time can be enabled via the transaction's nLockTime field to ensure that the recipient can only submit the receiving transaction to one output of the sPay transaction.

[0200] Spending transactions at staggered times Figure 11 The design shown is explained below. Time is displayed from left to right on a horizontal axis. Spending transactions are represented by full arrows, with the tail of the arrow starting at the time (or after) when the transaction can be successfully committed to blockchain 150, subject to the transaction lock time. For example, a receiving transaction Collect1 must be committed after time = t1, while a receiving transaction Winning2 must be committed after time = t2, and so on. The intended recipient of a spending transaction is shown at the head of the arrow. Cancelling transactions are not time-dependent (in this context, this means that the submission of a cancellation transaction is not restricted by the nLockTime value). A cancellation transaction can be committed to blockchain 150 at any time as long as the submitter knows the secret value k (and Alice's signature). Output o = 1 does not have a cancellation transaction. A cancellation transaction for any output j is used to enable Alice 103a to immediately 'cancel' Collect. j Transaction. Collect. j Submission is only possible after the receiving transaction for output i has been submitted. This is because Collection1 does not have a previous Collection. j Therefore, a cancel transaction with output i=1 is not applicable. Remember that if Bob never submits his Collect1 transaction, a Refund1 transaction exists for output i=1. Note that submitting a receive transaction to blockchain 150 exposes the value of k to any relevant parties.

[0201] according to Figure 11 The first transaction Tx1 that can be submitted is the transaction of Collect1 with output i=1. This can be submitted by Bob after time t1. For output i=1, the refund transaction Refund1 can only be submitted at time t. 1,2 (Referring to the time after time t1 but before time t2) (submitted by Alice). Therefore, after time t1, Bob has Δ1 = t. 1,2 Submit the collection transaction Collect1 using a time span of -t1 units (to prevent Alice from refunding her own output). This time span is represented by a double-headed arrow.

[0202] The next eligible transaction to receive payment, 1000, is Collect2..., and can only be submitted after time t2. This means that if Bob 103b wants to collect the prize for the second output i=1, he can only submit the transaction after t2, i.e., t... 1,2 After a certain time, Alice 103a can submit a refund transaction with output i=1. i The time (at or after that time).

[0203] This provides protection for Bob 103b's collection of multiple outputs of the sPay transaction. The individual (Alice) who raises funds for the payment transaction sPay is responsible for executing the refund transaction Refund1 before the recipient is able to submit the collection transaction Collect2. Therefore, in t i,i+1 After that, Alice has Δ i,i+1 =t i+1 -t i,i+1 The refund transaction Refund1 is submitted within a unit of time (so that Bob can submit Collect). i+1 ).

[0204] The output i=1 is an exception because it does not have the function of canceling a transaction. To explore canceling transactions, see [link to relevant documentation]. Figure 11 The general output i: i>1. Cancel the transaction. i The function to perform a refund is available, but it is related to the Refund transaction. i Conversely, canceling a transaction submission to blockchain 150 is not restricted by the nLockTime value, but rather by knowledge (or lack thereof) of a secret value. As long as the secret value is known to be k, Alice 103a can submit this cancel version of the'refund' transaction. In some examples, Alice's signature may also be included in the transaction. Given that the secret value is revealed when Bob 103b submits the collection transaction, if Bob 103b is to submit the collection transaction Collect i , then each cancel submission for outputs where j:j>i can be immediately submitted by Alice 103a. This would prevent Bob 103b from accessing all subsequent outputs.

[0205] Therefore, the proposed recipient Bob 103b is responsible for accessing (off-chain) the outputs that he can successfully spend and is willing to submit. The selected output is expected to be the one that rewards Bob with the maximum digital asset amount. If Bob 103b selects output i, then Bob must keep the k value secret until he submits the transaction Collect i up to that point. For any previous output (j < i), Alice could have (or at least had the opportunity to) submit a refund transaction Refund j .

[0206] While preferred, lock times and stagger times are not required. Instead, Alice 103a can submit cancel transactions and / or refund transactions only at appropriate times. Similarly, Bob 103b can be trusted to submit only a single collection transaction.

[0207] Figure 12 An exemplary sequence of the STP is shown, with time running from top to bottom. The specific sequence is as follows: <s

[0208] 1. Bob selects the secret value k.

[0209] 2. Bob sends the hash of the secret value to Alice.

[0210] 3. Alice creates the sPay transaction.

[0211] 4. Alice creates the refund transaction and the collection transaction.

[0212] 5. Alice sends the standard set and the lock time to Bob.

[0213] 6. Alice signs the refund transaction and the collection transaction and sends them to Bob.

[0214] 7. If Bob agrees, Bob signs the refund transaction and sends it back to Alice.

[0215] 8. Alice submits the sPay transaction to the blockchain.

[0216] 9. Bob determines the solution based on as many criteria as possible.

[0217] 10. Bob determines the output that he can unlock and that pays the highest digital asset amount.

[0218] 11. At this point, Alice can submit a refund for any output j < i to the blockchain.

[0219] 12. Bob submits the collection transaction for output i to the blockchain.

[0220] 13. Since the secret value has been revealed, Alice submits a cancellation transaction for output j > i.

[0221] Note that the above sequence is a specific example and other orderings are possible. For example, there is some flexibility in presenting the criteria to Bob.

[0222] As described above, in some implementations of the binary and spectrum threshold protocols, successfully meeting a criterion can increment a counter by 1, or in other implementations, the counter can be incremented by other values. "Weighted criterion" implementations may be necessary in some cases where some criteria are more 'important' than others. Weighted criteria can be used when the reward amount for meeting a criterion is not forced to be uniform but depends on the specific criterion.

[0223] Meeting criterion i increments the counter by w i , where the threshold is set to the value m i :m i ≤ v, where v ≥ n is the maximum achievable (counter) value. For example, meeting criterion_i increments the counter by 2, meeting criterion_j increments the counter by 1, and meeting criterion_k increments the counter by 3, etc.

[0224] In such implementations, reaching the threshold is not only limited by the number of criteria met but also by the criteria themselves. Bob 103b can achieve the threshold by meeting different numbers of criteria. For example, if the threshold is set to six, Bob 103b can achieve the threshold by meeting three criteria, each with a weight value of two units, or Bob 103b can achieve the threshold by meeting two criteria, each with a weight value of three units.

[0225] Both BTP and STP can be designed to incorporate this weighted consideration by simply changing the value by which the counter in the ALT stack in the [TEST] script is incremented to now be w for each criterion i i , where the threshold < m i > is still chosen by the payer and is chosen based on the criteria and their weights.

[0226]

[0227] Several improvements can be made to the [TEST] script (weighted or otherwise) shown so far to improve its execution efficiency. At least one aspect of this improvement is described below. The efficiency improvement is achieved by reducing the number of Input Criterion Assessments (I-CAs). In previous versions of the [TEST] script, each of the n inputs was evaluated according to its corresponding criterion; this meant that n I-CAs were always performed. This can be problematic if the input criterion assessment is computationally expensive.

[0228] Previous versions of the [TEST] and unlock scripts used an input set based on the idea that the receiver, Bob 103b, might or might not know which inputs would satisfy the corresponding criteria; therefore, the lock script determined which were correct when updating the counters accordingly. However, Bob 103b might know which m out of n criteria he would satisfy before submitting the payment transaction. The [TEST] script can be modified to require Bob 103b to specify the criteria he wants to perform I-CA.

[0229]

[0230] Note that for the modified [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 whether Bob wants to perform I-CA according to that criterion (1 if yes, 0 if no). The OP_IF opcode can be replaced with an equivalent function used to check a specific data element. Typically, the [TEST] script may include a "check" component configured to check whether the input includes one of two possible data elements. If the first data element is provided, the following script is executed for the second different data element, and vice versa.

[0231] Also note the introduction of OP_VERIFY. This can be a standalone opcode following a previous element in a standard script, or it can be a standard opcode that always uses verification.

[0232] OP_VERIFY following the following:

[0233] OP_IF[OP_EQUAL]OP_VERIFY

[0234] or VERIFY opcode

[0235] OP_IF[OP_EQUALVERIFY]

[0236] Note that if the top stack value is not true, the VERIFY script element will mark the transaction as invalid. Simultaneously, the top stack value will be removed. If the standard fails, the VERIFY component immediately invalidates the entire transaction without further script execution. Depending on the lock script revision [TEST], the unlock script in the receiving transaction also needs to be modified. The unlock script described above includes... <answers>Partial, as shown below:

[0237] <answers>≡<input_n><input_n-1>…<input_2><input_1> < / answers>

[0238] A valid modified version of this input script will be characterized by a first or second scattered data element (e.g., a value of 0 or 1), indicating whether Bob wants to perform I-CA against a specific standard. Examples of such modifications are shown below:

[0239]

[0240] Here, Bob 103b knows he can achieve the desired threshold by providing a solution that only provides the standard values ​​1, 4, and n. Therefore, <1> The value is placed<input_1> ,<input_4> and<input_n> After the element. <0> replace <answers>All other scripts<input_i> Value. Utilizing the above revisions <answers>The total number of I-CA completions will be 3, not n. Therefore, assuming that for all i, the weights... <w1>If the value is 1, then m I-CAs are performed only for the m / n threshold.

[0241] Figure 13 and Figure 14 An exemplary use case of an improved [TEST] script is shown. This use case is an alternative to the current implementation of m / n multisignature functionality in some blockchain protocols. In the existing implementation of m / n multisignature functionality, via OP_CHECKMULTISIG, the locking script contains a set of n public keys, while the unlocking script contains m digital (ECDSA) signatures. Determining whether a signature meets the threshold is done as follows: The OP_CHECKMULTISIG opcode compares the first signature with each public key until an ECDSA match is found. Starting with the subsequent public keys, it compares the second signature with each of the remaining public keys until an ECDSA match is found. This process is repeated until all signatures have been checked or there are not enough public keys to produce a successful result. All signatures must match the public keys. Because the public keys are not checked again if any signature comparison fails, the signatures must be placed in scriptSig in the same order as their corresponding public keys placed in scriptPubKey. If all signatures are valid, 1 is returned; otherwise, 0 is returned.

[0242] consider Figure 13 The example shown is a 3 / 5 multisignature. Each public key P i It can be considered a standard, and each signature Sig i This can be considered as one input. Remember that dashed arrows represent invalid I-CAs, and non-dashed arrows represent successful I-CAs. It can be seen that there are two I-CAs used to evaluate Sig3 (similar to Sig3). Since the script does not specify the public key P on which the Sig3 evaluation is based... i Sig3 must be based on a set of P i s is evaluated in an ordered sequence until:

[0243] a) Achieve matching P i ;

[0244] b) Deplete all P i The value was returned, but no match was found; or

[0245] c) Deplete enough P i No match was found for the value, so even if a match is eventually found in the remaining P... i Even if a match is found in set s, there will not be enough remaining P. i s is sufficient to satisfy the required threshold (even if all remaining P) i s and the remaining Sig i (s successfully matched).

[0246] Ultimately, the key lies in the fact that for OP_CHECKMULTISIG, ≥1 public key – signature I-CA involves each Sig i If an efficiency-enhancing [TEST] function is utilized, the number of I-CAs executed will be improved. Consider the following proposed m / nECDSA-signed [TEST] script.

[0247]

[0248] And below is its corresponding unlocking script, where Bob 103b provides three signatures, namely Sig1, Sig4, and Sig... n ,

[0249]

[0250] like Figure 14 As shown, since Bob uses values ​​0 and 1 to represent the public key on which the signature evaluation is based, this reduces the number of I-CAs involved in each signature to a maximum of 1 (the opposite of OP_CHECKMULTISIG≥1).

[0251] An added advantage of using the [TEST] function (both the previously presented version and the efficiency-improved version) is the gain of privacy protection. By using the [TEST] function with m / n multisignature instead of OP_CHECKMULTISIG, Bob 103b does not have to reveal any public key. This is because the OP_CHECKMULTISIG locking script includes the public key, while the [TEST] locking script includes the hash of the public key.

[0252] in conclusion

[0253] It should be understood that the above embodiments are described by way of example only.

[0254] More simply, based on a first example of the teachings disclosed herein, a method is provided for generating a computer implementation of a blockchain transaction for transferring a digital asset amount from a first party to a second party; the method is implemented by the first party and includes: generating a first transaction including an output that locks a digital asset amount, the output including an output script including a plurality of standard components, each requiring a corresponding input data item, and a plurality of counter script components, each standard component being associated with one of the counter script components, and wherein the output script is configured to, when executed together with an input script of a second transaction, i) increment a counter whenever a corresponding input data item of the input script satisfies a corresponding standard component, and ii) require the counter to increment to at least a predetermined amount for unlocking by the input script.

[0255] According to a second alternative example of the teachings disclosed herein, a method is provided according to the first example, wherein the total number of a plurality of standard components is greater than or equal to a predetermined number.

[0256] According to a third alternative example of the teachings disclosed herein, a method is provided according to the first or second example, wherein one, part or all of the plurality of standard components defines different corresponding standards.

[0257] According to the fourth alternative example of the teachings disclosed herein, a method is provided according to any one of the first to third examples, wherein one, part or all of a plurality of standard components includes a plurality of sub-standard components, each requiring a corresponding sub-input data item.

[0258] According to a fifth alternative example of the teachings disclosed herein, a method is provided according to any one of the first to fourth examples, wherein one, part or all of the plurality of standard components and / or one, part or all of the plurality of sub-standard components require a corresponding blockchain signature corresponding to a predetermined blockchain public key, respectively, as input or sub-input data items.

[0259] According to a sixth alternative example of the teachings disclosed herein, a method is provided according to any one of the first to fifth examples, wherein one, part or all of a plurality of standard components are associated with a counter script component configured to increment a counter by different amounts.

[0260] According to a seventh alternative example of the teachings disclosed herein, a method is provided according to any one of the first to sixth examples, wherein each input data item in an input script includes a first or second element, and wherein one, part or all of a plurality of standard components are associated with a corresponding inspection component, wherein each corresponding inspection component is configured, when executed with the input script, to i) determine whether each input data item includes the first element, and ii) if the input data item includes the first element, to execute only the associated standard component.

[0261] According to the eighth alternative example of the teachings disclosed herein, a method is provided according to the seventh example, wherein each output script is configured to invalidate the first transaction if the input data of the input script does not meet the standard components of the execution.

[0262] According to the ninth alternative example of the teachings disclosed herein, a method is provided according to any one of the first to eighth examples, including transmitting the corresponding standard and / or substandard to a second party.

[0263] According to the tenth alternative example of the teachings disclosed herein, a method is provided according to any one of the first to ninth examples, including transmitting a first transaction to one or more nodes associated with the blockchain for inclusion in the blockchain.

[0264] According to the eleventh example of the teachings disclosed herein, a first-party computer device is provided, the computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code arranged to run on the processing means, the code being configured to perform the method according to any one of the first to tenth examples when run on the processing means.

[0265] According to a twelfth example of the teachings disclosed herein, a computer program is provided, which is contained on a computer-readable storage medium and configured to perform the method according to any one of the first to tenth examples when run on a first party's computer device.

[0266] According to the thirteenth example of the teachings disclosed herein, a first transaction is provided for inclusion in a blockchain, the first transaction for transferring the amount of digital assets from a first party to a second party, the transaction being contained on a computer-readable data medium or media and including executable code comprising a plurality of standard components, each requiring a corresponding input data item, and a plurality of counter components, each standard component being associated with one of the counter components, and wherein the code is configured to, when executed together with an input script of a second transaction on a blockchain network node: increment a counter stored in the node's memory whenever a corresponding input data item of the input script satisfies a corresponding standard component; and transfer the amount of digital assets to the second party based on the incremented counters to at least a predetermined number.

[0267] According to the fourteenth example of the teachings disclosed herein, a method is provided for generating a computer implementation of a blockchain transaction for transferring a digital asset amount from a first party to a second party, both parties being associated with a blockchain; the method is implemented by the first party and includes: generating a first transaction comprising a plurality of outputs, each output locking a corresponding digital asset amount and including a corresponding first script condition, wherein each first script condition includes a plurality of standard components, each requiring a corresponding input data item, and a plurality of counter components, each standard component being associated with one of the counter components, and wherein each first output script condition is configured to, when executed with an input script of a second transaction, i) increment a counter whenever a corresponding input data item of the input script satisfies a corresponding standard component, and ii) require the counter to increment to at least a corresponding predetermined amount for unlocking by the input script, and wherein one, some, or all of the first script conditions require the counter to increment to different predetermined amounts.

[0268] According to the fifteenth optional example of the teachings disclosed herein, and according to the fourteenth example, a method is provided in which one, some, or all of the output is locked for different corresponding digital asset amounts.

[0269] According to the sixteenth alternative example of the teachings disclosed herein, and according to the fifteenth example, a method is provided in which the amount of a corresponding digital asset locked by the corresponding output is incremented to a corresponding predetermined amount based on the corresponding first script condition requiring a counter.

[0270] According to the seventeenth alternative example of the teachings disclosed herein, and according to any one of the fourteenth to sixteenth examples, a method is provided in which each first script condition is configured to require the input script to include a digital signature of a first party and / or a digital signature of a second party in order to be unlocked by an input script.

[0271] According to the eighteenth alternative example of the teachings disclosed herein, and according to the seventeenth example, a method is provided comprising: for each output, generating a corresponding second transaction, wherein the input script of each second transaction includes a pre-defined signature of the first party; and transmitting each second transaction to the second party.

[0272] According to the nineteenth alternative example of the teachings disclosed herein, a method is provided according to the eighteenth example, wherein each second transaction includes a different lock time, wherein each corresponding lock time is configured to prevent the corresponding second transaction from being included in the blockchain until after the corresponding predetermined time has elapsed.

[0273] According to the twentieth alternative example of the teachings disclosed herein, a method is provided according to any one of the fourteenth to nineteenth examples, wherein each first script condition includes a hash of a secret value, and wherein each first script condition is configured to require the input script to include a secret value in order to be unlocked by an input script.

[0274] According to the twenty-first alternative example of the teachings disclosed herein, and according to any one of the fourteenth to twentieth examples, a method is provided, wherein each output includes a corresponding second script condition configured to, when executed together with an input script for a third transaction, require the input script for the third transaction to include a predetermined digital signature of the first party and a predetermined digital signature of the second party for unlocking by the input script.

[0275] According to the twenty-second alternative example of the teachings disclosed herein, and according to the twenty-first example, a method is provided comprising: for each output, receiving a corresponding third transaction from a second party, wherein the input script of each third transaction includes a predetermined signature of the first party and a predetermined digital signature of the second party.

[0276] For example, the first party may sign a third transaction and transmit the signed third transaction to the second party. The second party may then transmit the third transaction to the first party.

[0277] According to the twenty-third alternative example of the teachings disclosed herein, a method is provided according to the twenty-second example, wherein each third transaction includes a different lock time, wherein each corresponding lock time is configured to prevent the corresponding second transaction from being included in the blockchain until after the corresponding predetermined time has elapsed.

[0278] According to the twenty-fourth alternative instance of the teachings disclosed herein, a method is provided according to the twenty-third instance which is at least subordinate to the nineteenth instance, wherein each output is associated with a different transaction in the second transaction and a different transaction in the third transaction, and wherein for each output, a corresponding lock time of the third transaction prevents the third transaction from being included in the blockchain until after the second transaction can be included in the blockchain.

[0279] According to the twenty-fifth alternative example of the teachings disclosed herein, and according to any one of the fourteenth to twenty-fourth examples, a method is provided in which one, part or all of the output includes a corresponding third script condition, wherein each third script condition is configured to, when executed together with the input script of the fourth transaction, require the input script of the fourth transaction to include a predetermined digital signature of the first party for unlocking by the input script.

[0280] According to the twenty-sixth alternative instance of the teachings disclosed herein, a method is provided according to the twenty-fifth instance, which is at least subordinate to the twentyth instance, wherein each third script condition includes a hash of a secret value, and wherein each third script condition is configured to require the input script to include a secret value in order to be unlocked by the input script of the fourth transaction.

[0281] According to the twenty-seventh alternative example of the teachings disclosed herein, and according to the twenty-sixth example, a method is provided comprising: obtaining a secret value; generating a corresponding fourth transaction for one, some, or all of the output, wherein the input script for each fourth transaction includes a predetermined signature of a first party and a secret value; and transmitting each fourth transaction to one or more nodes associated with the blockchain for inclusion in the blockchain.

[0282] According to the twenty-eighth alternative example of the teachings disclosed herein, a method is provided according to any one of the fourteenth to twenty-seventh examples, wherein the total number of the plurality of standard components is greater than each of the respective predetermined quantities.

[0283] According to the twenty-ninth alternative example of the teachings disclosed herein, a method is provided according to any one of examples fourteen through twenty-eight, wherein one, some or all of the plurality of standard components defines different corresponding standards.

[0284] According to the thirtieth alternative example of the teachings disclosed herein, and according to any one of the fourteenth to twenty-ninth examples, a method is provided in which one, part or all of a plurality of standard components comprises a plurality of sub-standard components, each requiring a corresponding sub-input data item.

[0285] According to the thirty-first alternative example of the teachings disclosed herein, a method is provided according to any one of the fourteenth to thirtieth examples, wherein for one, part or all, one, part or all, and / or one, part or all of the sub-standard components of a first script condition, a corresponding blockchain signature corresponding to a predetermined blockchain public key is required, respectively, as an input or sub-input data item.

[0286] According to the thirty-second alternative example of the teachings disclosed herein, and according to any one of the fourteenth to thirty-first examples, a method is provided in which, for one, some, or all of a first script condition, one, some, or all of a plurality of standard components are associated with a counter script component, which is configured to increment a counter by different amounts.

[0287] According to the thirty-third alternative example of the teachings disclosed herein, and according to any one of the fourteenth to thirty-second examples, a method is provided in which each input data item in the input script includes a first or second element, and wherein one, part or all of a plurality of standard components are associated with a corresponding inspection component, wherein each corresponding inspection component is configured, when executed with the input script, to i) determine whether each input data item includes the first element, and ii) execute only the standard script component corresponding to the input data item that includes the first element.

[0288] According to the thirty-fourth alternative example of the teachings disclosed herein, and according to the thirty-third example, a method is provided in which each first script condition is configured to invalidate the first transaction if the input data of the input script does not satisfy the standard script to be executed.

[0289] According to the thirty-fifth alternative example of the teachings disclosed herein, and according to any one of the fourteenth to thirty-fourth examples, a method is provided that includes transmitting the corresponding standard and / or sub-standard to a second party.

[0290] According to the thirty-sixth alternative example of the teachings disclosed herein, and according to any one of the fourteenth to thirty-fifth examples, a method is provided that includes transmitting a first transaction to one or more nodes associated with the blockchain for inclusion in the blockchain.

[0291] According to the thirty-seventh example of the teachings disclosed herein, a first-party computer device is provided, the computer device comprising: a memory including one or more memory cells; a processing means including one or more processing units, wherein the memory stores code disposed on the processing means for execution, the code being configured to perform the method according to any one of the fourteenth to thirty-sixth examples when on the processing means.

[0292] According to the thirty-eighth example of the teachings disclosed herein, a computer program is provided, which is contained on a computer-readable storage medium and configured to perform the method according to any one of the fourteenth to thirty-sixth examples when run on a first party's computer device.

[0293] According to the thirty-ninth example of the teachings disclosed herein, a method for generating a computer-implemented transaction for a blockchain is provided, the transaction being used to transfer a digital asset amount from a first party to a second party, both the first and second parties being associated with the blockchain, wherein the blockchain includes a first transaction, the first transaction including an output locking the digital asset amount and including a first script condition, wherein the first script condition includes a plurality of standard components, each requiring a corresponding input data item; the method is performed by the second party and includes: generating a second transaction, the second transaction including a first input script component, the first input script component including: i) a plurality of input data items, each corresponding to a corresponding standard component of the first script condition, ii) a secret value, iii) a predetermined digital signature of the first party, and iv) a predetermined signature of the second party; and transmitting the second transaction to one or more nodes associated with the blockchain for inclusion in the blockchain.

[0294] According to the fortieth alternative example of the teachings disclosed herein, a method is provided according to the thirty-ninth example, wherein a first transaction includes second and third script conditions, and wherein the second transaction includes: a second input script component configured to evaluate to false when executed according to the second script condition; and a third input script component configured to evaluate to false when executed according to the third script condition.

[0295] According to the forty-first alternative example of the teachings disclosed herein, a method is provided according to the thirty-ninth or fortieth example, wherein a first script condition includes a plurality of checking components, each associated with a corresponding component of a plurality of standard components, and wherein each corresponding checking component is configured, when executed with an input script, to i) determine whether each input data item includes a first element, and ii) execute only the standard script component corresponding to the input data item that includes the first element; and wherein each input data item includes either a first data element or a second different data element.

[0296] According to the forty-second alternative example of the teachings disclosed herein, and according to any one of the thirty-ninth to forty-first examples, a method is provided in which one, some or all of the input data items include a corresponding digital signature.

[0297] According to the forty-third embodiment of the teachings disclosed herein, a second-party computer device is provided, the computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code disposed on the processing means for execution, the code being configured to perform the method according to any one of the thirty-ninth to forty-second examples when on the processing means.

[0298] According to the forty-fourth embodiment of the teachings disclosed herein, a computer program is provided, which is contained on a computer-readable storage medium and configured to perform the method according to any one of the thirty-ninth to forty-second embodiments when run on a second-party computer device.

[0299] According to Example 45 of the teachings disclosed herein, a first transaction is provided for inclusion in a blockchain, the first transaction being used to transfer a digital asset amount from a first party to a second party, the first transaction being contained on a computer-readable data medium or media and including executable code comprising multiple output scripts, each output script locking a corresponding amount of digital assets and including corresponding first, second, and third script conditions, each first script condition including: i) multiple standard components, each requiring a corresponding input data item, and ii) multiple counter components, each standard component being associated with one of the counter components, and wherein the code is configured to, when interacting with a blockchain network node... When the input script of the second transaction is executed together with the corresponding output script: if the corresponding first script condition is executed, then whenever the corresponding input data item of the input script satisfies the corresponding standard component, the counter stored in the memory of the node is incremented, and the digital asset amount is transferred to the second party based on the incremented counter reaching at least a predetermined number; if the corresponding second script condition is executed, then it is determined whether the input script includes the predetermined digital signature of the first party and the predetermined digital signature of the second party, and the digital asset amount is transferred to the first party; and if the corresponding third script condition is executed, then it is determined whether the input script includes the predetermined digital signature and secret value of the first party, and the digital asset amount is transferred to the first party.

[0300] According to the forty-sixth example of the teachings disclosed herein, a computer-readable storage medium is provided on which the first transaction of the forty-fifth example is stored.

[0301] According to the forty-seventh example of the teachings disclosed herein, a computer-readable storage medium is provided on which the first transaction of the thirteenth example is stored.

[0302] Based on another example of the teachings disclosed herein, a method may be provided that includes measures by a first party and a second party.

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

[0304] According to another example of the teachings disclosed herein, a set of transactions may be provided, which includes first and second transactions.

[0305] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims. < / answers> < / answers> < / answers> < / dummy> < / answers> < / answers>

Claims

1. A computer-implemented method for generating transactions for blockchain, the transactions being used to transfer digital asset amounts from a first party to a second party; the method being implemented by the first party and comprising: A first transaction is generated, which includes an output that locks the amount of the digital asset. The output includes an output script, which comprises multiple standard components and multiple counter script components. Each standard component requires a corresponding input data item, and each standard component is associated with one of the counter script components. The output script is configured to, when executed together with the input script of the second transaction, i) increment a counter whenever a corresponding input data item of the input script satisfies a corresponding criterion component, and ii) require the counter to increment to at least a predetermined amount for unlocking by the input script.

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 claim 2, wherein the total number of the plurality of standard components is greater than or equal to the predetermined number.

4. The method of claim 1, wherein one, some, or all of the plurality of standard components define different corresponding standards.

5. The method of claim 1, wherein one, some or all of the plurality of standard components comprises a plurality of sub-standard components, each sub-standard component requiring a corresponding sub-input data item.

6. The method according to claim 5, wherein one, some or all of the plurality of standard components and / or one, some or all of the plurality of sub-standard components require a corresponding blockchain signature corresponding to a predetermined blockchain public key, respectively, as input or sub-input data items.

7. The method of claim 1, wherein one, some or all of the plurality of standard components are associated with a counter script component, the counter script component being configured to increment the counter by different amounts.

8. The method of claim 1, wherein each input data item in the input script includes a first element or a second element, wherein one, part or all of the plurality of standard components are associated with a corresponding inspection component, wherein each corresponding inspection component is configured to, when executed with the input script, i) determine whether each input data item includes the first element, and ii) if the input data item includes the first element, execute only the associated standard component.

9. The method of claim 8, wherein each output script is configured to invalidate the first transaction if the input data of the input script does not meet the standard components to be executed.

10. The method of claim 5, further comprising transmitting the corresponding standard and / or sub-standard to the second party.

11. A first-party computer device, said computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 1 to 10 when run on the processing apparatus.

12. A computer program product contained on a computer-readable storage medium and configured to perform the method according to any one of claims 1 to 10 when run on a computer device of the first party.

13. A computer-readable storage medium storing thereon a first transaction for inclusion in a blockchain, the first transaction for transferring digital asset amounts from a first party to a second party, the first transaction including executable code comprising a plurality of standard components and a plurality of counter components, each standard component requiring a corresponding input data item, each standard component being associated with one of the counter components, and wherein the code is configured to execute together with an input script for a second transaction on a blockchain network node: Whenever the corresponding input data item of the input script satisfies the corresponding standard component, the counter stored in the memory of the node is incremented; The digital asset amount is transferred to the second party based on a counter that has been increased to at least a predetermined number.

14. A computer-implemented method for generating transactions for a blockchain, the transactions being used to transfer digital asset amounts from a first party to a second party, the first and second parties being associated with the blockchain; the method being implemented by the first party and comprising: A first transaction is generated, comprising multiple outputs. Each output locks a corresponding digital asset amount and includes a corresponding first script condition. Each first script condition includes multiple standard components and multiple counter components. Each standard component requires a corresponding input data item, and each standard component is associated with one of the counter components. Each of the first output scripts is configured to, when executed together with the input script of the second transaction, i) increment a counter whenever a corresponding input data item of the input script satisfies a corresponding criterion component, and ii) require the counter to increment to at least a corresponding predetermined number to be unlocked by the input script, wherein one, some, or all of the first script conditions require the counter to increment to a different predetermined number.

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

16. The method of claim 14 or claim 15, wherein one, some, or all of the outputs are locked with different corresponding digital asset amounts.

17. The method of claim 14, wherein the corresponding digital asset amount locked by the corresponding output requires the counter to increase to the corresponding predetermined amount based on the corresponding first script condition.

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

19. The method of claim 18, wherein the method comprises: For each output, a corresponding second transaction is generated, wherein the input script for each second transaction includes the pre-defined signature of the first party; Each second transaction is transmitted to the second party.

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

21. The method of claim 14, wherein each first script condition includes a hash of the secret value, and wherein each first script condition is configured to require the input script to include the secret value in order to be unlocked by the input script.

22. The method of claim 14, wherein each output includes a corresponding second script condition configured to, when executed together with an input script for a third transaction, require the input script for the third transaction to include a predetermined digital signature of the first party and a predetermined digital signature of the second party for unlocking by the input script.

23. The method according to claim 22, wherein the method comprises: For each output, a corresponding third transaction is received from the second party, wherein the input script for each third transaction includes a predetermined signature of the first party and a predetermined digital signature of the second party.

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

25. The method of claim 24, wherein each output is associated with a different transaction in the second transaction and a different transaction in the third transaction, and wherein for each output, a corresponding lock time of the third transaction prevents the third transaction from being included in the blockchain until after the second transaction can be included in the blockchain.

26. The method of claim 14, wherein one, some, or all of the output includes a corresponding third script condition, wherein each third script condition is configured to, when executed together with the input script of the fourth transaction, require the input script of the fourth transaction to include a predetermined digital signature of the first party for unlocking by the input script.

27. The method of claim 26, wherein each third script condition includes a hash of the secret value, and wherein each third script condition is configured to require the input script to include the secret value in order to be unlocked by the input script of the fourth transaction.

28. The method of claim 27, wherein the method comprises: Obtain the secret value; For one, some, or all of the outputs, a corresponding fourth transaction is generated, wherein the input script for each fourth transaction includes the first party's predetermined signature and the secret value; Each fourth transaction is transmitted to one or more nodes associated with the blockchain to be included in the blockchain.

29. The method of claim 14, wherein the total number of the plurality of standard components is greater than or equal to each of the respective predetermined quantities.

30. The method of claim 14, wherein one, some, or all of the plurality of standard components define different corresponding standards.

31. The method of claim 14, wherein one, part or all of the plurality of standard components comprises a plurality of sub-standard components, each requiring a corresponding sub-input data item.

32. The method of claim 31, wherein one, some or all of the first script conditions, one, some or all of the plurality of standard components, and / or one, some or all of the plurality of sub-standard components require a corresponding blockchain signature corresponding to a predetermined blockchain public key, respectively, as input or sub-input data items.

33. The method of claim 14, wherein one, some or all of the first script conditions, or one, some or all of the plurality of standard components, are associated with a counter script component configured to increment the counter by different amounts.

34. The method of claim 14, wherein each input data item in the input script includes a first element or a second element, and wherein one, part or all of the plurality of standard components are associated with a corresponding inspection component, wherein each corresponding inspection component is configured, when executed with the input script, to i) determine whether each input data item includes the first element, and ii) execute only the standard script component corresponding to the input data item that includes the first element.

35. The method of claim 34, wherein each first script condition is configured to invalidate the first transaction if the input data of the input script does not satisfy the standard script to be executed.

36. The method of claim 31, further comprising transmitting the corresponding standard and / or sub-standard to the second party.

37. A first-party computer device, said computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being configured to execute the method according to any one of claims 14 to 36 when run on the processing apparatus.

38. A computer program product contained on a computer-readable storage medium and configured to perform the method according to any one of claims 14 to 36 when run on a computer device of the first party.

39. A computer-implemented method for generating transactions for a blockchain, the transactions being used to transfer digital asset amounts from a first party to a second party, the first party and the second party being associated with the blockchain, wherein the blockchain includes a first transaction, the first transaction including an output locking the digital asset amounts and including a first script condition, wherein the first script condition includes a plurality of standard components, each requiring a corresponding input data item; The method is performed by the second party and includes: Generate a second transaction, the second transaction including a first input script component, the first input script component including: i) a plurality of input data items, each corresponding to a corresponding standard component of the first script condition, ii) a secret value, iii) a predetermined digital signature of the first party, and iv) a predetermined signature of the second party; The second transaction is transmitted to one or more nodes associated with the blockchain to be included in the blockchain.

40. The method of claim 39, wherein the first transaction includes second and third script conditions, and wherein the second transaction includes: A second input script component, configured to evaluate to false when executed according to the second script condition; A third input script component is configured to evaluate to false when executed according to the third script condition.

41. The method of claim 39 or claim 40, wherein the first script condition includes a plurality of checking components, each associated with a corresponding component of the plurality of standard components, and wherein each corresponding checking component is configured, when executed with the input script, to i) determine whether each input data item includes a first element, and ii) execute only the standard script component corresponding to input data items that include the first element; and wherein each input data item includes the first element or a different second element.

42. The method of claim 39, wherein one, some, or all of the input data items include a corresponding digital signature.

43. A second-party computer device, said computer device comprising: The memory includes one or more memory units; as well as A processing apparatus comprising one or more processing units, wherein the memory stores code configured to run on the processing apparatus, the code being executed, when run on the processing apparatus, according to any one of claims 39 to 42.

44. A computer program product contained on a computer-readable storage medium and configured to perform the method according to any one of claims 39 to 42 when run on a computer device of the second party.

45. A computer-readable storage medium storing thereon a first transaction for inclusion in a blockchain, the first transaction for transferring a digital asset amount from a first party to a second party, the first transaction including executable code, the code including a plurality of output scripts, each output script locking a corresponding amount of the digital asset and including corresponding first, second and third script conditions, each first script condition including: i) multiple standard components, each requiring a corresponding input data item, and ii) multiple counter components, each standard component being associated with one of the counter components, wherein the code is configured to execute a corresponding output script along with the input script of a second transaction on a blockchain network node: If the corresponding first script condition is executed, then whenever the corresponding input data item of the input script satisfies the corresponding standard component, the counter stored in the memory of the node is incremented, and the digital asset amount is transferred to the second party based on the incremented counter to at least a predetermined number; If the corresponding second script condition is executed, it is determined whether the input script includes the predetermined digital signature of the first party and the predetermined digital signature of the second party, and the digital asset amount is transferred to the first party; If the corresponding third script condition is executed, it is determined whether the input script includes the first party's predetermined digital signature and secret value, and the digital asset amount is transferred to the first party.

Images