Signature-Based Atomic Swap

Abstract

A method performed in a system including a first party and a second party, comprising: generating, by the first party, a template of a first transaction having inputs based on outputs from a previous transaction associated with the second party; generating, by the first party, a message based on the template of the first transaction; generating, by the first party, a secret based on the message; generating, by the first party, a value based on the secret, where the secret cannot be derived from the value; generating, by the first party, a first puzzle transaction, where a first locking script of the first puzzle transaction includes a knowledge proof configured to require that an unlocking script includes the secret; 1. A method comprising: publishing a cheat transaction on a first blockchain; obtaining, by a second party, a value based on a secret; signing, by the second party, the value based on the secret to create a signature; sending the signature from the second party to the first party; including, by the first party, the signature in an unlock script for the first transaction and then sending the first transaction to the second blockchain; determining, by the second party, a message and a secret from the first transaction on the second blockchain; and creating, by the second party, a second transaction that unlocks a first output of the first puzzle transaction based on the secret and submitting the second transaction to the first blockchain.

Description

[Technical field]

[0001] The present disclosure relates to a method for securely conducting transactions, the method being applicable to blockchain technology. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which copies of the blockchain are maintained and publicly published at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereafter referred to as the "blockchain network"). The blockchain includes a chain of blocks of data, with each block including one or more transactions. Each transaction, other than the so-called "coinbase transaction", points backwards to a preceding transaction in the sequence, which may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are often created by a process called "mining", which involves multiple nodes each competing to solve a cryptographic puzzle based on a "proof of work", i.e., a representation of a defined set of ordered, approved, pending transactions that are waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and 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: transfer of digital assets (i.e., some digital tokens), ordering of a set of entries in a virtual ledger or registry, receiving and processing timestamp entries, and / or time-ordering of index pointers. A blockchain may also be utilized to stack additional functions on top of the blockchain. For example, a blockchain protocol may allow for storing additional user data or indexes to data in a transaction. There is no predefined limit on the maximum data capacity that can be stored in a single transaction, and thus much more complex data can be incorporated. For example, this may be used to store electronic documents in the blockchain, or to store audio or video data.

[0004] The nodes of the blockchain network (often called "miners") perform a distributed transaction registration and validation process that will be described in more detail later. In summary, during this process, nodes approve transactions and insert transactions into block templates where they attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes of the network, thus allowing each node to record a new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes of the network to be propagated. The nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate 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 a block. Assuming the transaction is approved and thereby accepted into the blockchain, the transaction (including any user data) thus remains registered and indexed in each of the nodes 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 typically rewarded with a new transaction called a "coinbase transaction" that distributes an amount of digital assets, i.e., some number of tokens. Detection and rejection of invalid transactions is enforced by the actions of competing nodes that act as agents of the network and are incentivized to report and block fraudulent activity. Widespread publication of information allows users to continuously audit node performance. Publication of mere block headers allows participants to guarantee 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. Every spendable output includes an element that specifies an amount of a digital asset derivable from an ongoing sequence of transactions. A spendable output is sometimes called a UTXO (unspent transaction output). An output may further include a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions required to approve and transfer a digital token or asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such output of a prior transaction and may further include an unlocking script to unlock the locking script of the pointed-to output. Now consider a pair of transactions, which we call a first transaction and a second transaction (or “target” transaction). The first transaction includes at least one output that specifies an amount of a digital asset and includes a locking script that defines one or more conditions for unlocking the output. The second, target transaction includes at least one input including a pointer to an output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when the second, target transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of the one or more conditions defined in the locking 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 the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but possibly propagate to register an invalid transaction) and will not include the transaction in a new block to be recorded in the blockchain.

[0008] An alternative kind of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing the UTXO of a previous transaction in a sequence of past transactions, but by referencing an absolute account balance. The current state of every account is stored and constantly updated by a node separate from the blockchain. Summary of the Invention [Means for solving the problem]

[0009] In some instances, a secret value based on the signature message of the unpublished transaction is determined. Before the secret transaction is revealed, a puzzle transaction that can be unlocked by the secret is generated and published. When the secret transaction is published, it creates an atomic swap between the two parties. This increases security by preventing either party from "cheating" the other.

[0010] According to an aspect disclosed herein, a method is provided that is executed in a system including a first party and a second party. The method includes generating, by the first party, a template of a first transaction having an input based on an output from a previous transaction related to the second party. The method may include generating, by the first party, a message based on the template of the first transaction, and generating, by the first party, a secret based on the message. The method may further include generating, by the first party, a value based on the secret, where the secret cannot be derived from the value, and generating, by the first party, a first puzzle transaction, where a first locking script of the first puzzle transaction includes a knowledge proof configured to require that an unlocking script includes the secret. The method may include publishing, by the first party, the first puzzle transaction to a first blockchain, and the second party obtaining a value based on the secret and signing the value based on the secret to create a signature. The method may further include transmitting the signature from the second party to the first party, and including the signature by the first party in an unlocking script for the first transaction and then transmitting the first transaction to the second blockchain. The method may further include determining, by the second party, a message and a secret from the first transaction on the second blockchain, and creating, by the second party, a second transaction that unlocks the first output of the first puzzle transaction based on the secret and submitting the second transaction to the first blockchain.

[0011] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made by way of example only to the accompanying drawings, in which: [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Diagram 2] FIG. 1 illustrates a schematic diagram of some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] FIG. 3B is a schematic mock-up diagram of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 2 is a schematic block diagram of certain node software for processing transactions. [Diagram 5] FIG. 1 is a schematic diagram of six different types of sighash flags. [Figure 6] FIG. 2 is a flow diagram of an exemplary method. [Figure 7] FIG. 2 is a flow diagram of an exemplary method. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may include a packet-switched network 101, typically a wide area internetwork such as the Internet. The packet-switched network 101 includes a number of blockchain nodes 104 that may be 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. Thus, each blockchain node 104 is tightly connected to the other blockchain nodes 104.

[0014] Each blockchain node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each blockchain node 104 includes a processing device including one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application specific integrated circuits (ASICs). Each node also includes a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium or multiple non-transitory computer readable media. The memory may include one or more memory units employing one or more memory media, for example, a magnetic medium such as a hard disk, an electronic medium such as a solid state drive (SSD), a flash memory, or an EEPROM, and / or an optical medium such as an optical disk drive.

[0015] The blockchain 150 includes a chain of blocks 151 of data, with a respective copy of the blockchain 150 maintained at each of multiple blockchain nodes 104 of a distributed or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing all of the blockchain 150. Instead, the blockchain 150 may be pruned of data, so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 of the chain includes one or more transactions 152, where a transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount that represents an amount of digital assets as property, an example being a user 103 to whom the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points backwards to an output of a previous transaction 152, thereby linking the transactions.

[0016] Each block 151 also contains a block pointer 155 that points back to previously created blocks 151 in the chain to define a chronological order up to block 151. Each transaction 152 (other than a coinbase transaction) contains a pointer back to a previous transaction to define an order in the sequence of transactions (note that the sequence of transactions 152 is allowed to branch). The chain of blocks 151 traces back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

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

[0018] For a given current transaction 152j, its (or each) input contains a pointer that references the output of a previous transaction 152i in the sequence of transactions, specifying that this output is to be fulfilled or "consumed" in the current transaction 152j. In general, a previous transaction can be any transaction in the ordered set 154 or any block 151. A previous transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even transmitted to the network 106, but the previous transaction 152i must exist and be approved for the current transaction to be valid. Thus, "predecessor" in this specification refers to a predecessor in the logical sequence linked by the pointer, and not necessarily to the time of creation or transmission in the temporal sequence, and therefore does not necessarily exclude transactions 152i, 152j from being created or transmitted out of order (see discussion below regarding orphan transactions). A previous transaction 152i may also be called an antecedent or predecessor transaction.

[0019] The input of the current transaction 152j also includes the authorization of the input, e.g., the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, the transaction 152 may have multiple outputs to split 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 previous transactions and redistribute them to one or more outputs of the current transaction.

[0020] According to an output-based transaction protocol such as Bitcoin, when a participant 103, such as an individual user or an organization, wants to put a new transaction 152j into action (either manually or by an automated process adopted by the participant), the participant sends the new transaction from his computer terminal 102 to the recipient. The participant or recipient eventually sends this transaction to one or more of the blockchain nodes 104 of the network 106 (currently generally servers or data centers, but in principle could be other user terminals). It is also not excluded that the participant 103 putting a new transaction 152j into action could send it directly to one or more of the blockchain nodes 104 and in some cases not to the recipient. The blockchain nodes 104 receiving the transaction check whether the transaction is valid according to a blockchain node protocol applied in each of the blockchain nodes 104. The blockchain node protocol generally requires the blockchain nodes 104 to check that the cryptographic signature of the new transaction 152j matches an expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may involve checking that a cryptographic signature or other authorization of a participant 103 included in the input of the new transaction 152j matches a condition defined in the output of the prior transaction 152i that the new transaction allocates, which condition generally includes at least checking that the cryptographic signature or other authorization of the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the prior transaction 152i.Alternatively, the conditions may be determined solely by the blockchain node protocol, or may result from a combination of these. In any case, if the new transaction 152j is valid, the blockchain node 104 forwards the new transaction 152j to one or more other blockchain nodes 104 of the blockchain network 106. These other blockchain nodes 104 apply the same tests 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 manner, the new transaction is propagated throughout the network of blockchain nodes 104.

[0021] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., spent) is whether that 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 it is not valid, the transaction 152j is not propagated (unless it is flagged as invalid for a warning and propagated) and is not recorded in the blockchain 150. This prevents double spending, where a transactor tries to allocate the output of the same transaction more than once. On the other hand, an account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance always has a single defined state.

