Enforcing conditions on blockchain transactions

Abstract

1. A computer-implemented method for enforcing conditions on a second blockchain transaction using a first blockchain transaction, wherein a first of the conditions is that when a first unlock script of the second transaction is executed with a first lock script of the first transaction, a representation of the second transaction is output to memory, the representation being based on a plurality of fields of the second transaction and a first output of the first transaction, the method comprising: generating a first transaction, the first transaction including the first output, the first output including a first lock script, the first lock script including a message subscript, a signature subscript, a public key corresponding to the private key, and a verification subscript.

Description

Technical Field

[0001] The present disclosure relates to a method for enforcing conditions on blockchain transactions. More specifically, a first blockchain transaction is used to enforce one or more conditions on a second, different blockchain transaction.

Background Art

[0002] A blockchain refers to a form of a distributed data structure in which a copy of the blockchain is maintained and widely published at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). A blockchain includes a chain of data blocks, with each block containing one or more transactions. Each transaction other than a so-called "coinbase transaction" points backward to a previous transaction in a sequence that may span one or more blocks that return to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are often created by a process called "mining," which involves competing to solve a cryptographic puzzle based on a defined set of ordered, approved, pending transactions that each of a plurality of nodes is waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and the publication of a block may be achieved by simply publishing the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: the transfer of digital assets (i.e., several digital tokens), the ordering of sets of entries in a virtual ledger or registry, the reception and processing of timestamp entries, and / or the time-ordering of index pointers. Blockchains can also be used to build additional functionality on top of them. For example, blockchain protocols may allow transactions to store additional user data or indices to data. There is no predetermined limit on the maximum amount of data that can be stored in a single transaction, and therefore, more complex data can be incorporated. For example, this may be used to store electronic documents on the blockchain, or to store audio or video data.

[0004] Nodes in a blockchain network (often called "miners") perform a decentralized transaction registration and verification process, which will be explained in more detail later. In short, during this process, nodes approve transactions and insert them into block templates, attempting to find a valid proof-of-work solution. Once a valid solution is found, the new block is propagated to other nodes in the network, thus enabling each node to record the new block on the blockchain. To have a transaction recorded on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network to be propagated. The node receiving the transaction may compete to find a proof-of-work solution that incorporates the approved transaction into a new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated and are not incorporated into blocks. Assuming a transaction is approved and thereby accepted into the blockchain, the transaction (including any user data) is therefore registered and indexed on each node of the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are generally rewarded with a new transaction called a "coinbase transaction," which distributes a certain amount of digital assets, i.e., several tokens. The detection and rejection of invalid transactions is enforced by the actions of competing nodes acting as agents of the network, who are incentivized to report and block fraudulent activity. Extensive disclosure of information allows users to continuously audit the performance of nodes. The mere publication of block headers allows participants to ensure the ongoing integrity of the blockchain.

[0006] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. All consumable outputs include an element specifying the amount of digital asset that can be derived from the ongoing sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unspent transaction output"). Outputs may further include a lock script that specifies the conditions for the output's future redemption. A lock script is a predicate that defines the conditions necessary to validate and send digital tokens or assets. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output of a preceding transaction and may further include an unlock script to unlock the lock script of the pointed-to output. So consider a pair of transactions, which we will call the first transaction and the second transaction (or "target" transaction). The first transaction includes at least one output specifying the amount of digital asset and a lock script that defines one or more conditions for unlocking the output. The second target transaction includes at least one input, which includes a pointer to the output of the first transaction and a lock release script for releasing the lock on the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded within the blockchain, one of the validity criteria applied at each node is that the unlock script satisfies all of one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not already been fulfilled by another previous valid transaction. Any node that finds a target transaction to be invalid according to any of these conditions will not propagate that transaction (as a valid transaction, however it may propagate to register an invalid transaction), nor will it include that transaction in a new block to be recorded on the blockchain.

[0008] An alternative type of transaction model is the account-based model. In this case, each transaction defines the amount to be sent by referencing the absolute account balance, rather than by backward referencing the UTXOs of preceding transactions in a sequence of past transactions. The current state of all accounts is stored and constantly updated by a node separate from the blockchain. [Prior art documents] [Patent Documents]

[0009] [Patent Document 1] PCT / IB2018 / 053335 [Patent Document 2] PCT / IB2018 / 053337 [Patent Document 3] PCT / IB2018 / 053339 [Patent Document 4] PCT / IB2018 / 053336 [Patent Document 5] PCT / IB2018 / 056430 [Patent Document 6] PCT / IB2018 / 056432 [Patent Document 7] PCT / IB2018 / 056431 [Overview of the project] [Means for solving the problem]

[0010] Existing techniques exist for enforcing conditions on blockchain transactions using other transactions. For example, it is possible to enforce conditions on the inputs and / or outputs of a future transaction attempting to unlock the output of a previous transaction, thereby making the output of the previous transaction responsible, at least partially, for enforcing those conditions. The conditions may include, for example, that the inputs and / or outputs of the future transaction contain or be in a specific format of data.

[0011] One technique used to enforce conditions on future transactions is widely known as "PUSHTX" or "OP_PUSHTX". PUSHTX is a pseudo-opcode, meaning that PUSHTX is not a single opcode in a blockchain scripting language (e.g., Script), but rather a set of opcodes (or more broadly, functions) configured together to execute a corresponding set of actions when executed. The PUSHTX technique was first disclosed in international patent applications PCT / IB2018 / 053335, PCT / IB2018 / 053337, PCT / IB2018 / 053339, PCT / IB2018 / 053336, PCT / IB2018 / 056430, PCT / IB2018 / 056432, and PCT / IB2018 / 056431. The core idea of ​​PUSHTX is to generate a signature within a script for a data element on the stack and then call OP_CHECKSIG to verify the signature. If the signature passes, it suggests that the message constructed by OP_CHECKSIG is identical to the data element pushed onto the stack. Thus, it has the effect of pushing the current spending transaction (i.e., a future transaction that unlocks the output of a previous transaction) onto the stack. Pushing the current transaction onto the stack allows for the enforcement of conditions, for example, by checking that certain fields of the current transaction (inputs, outputs, locktime, etc.) contain specific data, values, opcodes, scripts, etc.

[0012] This disclosure provides several optimizations of the PUSHTX technique. However, it should be understood that other similar techniques for pushing transactions onto the stack exist and are familiar to those skilled in the art, and that embodiments of this disclosure may be broadly applicable to any of those techniques, not just PUSHTX.

[0013] According to one embodiment disclosed herein, a computer implementation method for enforcing conditions on a second blockchain transaction using a first blockchain transaction, wherein a first condition is that a representation of the second transaction is output to memory when a first unlock script of the second transaction is executed together with a first lock script of the first transaction, and the representation is based on a plurality of fields of the second transaction and a first output of the first transaction, and the method is a step of generating a first transaction, wherein the first transaction includes a first output, the first output includes a first lock script, and the first lock script is a message subscript configured to output a candidate message representing the second transaction to memory when executed, the candidate message is based on a plurality of candidate fields of the first and second transactions, and one or more of the candidate fields represent the first unlock of the second transaction A message subscript is included in the removal script, and the message subscript is configured to generate one or more respective parts of a candidate message based on each set of candidate fields, and to reuse at least one of each set of candidate fields as each different part of the candidate message; a signature subscript is configured to generate a signature when executed, wherein the signature is a function of at least the candidate message, a private key, and an ephemeral private key; a public key corresponding to the private key; and when executed, i) construct a target message representing a second transaction, the target message being constructed based on multiple fields of the second transaction and the first output of the first transaction; and ii) verifying that the signature is valid for the target message using the public key, the verification that the signature is valid for the target message being valid, and verifying that the target message matches the candidate message, thereby,A computer execution method is provided, which includes a step that includes a verification subscript configured to perform verification, which enforces the condition that a candidate message output to memory is a representation of a second transaction.

[0014] The lock script for the first transaction and the unlock script for the second transaction are executed during the approval of the second transaction. The lock script for the first transaction includes a set of subscripts, each configured to perform one or more actions. A subscript is merely a label for a specific set of functions (e.g., opcodes) and, optionally, a set of data items, such as a public key or a hash of a public key.

[0015] The message subscript is configured to output candidate messages to memory, for example, the stack. A message is a "candidate message" in the sense that, if it is correctly configured, it matches another message referred to herein as the "target message". The candidate message is based on several fields (e.g., inputs, outputs, etc.) of a candidate for a second transaction (e.g., all fields of the second transaction) and the first output of a candidate for a first transaction, i.e., the output containing the first lock script. Here, the fields and outputs are "candidates" in the sense that they are included as data items (either in the lock script for the first transaction or the unlock script for the second transaction) and are claimed to be the correct fields of the first and second transactions. For example, the length of a candidate lock script may be included in the unlock script for the second transaction.

[0016] The signature subscript is configured to generate a digital signature (e.g., an ECDSA signature) based on a candidate message, a private key, and a temporary private key. In some embodiments, the temporary private key may be determined to be equal to 1. Given that temporary private keys are typically large numbers and are generally needed several times during signature generation, determining the temporary private key to be 1 reduces the storage size of the lock script and simplifies the signature generation process. The signature generation process is simplified because all mathematical operations involving the temporary private key become trivial. The signature subscript may be further optimized by determining both the private key and the temporary private key to be equal to 1. This further reduces the storage size of the lock script and decreases the computational complexity of the signature generation process. In additional or alternative embodiments, the temporary private key and the private key are determined in the lock script to be equal to the same value (not necessarily the value 1, but as mentioned above, that is of course optional). These embodiments offer significant savings for similar reasons. As will be described later, the inventors of this disclosure have recognized that these savings can be achieved without compromising the security of the first or second transaction.

[0017] The signature verification subscript (which may be a single function, e.g., an opcode) is configured to construct the target message based on the actual fields of the first and second transactions, e.g., the actual first output of the first transaction, the actual output of the second transaction, etc. The signature verification subscript also verifies that the signature generated by the signature subscript is valid for the target message. If the signature is valid, the candidate message is necessarily the same as the target message. Thus, the candidate message printed into memory is the target message, which is a representation of the second transaction. In other words, passing the signature check is only possible if the two messages are identical, and therefore, verifying the signature verifies that the candidate message and the target message are equal.

[0018] After the second transaction is output to memory (e.g., the stack), further checks may be performed to enforce additional conditions. For example, embodiments of this disclosure may be used to construct a perpetually enforcing locking script (PELS), which is a locking script that enforces some one or more conditions on all future transactions in a chain of transactions resulting from the output containing the locking script. For example, a PELS may be used to enforce that the locking script of a consuming transaction is the same as the PELS itself. A PELS is particularly useful for the sender (i.e., the creator of the transaction containing the first instance of the PELS) because the sender can ensure that all future consuming transactions comply with the rules set by the sender in the locking script. Any rule violation invalidates the transaction approval in terms of script execution. In effect, the sender can withdraw from all future transactions by delegating the approval work to the blockchain nodes.