[0022] In addition to approving transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process supported by "proof of work", usually called mining. At the blockchain nodes 104, new transactions are added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded in the blockchain 150. The blockchain nodes then compete to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Generally, this involves searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash satisfies a predefined condition. For example, the predefined condition may be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one particular type of proof of work puzzle, and others are not excluded. A property of a hash function is that it has an unpredictable output for its input. Therefore, this search can only be performed by brute force, thus expending a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0023] The first blockchain node 104 that solves the puzzle announces this to the network 106 and provides the solution as a proof that can then be easily checked by other blockchain nodes 104 in the network (given the hash solution, it is easy to check that it satisfies the conditions on the hash output). The first blockchain node 104 accepts the block and thus propagates the block up to a threshold consensus of other nodes that enforce the rules of the protocol. The ordered set of transactions 154 then becomes recorded in the blockchain 150 by each of the blockchain nodes 104 as a new block 151. The new block 151n is also assigned a block pointer 155 that points backwards to the previously created block 151n-1 in the chain. The significant amount of effort, e.g., in the form of hashing, required to create the proof-of-work solution signals the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it allocates the same output as a previously approved transaction, also known as double spending. Once created, blocks 151 cannot be modified because they are known and maintained at each of the blockchain nodes 104 of the blockchain network 106. Also, block pointers 155 impart a chronological order to blocks 151. This thus provides an immutable public ledger of transactions as transactions 152 are recorded in ordered blocks on each blockchain node 104 of the network 106.

[0024] Note 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 154 of transactions not yet published at any given time, depending on when they started searching for a solution or the order in which transactions were received. Whoever solves their respective puzzle first defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool 154 of unpublished transactions is updated. Then, the blockchain nodes 104 continue to compete to create blocks from the newly defined ordered pool 154 of unpublished transactions, and so on. There is also a protocol to resolve any "forks" that may occur, where a fork is the point at which two blockchain nodes 104 solve their puzzles within a very short time of each other, such that conflicting views of the blockchain are propagated between the nodes 104. In short, the claw of whichever fork is the longest becomes the final blockchain 150. Note that this should have no impact on users or agents of the network, since the same transactions appear in both forks.

[0025] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional permitted amount of digital assets in a new special type of transaction that distributes an additional defined amount of digital assets (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another). This special type of transaction is typically 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. The proof of work signals the node's intent to follow the rules of the protocol that allow this special transaction to be subsequently fulfilled. The rules of the blockchain protocol may require a maturity period, e.g., 100 blocks, before this special transaction may be fulfilled. Often, a regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is commonly referred to as the "transaction fee" and is discussed below.

[0026] Due to the resources involved in validating and publishing transactions, typically at least each of the blockchain nodes 104 takes the form of a server including 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.

[0027] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role or roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood that all actions attributed to the blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0028] Further connected to the network 101 are computer devices 102 for each of a number of participants 103 in the role of consuming users. These users may interact with the blockchain network 106 but do not participate in approving transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some participants may act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from a blockchain node 104).

[0029] Some or all of the participants 103 may be connected as part of a different network, for example, a network overlaid on the blockchain network 106. Although users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network 106, these users are not blockchain nodes 104 because they do not fulfill the required role of a blockchain node. Instead, each participant 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting (i.e., communicating) with the blockchain nodes 106. For illustrative purposes, two participants 103 and their respective devices 102 are shown: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that many more such participants 103 and their respective computer devices 102 may exist and participate in the system 100, but for convenience they are not shown. Each participant 103 may be an individual or an organization. Purely for purposes of illustration, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be understood that this is not limiting and all references herein to Alice or Bob may be replaced by "first party" and "second party," respectively.

[0030] The computing device 102 of each participant 103 includes a respective processing device including one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application specific processors, and / or FPGAs. The computing device 102 of each participant 103 further includes a memory, i.e., computer readable storage in the form of a non-transitory computer readable medium or multiple non-transitory computer readable media. This memory may include one or more memory units employing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memories, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software including a respective instance of at least one client application 105 arranged to execute on the processing device. It will be understood that all actions attributed to a given participant 103 herein may be performed using software executing on the processing device of the respective computing device 102. The computing equipment 102 of each participant 103 includes at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smart watch. The computing equipment 102 of a given participant 103 may also include one or more other networked resources, such as cloud computing resources, that are accessed via a user terminal.

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

[0032] The client application 105 includes at least a "wallet" functionality. It has two main functions. One of these is to allow each party 103 to create, authorize (e.g., sign) and then send transactions 152 to one or more Bitcoin nodes 104 to be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the amount of digital assets that it currently owns. In an output-based system, this second function involves aggregating the amounts defined in the outputs of the various transactions 152 scattered throughout the blockchain 150 that belong to the party in question.

[0033] NOTE: Although various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting; rather, any client functionality described herein may instead be implemented in a suite of two or more different applications that interface, for example, via an API or are plug-ins to one another. More broadly, client functionality may be implemented at the application layer, or at a lower layer such as an operating system, or any combination of these. While the following is described in terms of a client application 105, it will be understood that this is not limiting.

[0034] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to query the blockchain 150 for which each party 103 is the recipient of any transactions (or in embodiments, to verify the transactions of other parties in the blockchain 150, since the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet function of each computing device 102 is configured to assemble and send the transactions 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to approve the transactions 152 according to the blockchain node protocol and forward the transactions 152 to propagate the transactions 152 across the blockchain network 106. The transaction protocol and the node protocol 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 of the blockchain 150. The same node protocol is used by all nodes 104 of the network 106.

[0035] When a given party 103, say Alice, wants to submit a new transaction 152j to be included in the blockchain 150, she assembles the new transaction (using the wallet functionality of her client application 105) according to the relevant transaction protocol. The party 103 then transmits the transaction 152 from her client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this could be the blockchain node 104 that is best connected to Alice's computer 102. When any given blockchain node 104 receives a new transaction 152j, it processes the new transaction 152j according to the blockchain node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions to be "valid", examples of which will be considered 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 the transaction 152. Alternatively, the conditions could simply be an inbuilt feature of the node protocol or defined by a combination of the script and the node protocol.

[0036] Provided that the newly received transaction 152j passes the test to be considered valid (i.e., the newly received transaction 152j is "approved"), every blockchain node 104 that receives the transaction 152j adds the newly approved transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j propagates the approved transaction 152 towards one or more other blockchain nodes 104 of the network 106. Since each blockchain node 104 applies the same protocol, this means that the transaction 152j is immediately propagated throughout the network 106, assuming that the transaction 152j is valid.

[0037] Once placed in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 starts competing to solve a proof-of-work puzzle for the latest version of its respective pool 154 of transactions, including the new transaction 152. (Recall that other blockchain nodes 104 may be trying to solve the puzzle based on different pools 154 of transactions, but whoever succeeds first defines the set of transactions included in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for the part of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, the pool 154 becomes immutably part of one of the blocks 151 of the blockchain 150. Each transaction 152 includes a pointer back to the previous transaction, so the order of the transactions is also immutably recorded.

[0038] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore may have conflicting views of which instance is "valid" before one instance is published in a new block 151, at which point 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 the blockchain 150, it must accept it and discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that was not published in block 151).

[0039] An alternative kind of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by looking backwards at the UTXO of the preceding transaction in a sequence of past transactions. The current state of every account is stored and constantly updated by the nodes of that network, separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called "position") of the account. This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be assigned to the transaction. This data field may point backwards to a previous transaction, for example if the previous transaction ID is included in the data field.

[0040] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. It should be noted that the exemplary UTXO-based protocol is described in the context of Bitcoin, but may be similarly implemented in other exemplary blockchain networks.

[0041] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which may be used as a source of input 202 for another new transaction (if the UTXO has not already been fulfilled). The UTXO includes a value that specifies an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also include, among other information, a transaction ID for the transaction from which the UTXO originated. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the node 104.

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

[0043] The predecessor transaction Tx0 may already have been approved and included in a block 151 of the blockchain 150 when Alice creates her new transaction Tx1, or at least by the time Alice sends the new transaction Tx1 to the network 106. The predecessor transaction Tx0 may already have been included in one of the blocks 151 at that time, or may still be waiting in the ordered set 154, in which case the predecessor transaction Tx0 will be included in the new block 151 immediately. Alternatively, Tx0 and Tx1 may be created together and sent to the network 106, or even Tx0 may be sent after Tx1 if the node protocol allows for buffering of "orphan" transactions. The terms "predecessor" and "successor" as used herein in the context of a sequence of transactions refer to the order of transactions in a sequence defined by transaction pointers specified in the transaction (such as which transaction points backwards to which other transaction). The terms may be equally interchangeable with “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 the network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or “child”) that points to a preceding transaction (ancestor transaction or “parent”) will not be approved until and unless the parent transaction is approved. A child that arrives at a blockchain node 104 before its parent is considered an orphan. The child may be discarded or buffered for a certain amount of time to wait for the parent, depending on the node protocol and / or node behavior.

[0044] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, here labeled UTXO0. Each UTXO includes a value that specifies the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be met by an unlocking script of the input 202 of the subsequent transaction for the subsequent transaction to be approved and thus the UTXO to be successfully fulfilled. Generally, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition that generally includes a condition that the unlocking script of the input of the subsequent transaction includes a cryptographic signature of the party to whom the preceding transaction is locked.

[0045] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies what information is required to consume a transaction output 203, e.g., the need for Alice's signature. An unlock script appears in the output of a transaction. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the criteria of a lock script. For example, an unlock script might include Bob's signature. An unlock script appears in the input 202 of a transaction.

[0046] Thus, in the illustrated example, UTXO0 in output 203 of Tx0 must have Alice’s signature Sig P in order for UTXO0 to be fulfilled (or, more precisely, for a subsequent transaction that attempts to fulfill UTXO0 to be valid). A Requires lock script [Checksig P A ]. [Checksig P A] is the public key P from Alice's public-private key pair. A , a representation (i.e., a hash) of Tx1's input 202. Tx1's input 202 includes a pointer that points back into Tx0 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 includes an index that identifies UTXO0 within Tx0, to identify UTXO0 among any other possible outputs of Tx0. Tx1's input 202 includes an unlock script that includes Alice's cryptographic signature, created by Alice applying her private key from her key pair to a pre-defined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or by a combination of these.

[0047] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (which may include one or more criteria). In an embodiment, this involves concatenating the two scripts, i.e. <Sig P A > <P A > || [Checksig P A ] where "||" represents concatenation, "<...>" means putting 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 one after the other using a common stack rather than concatenating the scripts. In either case, when executed together, the scripts will use Alice's public key PA is used to authenticate that the input unlock script for Tx1 contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in order to perform this authentication. In an embodiment, the signed data includes the entirety of Tx1 (so a separate element specifying the signed portion of the plaintext data does not need to be included since it is already inherently present).

[0048] The details of authentication with public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then with 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 allowing all holders of the public key to authenticate the signature. Thus, it should be noted that all references herein to signing a particular piece of data or transaction, etc., may, in embodiments, mean signing a hash of that piece of data or transaction.

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

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