[0019] This disclosure acknowledges that one or more sets of candidate fields representing a portion of a candidate message may be reused to construct different portions of the candidate message. This provides significant space savings, as one or more sets of candidate fields only need to be included once in the lock script of the first transaction or the unlock script of the second transaction, rather than being included multiple times. A further effect of reusing one or more sets of candidate fields is that additional conditions may be enforced on the second transaction. For example, as described above, the candidate message is based on the output of the first transaction, which includes a lock script that enforces conditions. The unlock script may include a set of candidate fields representing the output of the first transaction (e.g., a value and a lock script). The message subscript may duplicate the set of candidate fields to construct the output of the second transaction. If signature verification passes, the candidate message must be identical to the target message, and therefore the second transaction must include output that matches the output of the first transaction. In other words, for the second transaction to be considered valid, the output of the first transaction must be included as the output of the second transaction. The same technique may be applied to any portion of a candidate message (and therefore a target message) that contains or is based on the same set of candidate (or actual) fields of a second transaction.

[0020] To aid in understanding embodiments of the present disclosure and to illustrate how such embodiments may be carried out, the accompanying drawings are referenced only as examples. [Brief explanation of the drawing]

[0021] [Figure 1] This is a schematic block diagram of a system for implementing blockchain. [Figure 2]This diagram schematically illustrates some examples of transactions that may be recorded on the blockchain. [Figure 3A] This is a schematic block diagram of the client application. [Figure 3B] Figure 3A is a schematic mockup of an exemplary user interface that may be presented by the client application. [Figure 4] This is a schematic block diagram of a node software used to process transactions. [Figure 5] This is a schematic block diagram of an exemplary system for implementing an embodiment of the present disclosure. [Figure 6] This figure shows an example of a first transaction configured to enforce conditions on a second transaction. [Figure 7] This figure shows an example of the second transaction. [Figure 8] This figure shows an example of a second transaction where the first transaction is optimized to generate parts of the candidate message from other parts. [Modes for carrying out the invention]

[0022] 1. Overview of an Exemplary System Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may include a packet-switched network 101, typically a wide-area internetnet such as the Internet. The packet-switched network 101 may include a number of blockchain nodes 104 that are arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a near-complete graph, so that each blockchain node 104 is tightly connected to other blockchain nodes 104.

[0023] Each blockchain node 104 includes the peer's computer equipment, and different nodes of node 104 belong to different peers. Each blockchain node 104 includes processing equipment, including 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), and other equipment such as application-specific integrated circuits (ASICs). Each node also includes memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media or multiple non-temporary computer-readable media. Memory may include one or more memory units employing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives.

[0024] Blockchain 150 contains a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 of the decentralized or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean remembering the entire blockchain 150. Rather, blockchain 150 may be pruned, as long as each blockchain node 150 remembers the block header (considered below) of each block 151. Each block 151 in the chain contains one or more transactions 152, where a transaction refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 contains at least one input and at least one output. Each output specifies an amount representing the quantity of a digital asset as property, an example being user 103 whose output is cryptographically locked (requiring the user's signature or other solution to be unlocked and thereby performed or consumed). Each input points backward to the output of the preceding transaction 152, thereby linking the transactions.

[0025] Each block 151 also includes a block pointer 155 that points backward to a previously created block 151 in the chain, defining the order of occurrence up to block 151. Each transaction 152 (other than coinbase transactions) includes a pointer that goes back to the previous transaction, defining the order of the transaction sequence (note that the sequence of transactions 152 is allowed to branch). The chain of block 151 traces back to the genesis block (Gb) 153, which was the first block in the chain. One or more initial transactions 152 in the early stages of chain 150 pointed to the genesis block 153, rather than a preceding transaction.

[0026] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in the memory of each of those blockchain nodes 104. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. In this specification, this term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to an ordered set of transactions that a node 104 accepts as valid and that a node 104 is obligated not to accept any other transactions that attempt to consume the same output.

[0027] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output will be performed or "consumed" in the current transaction 152j. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. A preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, a preceding transaction 152i must exist and be acknowledged. Thus, "predecessor" as used herein refers to a predecessor in a logical sequence linked by pointers, and not necessarily to the time of creation or transmission in a temporal sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or sent out of order (see the discussion below regarding orphan transactions). A preceding transaction 152i may similarly be called an antecedent or predecessor transaction.

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

[0029] According to output-based transaction protocols like Bitcoin, when a party 103, such as an individual user or organization, wants to execute a new transaction 152j (either manually or through an automated process adopted by the party), the executer sends the new transaction from their computer terminal 102 to the recipient. The executer or recipient then sends this transaction to one or more blockchain nodes 104 on the network 106 (currently generally a server or data center, but in principle could be other user terminals). It is also not ruled out that the party 103 executing the new transaction 152j might send the transaction directly to one or more blockchain nodes 104 and, in some cases, not to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applicable to each blockchain node 104. The blockchain node protocol generally requires the blockchain node 104 to check that the cryptographic signature of the new transaction 152j matches the expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i allocated by the new transaction, which generally includes checking that the cryptographic signature or other authorization of the input of the new transaction 152j unlocks the output of transaction 152i before the input of the new transaction was linked. The condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, the conditions may be determined solely by the blockchain node protocol, or by a combination thereof. In any case, if the new transaction 152j is valid, blockchain node 104 forwards the new transaction 152j to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and therefore forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0030] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., consumed) is whether its output has already been validly fulfilled by the input of another onward transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to fulfill has not already been fulfilled by another transaction. Again, if invalid, transaction 152j is not propagated (unless flagged as invalid for warning and propagated) and is not recorded on blockchain 150. This prevents double spending, where the transactional party attempts to allocate the output of the same transaction more than once. Account-based models, on the other hand, prevent double spending by maintaining account balances. Again, since there is a defined order of transactions, account balances always have a single defined state.

[0031] In addition to approving transactions, blockchain node 104 further competes to become the node that first creates a block of transactions in a process usually called mining, supported by "proof of work". At blockchain node 104, the new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 recorded in blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transaction 152 from the ordered set 154 of transactions by attempting to solve a cryptographic puzzle. Generally, this involves searching for a "nonce" value such that the output of the hash satisfies a given condition when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed. For example, the given condition may be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one specific type of proof of work puzzle, and other types are not excluded. A property of hash functions is that they have an unpredictable output for their inputs. Therefore, this search can only be performed by brute force, and thus may consume a considerable amount of processing resources on each blockchain node 104 attempting to solve the puzzle.

[0032] The first blockchain node 104 to solve the puzzle announces this to the network 106 and provides the solution as proof that can then be easily checked by other blockchain nodes 104 on the network (given a hash solution, it is easy to check that it satisfies the conditions for the hash output). The first blockchain node 104 accepts the block and thus propagates it until a threshold consensus is reached among the other nodes enforcing the rules of the protocol. Then, the ordered set of transactions 154 is recorded as a new block 151 in blockchain 150 by each of the blockchain nodes 104. Also, a block pointer 155 that points backward to previously created blocks 151n-1 in the chain is assigned to the new block 151n. The significant amount of effort required to create the proof of work solution, for example in the form of a hash, signals the first node 104's intention to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously approved transaction, also known as double spending. Once created, block 151 is recognized and maintained at each of the blockchain nodes 104 of the blockchain network 106, and therefore cannot be modified. Furthermore, block pointers 155 assign an order of occurrence to block 151. Since transaction 152 is recorded in the ordered blocks of each blockchain node 104 of the network 106, this thus provides an immutable public ledger of transactions.

[0033] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of transactions 154 that have not yet been published at any given time, depending on when those blockchain nodes 104 began searching for the solution or the order in which the transactions were received. Whoever first solves each of those puzzles defines which transactions 152 will be included in the next new block 151n in what order, and the current pool of unpublished transactions 154 is updated. The blockchain nodes 104 then continue to compete to create a block from the newly defined ordered pool of unpublished transactions 154, and so on. There is also a protocol for resolving all possible "forks," which are points where two blockchain nodes 104 solve the puzzle of their respective blockchain nodes 104 within a very short time, so that opposing views of the blockchain propagate between the nodes 104. In short, the fork claw of whichever one is the longest becomes the final blockchain 150. Please note that this should not affect any network users or agents, as the same transaction will appear on both forks.

[0034] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to newly allocate an additional approved amount of digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to inter-agent or inter-user transactions that transfer a certain amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." This special type of transaction generally forms the first transaction of a new block 151n. Proof of work informs the node constructing the new block of its intention to follow the protocol rules that will allow this special transaction to be fulfilled later. The rules of the blockchain protocol may require a maturity period, for example, 100 blocks, before this special transaction may be allowed to be fulfilled. In many cases, a normal (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created block 151n in which the transaction was published. This fee is commonly referred to as the "transaction fee" and will be discussed below.

[0035] Due to the resources involved in transaction approval and publication, each blockchain node 104 generally takes the form of a server containing one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal, or a group of user terminals networked together.

[0036] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform one or more of its respective roles in accordance with the blockchain node protocol and to process transaction 152. It will be understood herein that all actions attributed to the blockchain node 104 may be performed by software running on the processing unit of each computer device. The node software may be implemented in one or more applications of the application layer, in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0037] Further connected to network 101 are the computer devices 102 of multiple stakeholders 103 acting as consumer users. These users may interact with the blockchain network 106 but do not participate in transaction approval or block construction. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with blockchain 150 without necessarily acting as senders or receivers. For example, some stakeholders may act as storage entities that store copies of blockchain 150 (e.g., copies obtained from blockchain node 104).

[0038] Some or all of the stakeholders 103 may be connected as part of a different network, for example, a network superimposed on top of the blockchain network 106. Users of the blockchain network (often referred to as “clients”) may be said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104, as they do not perform the required role of a blockchain node. Instead, each stakeholder 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain nodes 106. For illustrative purposes, two stakeholders 103 and their respective devices 102 are shown, namely, the first stakeholder 103a and its respective computer device 102a, and the second stakeholder 103b and its respective computer device 102b. Many further such stakeholders 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience, they are not illustrated. Each stakeholder 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a will be referred to herein as Alice, and the second party 103b as Bob, but this is not limited to, and it will be understood that all references herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0039] Each of the parties 103's computer equipment 102 includes one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each of the parties 103's computer equipment 102 further includes memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media or multiple non-temporary computer-readable media. This memory may include one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each of the parties 103's computer equipment 102 stores software, each including at least one instance of a client application 105 arranged to run on the processing unit. It will be understood that all actions attributed to a given party 103 in this specification may be performed using software running on the processing unit of each of the parties 102. Each party 103's computer equipment 102 includes at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device such as a smartwatch. A given party 103's computer equipment 102 may also include one or more other networked resources, such as cloud computing resources, accessed via the user terminal.

[0040] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on one or more suitable computer-readable storage media, for example, by downloading from a server or by providing on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0041] The client application 105 includes at least a “wallet” function, which has two main functions. One of these is to enable each party 103 to create, authorize (e.g., sign) a transaction 152, which is then propagated throughout the network of blockchain nodes 104 and sent to one or more Bitcoin nodes 104 so that it may be included in blockchain 150. The other is to return to each party a report of the amount of digital assets they currently own. In an output-based system, this second function includes matching the defined amounts in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0042] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client function described herein may instead be implemented in a suite of two or more different applications, for example, by interface via an API, or one of which is a plug-in to the others. More broadly, client functions may be implemented in the application layer, or in lower layers such as the operating system, or any combination thereof. The following description will be from the perspective of client application 105, but it will be understood that this is not limiting.

[0043] Each computer device 102 has an instance of a client application or software 105 that is coupled to at least one of the blockchain nodes 104 of the network 106 so that it can operate. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact blockchain node 104 to query blockchain 150, which is the recipient of any transaction by each party 103 (or, in embodiments, blockchain 150 is a public facility that provides partial trust in transactions by its public visibility, so as to ensure that transactions of other parties within blockchain 150 are verified). The wallet function of each computer device 102 is configured to assemble and send transaction 152 according to the transaction protocol. As described above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate it throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0044] When a given party 103, for example Alice, wants to send a new transaction 152j so that it can be included in blockchain 150, she constructs the new transaction according to the relevant transaction protocol (using the wallet function of her client application 105). Then, party 103 sends transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes the new transaction 152j according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be examined in more detail shortly. In some transaction protocols, the conditions for approval may be configurable on a per-transaction basis by a script included in transaction 152. Alternatively, the conditions may simply be built-in features of the node protocol or defined by a combination of the script and the node protocol.

[0045] Subject to the test that a newly received transaction 152j passes to be considered valid (i.e., subject to the condition that a newly received transaction 152j is "approved"), all blockchain nodes 104 that receive transaction 152j add the new approved transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Furthermore, all blockchain nodes 104 that receive transaction 152j propagate the approved transaction 152 to one or more other blockchain nodes 104 in network 106. Since each blockchain node 104 applies the same protocol, assuming that transaction 152j is valid, this means that transaction 152j is immediately propagated throughout network 106.

[0046] When a pending transaction is placed in an ordered pool 154 maintained at a given blockchain node 104, that blockchain node 104 begins a competition to solve a proof-of-work puzzle about the latest version of each of those pools 154 containing the new transaction 152 (other blockchain nodes 104 may be attempting to solve puzzles based on different pools 154 of transactions, but it should be noted that whoever succeeds first defines the set of transactions included in the latest block 151. Ultimately, blockchain node 104 solves the puzzle about the portion of the ordered pool 154 containing Alice's transaction 152j). Once proof-of-work is performed for the pool 154 containing the new transaction 152j, the pool 154 immutably becomes part of one of the blocks 151 of blockchain 150. Each transaction 152 contains a pointer back to a previous transaction, and therefore the order of transactions is also immutably recorded.

[0047] Different blockchain nodes 104 initially receive different instances of a given transaction and therefore may have conflicting views on which instance is "valid" before one instance is published in the new block 151. Once one instance is published in the new block 151, all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in blockchain 150, that blockchain node 104 must accept this and discard (i.e., treat as invalid) the instance that it initially accepted (i.e., the instance that was not published in block 151).

[0048] An alternative type of transaction protocol operated by some blockchain networks is sometimes referred to as an “account-based” protocol, as part of an account-based transaction model. In an account-based protocol, each transaction defines the amount to be sent by referencing the absolute balance of the account, rather than by backward referencing the UTXOs of preceding transactions in a sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes of that network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called a “position”) of the account. This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of a transaction reference calculation. Additionally, an arbitrary data field may be assigned to the transaction. This data field may, for example, backward point to the previous transaction if the previous transaction ID is included in the data field.

[0049] 2. UTXO-based models Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to output-based or "UTXO"-based protocols. However, this is not limited to all possible embodiments. Note that while the exemplary UTXO-based protocol is described in relation to Bitcoin, it may be similarly implemented in other exemplary blockchain networks.

[0050] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure containing one or more inputs 202 and one or more outputs 203. Each output 203 may contain an unused transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been fulfilled). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which the UTXO originates. The transaction data structure may also include a header 201 which may contain an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an 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 raw transaction 152 submitted to node 104.

[0051] Suppose Alice103a wants to create transaction 152j to send the amount of the digital asset in question to Bob103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". Transaction 152j retrieves the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence and sends at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction on blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could retrospectively point to any preceding (i.e., ancestor) transaction that still holds the unused output 203 locked in Alice.

[0052] The preceding transaction Tx0 may have already been confirmed and included in block 151 of blockchain 150 when Alice creates her new transaction Tx1, or at least by the time Alice sends that new transaction Tx1 to network 106. The preceding transaction Tx0 may then have already been included in one of the blocks 151, or it may still be waiting in the ordered set 154, in which case the preceding transaction Tx0 will be immediately included in the new block 151. Alternatively, Tx0 and Tx1 may be created together and sent to network 106, or if the node protocol allows buffering of “orphan” transactions, Tx0 may even be sent after Tx1. The terms “preceding” and “successor” as used herein in the context of transaction sequences refer to the order of transactions in a sequence defined by the transaction pointers specified in the transaction (e.g., which transaction points backward to which other transaction). Those terms may be equally replaced by “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which those transactions are created, sent to network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be confirmed until the parent transaction is confirmed, and will not be confirmed until the parent transaction is confirmed. A child that arrives at blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or the behavior of the node, that child may be discarded or buffered for a certain time to wait for its parent.

[0053] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, here labeled UTXO0. Each UTXO contains a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining the conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be approved and therefore the UTXO to be successfully executed. Generally, a lock script locks the amount to a specific party (the beneficiary of the transaction containing that lock script). That is, generally, a lock script defines unlock conditions that include the condition that the unlock script in the subsequent transaction's input contains the cryptographic signature of the party to whom the preceding transaction is locked.

[0054] A lock 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 "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to consume transaction output 203, for example, the need for Alice's signature. The unlock script appears in the input of the transaction. The unlock script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the lock script. For example, the unlock script might include Bob's signature. The unlock script appears in the input of the transaction 202.

[0055] Therefore, in the illustrated example, the UTXO0 of output 203 of Tx0 is signed by Alice Sig P for the UTXO0 to be fulfilled (more precisely, for subsequent transactions attempting to fulfill the UTXO0 to be valid). A Lock script that requires [Checksig P A ] includes. [Checksig P A] is the public key P from Alice's public-private key pair. A The input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points backward to Tx1 (for example, by its transaction ID, TxID0, which in this embodiment is a hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 among any other possible outputs of Tx0. The input 202 of Tx1 includes an unlock script containing Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predefined portion of the data (sometimes called a "message" in cryptographic terms). <Sig P A >Furthermore, data (or "messages") that need to be signed by Alice to provide a valid signature may be defined by the lock script, the node protocol, or a combination thereof.

[0056] When a new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol. This involves executing the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (these conditions may include one or more criteria). In embodiments, this involves concatenating the two scripts, i.e., <Sig P A > <P A > || [Checksig P A ] The string includes, where "||" represents concatenation, "<...>" means placing data on the stack, and "[...]" is a function included by the lock script (in this example, a stack-based language). Equivalently, the scripts may be executed sequentially using a common stack rather than concatenating them. In any case, when executed together, the scripts include Alice's public key P, which is included in the lock script of the output of Tx0.A Use A to authenticate that the unlock script for the input of Tx1 contains Alice's signature that signs the expected part of the data. The expected part of the data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (thus, a separate element specifying the signed part of the plaintext data need not be included as it already essentially exists).

[0057] Details of authentication by public - private cryptography will be well known to those skilled in the art. Basically, when Alice signs a message using her private key, given Alice's public key and the plaintext message, another entity such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature to the message, thus enabling all holders of the public key to authenticate the signature. It should be noted that all references herein to signing something such as a particular data or part of a transaction may, in an embodiment, mean signing the hash of that data or part of the transaction.