[0051] Note that in a UTXO-based transaction model, a given UTXO must be spent in its entirety. A given UTXO cannot have a portion of the amount defined in the UTXO as spent spent while leaving another portion "left over." However, an amount from a UTXO can be split among multiple outputs of a subsequent transaction. For example, the amount defined in UTXO0 of Tx0 can be split among multiple UTXOs of Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use the remainder to give herself change or pay another party in the second output of Tx1.

[0052] In practice, Alice would usually also need to include a fee to any Bitcoin node 104 that successfully includes her transaction 104 in the block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104 and thus may not be propagated and included in the blockchain 150, although it is technically valid (the node protocol does not force the blockchain node 104 to accept the transaction 152 if it does not want to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, any 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 that publishes the transaction. For example, suppose that a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work race to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in one of the UTXOs 203 of transaction 152 itself.

[0053] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, the assets of a given party 103 are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no one number stored anywhere in the blockchain 150 that defines the total balance of a given party 103. It is the role of a wallet function within the client application 105 to compile the value of all the various UTXOs locked to each party and that have not yet been spent in another onward transaction. The wallet function can do this by querying the copy of the blockchain 150 stored in any of the Bitcoin nodes 104.

[0054] Note that script code is often expressed generally (i.e., without using a precise language). For example, an operation code (opcode) may be used to express a particular function. "OP_..." refers to a particular opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data on the blockchain 150. For example, the data could include a document that is desired to be stored on the blockchain.

[0055] In general, the input for a transaction is a public key P AIn an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific parts of the outputs that the signature signs depend on the SIGHASH flag, which is a 4-byte code typically included at the end of the signature (and therefore fixed at the time of signing) to select which outputs are signed.

[0056] A lock script may be referred to as a "scriptPubKey", generally referring to the fact that it contains the public key of the party to whom each transaction is locked. An unlock script may be referred to as a "scriptSig", generally referring to the fact that it provides the corresponding signature. However, more broadly, it is not required in all applications of blockchain 150 that the condition for a UTXO to be fulfilled include authenticating the signature. More broadly, a scripting language may be used to define any condition or conditions. Thus, the broader terms "lock script" and "unlock script" may be preferred.

[0057] Side Channels As shown in FIG. 1, each of the client applications on Alice's and Bob's computing devices 102a, 102b may include additional communication capabilities. This additional capability allows Alice 103a to establish (at the urging of either party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 allows data to be exchanged separately from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 between Alice and Bob without the transaction (yet) being registered in the blockchain network 106 or progressing towards the chain 150 until one of the parties chooses to broadcast the transaction 152 to the network 106. Sharing transactions in this manner may be referred to as 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, data content, etc.

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

[0059] Client Software 3A illustrates an example implementation of a client application 105 for implementing embodiments of the presently disclosed schemes. 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 functionality of the client 105, such as assembling transactions 152, receiving and / or sending transactions and / or other data via a side channel 107, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106, according to the schemes discussed above and as will be discussed in more detail shortly.

[0060] The UI layer 402 is configured to provide a user interface via user input / output (I / O) means of the computing device 102 of each user, including outputting information to each user 103 via user output means of the device 102 and receiving input back from each user 103 via user input means of the device 102. For example, the user output means may include one or more display screens (touch screen or non-touch screen) for providing visual output, one or more speakers for providing audio output, and / or one or more tactile output devices for providing tactile output, etc. The user input means may include, for example, one or more touch screens (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 an input array such as one or more mechanical buttons, switches, or joysticks.

[0061] NOTE: Although various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting and instead the functions may be implemented in a suite of, for example, two or more different applications, one of which is a plug-in to the other, or which interface via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split between two or more applications. It is also not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, etc., it will be understood that this is merely exemplary and that more broadly the described functionality may be implemented in any form of software.

[0062] 3B provides a mock-up of an example user interface (UI) 500 that might be rendered by the UI layer 402 of the client application 105a on Alice's device 102a. It will be appreciated that a similar UI may be rendered by the client 105b on Bob's device 102b, or a client on any other participant's device.

[0063] 3B illustrates the UI 500 from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 502 that are rendered as different UI elements via user output means.

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

[0065] Alternatively or additionally, the UI elements may include one or more data entry fields 502. These data entry fields may be rendered via user output means, e.g., on a screen, and data may be entered into the fields via user input means, e.g., a keyboard or a touch screen. Alternatively, data may be received dictated, e.g., based on voice recognition.

[0066] Alternatively or additionally, the UI elements may include one or more output information elements 503 for outputting information to the user, which may be rendered on a screen or audibly, for example.

[0067] It will be understood that the particular means of rendering the various UI elements, selecting options, and inputting data is not important. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 500 shown in FIG. 3 is only a stylized mockup, and may in fact include one or more additional UI elements that are not shown for the sake of brevity.

[0068] Node Software FIG. 4 illustrates an example of node software 450 that runs on each blockchain node 104 of the network 106 in an example UTXO or output-based model. It should be noted that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the required actions of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may run node software that includes, but is not limited to, all three of a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize different fields of a transaction 152 and process those fields according to a node protocol. Another prior transaction 152i (Tx m-1 ) j ) is received, the protocol engine 451 j The protocol engine 451 also identifies the unlock script for Tx j Based on the input pointer of Tx i Identify and extract. Tx i may be published on the blockchain 150, in which case the protocol engine may generate Tx i Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 may select Tx from the ordered set of unpublished transactions 154 maintained by the node 104. iIn any case, the protocol engine 451 may extract Tx i The script engine 452 then locates the lock script for the referenced output of the

[0069] Therefore, the script engine 452 executes the Tx i Lock script and Tx j and an unlock script from the corresponding inputs of . For example, transactions labeled Tx0 and Tx1 are shown in FIG. 2, but the same could apply to any pair of transactions. The script engine 452 executes the two scripts together as previously discussed, which includes pushing data onto and popping data from the stack 453 according to the stack-based scripting language being used (e.g., Script).

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

[0071] In an output-based model, the result "true" from the script engine 452 is one of the conditions for the validity of a transaction. j The total amount of digital assets specified in the output of Tx j and Tx iThere are also one or more further protocol-level conditions evaluated by protocol engine 451 that must also be satisfied, such as that the pointed-to output of has not already been consumed by another valid transaction. Protocol engine 451 evaluates the result from script engine 452 together with one or more protocol-level conditions, and accepts transaction Tx only if they are all true. j The protocol engine 451 outputs an indication to the application level decision engine 454 whether the transaction is valid. Tx j Only on condition that the Tx j , which may be used by the consensus module 455C to select nodes to perform their respective blockchain-related functions with respect to Tx j The propagation module 455P is added to the Tx j to another blockchain node 104 in the network 106. Optionally, in embodiments, 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 the transaction only on the condition that the transaction is valid and has sufficient transaction fees remaining.

[0072] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only one binary digit (bit), but that is certainly one possible implementation. More broadly, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates an unsuccessful or non-positive outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level approval of a signature and an additional positive output of a smart contract (where the overall outcome is considered to signal true if both individual outcomes are true).

[0073] Blockchain Signed Messages An exemplary blockchain transaction is shown generally in Table 1. The blockchain transaction may include, for example, a Bitcoin transaction. In the example of Table 1, the transaction includes two inputs and three outputs, but it will be understood that in other examples, a different number of inputs and outputs may be used.

[0074] [Table 1]

[0075] In the example of Table 1, the outpoint used at index 2 contains a pay-to-public-key-hash (P2PKH) lock script that specifies the public key P. Index 2 therefore requires an unlock script that provides a signature generated using the associated private key a and the message m.

[0076] A blockchain signature message (e.g., a Bitcoin signature message) is derived from the details of the transaction being signed. Thus, in addition to proving that the user holds the appropriate private key, the signature also guarantees the integrity of all details in the transaction contained in the signature message. If the details of the signed transaction are modified, the signature verification process fails.

[0077] In the example of Table 1, the TxID and Unlock Script fields are not included in the signed message because they must be created and / or edited after the signature is generated. The Version and Locktime fields are used to validate the details of the input that the signature is used to approve (e.g., the Outpoint j and nSeq j ) is always included in the signing message. The message may also include details of other inputs and any transaction outputs, depending on which sighash flags are used during signing.

[0078] sighash flag Figure 5 is a schematic diagram of six inputs and outputs included in a signed message using six different sighash flags. Inputs or outputs that are bracketed (surrounded by parentheses) indicate elements that are not signed. Inputs and outputs that are not bracketed (surrounded by parentheses) are included in a signed message.

[0079] Of the six sighash flag types shown in Figure 5, each sighash flag type allows the signature to selectively endorse (and determine the details of) either all inputs and outputs or various subsets. The different sets are shown in Figure 5 based on the signature that unlocks the input at index 1. The input to which the signature applies is always signed.

[0080] By way of example, a complete signature message based on the transaction shown in Table 1 and the signature for input 1 is constructed as follows: m = [Version][Hash(outpoint)][Hash(nSeq)][Outpoint k ]... [LockScriptLength k ][LockScript k ][Value k ][nSeq k ][Hash(output)]... [Lock time] [Flag]

[0081] The one-byte field Flag at the end of the message indicates a sighash flag that may correspond to one of the six sighash flag types shown in Figure 5. The fields [Hash(outpoint)], Hash(nSeq), and Hash(output) contain different information depending on the sighash flag used. If the hash field contains hashing an empty value (e.g., Hash(output) when using the NONE flag), the field value is set to 0. In such instances, the notation Hash(empty) may be used to indicate these cases.

[0082] Figure 5 shows the six sighash flag varieties and which inputs and outputs are included in the signed message for each. The top row of the table shows the "regular" sighash flag variants, which sign all inputs and ALL, NONE, or SINGLE outputs. The bottom row of the table shows the "anyone can pay" (ACP) variants, where only a single input -- the one at index 1, where the signature is placed -- is included in the signed message.

[0083] Hash Puzzle Hash Functions A hash function is a cryptographic function that transforms a variable-length input into an output of a specific length. A hash function may have the following properties: Deterministic: Using the same input always returns the same output. · Unpredictable: Small changes in the inputs result in large changes in the outputs. One-way: It is computationally infeasible to reconstruct the input given only the output. Collision-resistant: the chance that two inputs will result in the same output value is extremely small. The exact likelihood of a collision depends on the size of the output: larger outputs result in fewer collisions. Examples of hash functions include RIPEMD-160, SHA-1, and SHA-256.

[0084] Bitcoin hash puzzle Bitcoin transactions traditionally use the Pay to Public Key Hash (P2PKH) locking script, but various non-standardized locking scripts have been enabled since the Genesis upgrade in February 2020. One of these is the hash puzzle, where the locking script is configured such that a user must provide a preimage of a specific hash value in order to spend a UTXO.

[0085] For the preimage s, H 256 (s) may be a hash digest from a SHA-256 hash function. A Bitcoin hash puzzle of this value may be implemented by creating a UTXO with the following locking script: OP_SHA256 < H 256 (s) > OP_EQUALVERIFY To spend this UTXO, a user must know the value of the preimage s, which is used as the unlock script for the transaction that spends the UTXO. During validation, the SCRIPT engine concatenates the unlock script with the lock script to give: <s>OP_SHA256 <H 256 (s) > OP_EQUALVERIFY The OP_EQUALVERIFY code is SHA-256(s) = H 256 (s) It returns a value of 1 if and only if s, i.e. the transaction is valid only if the user submits a correct preimage. This style of locking script puzzle relies on the collision-resistance property of the hash function, i.e. only a user who knows the (secret) value of s can "solve" the hash puzzle.

[0086] Safety features Although the hash puzzle cannot be solved by someone who does not know the required preimage, once a transaction has been constructed by a user who knows the value of the secret preimage, the transaction must be broadcast to the Bitcoin network and published to the blockchain. After a transaction has been sent to the Bitcoin network, it is vulnerable to attack, i.e. all parties receiving the transaction details now know the secret value, which is sufficient to authorize the spending of the puzzle UTXO. As no signature is required on the unlocking script, a malicious actor may change the output details without invalidating the transaction.

[0087] To address this malleability, hash puzzles can be combined with the OP_CHECKSIG requirement to tie a UTXO to a particular user's public key. For example, let us denote the RIPEMD-160 hash of x for a user with public key P by the notation H 160Using (x), a hash puzzle lock script might be constructed as follows: OP_SHA256 < H 256 (s) > OP_EQUALVERIFY OP_DUP OP_ HASH160 <H 160 (P)> OP_EQUALVERIFY OP_CHECKSIG This puzzle requires the following inputs in the unlock script: <sig P > <s> The puzzle for this format locks a UTXO to a specific user, so that it can only be spent if the user knows the required secret preimage. The resulting transaction is then signed with a sig P It is safe against malleation of any of the values ​​included in the signed message used to create . As mentioned above, the transaction information included in the signed message may depend on the sighash flags used.

[0088] Secret Access Token FIG. 6 illustrates an example method for controlling access to a resource (e.g., a data resource) owned by a first party. The first party may include one or more users. In this example, the first party is Alice 103a. In some examples, the resource may include a data resource or a physical resource, and Alice may be an oracle, or other type of trusted third party. In some examples, a party (e.g., Bob 103b) may apply for access to the resource, and access is granted by the oracle if certain conditions are met (e.g., paying a sufficient fee or passing an identity check). In other examples, the method may be used by Bob 103b to purchase an item from Alice 103a in a transaction.

[0089] Alice 103a and Bob 103b may need to use one or more private keys throughout the protocols described in this section. A and P B refers to the overall public key from a set of single-use private-public key pairs held by Alice 103a or Bob 130b, respectively. Although they share notations, it will be understood that each key is unique.

[0090]

number

[0091] ,

[0092]

number

[0093] ,

[0094]

number

[0095] etc. refer to a single specific public key used within the protocol. Each key has a consistent representation, i.e.

[0096]

number

[0097] All instances of point to the same public key.

[0098] As part of some signature algorithms, such as the ECDSA signature algorithm, the signed message is double hashed (i.e., the SHA-256 hash algorithm is applied twice). The values ​​of both the single hash and the double hash of the signed message are defined with respect to the message m as follows: Single hash: h1= H 256 (m) Double hash: h2= H 256 (h1) = H 256 (H 256 (m)

[0099] In some examples, a hash algorithm other than the SHA-256 algorithm may be used (such as the R-puzzle algorithm or a different SHA algorithm, e.g., SHA-512). h1 may be determined by hashing the message m once using the hash algorithm, and h2 may be determined by hashing the message m a second time using the hash algorithm.

[0100] Alice 103a may be considered a first party in some instances, and Bob 103b may be considered a second party in some instances.

[0101] S|ACP Token At 611, Bob 103b sends the TxID setup Generate TxID setup In this case, Bob 103b has his public key

[0102]

number

[0103] The fee required for access is allocated to the user. Bob 103b may also include data related to his access request (e.g., encrypted identity proof) in his output OP_RETURN. The setup transaction may be published on-chain. Table 2 shows the TxID setup In all examples in this specification, TxID setup may be considered as the previous transaction.

[0104] [Table 2]

[0105] At 613, Bob 103b sends the details of the UTXO, i.e., the TxID setup || 0 and another of your public keys

[0106]

number

[0107] to Alice 103a.

[0108] At 615, Alice 103a receives the first transaction TxID sale The first transaction is Bob’s UTXO, i.e., TxID setup It may have || 0 as input and the value

[0109]

number

[0110] In some instances, Bob 103b may

[0111]

number

[0112] I don't know the details.

[0113] [Table 3]

[0114] TxID sale may be considered as the first transaction, and the previous transaction TxID setup The output of the first transaction may be locked to the public key of the first party.

[0115] At 615, Alice 103a receives the TxID sale Calculate h1 and h2, single hash and double hash of S|ACP signature message m of template of . Thus, the message is based on the template of the first transaction. Message m may be determined, for example, using: m = [Version][Hash(Outpoint0)][Hash(nSeq0)][Outpoint0][LockScriptLength0] [LockScript0][Value0][nSeq0][Hash(Output0)][Locktime][S|ACP]

[0116] As can be seen above, in this example, the S|ACP sighash flag is used.

[0117] Secret h1 may then be determined based on message m. In some examples, h1 may then be determined by hashing message m, for example, by using a SHA-256 hash.

[0118] A value based on h1, i.e., a secret, is denoted as h2. In some examples, h2 may then be determined by hashing h1, for example, by using a SHA-256 hash. Bob 103b knows the details of the input but cannot guess the details of the output defined by Alice 103a, and therefore the value h1 is unknown to Bob 103b. This allows h1 to act as a secret.

[0119] In 617, Alice 103a assigns a small value (which in some instances may be enough to cover the transaction fee of 631) to the output whose lock script hash puzzle requires secret h1 to solve. puzzle Create a.

[0120] [Table 4]

[0121] For example, a rock script puzzle might take the following form: OP_SHA256< / s> <h2> <s>OP_EQUALVERIFY P2PKH

[0122]

number

[0123] This UTXO can only be spent by Bob 103b, and only when Bob 103b knows the value of the secret h1, which is a preimage of h2. Note that it is possible for Alice 103a to generate multiple puzzle UTXOs in a single transaction, each with a unique value of h2 and associated with one user's public key.

[0124] In 619, Alice 103a receives the TxID puzzle , which is published to the first blockchain 150a. In some examples, the first blockchain 150a is the same blockchain as the second blockchain 150b. In some examples, the first blockchain 150a is a different blockchain compared to the second blockchain 150b. For example, the first blockchain 150a may be a proof-of-work blockchain and the second blockchain may be a proof-of-stake blockchain 150b, or vice versa.

[0125] At 621b, Alice 103a receives a TxID puzzle , and the value h2 to Bob 103b. Note that the information passed to Bob 103b is related to the puzzle transaction (published on-chain). sale is, at this stage, a secret held as a template by Alice 103a.

[0126] In some examples, Bob 103b may receive the value h2 from Alice 103a, as in 621b. In other examples, Bob 103b may retrieve the value h2 from the first blockchain 150a, as shown in 621a.

[0127] The value h2 now serves two purposes: the hash digest for which Bob must find the preimage to solve the access puzzle, and Bob's payment UTXO (TxID setup || 0) A double hash of the message that must be signed to authorize consumption.

[0128] At 623, Bob 103b sends the same value of h2 that Bob 103b received from Alice 103a as the TxID (if Bob 103b received the value of h2 at 621b rather than retrieving it using 621a). puzzle and the lock script is P2PKH

[0129]

number

[0130] The value of h2 received by Bob 103b from Alice 103a may be considered a candidate value. If so, Bob 103b knows that Alice 103a cannot use Bob's signature to authorize the sale transaction without revealing details of the transaction that the secret needs to access.

[0131] In 623, Bob 103b

[0132]

number

[0133] , signs h2 using the private key associated with h2 and sends the signature to Alice 103a at 625.

[0134] At 627, once all of the conditions for Bob's access are met (e.g., verifying his identity based on the data provided by Bob), Alice 103a receives the TxID generated by Alice at 615. sale , applying Bob's signature to the template. In this example, because Bob 103b signed the derived signature message using the S|ACP sighash flag, the resulting signature places no constraints on any of the information in the inputs or outputs of the other index positions. This means that Alice 103a can freely combine payments from multiple users into a single transaction without invalidating any of the users' signatures. Alice 103a may include her signature in the unlock script of the first transaction and then submit the first transaction to the second blockchain.

[0135] [Table 5]

[0136] Alice 103a publishes the sales transaction to the second blockchain 150b at 629.

[0137] At 629, Alice 103a publishes the TxID sale Alternatively or additionally, Bob 103b may notify Bob 103b when he or she is sending the TxID setup UTXO or your public key

[0138]

number

[0139] At 631, Bob 103b can identify the transaction by monitoring the blockchain 150b for the puzzle UTXO TxID puzzle Derive the secret h1 (a single hash of the S|ACP signed message based on the index, where Bob 103b’s UTXO is the input) needed to consume || 0. Bob 103b uses the published TxID sale It is also possible to determine the message m from

[0140] In 633, Bob 103b sends the TxID puzzle || TxID with 0 as input access Create a TxID. access may be considered to contain a second transaction. In some instances, this UTXO has sufficient value to cover the transaction fee for this transaction. The required unlocking script contains a valid signature and the associated public key.

[0141]

number

[0142] TxID is a secret h1 with access When is published and submitted on-chain, a purchase by Bob from Alice 103a is triggered, which may include triggering access from Alice 103a to Bob 103b.

[0143] [Table 6]

[0144] The method and system of Figure 6 ensures that Alice 103a cannot collect Bob's fees without granting Bob 103b access (or providing Bob 103b with the relevant goods or services). sale simultaneously transfers the access fee to Alice 103a and reveals the access secret to Bob 103b, performing what may be considered an atomic swap.

[0145] If Bob 103b decides to withdraw his application before this swap occurs, he will be able to use the TxID setup || An alternative transaction can be created that consumes 0. Bob's fee is refunded and the TxID sale is no longer valid, and therefore the access secret cannot be revealed on-chain. Similarly, if Bob's access conditions are not met (e.g., identity verification fails), Alice 103a can use the TxID sale Bob 103b cannot disclose the TxID setup || Keep control of 0.

[0146] The fact that the puzzle UTXO is locked to Bob's public key means that Alice 103a cannot spend the puzzle UTXO even if she knows the required secret. For this reason, the puzzle UTXO may have a dust (or even zero) value in case access is not granted to Bob 103b. However, the signing requirement is that Alice 103a must have the TxID sale Upon receiving Bob's signature for TxID, Alice 103a sale This is an important aspect of the system because it ensures that Bob 103b cannot be denied access by spending the puzzle UTXO himself before publishing TxID 103b. sale and TxID access do not share a common public key and appear independent to an outside observer, thus preserving user privacy.

[0147] In some cases, TxID puzzle In this case, it is possible to use an R-puzzle instead of a hash puzzle. The secret h1 is r = [h1 G] x It is used as an ephemeral key during the generation of the ECDSA signature, so that r is the ephemeral key for the puzzle. The puzzle locking script checks that a proper value of r was used.

[0148] Bob 103b is notified that Alice 103a has TxID sale Since we do not know the details of the output that Alice 103a defines for the charge, we cannot predict the value of the secret h1. However, the system requires that Alice 103a defines her own output address for the charge at the very beginning of the process, which cannot be changed. This means that even if Alice 103a sends access tokens for multiple users to a single TxID, sale This means that even if all inputs are combined into one, there must be a unique output defined for each input. Compared to defining a single output, this significantly increases the size of the transaction and the associated transaction fee that Alice 103a must pay.

[0149] In the section "NONE|ACP Tokens" below, some of the tokens are sent to Alice 103a as TxIDs. sale The present invention is adapted to provide flexibility in controlling the output of the

[0150] NONE|ACP token In the example described above in relation to FIG. 6, the S|ACP sighash flag is sale Used for. TxID sale A further example in which the NONE|ACP sighash flag is used rather than the S|ACP is considered below (also in relation to FIG. 6).

[0151] In 611, Bob 103b receives a unique public key from Alice 103a.

[0152]

number

[0153] Bob 103b can request the TxID setup , and TxID setup In, Bob 103b,

[0154]

number

[0155] ,

[0156]

number

[0157] , and

[0158]

number

[0159] 1. Bob 103b allocates the fee required for access to the 2-of-3 multisig account associated with the . Bob 103b may also include data related to his access request (e.g., encrypted identity proof) in his output OP_RETURN. The setup transaction is published on-chain.

[0160] [Table 7]

[0161] At 613, Bob 103b sends the details of the UTXO, i.e., the TxID setup || 0 and another of your public keys

[0162]

number

[0163] to Alice.

[0164] At 615, Alice 103a receives a TxID with multisig input but no output. sale Create a template.

[0165] [Table 8]

[0166] At 615, Alice 103a uses the standard lock time but randomizes n0 so that Bob 103b receives the TxID sale NONE|ACP does not know the full details of the input. The signed message (and its hash digest h1) is thus unique to the TxID. sale is based on information not known to Bob 103b until it is published on-chain.

[0167] Alice 103a is TxID sale Compute h1 and h2, single hash and double hash of the NONE|ACP signed message m of the template. m = [Version][Hash(Outpoint0)][Hash(nSeq0)][Outpoint0][LockScriptLength0] [LockScript0][Value0][nSeq0][Hash(empty)][Locktime][NONE|ACP]

[0168] As mentioned above, the R-puzzle may be used instead of the hash algorithm to calculate h1 and h2. It should be noted that any other suitable algorithm of the hash algorithm or the R-puzzle algorithm may be used.

[0169] At 617, Alice 103a creates a TxID with input from Alice 103a that assigns a dust value to the output with a hash puzzle of the lock script that requires secret h1 to solve. puzzle Create a.

[0170] [Table 9]

[0171] Lock script puzzles may take the following forms: OP_SHA256 <h2>OP_EQUALVERIFY P2PKH

[0172]

number

[0173] Alice 103a is TxID puzzle Sign and its TxID puzzle is published at 619. At 621b, Alice 103a publishes the TxID puzzle and the value h2 to Bob 103b, who then uses this to puzzle Alternatively, Bob 103b can retrieve the TxID from the blockchain 150a at 621a. puzzle can be directly extracted.

[0174] At 623, Bob 103b sends the same value of h2 that he received from Alice 103a as TxID puzzle and the lock script is P2PKH

[0175]

number

[0176] If so, Bob 103b knows that Alice 103a cannot use Bob's signature to authorize a sale transaction without revealing the details of the transaction from which the secret h1 that Bob 103b needs to access is derived. Bob 103b checks that

[0177]

number

[0178] (or

[0179]

number

[0180] ), and sends the signature to Alice 103a at 625.

[0181] At 627, once all conditions for Bob's access are met (e.g., verification of identity based on data provided by Bob 103b), Alice 103a receives the TxID sale Apply Bob's signature to the input. Because Bob 103b and other users signed the derived signature message with the NONE|ACP sighash flag, Alice 103a can combine payments from multiple users into a single transaction as input without invalidating any of the users' signatures. Because the output is not signed, Alice 103a can set up exactly one output that combines the fees from all users into a single address.

[0182] [Table 10]

[0183] At 627, Alice 103a adds her own signature to satisfy the multisig requirement. Alice's signature can use a sighash to sign the details of the output, such as sighash ALL, to ensure that Alice's output cannot be modified.

[0184] At 629, Alice 103a receives TxID on the chain. sale will be made public.

[0185] In 631, Bob 103b creates a TxID based on the UTXO or his public key. sale Bob identifies the puzzle UTXO TxID puzzle Derive the secret h1 (a single hash of the NONE|ACP signed message based on the index where Bob’s UTXO is the input), which is needed to spend || 0.

[0186] In 633, Bob 103b sends the TxID puzzle || TxID with 0 as input access The required unlock script is a valid signature and the associated public key.

[0187]

number

[0188] Bob 103b may include an additional input to cover the transaction fee since the puzzle UTXO had a dust value. TxID access When is published on-chain at 635, Bob's access is triggered.

[0189] [Table 11]

[0190] When using the NONE|ACP sighash flag, the user does not finalize any output details when signing h2 by basing the secret h1 on the NONE|ACP sighash flag. This is because the TxID sale This allows Alice 103a to configure the details of the output, meaning that she only needs to define a single output, which is the TxID sale This reduces transaction fees and simplifies key management for Alice. To protect the details of the output, Alice 103a can provide a signature, which in some examples can be achieved by setting the input, including the user's fee, to have a multi-sig requirement.

[0191] Alice 103a controls one key for the multisig UTXO and two signatures are required to authorize spending, so Alice 103a cannot take a fee without Bob's consent. Bob 103b controls two of the keys and therefore retains the power to abort the protocol if necessary by generating the two signatures required to spend the multisig UTXO.

[0192] NONE | ACP systems limit the number of required outputs to TxID sale While this may reduce the size of the lock, having a multisig requirement on the input may negate this due to the increased size of the unlock script. A threshold signature system could provide many of the benefits of a multisig system without increasing the size of the transaction, but it may not be applicable to the system designed here since it requires all parties to sign the same signature message (i.e., Alice 103a may not use a different sighash flag than Bob 103b).

[0193] An alternative solution that does not require the introduction of any signature from Alice 103a is for Alice 103a to sale The solution is to make an arrangement with a trusted block producer where the TxID can be published without being broadcast to the wider network. sale The input to may remain a P2PKH UTXO locked to a single user's public key, as described above in relation to Figure 6 with respect to S|ACP tokens.

[0194] Bob 103b should not be able to guess or brute force the secret value. For S|ACP tokens, Bob cannot know the details of Alice's output until the transaction is published on-chain. All P2PKH locking scripts contain a 20-byte (160-bit) public key that is considered secure enough to prevent brute force attacks. (If additional security is needed, Alice 103a may include an additional secret nonce of any size in the output locking script -- for example, using OP_PUSH, OP_DROP, or OP_RETURN -- to increase the security level.) In contrast, for NONE|ACP tokens, the output is not included in the derivation of h1 and therefore cannot be an unknown element in the signing message. Use the sequence number of the input as a value unknown to Bob 103b. However, the nSeq field is size-limited in some examples (4 bytes = 32 bits), making a brute force attack by Bob much easier to perform. Other values ​​included in the signing message are the version and the locking time. However, in some instances, these values ​​may both still be capped at 4 bytes, so that as Alice 103a sets all three values ​​randomly (and note that lock times cannot be set completely randomly without delaying transaction disclosure), the security is only 96 bits. Thus, the system described using the NONE|ACP sighash flag may be more suitable for situations where Bob's computational power is constrained, such as devices connected to an IoT network, and where the time between Alice 103a passing h2 to Bob 103b and Bob 103b performing his access is short. In situations where Bob 103b has high computational power or the time between Alice 103a passing h2 to Bob 103b and Bob 103b performing his access is long, the TxID sale It may be preferable to use the S|ACP sighash flag.

[0195] Chained Secret Access Token In some instances, the secret access tokens are chained. One use of this could be in supply chain management, where for example, as each transfer between supply chain parties occurs, a transaction is made on-chain that reveals the secret needed for the party delivering the goods to get paid. A swap may occur between the goods and the money for the supply chain step that has just been completed.

[0196] For example, consider a supply chain with an oracle, Alice 103a, two actors, Bob 103b and Charlie 103c, who are responsible for an item in the chain, and Debbie 103d, who is the last actor to receive the item. It will be appreciated that in some instances similar methods may be used with a different number of actors in the supply chain.

[0197] In some instances, the last participant, Debbie 103d, may act as the oracle for the supply chain, assuming the role assigned to Alice. The notation above applies, with each participant possessing a public key denoted by their initials as a subscript, and the key without the * superscript is the global label for the set of single-use keys belonging to the participant.

[0198] In 741a, Bob 103b, the first participant in the chain,

[0199]

number

[0200] Details of UTXOs controlled by Bob 103b on-chain related to Bob || i B ) to Alice 103a. For simplicity, let us assume that this UTXO has enough value to cover the transaction fees for the chain of transactions, with an amount of dust left behind. Bob 103b then uses another of his public keys

[0201]

number

[0202] At 741b, a party in the middle of the chain (here Charlie 103c) sends two unused public keys to Alice 103a, and at 741c, the last party in the chain, Debbie 103d, sends one unused public key to Alice 103a. Alice 103a then

[0203]

number

[0204] The participants in the chain do not know each other’s public key details.

[0205] At 743, Alice 103a creates a template for each transaction that occurs in the chain and calculates a secret based on each transaction. In this example, Alice 103a creates a template for each transaction that occurs in the chain and calculates a secret based on each transaction. chain1 (considered to be the first transaction in this example) and TxID chain2 (considered the third transaction in this example), which represent handover points in the supply chain. Alice 103a knows the details of the inputs and outputs that form these transactions, but these details are not known by the other participants in the chain.

[0206] [Table 12]

[0207] [Table 13]

[0208] From each transaction, Alice 103a can calculate the signature message to be used. Note that this could be the S|ACP sighash flag as described above, but could also be the ALL flag, since chain transactions are not expected to include any other inputs or outputs.

[0209] TxID using sighash ALL flag chain1 The message is, m1= [Version][Hash(Outpoint0)][Hash(nSeq0)][Outpoint0][LockScriptLength0] [LockScript0][Value0][nSeq0][Hash(Output0)][Locktime][ALL] From this message, Alice 103a obtains the secret value h 11 and its hash h 12 These are used as the basis of the puzzle that Bob 103b must solve to receive his payment. Alice 103a can then calculate the TxID chain2 Do the same for m2 (the second message), h 21 (Second Secret), and h 22 (a second value based on the second secret).

[0210] In 745a, Alice 103a receives TxID chain1 Send the template details to Charlie 103c only. TxID chain1 The details of the template are not sent to Bob 103b. At 745b, Alice 103a sends the TxID chain2 Send the template details to Debbie 103d only. TxID chain2 The template details are not sent to Charlie 103c.

[0211] At 747, Alice 103a creates a puzzle transaction that includes payments to Bob 103b and Charlie 103c for their roles in the supply chain. Bob 103b and Charlie 103c, as participants in the supply chain, require payment for their services. Alice 103a creates a puzzle transaction with two outputs, which may have the following locking script: Puzzle 1: OP_SHA256 <h 12 > OP_EQUALVERIFY P2PKH

[0212]

number

[0213] Puzzle 2: OP_SHA256 <h 22 > OP_EQUALVERIFY P2PKH

[0214]

number

[0215] [Table 14]

[0216] Puzzle1 and Puzzle2 may comprise independent puzzles, or Puzzle1 may comprise Puzzle2.

[0217] At 749, Alice 103a signs and publishes the puzzle transaction. Alice 103a publishes the TxID puzzle Merkle proof of and the value h 12 and to Bob 103b. Alice 103a sends TxID puzzle Merkle proof of and the value h 22 and send it to Charlie 103c.

[0218] At 751, Bob 103b transfers the item to Charlie 103c. Bob 103b uses the online TxID puzzle1 Includes your expected charges, TxID puzzle1 The public key that locks the funds is

[0219]

number

[0220] and the value of h in the puzzle script 12 is the same as the value that Alice 103a sent to Bob 103b. Bob 103b delivers the item to Charlie 103c. Bob 103b

[0221]

number

[0222] message h using the private key associated with 12 Bob 103b gives the signature to Charlie 103c, and in 753 Charlie creates a signature using the TxID chain1 You can then apply the signature to the template in TxID chain1 Bob 103b verifies that the transaction has been published, at 757, and transfers the item to Charlie 103c, at 759.

[0223] [Table 15]

[0224] At 761, Bob 103b can collect his payment. TxID chain1 From the details, Bob 103b has a TxID that contains Bob's payment. puzzle The secret needed to unlock the output of 11 can be calculated.

[0225] [Table 16]

[0226] At 763, Charlie 103c transfers the item to Debbie. Charlie 103c uses the online TxID puzzle2 Includes your expected charges, TxID puzzle2 The public key that locks the funds is

[0227]

number

[0228] and the value of h in the puzzle script 22 is the same as the value that Alice 103a sent to Charlie 103c. Charlie 103c delivers the item to Debbie 103d. Charlie 103c

[0229]

number

[0230] message h using the private key associated with 22 Charlie 103c gives the signature to Debbie 103d, who then sends the TxID chain2 A signature can be applied to the template in 766, TxID chain2 At 767, Charlie 103c verifies that the transaction has been published and transfers the item to Debbie 103d.

[0231] [Table 17]

[0232] At 771, Charlie 103c is able to retrieve his payment. TxID chain2 From the details, Charlie 103c has a TxID that includes Charlie's payment. puzzle The secret needed to unlock the output of 21 can be calculated.

[0233] [Table 18]

[0234] The method described above in relation to Figure 7 allows each party on the chain to transfer an item to a subsequent party that they know will be paid for. By waiting for the publication of the corresponding on-chain transaction on the chain, each party knows that the secret it needs to unlock its payment is available to that party.

[0235] Two parties conspire to commit fraud, for example, when Charlie 103c commits fraud with Bob 103b and TxID without any transfer of goods taking place. chain1 If Bob 103b were to agree to share the details of Debbie 104d (from which Bob 103b could determine the secrets Bob 103b needs to make the payment), Charlie 103c knows that he will not be able to deliver the goods to Debbie 104d and therefore will not receive his payment. Even if Bob 103b says he will split the fee he receives with Charlie 103c, Charlie 103c has no evidence that this will happen and therefore has no incentive to collude.

[0236] For puzzle transactions, a check may be included that the unlock script contains a signature from an expected on-chain actor to ensure that the fee cannot be stolen by another actor when the secret value is revealed on-chain. For this use case, it may be appropriate for the puzzle transaction's lock script to have a 1-of-2 multisig signature condition (with Alice 103a as one possible signer), so that funds are not locked in the puzzle UTXO if an actor on-chain does not fulfill their role. In this situation, Alice 103a is a trusted actor independent of the supply chain.

[0237] The system may be adapted to integrate information from IoT devices, e.g. a thermometer packed together with the goods, to ensure that the agreed conditions of the supply service are met. To implement this, puzzle transactions (including payments) may have a 1-of-n signature requirement (parties on the chain plus n - 1 IoT devices). All IoT devices have secret details so that they can consume the puzzle transaction at any time, and are programmed to consume the transaction under certain conditions, e.g. if the temperature of the goods exceeds a certain threshold.

[0238] Cross Chain They are linked by a secret value h2, but the TxID sale and TxID puzzle Note that the TxIDs are completely independent in terms of input and output. sale and TxID puzzle may occur on different blockchains. This allows atomic swaps to occur between two chains (e.g., blockchain 150a and blockchain 150b in the example where the blockchains are different from one another). This may be used, for example, to exchange coins or tokens of one chain for coins or tokens of another chain.

[0239] Both parties involved in the exchange must control the public keys on both chains. sale occurs on chain 1 (Table 19 below), TxID puzzle occurs on chain 2 (Table 20 below). Bob’s UTXO on chain 1 is exchanged for Alice’s UTXO on chain 2.

[0240] [Table 19]

[0241] [Table 20]

[0242] conclusion Other variations or uses of the disclosed technology will be apparent to one of ordinary skill in the art given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims.

[0243] For example, some embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain is one particular example of the blockchain 150, and the above description may apply broadly to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More broadly, all references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104 described above.

[0244] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform all the described functions of at least creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, but not all of them. That is, network entities may perform the functions of propagating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0245] In other embodiments of the invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, propagating, and storing blocks 151 of the blockchain 150. For example, on these other blockchain networks, a "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.

[0246] Even more broadly, all references above to the term “Bitcoin node” 104 may be replaced by the term “network entity” or “network element,” where such entity / element is configured to perform some or all of the roles of creating, publishing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same manner as described above in connection with the blockchain node 104.

[0247] It will be appreciated that the above embodiments have been described by way of example only. More broadly, there may be provided a method, apparatus or program according to any one or more of the following statements:

[0248] Statement 1: A method performed in a system including a first party and a second party, comprising: generating, by the first party, a first transaction template having inputs based on outputs from a previous transaction related to the second party; generating, by the first party, a message based on the first transaction template; generating, by the first party, a secret based on the message; generating, by the first party, a value based on the secret, where the secret cannot be derived from the value; generating, by the first party, a first puzzle transaction, where a first locking script of the first puzzle transaction includes a knowledge proof configured to require that an unlocking script includes the secret; 1. A method comprising: publishing a first puzzle transaction on a first blockchain; obtaining, by a second party, a value based on the secret; signing, by the second party, the value based on the secret to create a signature; sending the signature from the second party to the first party; including, by the first party, the signature in an unlock script for the first transaction and then sending the first transaction to the second blockchain; determining, by the second party, a message and a secret from the first transaction on the second blockchain; and creating, by the second party, a second transaction that unlocks a first output of the first puzzle transaction based on the secret and submitting the second transaction to the first blockchain.

[0249] Statement 2: The method according to statement 1, where the output of the first transaction is locked to the public key of the first party.

[0250] Statement 3: The method according to any preceding statement, wherein the first puzzle transaction is locked to the public key of the second party.

[0251] Statement 4: The method according to any preceding statement, wherein the step of obtaining, by the second party, a secret-based value includes obtaining, by the second party, a secret-based value from the first puzzle transaction, and the method includes the steps of receiving, by the second party, a candidate value for the secret-based value from the first puzzle transaction from the first party, and checking, by the second party, for equality of the candidate value and the secret-based value from the first puzzle transaction.

[0252] Statement 5: The method according to any preceding statement, wherein the secret includes the input and corresponding output of the first transaction.

[0253] Statement 6: The method according to any preceding statement, wherein the secret includes all inputs and all outputs of the first transaction.

[0254] Statement 7: 6. The method according to any of statements 1 to 5, wherein the secret includes the inputs of the first transaction and does not include any of the outputs of the first transaction.

[0255] Statement 8: The method according to any preceding statement, wherein the input of a first transaction unlocks a multiple signature output of a previous transaction, the multiple signature output being locked to one or more public keys of the first party and / or the second party.

[0256] Statement 9: The first transaction includes an output locked to a public key of a third party, the method comprising: generating, by the first party, a template for a third transaction that consumes the output of the first transaction; generating, by the first party, a second message based on the template of the third transaction; generating, by the first party, a second secret based on the second message; generating, by the first party, a second value based on the second secret, where the second secret cannot be derived from the second value; generating, by the first party, a second puzzle transaction, where a second locking script of the second puzzle transaction includes a knowledge proof configured to require that a second unlocking script includes the second secret; The method according to any preceding statement including the steps of: signing, by the party, a second value based on the second secret to create a second signature; sending the second signature from the third party to a fourth party; obtaining, by the fourth party, the third transaction; including, by the fourth party, the second signature in an unlock script for the third transaction and then sending the third transaction to the second blockchain; determining, by the third party, the second message and the second secret from the third transaction on the second blockchain; creating, by the third party, a fourth transaction that unlocks the output of the second puzzle transaction based on the second secret and submitting the second transaction to the first blockchain.

[0257] Statement 9A. The fifth transaction includes an output locked to a public key of a third party, the method comprising: generating, by the first party, a template for a third transaction that consumes the output of the fifth transaction; generating, by the first party, a second message based on the template of the third transaction; generating, by the first party, a second secret based on the second message; generating, by the first party, a second value based on the second secret, where the second secret cannot be derived from the second value; generating, by the first party, a second puzzle transaction, where a second locking script of the second puzzle transaction includes a knowledge proof configured to require that a second unlocking script includes the second secret; 9. A method according to any of statements 1 to 8, comprising: signing, by the party, a second value based on the second secret to create a second signature; sending the second signature from the third party to a fourth party; obtaining, by the fourth party, the third transaction; including, by the fourth party, the second signature in an unlock script for the third transaction and then sending the third transaction to the second blockchain; determining, by the third party, the second message and the second secret from the third transaction on the second blockchain; creating, by the third party, a fourth transaction that unlocks the output of the second puzzle transaction based on the second secret and submitting the second transaction to the first blockchain.

[0258] Statement 10: The method according to statement 9 or statement 9A, wherein the first puzzle transaction and the second puzzle transaction are independent puzzle transactions.

[0259] Statement 11: The method according to statement 9 or statement 9A, wherein the first puzzle transaction includes the second puzzle transaction.

[0260] Statement 12: The method according to any preceding statement, wherein the first blockchain and the second blockchain are different blockchains.

[0261] Statement 13: The method according to any preceding statement, wherein the first blockchain and the second blockchain are the same blockchain.

[0262] Statement 14: The method according to any preceding statement, wherein the secret is generated by hashing the message.

[0263] Statement 15: The method according to any preceding statement, wherein the secret is generated by using an R puzzle.

[0264] Statement 16: 1. A method performed by a first party, the method comprising: generating a first transaction template having input based on output from a previous transaction related to a second party; generating a message based on the first transaction template; generating a secret based on the message; generating a value based on the secret, where the secret cannot be derived from the value; generating a first puzzle transaction, where a first locking script of the first puzzle transaction includes a proof of knowledge configured to require that an unlocking script include the secret; publishing the first puzzle transaction to a first blockchain; receiving a signature from a second party, where the signature is created by the second party using the value based on the secret; including the signature in an unlocking script of the first transaction and then sending the first transaction to the second blockchain.

[0265] Statement 17: The method according to statement 16, wherein the output of the first transaction is locked to the public key of the first party.

[0266] Statement 18: The method according to statements 16 or 17, wherein the first puzzle transaction is locked to the public key of the second party.

[0267] Statement 19: The method according to any of statements 16 to 18, comprising the step of sending candidate values ​​based on the secret from the first puzzle transaction to the second party.

[0268] Statement 20: 20. The method according to any of statements 16 to 19, wherein the secret includes the inputs and corresponding outputs of the first transaction.

[0269] Statement 21: 21. The method according to any of statements 16 to 20, wherein the secret includes all inputs and all outputs of the first transaction.

[0270] Statement 22: 22. The method according to any of statements 16 to 21, wherein the secret includes any of the inputs of the first transaction and does not include any of the outputs of the first transaction.

[0271] Statement 23: 23. The method according to any of statements 16 to 22, wherein the input of a first transaction unlocks the multi-signature output of a previous transaction, and the multi-signature output is locked to one or more public keys of the first party and / or the second party.

[0272] Statement 24: 24. The method according to any of statements 16 to 23, wherein the first transaction includes an output locked to a public key of a third party, the method including the steps of generating a template for a third transaction that consumes the output of the first transaction, generating a second message based on the template of the third transaction, generating a second secret based on the second message, and generating a second value based on the second secret, where the second secret cannot be derived from the second value; and generating, by the first party, a second puzzle transaction, where a second locking script of the second puzzle transaction includes a knowledge proof configured to require that a second unlocking script includes the second secret.

[0273] Statement 24A: 24. The method according to any of statements 16 to 23, wherein the fifth transaction includes an output locked to a public key of a third party, the method including the steps of generating a template for a third transaction that consumes the output of the fifth transaction, generating a second message based on the template of the third transaction, generating a second secret based on the second message, and generating a second value based on the second secret, where the second secret cannot be derived from the second value; and generating, by the first party, a second puzzle transaction, where a second locking script of the second puzzle transaction includes a knowledge proof configured to require that a second unlocking script includes the second secret.

[0274] Statement 25: The method according to statement 24 or statement 24A, wherein the first puzzle transaction and the second puzzle transaction are independent puzzle transactions.

[0275] Statement 26: A method according to statement 24 or statement 24A, in which a first puzzle transaction includes a second puzzle transaction.

[0276] Statement 27: 27. The method according to any of statements 16 to 26, wherein the first blockchain and the second blockchain are different blockchains.

[0277] Statement 28: 28. The method according to any of statements 16 to 27, wherein the first blockchain and the second blockchain are the same blockchain.

[0278] Statement 29: 29. The method according to any of statements 16 to 28, wherein the secret is generated by hashing the message.

[0279] Statement 30: A method according to any of statements 16 to 29 in which the secret is generated by using an R puzzle.

[0280] Statement 31: 11. A method performed by a second party, the method comprising: obtaining a value generated by the first party based on a secret, where the secret cannot be derived from the value, the secret being based on a message generated by the first party based on a first transaction template, the first transaction template having an input based on an output from a previous transaction associated with the second party; signing the value based on the secret to create a signature; sending the signature to the first party, where the first party includes the signature in an unlocking script for the first transaction and then submits the first transaction to a second blockchain; determining the message and the secret from the first transaction on the second blockchain; and creating a second transaction by the second party that unlocks a first output of the first puzzle transaction based on the secret and submitting the second transaction to the first blockchain, where the first locking script of the puzzle transaction includes a proof of knowledge configured to require that the unlocking script include the secret.

[0281] Statement 32: The method according to statement 31, wherein the first transaction is locked to the public key of the first party.

[0282] Statement 33: The method according to statement 31 or statement 32, in which the first puzzle transaction is locked to the public key of the second party.

[0283] Statement 34: The method according to any of statements 31 to 33, wherein the step of obtaining a secret-based value includes obtaining a secret-based value from a first puzzle transaction, and the method includes the steps of receiving a candidate value for the secret-based value from the first puzzle transaction from the first party, and checking that the candidate value and the secret-based value from the first puzzle transaction are equal.

[0284] Statement 35: The method according to any of statements 31 to 34, wherein the secret includes the inputs and corresponding outputs of the first transaction.

[0285] Statement 36: The method according to any of statements 31 to 35, wherein the secret includes all inputs and all outputs of the first transaction.

[0286] Statement 37: The method according to any of statements 31 to 34, wherein the secret includes the inputs of the first transaction and does not include any of the outputs of the first transaction.

[0287] Statement 38: 38. The method according to any of statements 31 to 37, wherein the input of a first transaction unlocks the multi-signature output of a previous transaction, where the multi-signature output is locked to one or more public keys of the first party and / or the second party.

[0288] Statement 39: 39. The method according to any of statements 31 to 38, wherein the first transaction includes an output locked to a public key of a third party, the first party generating a template for a third transaction that consumes the output of the first transaction, generating a second message based on the template of the third transaction, generating a second secret based on the second message, and generating a second value based on the second secret, where the second secret cannot be derived from the second value, and generating, by the first party, a second puzzle transaction, where a second locking script of the second puzzle transaction includes a knowledge proof configured to require that a second unlocking script includes the second secret.

[0289] Statement 39A: 39. The method according to any of statements 31 to 38, wherein the fifth transaction includes an output locked to a public key of a third party, the first party performing: generating a template for a third transaction that consumes the output of the fifth transaction; generating a second message based on the template of the third transaction; generating a second secret based on the second message; and generating a second value based on the second secret, where the second secret cannot be derived from the second value; and generating, by the first party, a second puzzle transaction, where a second locking script of the second puzzle transaction includes a knowledge proof configured to require that a second unlocking script includes the second secret.

[0290] Statement 40: The method according to statement 39 or statement 39A, wherein the first puzzle transaction and the second puzzle transaction are independent puzzle transactions.

[0291] Statement 41: A method according to statement 39 or statement 39A, in which a first puzzle transaction includes a second puzzle transaction.

[0292] Statement 42: 42. The method according to any of statements 31 to 41, wherein the first blockchain and the second blockchain are different blockchains.

[0293] Statement 43: 43. The method according to any of statements 31 to 42, wherein the first blockchain and the second blockchain are the same blockchain.

[0294] Statement 44: 44. The method according to any of statements 31 to 43, wherein the secret is generated by hashing the message.

[0295] Statement 45: A method according to any of statements 31 to 44, in which the secret is generated by using an R puzzle.

[0296] Statement 46: A computing device comprising: a memory including one or more memory units; and a processing device including one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any of statements 1 to 45.

[0297] Statement 47: A computer program embodied on a computer readable storage and configured to perform the method of any of statements 1 to 45 when executed on one or more processors.

[0298] According to another aspect disclosed herein, a method may be provided that includes actions of a first user and a second user.

[0299] According to another aspect disclosed herein, a method may be provided that includes an action of a first user.

[0300] According to another aspect disclosed herein, a method may be provided that includes an action of a second user.

[0301] According to another aspect disclosed herein, a system may be provided that includes a computing device of a first user and a second user.

[0302] According to another aspect disclosed herein, there may be provided a system that includes a computing device of a first user.

[0303] According to another aspect disclosed herein, there may be provided a system that includes a computing device of a second user. [Explanation of symbols]

[0304] 100 Systems 101 Packet Switching Network 102 Computer terminals, computer equipment 102a Computer equipment 102b Computer equipment 103 Users, Parties, and Agents 103a User, original user or entity, first party, Alice 103b New user or entity, second party, Bob 103c Charlie 103d Debbie 104 Blockchain nodes, Bitcoin nodes 105 Client Applications, Software 105a Client Applications 106 Peer-to-Peer (P2P) Network, Blockchain Network, Bitcoin Network 107 Side Channel 150 Blockchain, Bitcoin Blockchain 150a The First Blockchain 150b Second Blockchain 151 Blocks of Data Blocks created before 151n-1 151n New Block 152 Transactions 152i Preceding Transaction 152j Current Transaction, New Transaction, Onward Transaction 153 Genesis Block (Gb) 154 Ordered Sets, Ordered Pools 155 Block Pointer 201 Header 202 Input 203 Output, UTXO 401 Transaction Engine 402 User Interface (UI) Layer 450 Node Software 451 Protocol Engine 452 Script Engine 453 Stack 454 Application Level Decision Engine 455 Blockchain-related functional modules 455C Consensus Module 455P Propagation Module 455S Storage Module 500 User Interface (UI) 501 UI elements, user selectable elements 502 UI elements, data entry fields 502 UI elements, information elements< / h2> < / s> < / h2>

Claims

1. 1. A method implemented in a system including a first party and a second party, comprising: generating, by the first party, a template for a first transaction having inputs based on outputs from a previous transaction related to the second party; generating, by the first party, a message based on the template for the first transaction; generating, by the first party, a secret based on the message; generating, by the first party, a value based on the secret, the secret not being derivable from the value; generating, by the first party, a first puzzle transaction, wherein a first locking script of the first puzzle transaction includes a knowledge proof configured to require that an unlocking script include the secret; publishing, by the first party, the first puzzle transaction on a first blockchain; obtaining, by the second party, the value based on the secret; signing, by the second party, the value based on the secret to create a signature; transmitting the signature from the second party to the first party; including, by the first party, the signature in the unlock script of the first transaction and then transmitting the first transaction to a second blockchain; determining, by the second party, the message and the secret from the first transaction on the second blockchain; creating, by the second party, a second transaction that unlocks a first output of the first puzzle transaction based on the secret and submitting the second transaction to the first blockchain.

2. 2. The method of claim 1, wherein an output of the first transaction is locked to a public key of the first party.

3. The method of claim 1 , wherein the first puzzle transaction is locked to the public key of the second party.

4. and the step of obtaining, by the second party, the value based on the secret includes obtaining, by the second party, the value based on the secret from the first puzzle transaction, the method comprising: receiving, by the second party, from the first party, candidate values ​​for the value based on the secret from the first puzzle transaction; 2. The method of claim 1, further comprising checking, by the second party, that the candidate value is equal to the value based on the secret from the first puzzle transaction.

5. The method of claim 1 , wherein the secret includes an input and a corresponding output of the first transaction.

6. The method of claim 1 , wherein the secret includes all inputs and all outputs of the first transaction.

7. 2. The method of claim 1 , wherein the secret includes the inputs of the first transaction and does not include any of the outputs of the first transaction.

8. 2. The method of claim 1 , wherein the input of the first transaction unlocks a multi-signature output of the previous transaction, the multi-signature output being locked to one or more public keys of the first party and / or the second party.

9. the fifth transaction includes an output locked to a public key of a third party, and the method further comprises: generating, by the first party, a template for a third transaction that consumes the output of the fifth transaction; generating, by the first party, a second message based on the template for the third transaction; generating, by the first party, a second secret based on the second message; generating, by the first party, a second value based on the second secret, wherein the second secret cannot be derived from the second value; generating, by the first party, a second puzzle transaction, wherein a second locking script of the second puzzle transaction includes a knowledge proof configured to require that a second unlocking script includes the second secret; signing, by a third party, the second value based on the second secret to create a second signature; transmitting the second signature from the third party to a fourth party; capturing, by a fourth party, the third transaction; including, by the fourth party, the second signature in an unlock script for the third transaction and then transmitting the third transaction to the second blockchain; determining, by the third party, the second message and the second secret from the third transaction on the second blockchain; and creating, by the third party, a fourth transaction that unlocks an output of the second puzzle transaction based on the second secret and submitting the second transaction to the first blockchain.

10. The method of claim 9 , wherein the first puzzle transaction and the second puzzle transaction are independent puzzle transactions.

11. The method of claim 9 , wherein the first puzzle transaction includes the second puzzle transaction.

12. The method of claim 1 , wherein the first blockchain and the second blockchain are different blockchains.

13. The method of claim 1 , wherein the first blockchain and the second blockchain are the same blockchain.

14. The method of claim 1 , wherein the secret is generated by hashing the message.

15. The method of claim 1 , wherein the secret is generated by using an R-puzzle.

16. A method performed by a first party, comprising: generating a template for the first transaction having inputs based on outputs from a previous transaction relating to the second party; generating a message based on the template for the first transaction; generating a secret based on the message; generating a value based on the secret, the secret not being derivable from the value; generating a first puzzle transaction, a first locking script of the first puzzle transaction including a knowledge proof configured to require an unlocking script to include the secret; publishing the first puzzle transaction on a first blockchain; receiving a signature from the second party, the signature being created by the second party using the value based on the secret; including the signature in the unlock script of the first transaction and then sending the first transaction to a second blockchain.

17. 17. The method of claim 16, wherein an output of the first transaction is locked to a public key of the first party.

18. 17. The method of claim 16, wherein the first puzzle transaction is locked to the public key of the second party.

19. 17. The method of claim 16, further comprising the step of transmitting the candidate value based on the secret from the first puzzle transaction to the second party.

20. 17. The method of claim 16, wherein the secret includes an input and a corresponding output of the first transaction.

21. 17. The method of claim 16, wherein the secret includes all inputs and all outputs of the first transaction.

22. 17. The method of claim 16, wherein the secret includes the inputs of the first transaction and does not include any of the outputs of the first transaction.

23. 17. The method of claim 16, wherein the input of the first transaction unlocks a multi-signature output of the previous transaction, the multi-signature output being locked to one or more public keys of the first party and / or the second party.

24. the fifth transaction includes an output locked to a public key of a third party, and the method further comprises: generating a template for a third transaction that consumes the output of the fifth transaction; generating a second message based on the template of the third transaction; generating a second secret based on the second message; generating a second value based on the second secret, the second secret not being derivable from the second value; and generating, by the first party, a second puzzle transaction, wherein a second locking script of the second puzzle transaction includes a proof of knowledge configured to require that a second unlocking script include the second secret.

25. 25. The method of claim 24, wherein the first puzzle transaction and the second puzzle transaction are independent puzzle transactions.

26. 25. The method of claim 24, wherein the first puzzle transaction includes the second puzzle transaction.

27. 17. The method of claim 16, wherein the first blockchain and the second blockchain are different blockchains.

28. 17. The method of claim 16, wherein the first blockchain and the second blockchain are the same blockchain.

29. 17. The method of claim 16, wherein the secret is generated by hashing the message.

30. The method of claim 16, wherein the secret is generated by using an R-puzzle.

31. obtaining, by a second party, a value generated by a first party based on a secret, the secret not being derivable from the value, the secret being based on a message generated by the first party based on a template of a first transaction, the template of the first transaction having inputs based on outputs from a previous transaction associated with the second party; signing, by the second party, the value based on the secret to create a signature; sending the signature from the second party to the first party, where the first party includes the signature in an unlock script for the first transaction and then sends the first transaction to a second blockchain; determining, by the second party, the message and the secret from the first transaction on the second blockchain; creating, by the second party, a second transaction that unlocks a first output of a first puzzle transaction based on the secret and submitting the second transaction to a first blockchain, wherein a first locking script of the first puzzle transaction includes a proof of knowledge configured to require that an unlocking script include the secret; The template of the first transaction, the secret, and the first puzzle transaction are generated by the first party.

32. 32. The method of claim 31, wherein the first transaction is locked to a public key of the first party.

33. 32. The method of claim 31, wherein the first puzzle transaction is locked to the public key of the second party.

34. The step of obtaining the value based on the secret includes obtaining the value based on the secret from the first puzzle transaction, the method comprising: receiving from the first party a candidate value for the value based on the secret from the first puzzle transaction; 32. The method of claim 31, comprising checking for equality between the candidate value and the value based on the secret from the first puzzle transaction.

35. 32. The method of claim 31 , wherein the secret includes an input and a corresponding output of the first transaction.

36. 32. The method of claim 31 , wherein the secret includes all inputs and all outputs of the first transaction.

37. 32. The method of claim 31 , wherein the secret includes the inputs of the first transaction and does not include any of the outputs of the first transaction.

38. 32. The method of claim 31 , wherein the input of the first transaction unlocks a multi-signature output of the previous transaction, the multi-signature output being locked to one or more public keys of the first party and / or the second party.

39. The fifth transaction includes an output locked to a public key of a third party, the first party: generating a template for a third transaction that consumes the output of the fifth transaction; generating a second message based on the template for the third transaction; and generating a second secret based on the second message; generating a second value based on the second secret, the second secret not being derivable from the second value; 32. The method of claim 31, further comprising: generating, by the first party, a second puzzle transaction, wherein a second locking script of the second puzzle transaction includes a knowledge proof configured to require that a second unlocking script include the second secret.

40. 40. The method of claim 39, wherein the first puzzle transaction and the second puzzle transaction are independent puzzle transactions.

41. 40. The method of claim 39, wherein the first puzzle transaction includes the second puzzle transaction.

42. 32. The method of claim 31 , wherein the first blockchain and the second blockchain are different blockchains.

43. 32. The method of claim 31 , wherein the first blockchain and the second blockchain are the same blockchain.

44. 32. The method of claim 31 , wherein the secret is generated by hashing the message.

45. 32. The method of claim 31 , wherein the secret is generated by using an R-puzzle.

46. a memory including one or more memory units; 46. ​​A computing device comprising: a processing device including one or more processing units, the memory storing code arranged to be executed on the processing device, the code being configured, when on the processing device, to perform the method of any one of claims 1 to 45.

47. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 45 when executed on one or more processors.

Images