[0058] Blockchain node 104 considers Tx1 valid if the unlock script for Tx1 satisfies one or more conditions specified in the lock script for Tx0 (i.e., in the example shown, Alice's signature is provided and authenticated in Tx1). This means that blockchain node 104 adds Tx1 to the ordered pool 154 of pending transactions. Blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in network 106 so that transaction Tx1 is propagated throughout network 106. Once Tx1 is accepted and included in blockchain 150, this defines the UTXO0 from Tx0 as used. Note that Tx1 can only be valid if it consumes unused transaction output 203. If Tx1 attempts to consume output that has already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO of the preceding transaction Tx0 has already been consumed (i.e., whether that UTXO has already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to assign a defined order to transaction 152. In practice, a given blockchain node 104 may maintain a separate database showing which UTXO 203 of which transaction 152 has been consumed, but ultimately, what defines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction within blockchain 150.

[0059] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all inputs 202 of that transaction 152, this is another ground for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not included in block 151.

[0060] In a UTXO-based transaction model, it should be noted that a given UTXO must be consumed entirely. A given UTXO cannot have a portion of its value, defined as used, consumed while other portions are "left behind." However, the amount from a UTXO can be divided among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be divided among multiple UTXOs in Tx1. Therefore, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change or make a payment to another party in the second output of Tx1.

[0061] In practice, Alice would typically also need to include a fee to the Bitcoin node 104 that successfully includes her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and therefore, strictly speaking, valid but not propagated and not included in blockchain 150 (the node protocol does not force blockchain node 104 to accept transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, all the difference between the total amount pointed to by the input 202 of a given transaction 152 and the total amount specified in the output 203 is automatically given to the blockchain node 104 publishing that transaction. For example, suppose a pointer to UTXO0 is the sole input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by node 104, which wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily ruled out that, alternatively or additionally, a transaction fee may be explicitly specified in its own UTXO203 within transaction 152's UTXO203.

[0062] Alice and Bob's digital assets consist of UTXOs locked to Alice and Bob in any transaction 152 at any location on blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout blockchain 150. Nowhere on blockchain 150 is there a single number that defines the total balance of a given party 103. It is the role of the wallet function within the client application 105 to match the values ​​of all the various UTXOs locked to each party that have not yet been consumed in another onward transaction. The wallet function can do this by querying a copy of blockchain 150 stored on one of the Bitcoin nodes 104.

[0063] It should be noted that script code is often expressed in general terms (i.e., without using the exact language). For example, operation codes (opcodes) may be used to express specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of the lock script, allows data to be stored within the transaction, thereby creating an immutable output of the transaction that can record the data immutably on blockchain 150. For example, the data may include documents that are desired to be stored on the blockchain.

[0064] Generally, the input to a transaction is the public key P AThis includes a corresponding digital signature. In embodiments, this is based on ECDSA using elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, with respect to a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the output that the signature signs are determined by the SIGHASH flag. The SIGHASH flag is a 4-byte code that is typically included at the end of the signature (and therefore determined at the time of signing) to select which outputs are signed.

[0065] A lock script is sometimes called a “scriptPubKey,” generally indicating that it contains the public keys of the parties involved in the locking of each transaction. An unlock script is sometimes called a “scriptSig,” generally indicating that it supplies the corresponding signature. However, more broadly, it is not mandatory in all applications of blockchain that the condition for a UTXO to be fulfilled includes authenticating a signature. More broadly, a scripting language may be used to define any one or more conditions. Thus, the broader terms “lock script” and “unlock script” may be preferred.

[0066] 3. Side Channel As shown in Figure 1, the respective client applications for Alice and Bob's computer devices 102a and 102b may each include additional communication capabilities. This additional capability allows Alice 103a to establish a separate side channel 107 with Bob 103b (at the suggestion of either party or a third party). The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication is sometimes called “off-chain” communication. For example, this may be used to exchange transaction 152 between Alice and Bob when the transaction has not yet been registered on the blockchain network 106 or has not progressed toward chain 150 until one of the parties chooses to broadcast transaction 152 to network 106. Sharing a transaction in this manner is sometimes called sharing a “transaction template.” A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, or data content.

[0067] The side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 107 may be established via a different network, such as a mobile cellular network, a local area network such as a local wireless network, or even a direct wired or wireless link between Alice and Bob's devices 102a, 102b. In general, any side channel 107 referred to herein may also include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain," i.e., separately from the blockchain network 106. If two or more links are used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 107. Therefore, it should be noted that when it is said that Alice and Bob exchange certain information or data etc. via the side channel 107, this does not necessarily imply that all of this data must be transmitted over the exact same link or even the same type of network.

[0068] 4. Client Software Figure 3A shows an exemplary implementation of a client application 105 for carrying out an embodiment of the scheme now disclosed. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functions of the client 105, such as assembling a transaction 152, receiving and / or transmitting transactions and / or other data via a side channel 107, and / or sending transactions to one or more nodes 104 to propagate through the blockchain network 106, in accordance with the scheme discussed above and as will be discussed in more detail shortly.

[0069] The UI layer 402 is configured to provide a user interface via the user input / output (I / O) means of each user's computer device 102, including outputting information to each user 103 via the user output means of the device 102 and receiving input returned from each user 103 via the user input means of the device 102. For example, the user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing audio output, and / or one or more haptic output devices for providing haptic output. The user input means may include, for example, one or more touchscreens (same or different as those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and voice or voice recognition algorithms for receiving speech or vocal input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more input arrays such as mechanical buttons, switches, or joysticks.

[0070] Note: While various functions in this specification may be described as being integrated into the same client application 105, this is not necessarily limiting. Instead, those functions may be implemented in a suite of two or more different applications, one of which may be a plugin for the other, or interfaced via an API (Application Programming Interface). For example, the functions of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functions of a given module such as the transaction engine 401 may be separated between two or more applications. It is not excluded that some or all of the functions described may be implemented in the operating system layer, for example. Wherever a single or given application 105 is referenced anywhere in this specification, this is merely illustrative, and it should be understood that more broadly, the functions described may be implemented in any form of software.

[0071] Figure 3B provides a mockup of an example of a user interface (UI) 500 that may be rendered by the UI layer 402 of the client application 105a for Alice's device 102a. It will be understood that a similar UI may be rendered by the client 105b of Bob's device 102b, or by a client of any other party's device.

[0072] As an example, Figure 3B shows UI500 from Alice's perspective. UI500 may include one or more UI elements 501, 502, 502 which are rendered as different UI elements via a user output means.

[0073] For example, the UI elements may include one or more user-selectable elements 501, which may be buttons on different screens or different options in a menu. User input means are arranged to allow user 103 (in this case, Alice 103a) to select one of the options or otherwise interact with it, such as by clicking or touching the UI elements on the screen or by saying the name of the desired option (note that the term “manual” as used herein is intended only in contrast to “automatic” and is not necessarily limited to the use of one or more hands).

[0074] Alternatively or additionally, the UI element may include one or more data input fields 502. These data input fields may be rendered on a screen, for example, via user output means, and data may be entered into the fields via user input means, for example, a keyboard or touchscreen. Alternatively, data may be received orally, for example, based on speech recognition.

[0075] Alternatively or additionally, a UI element may include one or more information elements 503 outputs for outputting information to the user. For example, these may be rendered on the screen or audibly.

[0076] It will be understood that the specific means of rendering various UI elements, selecting options, and entering data are not important. The functionality of these UI elements will be examined in more detail shortly. It will also be understood that UI500 shown in Figure 3 is merely a diagrammatic mockup and may actually include one or more additional UI elements that are not shown for the sake of brevity.

[0077] 5. Node Software Figure 4 shows an example of node software 450 running on each blockchain node 104 of network 106 in an example of a UTXO or output-based model. Note that another entity may run node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required of a node 104. Node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software including, but is not limited to, all three: a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 451 is typically configured to recognize different fields of transaction 152 and process those fields according to the node protocol. Another preceding transaction 152i (Tx m-1 Transaction 152j(Tx) has an input that points to the output (e.g., UTXO) of ) j When ) is received, protocol engine 451 will j Identify the unlock script and pass it to script engine 452. Also, protocol engine 451 processes Tx j Based on the input pointer, Tx i Identify and extract. Tx i It may be publicly available on blockchain 150, in which case the protocol engine will take the transaction from a copy of block 151 of blockchain 150 stored on node 104. i You may extract Tx. Alternatively, i It may not yet be publicly available on blockchain 150. In that case, the protocol engine 451 will retrieve the Tx from an ordered set of unpublished transactions 154 maintained by node 104. iYou may extract it. In any case, protocol engine 451 will Tx i Identify the lock script in the referenced output and pass it to script engine 452.

[0078] Therefore, script engine 452 is Tx i The lock script and Tx j It has a lock-unlocking script from the corresponding input. For example, transactions labeled Tx0 and Tx1 are shown in Figure 2, but the same could be true for any pair of transactions. The script engine 452 executes the two scripts together as already discussed, which involves putting data into the stack 453 and taking data out of the stack 453, according to the stack-based scripting language being used (e.g., Script).

[0079] By executing the scripts together, the script engine 452 determines whether the unlock script satisfies one or more criteria defined in the lock script—that is, whether the unlock script "unlocks" the output containing the lock script. The script engine 452 returns the result of this determination to the protocol engine 451. If the script engine 452 determines that the unlock script satisfies one or more criteria specified in the corresponding lock script, it returns the result "true." Otherwise, the script engine 452 returns the result "false."

[0080] In output-based models, the result "true" from script engine 452 is one of the conditions for transaction validity. Generally speaking, Tx j In the output, the total value of the specified digital assets is Tx j The total amount indicated by the input must not exceed the Tx iThere are also one or more further protocol-level conditions, which must be satisfied and are evaluated by the protocol engine 451, such as that the indicated output has not already been consumed by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and only if they are all true does transaction Tx proceed. j The transaction is approved. The protocol engine 451 outputs an indication to the application-level decision engine 454 indicating whether the transaction is valid. j Only on the condition that it is certainly approved, the decision engine 454 controls both the consensus module 455C and the propagation module 455P, Tx j You may choose to perform each of those blockchain-related functions. This means that the consensus module 455C will input Tx into each ordered set 154 of the transaction nodes for incorporation into block 151. j Adding the propagation module 455P, Tx j This includes transferring the transaction to another blockchain node 104 on network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and leaves sufficient transaction fees.

[0081] The terms “true” and “false” as used herein are not necessarily limited to returning a result represented solely in the form of a single binary digit (bit), although this is certainly one possible implementation. More broadly, “true” can refer to any state indicating a successful or positive outcome, and “false” can refer to any state indicating a failed or unpositive outcome. For example, in an account-based model, a “true” result might be indicated by a combination of implicit protocol-level approval of the signature and an additional positive output from the smart contract (the overall result is considered to indicate true if both individual results are true).

[0082] 6. Enforcing conditions on blockchain transactions Embodiments of this disclosure enable one transaction to enforce (i.e., impose) a condition on another transaction. The transaction enforcing the condition is referred to as the “first transaction,” and the transaction to which the condition is applied is referred to as the “second transaction.” The condition is enforced in such a way that the second transaction will not be successfully validated by blockchain node 104 during transaction validation unless the condition is met. Figure 5 shows an exemplary system for implementing the embodiment. As shown, the system includes a first party configured to generate the first transaction, a second party configured to generate the second transaction, and one or more blockchain nodes of blockchain network 106. For convenience, the first party is referred to as Alice 103a, and the second party as Bob 103b. Generally, both the first and second parties may be configured to perform any of the actions described above as being performed by Alice 103a and / or Bob 103b. The system may include other entities (not shown), such as additional users.

[0083] As stated, Alice103a is configured to generate a first transaction. The first transaction contains a first output. The first output does not necessarily have to be the first logically appearing item in the list of outputs of the first transaction, but it is one possibility. The first output contains a lock script, which is referred to as the "first lock script". The first lock script is configured to enforce one or more conditions on all transactions attempting to unlock the first output, which in this exemplary scenario is the second transaction. At least one of those conditions is that a representation of the second transaction is printed into memory while the second transaction is executing (e.g., accepting). That is, the first transaction (and in particular the first lock script of the first transaction) has the effect of ensuring that a representation of the second transaction is printed into memory when the second transaction's unlock script is executed together with the first lock script. For convenience, the unlock script of the second transaction, which runs alongside the first lock script of the first transaction, is referred to as the "first unlock script" included in the first input of the second transaction. The first input does not necessarily have to be the first logically occurring input in the list of inputs for the second transaction, but it is one possibility.

[0084] The representation of the second transaction may differ depending on the specific blockchain on which the transaction is part. Generally, the representation of the second transaction is based on multiple fields of the second transaction and the first output of the first transaction. In other words, the representation of the current transaction is based on both the current transaction and the output of the previous transaction that has been unlocked, i.e., consumed, allocated, sent, etc. Outputting the representation of the second transaction to memory allows checks to be performed on some or all of the second transaction, and therefore further conditions may be enforced, for example, by checking that those conditions are met and failing to execute the transaction if those conditions are not met.

[0085] The first lock script includes subscripts that are configured together to ensure that the representation output to memory is indeed an accurate representation of the second transaction.

[0086] The first of the subscripts is called the “message subscript.” The message subscript may appear logically first within the first lock script, or there may be other subscripts included in the first lock script that appear before the first lock script. The message subscript is configured to output a candidate message into memory. The candidate message is based not only on the “candidate first output” of the first transaction, but also on several “candidate fields” of the second transaction. The candidate message is “candidate” in the sense that, at the time it is output into memory, it is not yet known (or at least not yet verified within the script) that the candidate message was constructed based on the actual fields of the second transaction and the actual first output of the first transaction. The candidate fields and the candidate first output are candidates in a similar sense, that is, it is not known whether they are correct until they are verified within the script.

[0087] At least some of the candidate fields are included in the first unlock script of the second transaction. Each candidate field may be a separate data item, or a data item may contain two or more candidate fields. Some or all of the candidate's first output (e.g., the value assigned to the first output, the first lock script for the first output, the length of the first lock script for the first output) may also be included in the first unlock script. In some embodiments, one or more of the candidate fields of the second transaction may be included in the first lock script of the first transaction. As discussed below, all candidate fields on which a candidate message is based, included in the first lock script, must necessarily be included in the second transaction. Thus, the condition that the second transaction must include those candidate fields may be enforced. As an example, the first lock script may determine the lock time of the second transaction by including the candidate lock time on which the candidate message is based. Optionally, some (but not all) of the candidate's first output may be included in the first output of the first transaction.

[0088] A message subscript is configured to construct part or all of a candidate message. For example, a message subscript may combine (e.g., concatenate) one or more data items contained in a first lock script and / or first unlock script, each data item containing one or more candidate fields and / or part of the candidate's first output. More specifically, a message subscript is configured to construct part of a candidate message based on one or more candidate fields and reuse at least some of those one or more candidate fields as different parts of the candidate message. For example, one or more candidate fields may be duplicated and used to construct part of a candidate message, and then used as different parts of a message (or used to construct different parts of a message). As an example, a set of candidate fields (e.g., candidate output values ​​and candidate lock scripts) may be used as part of a candidate message representing the previous output of a candidate for a second transaction (i.e., the first output of the first transaction) and reused as a candidate output for the second transaction. In this example, the candidate message may contain a candidate hash of the output of the second transaction, and therefore the message subscript may hash a reused set of candidate fields. The message subscript may be configured to reuse a single set of candidate fields or multiple sets of candidate fields, depending on the format of the message.

[0089] The first lock script also includes a signature subscript configured to generate a signature based on a candidate message. The signature is generated based on a private key and a temporary private key, both of which are determined by the first lock script (for example, included as part of the first lock script). The signature may be an ECDSA signature. Note that the private key and temporary private key do not necessarily have to be included in the first lock script, as they are "determined" by the first lock script. For example, the first lock script may include a value based on the private key and / or temporary private key, and that value thus determines the private key and / or temporary private key. The temporary private key may be any number, preferably a small number. For example, the temporary private key may be determined to be equal to 1. This provides a significant space saving compared to a normal temporary private key, which is usually a 256-bit integer. In addition, the private key, which may generally be any number, may also be determined to be equal to 1, thus providing further space savings (private keys are also usually 256-bit integers). As an alternative to both the private key and the temporary private key being determined to be equal to 1, they may be determined to be equal to each other, for example, both taking the value 2 or another small number. Since the same value is used for both keys, the signature generation process is simplified.

[0090] The first lock script also includes a verification subscript. The verification subscript is configured to construct a target message representing the second transaction. The target message is based on several fields of the second transaction. The target message is based on the actual fields of the second transaction, i.e., actual fields obtained from or generated based on the second transaction. The target message is based on the same set of fields of the second transaction as the candidate message. For example, the candidate message and the target message may be based on one or more inputs of the second transaction. The target message is also based on the actual first output of the first transaction, i.e., the actual first output obtained from the first transaction itself.

[0091] The verification subscript is also configured to verify that the signature generated by the signing subscript is a valid signature of the target message. The signature is authenticated using a public key corresponding to a private key. The public key is included, for example, in the first lock script as part of the verification subscript. If the signature (generated based on the candidate message) is a valid signature of the target message, then the candidate message and the target message are the same message, and therefore the candidate message is based on the actual fields of the second transaction and the actual first output of the first transaction. Thus, the candidate message printed into memory by the message subscript is a representation of the second transaction, and the condition that a representation of the second transaction is printed into memory during script execution is met. Conversely, if the signature verification fails, the candidate message is not the same as the target message and therefore is not the required representation of the second transaction.

[0092] In summary, Alice103a creates a transaction with a lock script, and for the lock script to be released, a representation of the transaction to be consumed during execution must be printed into memory (e.g., the stack). In an example where memory is stack-based, a verification subscript may include the OP_CHECKSIG or OP_CHECKSIGVERIFY opcode, which is configured to verify that the signature is valid for the target message. OP_CHECKSIG prints 1 or 0 to the stack depending on whether the signature is valid (1) or invalid (0). 0 indicates that the signature is invalid. OP_CHECKSIGVERIFY consumes the output and fails execution if it is 0.

[0093] For the second transaction to be valid, it is understood that the target message constructed by the validation subscript must then match the candidate message constructed by the message subscript. Therefore, if the set of candidate fields reused to construct different parts of the candidate message (or as different parts of the candidate message) are fields of the first transaction, they must also be fields of the second transaction. This is because the target message is based on the actual fields of the second transaction. Thus, this disclosure may be used to ensure that parts of the first transaction (e.g., lock scripts, values, outputs, etc.) also appear as the same parts of the second transaction. In other words, parts of the second transaction must be the same as parts of the first transaction. Generally, one or more parts of the second transaction may be compelled to be the same as one or more parts of the first transaction.

[0094] As mentioned above, the signature may include an ECDSA signature. A person skilled in the art will be familiar with ECDSA signatures themselves. The signature is s = k -1The expression may take the form (z + ra) mod n, where k is the temporary private key, a is the private key, z is the hash of the candidate message, n is the integer order of the elliptic curve generator point G, and r is the modulo n of the x-coordinate of the temporary public key. As mentioned above, the temporary private key k may be set to 1 to optimize signature generation. To further optimize signature generation, the private key a may also be set to 1.

[0095] Setting both the private key and the temporary private key to 1 means that the signature is s = z + G x It makes it possible to take the form mod n, G x is the x-coordinate of the generator G of the elliptic curve. This has the effect that G is both a temporary private key and a private key. The first lock script (e.g., a signature subscript) is G x The system may include the values ​​of n and n respectively, and may be configured to generate a signature based on those values.

[0096] In some cases, the signature subscript is G x And the value of n may be configured to be used more than once. In the example where memory is stack-based, G x And instead of including n multiple times in the first lock script, to save space, the first lock script (e.g., the signature subscript) is G x The value of n is output to an alternate stack (i.e., a stack other than the main stack where the first lock script is initially placed), and G is retrieved from the alternate stack when needed. x And it may be configured to extract the value of n.

[0097] When both the private key and the temporary private key are determined to have the same value, the savings occur even if that value is not 1. This is because, when the signature takes the form of an ECDSA signature or an equivalent scheme, the signature is calculated based on the reciprocal of the temporary private key and the private key. Therefore, determining both keys to have the same value has the effect of canceling out the multiplication, thus removing two mathematical operations from the process. Thus, the calculation of the signature in the script is simplified. Furthermore, the savings by "a=k" result in a compressed public key G x This is also due to the fact that r is the same as the signature r, and therefore the same value can be used twice (for example, by utilizing the alt stack as discussed below).

[0098] Depending on the specific blockchain protocol of blockchain network 106, the signature generated by the signature subscript may require further processing, for example, to be verified by a verification subscript. For example, the verification subscript may include a signature verification function (e.g., an opcode) that requires the signature to be in a specific format. For example, the signature may need to be formatted according to distinguishing encoding rules (DER). In these examples, the first lock script may include a DER subscript configured to convert the signature generated by the signature subscript into a DER-formatted signature. The DER subscript may be part of the signature subscript. The verification subscript may be configured to verify the DER-formatted signature using a public key (which may be the origin G in some examples, as mentioned above).

[0099] In some examples, the signature subscript may include signature flags, and the signature subscript may be configured to associate (e.g., concatenate) the generated signature and signature flags. Signature flags are sometimes referred to as "sighash flags" in the art. Signature flags indicate which parts of a transaction are signed by the signature. For example, signature flags may indicate that only certain inputs and / or outputs are signed by the signature, or that the entire transaction is signed by the signature. In these examples, the verification subscript is configured to construct a target message based on the signature flags. That is, the verification subscript is configured to construct a target message based on a specific part of a second transaction, depending on the signature flags included in the signature subscript. For a signature to be considered valid by the signature subscript, candidate fields included in the first unlock script (and optionally the first lock script) of the second transaction must yield a candidate message that matches the target message. In other words, the candidate message must be based on the same part of the second transaction as the target message, indicated by the signature flags.

[0100] For example, the signature flag may indicate that the target message should be based on each input and each output of the second transaction. In this case, the signature flag (e.g., the sighash flag) may be ALL. In another example, the signature flag may indicate that the target message should be based only on the inputs of the second transaction, which contain the first unlock script, and the corresponding outputs of the second transaction. In this case, the signature flag (e.g., the sighash flag) may be SINGLE|ANYONECANPAY.

[0101] The table below provides an exemplary format for candidate (and target) messages. Candidate (and target) messages may be a concatenation of the items in the table. Items may appear in order based on their corresponding numbers in the table; for example, a candidate (and target) message may begin with a version number and end with a sighash flag. Note that this is merely an example and is not intended to be restrictive to all examples. For example, items may be concatenated in a different order, or a candidate (and target) message may include some of the items below, but not all of them.

[0102] [Table 1]

[0103] In this example, the “previous” lock script refers to the first lock script of the first transaction. All other items are either taken from or based on the second transaction itself. The table also indicates whether an item may be determined in the first lock script. For example, the previous (i.e., first) lock script cannot be determined in the first lock script itself. The first lock script may contain any of the above items that can be determined in a lock script. Note that some data items are fields of the first or second transaction (for example, “lock time” is a field of the second transaction), while some data items are based on one or more fields of the first or second transaction (for example, “output hash” is based on the output of the second transaction, where each output is a field of the second transaction).

[0104] As discussed above, the first lock script is configured to construct a portion of a candidate message (for example, one of the items in the table above) based on one or more candidate fields included in the first unlock script of the second transaction. That is, the first unlock script may include a set of candidate fields, and the first lock script may process that set of candidate fields to generate a portion of a candidate message (this may include one or more of the following: combination, concatenation, or hashing). For example, the first unlock script of the second transaction may include a data item representing the candidate output of the second transaction as a candidate field, and the first lock script of the first transaction may use the candidate output as items 5, 6, and 7 in the table above (representing the first output of the first transaction) and item 9 in the table above (representing the hash of the output of the second transaction). To do this, the first lock script (or rather, message subscript) might combine items 5, 6, and 7, hash them, and generate item 9. This enforces the condition that the first output of the first transaction is exactly the same as the output of the second transaction.

[0105] It should be noted that this applies broadly to any part of a candidate message that may be based on the same set of fields. For example, a message subscript may be configured to reuse a candidate lock script as the previous lock script (item 7) and generate an output hash (item 9) without reusing the candidate value of the previous lock script. This enforces the condition that the second transaction must contain an output containing the first lock script of the first transaction, but the value of the output can be freely chosen (within the rules of the blockchain protocol).

[0106] 7. Exemplary Implementation The following describes an exemplary implementation of the embodiment described.

[0107] 7.1 Generating Signatures within Scripts One function of the first lock script of the first transaction is to generate a signature for a given message m. The script segment below is part of the first lock script, and the input data can either be in the unlock script of a future transaction or hardcoded into the first lock script. [sign]:= OP_HASH256 k -1 OP_MUL k -1 ra OP_ADD n OP_MOD r [toDER] SIGHASH_FLAG OP_SWAP OP_CAT Input data: m

[0108] The script segment [sign] (referred to above as the "signature subscript"), as part of the lock script, may determine both the temporary key k and the private key a. Anyone can use [sign] to generate a valid signature, but the focus is on the input m. The requirement is that for any given consuming transaction, there exists only one value for m that can pass OP_CHECKSIG. If the private or public key cannot be determined, the transaction becomes insecure. Further details can also be found in Section 8. If the temporary key k cannot be determined, anyone can use different ks to create a valid transaction with different transaction IDs, which is undesirable in some use cases.

[0109] The value of s in the signature is s = k -1 It may be calculated as (z + ra) mod n. Since signatures are not used for authenticity, the private key a and the temporary key k can be freely chosen and made public. In this relaxed case, k -1 Mod n and k -1By pre-calculating ra mod n and including them in the lock script, signature generation can be significantly lighter. Furthermore, small values ​​such as 1 can be chosen for k and a, and they can be the same every time. If k = a = 1, then s = z + G x modulo n, G x This is the x-coordinate of the source G. The compressed public key is also G x The definition of [sign] can be rewritten as follows: [sign]:= OP_HASH256 G x OP_ADD n OP_MOD G x [toDER] SIGHASH_FLAG OP_SWAP OP_CAT

[0110] The script segment [toDER] will convert the pair (r, s) into a prescriptive DER format that is accepted by OP_CHECKSIG. It enforces that s must be within the range of 0 to n / 2 to avoid malleability of the transaction ID.

[0111] Note that the SIGHASH_FLAG in [sign] is used to specify which parts of the transaction to be consumed should be pushed onto the stack. The ALL flag requests that all inputs and outputs be included in message m, while SINGLE|ANYONECANPAY requests that the inputs and their corresponding outputs corresponding to this lock script be included in m.

[0112] After executing the script segment OP_DUP [sign] < PK > on input m, the stack from bottom to top looks like [m, Sig, PK]. The call to OP_CEHCKSIGVERIFY consumes the signature and public key, leaving m at the top of the stack. If the verification is successful, we can be confident that the message m left on the stack is an exact representation of the transaction being consumed.

[0113] 7.2 Constructing messages within a script A signed message in its serialized format is different from a serialized transaction. The latter publishes all information about the transaction, whereas a signed message unintentionally hides some information about the transaction in a hash value and provides some information about the output being consumed, namely the value of that output and the lock script for that output. Message m cannot be fully embedded in the lock script because it contains the lock script itself and some unknown information about future transactions to be consumed. Only some of the fields, such as version, sequence number, and lock time, can be explicitly enforced in the lock script. Message m is either provided in its entirety in the unlock script, or it is constructed in the script using some inputs from the unlock script and instructions from the lock script. The latter is more restrictive from the perspective of the transactions to be consumed, so we will focus on the latter. The table in Section 6 above captures all the data fields of a message and whether they should or can be determined in the lock script.

[0114] Hereafter, the data fields in the table will be referred to as Item 1, 2, 3, etc. When it is optional to include an item in a lock script, whether that item is provided in a lock or unlock script depends on the use case. The principle is that if data is available or known at the time the lock script is created, that data can be included in the lock script. Another point to consider is the size of the transaction and the transactions it consumes. By shifting data between the lock script and the unlock script, it is possible to shift a portion of the transaction fee cost between the senders of the two transactions.

[0115] When we say that execution is impossible due to a circular reference, note that granularity is set in the data field. For example, a partial lock script or even a partial transaction ID (e.g., fixing the first two bytes and allowing iteration in the nonce field) may be determined in the lock script as needed.

[0116] The focus is on constructing message m, but the goal is to use m to coerce values ​​for different fields in the current transaction. To coerce a hash value, i.e., the data behind item 9, the lock script should be designed to request the protoimage, hash it within the script, and then construct a message that will be signed within the script. Taking item 9 as an example, to coerce the output in the current transaction, we could do the following: [outputsRequest]:= OP_DUP OP_HASH256 OP_ROT OP_SWAP OP_CAT <items 10 and 11> OP_CAT Input data: <Items 1 to 8> <Serialized output of the current transaction>

[0117] The script segment [outputsRequest] (which may be part of the "message subscript") takes items 1 through 8 on the stack and the serialized output to construct item 9, which is then concatenated with items 10 and 11 to obtain message m within the script. [sign] follows [outputsRequest] <G x By calling OP_CHECKSIGVERIFY and passing the verification, we can be confident that the serialized output left at the top of the stack is a true representation of the output of the current transaction.

[0118] It is also very useful to leave copies of items 1 through 7 on the stack for comparison. This can be achieved by modifying the script segment as follows: [outputsRequest]:= OP_2DUP OP_HASH256 OP_SWAP <Item 8> OP_CAT OP_SWAP OP_CAT <Items 10 and 11> OP_CAT Input data: <Items 1 to 7> <Serialized output of the current transaction>

[0119] After executing the modified [outputsRequest] on the input data, [sign] to consume the message. <G x > OP_CHECKSIGVERIFY can be called. The stack has the current serialized output at the top, followed by <items 1 through 7>.

[0120] Grouping consecutive items together, as in <Items 1 through 7>, makes things simpler. These items are either all within the unlock script or all determined within the lock script. However, a more granular approach is available at the potential cost of having more complex scripts.

[0121] Please note that the current serialization format for output is as follows: a. Output value is 8 bytes (little-endian), b. Length of the lock script, c. Lock script, and d. If there are two or more outputs, concatenate the serialized outputs in the correct order.

[0122] The serialization format of the output prior to the signed message (items 5 to 7) is as follows: a. Length of the lock script, b. Lock script, and c. Output value is 8 bytes (little-endian).

[0123] In the example below, the previous output is compared to the output of the currently consumed transaction, and they are forced to be identical. The two formats are useful for designing lock scripts for comparison.

[0124] 7.3 Persistent Forced Lock Script Assume Alice is the root Certificate Authority (CA) and Bob is a subordinate CA. Alice delegates Bob some task requiring him to expose a transaction on-chain as certificate attestation. Alice does not want Bob to consume the output for anything else. Therefore, Alice forces all subsequent consuming transactions to have a fixed [P2PKH Bob] lock script and a fixed output value. Bob can consume the output because he can generate a valid signature, but he cannot choose any output other than sending the same amount to himself.

[0125] Alice constructs the first transaction as shown in Figure 6.

[0126] The script segment is defined as follows: [outputsRequest]:= OP_2DUP OP_HASH256 OP_SWAP <Item 8> OP_CAT OP_SWAP OP_CAT <Items 10 and 11> OP_CAT [sign]:= OP_HASH256 G x OP_ADD n OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT G compressed [toDER]:= [toCanonical][concatenations] [toCanonical]:= OP_DUP n / 2 OP_GREATERTHAN OP_IF n OP_SWAP OP_SUB OP_ENDIF [concatenations]:= OP_SIZE OP_DUP $ OP_ADD 0 OP_SWAP OP_CAT <0220||G x > OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT

[0127] The length of the lock script is (7+12) + (6 + 32 + 32 + 33) + (6 + 32 + 32) + (11) + (15 + 34) + (14 + 20) = 286 = 0x011e.

[0128] Please note that item 8 may be 0xFFFFFFFF, item 10 may be 0x00000000, and item 11 may be 0x41000000.

[0129] To consume a transaction, Bob creates a transaction to consume, as shown in Figure 7. Referring to Figure 7, the input Data1 represents items 1 through 7 and can be described as follows: 010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763bb13029ce7b1 f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044TxID000000000011e{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP h OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160<H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}e803000000000000

[0130] [Table 2]

[0131] Data2 represents the output of TxID1 (value || lock script length || lock script) and can be written as follows: e803000000000000011e{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP h OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160<H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG}

[0132] The complete script executed during TxID1 authorization is as follows: <Sig B > <PK B > <data1> <data2>[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP h OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160<H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG

[0133] After the first OP_CHECKSIGVERIFY, < Sig is added to the stack (rightmost top). B > < PK B It has <Data1> and <Data2>.

[0134] [Table 3]

[0135] The size of TxID1 is: Version + Lock Time + Input + Output = 4 + 4 + (36 + 72 + 33 + 104 + 287 + 8 + 287 + 8 + 4) + (8 + 287) = 1142 bytes.

[0136] Considering the current settings, Bob can add his own input to cover the transaction fees. If Alice uses SIGHASH_SINGLE|ANYONECANPAY in the script segment [sign], Bob can add another output to receive change. This effectively makes Alice's lock script enforcement permanent. It is possible to think of this as a smart contract between Alice and Bob.

[0137] The lock script can also take transaction fees into account. After step 3, the top element of the stack is the value from the previous output. Before concatenation in step 4. <txfee>Adding OP_SUB allows Bob to pay transaction fees from the previous output. This can be a desirable feature as it leads to a decrease in the output value as consumption progresses, which sets the total number of consumptions Bob is eligible to pay.

[0138] 7.4 Optimization When Data1 contains Data2, Data2 can be constructed from Data1. In other words, it is assumed that the current output is identical to the previous output, and the message is constructed using the previous output. If that message passes OP_CHECKSIG, the two outputs must be identical. The script segment of [outputsRequest] can be rewritten as follows: [outputsRequest]:= OP_2DUP OP_CAT OP_TOALTSTACK OP_SWAP OP_CAT OP_HASH256 <Item 8> OP_SWAP OP_CAT OP_FROMALTSTACK OP_SWAP OP_CAT OP_CAT <Items 10 and 11> OP_CAT Input data: <Items 1 to 4> <Items 5 and 6> <Item 7>

[0139] This new [outputsRequest] is used to create lock scripts for TxID0 and TxID1. [outputsRequest][sign] OP_CHECKSIGVERIFY OP_DUP OP_HASH160<H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG Update it like this and set the unlock script to <Sig B > < PK B Update it as follows: <Data1> <Data2> <Data3>, where Data1 contains items 1 through 4, i.e., 010000002268f59280bdb73a24aae224a0b30c1f60b8a386813d63214f86b98261a6b8763b b13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044TxID000000000 And Data2 consists of items 5 and 6, namely, 011b{[outputsRequest] [sign] OP_CHECKSIGVERIFY OP_SWAP h OP_SPLIT OP_NIP OP_8 OP_SPLIT OP_SWAP OP_CAT OP_EQUALVERIFY OP_DUP OP_HASH160<H(PK_B)> OP_EQUALVERIFY OP_CHECKSIG} Therefore, Data3 is item 7, i.e., e803000000000000.

[0140] The size of TxID1 is 941 bytes. A step-by-step execution is given below, with steps 1 through 5 coming from [outputsRequest].

[0141] [Table 4]

[0142] G x Further improvements can be made by using the alt stack to store n. x Each of n is 32 bytes in size. compress is G x And,

[0143]

number

[0144] Since these can be derived from n, they can be referenced from the alt stack using some opcodes. Before: [sign]:= OP_HASH256 G x OP_ADD n OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT G x [toDER]:= [toCanonical][concatenations] [toCanonical]:= OP_DUP n / 2 OP_GREATERTHAN OP_IF n OP_SWAP OP_SUB OP_ENDIF [concatenations]:= OP_SIZE OP_DUP $ OP_ADD 0 OP_SWAP OP_CAT <0220||G_x> OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT after: [sign]:= OP_HASH256 G x OP_DUP OP_TOALTSTACK OP_ADD n OP_DUP OP_TOALTSTACK OP_MOD [toDER] SIGHASH_FLAG OP_SWAP OP_CAT OP_FROMALTSTACK [toDER]:= [toCanonical][concatenations] [toCanonical]:= OP_DUP OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_2 OP_DIV OP_GREATERTHAN OP_IF OP_FROMALTSTACK OP_SWAP OP_SUB OP_ENDIF [concatenations]:= OP_SIZE OP_DUP $ OP_ADD 0 OP_SWAP OP_CAT <0220> OP_FROMALTSTACK OP_DUP OP_TOALTSTACK OP_CAT OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT

[0145] Add 15 operating codes, G x Two instances of and two instances of n were deleted. The total savings are (32 × 2 + 32 × 2) - 15 = 113 bytes. Therefore, the size of transaction TxID1 consuming can be further reduced to 828 bytes.

[0146] Figure 8 shows an optimized version of the transactions to be consumed.

[0147] 8. Security Analysis Assertion 1: If (r, s) is a valid signature for both messages m and m' with respect to the public key P, then m = m'. Proof: Let z = hash(m) and z' = hash(m'). u = zs -1 mod n, u' = z's -1 mod n, and v = rs -1 Let's assume modulo n. Therefore, [uG + vP] x = [u'G + vP] x = r mod n is obtained. ⇒ uG = u'G ⇒ u = u' mod n ⇒ z = z' mod n ⇒ m = m'

[0148] Claim 2: The public key P must be determined in the lock script. Reasoning: Assume that P cannot be determined, and that (r, s) is a valid signature for m with respect to P. z' = hash(m'), u' = z's -1 , and v = rs -1 Let's assume that. We want to find P' such that u'G + vP' = R. P' = v -1 (R - u'G) Now (r, s) is valid with respect to P' for m'. Therefore, P must be determined in the lock script.

[0149] Argument 3: k should be determined in the lock script. basis: Assume that (r, s) is a valid signature generated in the lock script for m with respect to P. Assume that k is not determined in the lock script but is provided in the unlock script. At that time, the adversaries, 1. It is possible to intercept the transaction being consumed, 2. In the unlock script, k can be replaced with k'. Then, the (r', s') generated in the lock script becomes a valid signature for m with respect to P. The transaction remains valid, but the transaction ID will be changed.

[0150] Argument 4: The sighash flag should be determined in the lock script. basis: Assume that (r, s) is a valid signature generated in the lock script for m with respect to P. Assume the sighash flag is not determined in the lock script but is provided in the unlock script. 1. Intercept the transaction being consumed. 2. Change the sighash flag. 3. Update message m to m' accordingly. In certain use cases, this invalidates the transaction. For example, a lock script might expect multiple inputs and outputs with the sighash flag "ALL," and changing the flag to anything else would invalidate the script's execution. In other use cases, this modifies the transaction ID without invalidating the transaction. For example, a lock script might only enforce conditions on the output of the transaction it consumes, adding or removing "ANYONECANPAY" without invalidating the transaction, but it would change the transaction ID.

[0151] 9. Example script The tests showed that it is possible to implement a transaction consuming a size of 1415 bytes. The overhead mainly comes from endian inversion. A 32-byte column requires a 124-byte opcode to invert its endianness, and in some examples, it is necessary to invert the endianness of two columns in the lock script. The lock script appears in both the unlock script and the output. Therefore, the total overhead due to endianness in our implementation exceeds 500 bytes. For simplicity, in our current implementation G x We did not use the Alt stack to store n. This will save us a total of 200 bytes.

[0152] 9.1 Lock Script 1 (LS1) - generateSig and checkSig Input: The serialized transaction message for signing, as shown in the table in Section 6.

[0153] The lock script retrieves message m, 1. Perform a double SHA256 on m to obtain z, 2. Invert the endianness of z, 3. Add 0x00 to ensure that z is not interpreted as a negative number. 4. Call OP_BIN2NUM to obtain the minimum encoding for z (to address the case where step 3 introduces redundancy), 5. s = z + G x Calculate mod n, 6. If s > n / 2, convert s to n - s, 7. Get the length of s, 8. Invert the endianness of s (32 bytes), 9. If the length of s is longer than 32, invert another byte, 10. Calculate the total length of the DER signature (length of 0x24 + s), 11. Add the DER prefix 0x30, 12. r = G x Connect them, 13. Concatenate s, 14. Concatenate the sighash flag "ALL", 15. Push the compressed public key, 16. Call OP_CHECKSIG.

[0154] 9.2 Lock Script 2 (LS2) - constructMsg + LS1 + P2PKH input: <sig> <pk><Items 1 to 4> <Items 5 and 6> <Item 7>

[0155] The lock script retrieves the signature and public key pair, and items 1 through 7 as shown in the table in Section 6, through three PUSHDATA operations. 1. Get the previous value, calculate the new output value (subtracting a fixed transaction fee), 2. Take the previous lock script as a new lock script for the new output, 3. Concatenate the new output value and the new lock script to obtain the new output. 4. Perform a double SHA256 on the new output to obtain the hash of the output (item 9). 5. Push the sequence number (item 8), 6. Concatenate to obtain the message sequence (items 1 to 9), 7. Push the lock time and sighash flag (items 10 and 11). 8. Obtain the concatenated and signed message m, 9. Call LS1 with OP_CHECKSIGVERIFY, 10. Call P2PKH to check the Sig regarding PK.

[0156] 9.3 Transaction 0 - Genesis Transaction { "txid": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34", "hash": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34", "version": 1, "size": 730, "locktime": 0, "vin": [ { "txid": "52685bdbaae5c76887c23cee699bc48f293192a313c19b9fad4c77b993655df5", "vout": 0, "scriptSig": { "asm": "3044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a5[ALL|FORKID] 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798", "hex": "473044022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802201229c3605c61c4133b282cc30ece9e7d5c3693bf2cd1c03a3caadcd9f25900a541210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798" }, "sequence": 4294967295 } ], "vout": [ { "value": 49.99999388, "n": 0, "scriptPubKey": { "asm": "OP_2DUP OP_BIN2NUM 512 OP_SUB 8 OP_NUM2BIN OP_SWAP OP_CAT OP_HASH256 -2147483647 OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT 0000000041000000 OP_CAT OP_HASH256 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 0 OP_CAT OP_BIN2NUM9817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be79 OP_ADD 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_MOD OP_DUP 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffff00 2 OP_DIV OP_GREATERTHAN OP_IF 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffffff00 OP_SWAP OP_SUB OP_ENDIF OP_SIZE OP_DUP OP_TOALTSTACK OP_TOALTSTACK 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF 1 OP_SPLIT OP_ENDIF OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CATOP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF OP_SWAP OP_CAT OP_ENDIF OP_SIZE OP_DUP 36 OP_ADD 48 OP_SWAP OP_CAT 022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802 OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 65 OP_CAT 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIGVERIFY OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG", "type": "nonstandard" } } ], }

[0157] 9.4 Transaction 1 - Transactions to Consume { "txid": "c700e1d6c995e4c77014536d4431be84d7fb40d3fbef52ed85be2ad06414eac8", "hash": "c700e1d6c995e4c77014536d4431be84d7fb40d3fbef52ed85be2ad06414eac8", "version": 1, "size": 1415, "locktime": 0, "vin": [ { "txid": "88b9d41101a4c064b283f80ca73837d96f974bc3fbe931b35db7bca8370cca34", "vout": 0, "scriptSig": { }, "sequence": 4294967295 } ], "vout": [ { "value": 49.99998876, "n": 0, "scriptPubKey": { "asm": "OP_2DUP OP_BIN2NUM 512 OP_SUB 8 OP_NUM2BIN OP_SWAP OP_CAT OP_HASH256 -2147483647 OP_SWAP OP_CAT OP_CAT OP_CAT OP_CAT 0000000041000000 OP_CAT OP_HASH256 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 0 OP_CAT OP_BIN2NUM9817f8165b81f259d928ce2ddbfc9b02070b87ce9562a055acbbdcf97e66be79 OP_ADD 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffff00 OP_MOD OP_DUP 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffff00 2 OP_DIV OP_GREATERTHAN OP_IF 414136d08c5ed2bf3ba048afe6dcaebafeffffffffffffffffffffffffffffffff00 OP_SWAP OP_SUB OP_ENDIF OP_SIZE OP_DUP OP_TOALTSTACK OP_TOALTSTACK 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT 1 OP_SPLIT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF 1 OP_SPLIT OP_ENDIF OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CATOP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT OP_FROMALTSTACK 32 OP_GREATERTHAN OP_IF OP_SWAP OP_CAT OP_ENDIF OP_SIZE OP_DUP 36 OP_ADD 48 OP_SWAP OP_CAT 022079be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179802 OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT 65 OP_CAT 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIGVERIFY OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG", "type": "nonstandard" } } ], }

[0158] 10. Conclusion Other variations or use cases of the disclosed technology will become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is not limited by the embodiments described herein, but is limited only by the appended claims.

[0159] For example, some of the embodiments described above have been explained in terms of a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is just one specific example of blockchain 150, and the above description may be broadly applicable to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More broadly, all of the above references to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced with references to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104 described above.

[0160] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing block 151 of blockchain 150. It is not ruled out that there may be other network entities (or network elements) that perform only one or some of these functions, but not all of them. That is, a network entity may perform the function of propagating and / or storing blocks without creating and publishing blocks (it should be noted that these entities are not considered nodes of the preferred Bitcoin network 106).

[0161] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or part of the functions of creating, publishing, propagating, and storing blocks 151 of blockchain 150, but not all of them. For example, on those other blockchain networks, “node” may be used to refer to a network entity that is configured to create and publish blocks 151, but is not configured to store and / or propagate those blocks 151 to other nodes.

[0162] More broadly, any reference to the above term “Bitcoin node” 104 may be replaced with the term “network entity” or “network element,” such entity / element configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above in relation to blockchain node 104.

[0163] It will be understood that the embodiments described above are for illustrative purposes only. More broadly, methods, apparatus, or programs may be provided by any one or more of the following statements.

[0164] Statement 1. A computer implementation method for enforcing conditions on a second blockchain transaction using a first blockchain transaction, wherein the first condition is that when a first unlock script of the second transaction is executed together with a first lock script of the first transaction, a representation of the second transaction is output to memory, and the representation is based on multiple fields of the second transaction and a first output of the first transaction, the method A step of generating a first transaction, wherein the first transaction includes a first output, the first output includes a first lock script, and the first lock script is A message subscript configured to output a candidate message representing a second transaction into memory when executed, wherein the candidate message is based on multiple candidate fields of the first and second transactions, with one or more of the candidate fields included in the first unlock script of the second transaction, and the message subscript is configured to generate one or more respective parts of the candidate message based on each set of candidate fields, and to reuse at least one of each set of candidate fields as each different part of the candidate message; A signature subscript configured to generate a signature when executed, wherein the signature is a function of at least a candidate message, a private key, and a temporary private key, The public key corresponds to the private key, A computer execution method comprising the steps of: i) constructing a target message representing a second transaction, wherein the target message is constructed based on multiple fields of the second transaction and a first output of the first transaction; and ii) verifying that the signature is valid on the target message using a public key, wherein the verification of the signature is valid on the target message verifies that the target message matches a candidate message, thereby enforcing the condition that the candidate message output to memory is a representation of the second transaction.

[0165] Verifying that the target message matches the candidate message and that the candidate message is a representation of the second transaction is a result of the signature being valid for the target message.

[0166] Statement 2. One of the aforementioned parts of the candidate message includes a hash of one or more outputs of the second transaction, Each of the first set of candidate fields includes a) the length of each of the first lock scripts for the first transaction, and b) the first lock script for the first transaction. A method of statement 1 configured such that when the message subscript is executed, it generates a hash of one or more outputs based on candidate fields a) and b), thereby enforcing the condition that the first output of the second transaction contains the first lock script of the first transaction.

[0167] Statement 3. Each of the first set of candidate fields contains the respective values ​​locked by the first lock script of the first transaction. A method of statement 2 in which a message subscript is configured, when executed, to generate a hash of one or more outputs based on candidate fields a), b), and c), thereby enforcing the condition that the first output of the second transaction contains the first output of the first transaction.

[0168] Statement 4. Any of the aforementioned statements, which configures the message subscript to output at least one of the one or more parts of the candidate message into memory.

[0169] Statement 5. Any of the aforementioned statements' methods configured such that, when executed, the message subscript duplicates at least one of the candidate fields or each set of candidate fields as part of the candidate message so that they can be reused as different parts of the candidate message.

[0170] Statement 6. The first lock script includes a DER subscript configured to convert the signature into a signature in the Identification Encoding Rule DER format when executed, and the method of any of the preceding statements includes using the public key to verify that the signature is valid for the target message, or using the public key to verify that the signature in DER format is valid for the message.

[0171] Statement 7. Any of the aforementioned statements, where the signing subscript includes a signing flag that specifies which of several fields of the second transaction should form the basis of the target message, and the verification subscript is configured to construct the target message based on the signing flag.

[0172] Statement 8. A signature flag in statement 7 specifies that each input and each output of the second transaction should form the basis of the target message.

[0173] Statement 9. A method of statement 7 in which the signature flag specifies that a) a first input containing a first unlock script for a second transaction, and b) a second first output paired with the first input, should form the basis of the target message.

[0174] Statement 10. One or more of the candidate fields are included in any of the aforementioned statements in the first lock script of the first transaction.

[0175] Statement 11. The following candidate fields, namely, - Version number of the second transaction, - Length of the first lock script for the first transaction, - The value of the first lock script for the first transaction, - Sequence number of the first input of the second transaction, - Lock time for the second transaction, - Signature flag of the first unlock script for the second transaction One or more of these are methods of statement 10 included in the first lock script of the first transaction.

[0176] Statement 12. Any of the aforementioned statement methods, in which a candidate message representing a second transaction includes one or more data items based on one or more sets of each candidate field of the second transaction.

[0177] Statement 13. Each of the one or more data items is, - The hash of the input sequence number of the second transaction, - The hash of the combined output of the second transaction A method of statement 12 including one or more of the above.

[0178] Statement 14. A method of any of the above statements where the memory is a stack-based memory.

[0179] Statement 15. A method of statement 14 where the signature verification subscript includes at least one of the OP_CHECKSIGVERIFY opcode and the OP_CHECKSIG opcode.

[0180] Statement 16. A method of any of the above statements including the step of making the first transaction available to one or more nodes of a blockchain network.

[0181] Statement 17. A method of any of the above statements including the step of making the first transaction available to parties for generating a second transaction.

[0182] Statement 18. A method of any of the above statements where the temporary private key is determined by the first lock script to be equal to 1 and / or the temporary private key is determined to be equal to the private key.

[0183] Statement 19. A method of statement 17 where the private key is determined by the first lock script to be equal to 1.

[0184] Statement 20. The signature is s = k -1 The method of statement 18 or statement 19, in the form (z + ra) mod n, where k is the temporary private key, a is the private key, z is the hash of the candidate message, n is the integer order of the elliptic curve generator G, and r is the modulo n of the x-coordinate of the temporary public key.

[0185] Statement 21. The signature is s = z + G x It is a modulo n form, G x The method of statement 18 or any statement subordinate thereto, where G is the x-coordinate of the generator G of the elliptic curve, and G is both a temporary public key and a public key.

[0186] Statement 22. The signature subscript is G x The signature includes the respective values ​​of and n, and G x The method of generating statement 21 based on the respective values ​​of n.

[0187] Statement 23. Stack-based memory includes a primary stack and an alternate stack, and the first lock script is G x And each of the values ​​of n is configured to be used two or more times, and the first lock script is executed, G x The respective values ​​of n are output to the alternate stack, and G is executed on the first attempt. x And each time a value of n is needed, G x The methods of statements 21 and 22 are configured to retrieve the respective values ​​of n from an alternate stack.

[0188] Statement 24. Memory including one or more memory units, A computer device comprising one or more processing units, wherein memory stores code arranged to be executed on the processing unit, and the code is configured to execute any of the methods of statements 1 to 23 when it is on the processing unit.

[0189] Statement 25. A computer program that is implemented on computer-readable storage and configured to execute one of the methods of statements 1 through 23 when executed on one or more processors. [Explanation of symbols]

[0190] 100 Systems 101 Packet-switched network 102 Computer terminals, computer equipment 102a Computer equipment 102b Computer equipment 103 Users, Stakeholders, Agents 103a User, First Party, Alice 103b New user or entity, second party, Bob 104 blockchain nodes, Bitcoin nodes 105 Client Applications 105a Client Application 105b Client 106 Peer-to-peer (P2P) networks, blockchain networks, Bitcoin networks 107 Side Channel 150 blockchains, Bitcoin blockchain 151 data blocks 151n-1 previously created block 151n New block 152 transactions 152i Preceding Transactions 152j Current transaction, forward transaction 153 Genesis block (Gb) 154 Ordered set (or "pool") 155 Block pointer 201 Header 202 Input 203 Output 401 Transaction engine 402 User interface (UI) layer 450 Node software 451 Protocol engine 452 Script engine 453 Stack 454 Application-level judgment engine 455 Blockchain-related functional module 455C Consensus module 455P Propagation module 455S Storage module 500 User interface (UI) 501 UI element, user-selectable element 502 UI element, data input field 503 Information element< / pk> < / sig> < / txfee> < / data1>

Claims

1. A computer implementation method for enforcing conditions on a second blockchain transaction using a first blockchain transaction, wherein a first condition is that a representation of the second transaction is output to memory when a first unlock script of the second transaction is executed together with a first lock script of the first transaction, and the representation is based on a plurality of fields of the second transaction and a first output of the first transaction, the computer implementation method A step of generating the first transaction, wherein the first transaction includes a first output, the first output includes a first lock script, and the first lock script is A message subscript configured to output a candidate message representing the second transaction into memory when executed, wherein the candidate message is based on a plurality of candidate fields of the first transaction and the second transaction, one or more of the candidate fields are included in the first unlock script of the second transaction, and the message subscript is configured to generate one or more respective parts of the candidate message based on each set of the candidate fields, and to reuse at least one of each set of the candidate fields as each different part of the candidate message, A signature subscript configured to generate a signature when executed, wherein the signature is a function of at least the candidate message, private key, and temporary private key, The public key corresponding to the aforementioned private key, A computer execution method comprising the steps of: i) constructing a target message representing the second transaction, wherein the target message is constructed based on a plurality of fields of the second transaction and the first output of the first transaction; and ii) verifying that the signature is valid for the target message using the public key, wherein the verification that the signature is valid for the target message verifies that the target message matches the candidate message, thereby enforcing the condition that the candidate message output to memory is the representation of the second transaction.

2. One of the respective parts of the candidate message includes a hash of one or more outputs of the second transaction. Each of the first set of candidate fields includes a) the length of each of the first lock scripts of the first transaction, and b) the first lock script of the first transaction. The method according to claim 1, wherein the message subscript is configured, when executed, to generate the hash of one or more outputs based on candidate fields a) and b), thereby enforcing the condition that the first output of the second transaction includes the first lock script of the first transaction.

3. Each of the first set of candidate fields includes, c) the respective values ​​locked by the first lock script of the first transaction, The method according to claim 2, wherein the message subscript is configured, when executed, to generate the hash of one or more outputs based on candidate fields a), b), and c), thereby enforcing the condition that the first output of the second transaction includes the first output of the first transaction.

4. The method according to claim 1, wherein the message subscript is configured to output at least one of the one or more portions of the candidate message to the memory.

5. The method according to claim 1, wherein the message subscript is configured to duplicate as part of the candidate message so that when executed, at least one of the respective sets of candidate fields is reused as the respective different parts of the candidate message.

6. The method according to claim 1, wherein the first lock script includes a DER subscript configured to convert the signature into a signature in the Identification Encoding Rule DER format when executed, and the method includes using the public key to verify that the signature is valid for the target message, or using the public key to verify that the signature in DER format is valid for the target message.

7. The method according to claim 1, wherein the signing subscript includes a signing flag that specifies which of the plurality of fields of the second transaction should form the basis of the target message, and the verification subscript is configured to construct the target message based on the signing flag.

8. The method according to claim 7, wherein the signature flag specifies that each input and each output of the second transaction should form the basis of the target message.

9. The method according to claim 7, wherein the signature flag specifies that a) a first input including the first unlock script for the second transaction and b) a first output of the second transaction paired with the first input should form the basis of the target message.

10. The method according to claim 1, wherein one or more of the candidate fields are included in the first lock script of the first transaction.

11. The following candidate fields, namely, - The version number of the second transaction mentioned above, - Length of the first lock script of the first transaction, - The value of the first lock script of the first transaction, - Sequence number of the first input of the second transaction, - Lock time for the second transaction mentioned above, - Signature flag of the first unlock script for the second transaction The method according to claim 10, wherein one or more of the above are included in the first lock script of the first transaction.

12. The method according to claim 1, wherein the candidate message representing the second transaction includes one or more respective data items based on one or more respective sets of each candidate field of the second transaction.

13. Each of the one or more data items mentioned above is - The hash of the input sequence number of the second transaction, - The hash of the combined output of the second transaction described above. The method according to claim 12, comprising one or more of the above.

14. The method according to claim 1, wherein the memory is a stack-based memory.

15. The method according to claim 14, wherein the verification subscript includes at least one of the OP_CHECKSIGVERIFY opcode and the OP_CHECKSIG opcode.

16. The method according to claim 1, further comprising the step of making the first transaction available to one or more nodes of a blockchain network.

17. The method according to claim 1, further comprising the step of making the first transaction available to the parties to generate the second transaction.

18. The method according to claim 1, wherein the temporary private key is determined to be equal to 1 by the first lock script, and / or the temporary private key is determined to be equal to the private key.

19. The method according to claim 18, wherein the private key is determined to be equal to 1 by the first lock script.

20. The aforementioned signature, s = k -1 The method according to claim 18, wherein the expression is of the form (z + ra) mod n, where k is the temporary private key, a is the private key, z is the hash of the candidate message, n is the integer order of the generator G of the elliptic curve, and r is the modulo n of the x-coordinate of the temporary public key.

21. The aforementioned signature is s = z + G x It is a modulo n form, G x The method according to claim 18, wherein is the x-coordinate of the generator G of the elliptic curve, and G is both the temporary public key and the public key.

22. The aforementioned signature subscript is G x and each of the values ​​of n, the signature is G x The method according to claim 21, which is generated based on the respective values ​​of n.

23. The stack-based memory includes a main stack and an alternative stack, and the first lock script is configured to use each value of G x and n more than once, and when the first lock script is executed, it outputs each value of G x and n to the alternative stack, and each value of G x and n is obtained from the alternative stack whenever each value of G x and n is required, the method according to claim 21, wherein the method is configured to obtain each value of G

24. Memory including one or more memory units, A computer device comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing unit, and the code is configured to perform the method described in any one of claims 1 to 23 when it is on the processing unit.

25. A computer program that is embodied on computer-readable storage and configured to perform the method described in any one of claims 1 to 23 when executed on one or more processors.

Images