Consensus on the Blockchain

Abstract

1. A computer-implemented method for recording an agreement between a requestor and a verifier on a blockchain, the computer-implemented method comprising: generating a request transaction, executed by the requestor, the request transaction including an input signed by the requestor and a first output including a cryptographic puzzle based on at least a first data item known to both the requestor and the verifier, the first data item representing the agreement; and causing the request transaction to be sent to one or more blockchain nodes.

Description

Technical Field

[0001] The present disclosure relates to a method of recording an agreement between a requesting party and a confirming party on a blockchain, and more particularly, to proving the commitment to the agreement by both parties.

Background Art

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

[0003] Transactions in a blockchain are used to perform one or more of the following, namely, the transfer of digital assets (i.e., a number of digital tokens), the ordering of a set of journal entries of a virtual ledger or registry, the receipt and processing of timestamp entries, and / or the time-ordering of index pointers. The blockchain can also be utilized to stack additional functionality on top of the blockchain. The blockchain protocol may allow for the storage of additional user data or an index to data within a transaction. There is no predefined limit to the maximum data capacity that can be stored in a single transaction, and thus, even more complex data can be incorporated. For example, this may be used to store electronic documents on the blockchain or to store audio or video data.

[0004] Nodes of a blockchain network (often referred to as "miners") perform a distributed transaction registration and verification process described in detail below. Briefly, during this process, nodes approve transactions and insert them into a block template that attempts to identify a valid proof-of-work solution for them. When a valid solution is found, a new block is propagated to other nodes in the network, thus enabling each node to record the 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 in the network for propagation. A node that receives a transaction may compete to find a proof-of-work solution that incorporates the approved transaction into a new block. Each node is configured to enforce the same node protocol that includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated and are not incorporated into blocks. Assuming that a transaction is approved and thereby accepted into the blockchain, the transaction (including any user data) is then registered and indexed as an immutable public record at each of the nodes of the blockchain network.

[0005] Nodes that succeed in solving the proof-of-work puzzle to create the latest block are generally rewarded by a new transaction called a "coinbase transaction" that distributes a certain amount of digital assets, i.e., some tokens. The detection and rejection of invalid transactions are enforced by the actions of competing nodes acting as agents of the network, which are incentivized to report and block improper behavior. The extensive public disclosure of information enables users to continuously audit the performance of nodes. The mere disclosure of block headers enables participants to ensure the ongoing integrity of the blockchain.

[0006] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. All spendable outputs include an element that specifies an amount of digital assets derivable from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs (unspent transaction outputs). An output may further include a lock script that specifies the conditions for future redemption of the output. A lock script is a predicate that defines the conditions necessary to authorize and transfer a digital token asset. Each input of a transaction (other than a coinbase transaction) includes a pointer (i.e., a reference) to such an output of a previous transaction and may further include an unlocking script to unlock the lock script of the indicated output. Thus, consider a pair of transactions, called the first transaction and the second transaction (or "target" transaction). The first transaction includes at least one output that specifies an amount of digital assets and includes a lock script that defines one or more conditions for unlocking the output. The second, target transaction includes at least one input that includes a pointer to the output of the first transaction and an unlocking script for unlocking the lock script of the output of the first transaction.

[0007] In such a model, when a second, target transaction is transmitted to the blockchain network so as to be propagated and recorded within the blockchain, one of the criteria of validity applied at each node is that the unlock script satisfy all of one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not already been fulfilled by another previous valid transaction. Any node that determines that the target transaction is invalid according to any of these conditions does not propagate the transaction (except in some cases where an invalid transaction may be propagated for the purpose of registering it), and does not include the transaction in a new block so as to be recorded on the blockchain.

[0008] An alternative kind of transaction model is the account-based model. In this case, each transaction defines the amount being transferred not by referring backward to the UTXOs of previous transactions within the sequence of past transactions, but by referring to the absolute balance of an account. The current state of all accounts is stored and constantly updated by a node separate from the blockchain.

Prior Art Documents

Patent Documents

[0009]

Patent Document 1

Patent Document 2

Non-Patent Documents

[0010]

Non-Patent Document 1

Non-Patent Document 2

Summary of the Invention

Means for Solving the Problems

[0011] A blockchain can be used to record an agreement between two parties (e.g., a legal contract). For example, the agreement may be included in a transaction, which is made public on the blockchain when submitted to the blockchain network. This is useful, but it is beneficial to be able to evidence that both parties have given their explicit commitment or approval regarding the agreement. This “proof of consent” may be used by both parties to the agreement for purposes such as contract enforcement, dispute resolution, etc.

[0012] According to one aspect disclosed herein, a method implemented by a computer for recording an agreement between a requesting side and a confirming side on a blockchain, the method comprising: a step of being executed by the requesting side to generate a request transaction, the request transaction including an input signed by the requesting side and a first output including a cryptographic puzzle based on at least a first data item known to both the requesting side and the confirming side, the first data item representing the agreement; and a step of causing the request transaction to be sent to one or more blockchain nodes.

[0013] According to one aspect disclosed herein, a method implemented by a computer for recording an agreement between a requesting party and a verifying party using a blockchain, the method comprising: a step of being executed by the verifying party to generate a verification transaction, wherein the verification transaction includes an input referring to the output of a request transaction, the output of the request transaction is known to both the requesting party and the verifying party, includes a cryptographic puzzle based on a first data item representing the agreement, and the input of the verification transaction includes the first data item; and a step of causing the verification transaction to be sent to one or more blockchain nodes. A method implemented by a computer is provided.

[0014] The requesting party (e.g., Alice) sets a cryptographic puzzle that requires knowledge of the agreement that Alice wishes to conclude with the verifying party (e.g., Bob) in order to be solved. That is, the request transaction submitted to the blockchain network by Alice includes an output that includes the cryptographic puzzle. For the output to be unlocked, the input of Bob's transaction that refers to the output must include the solution to the cryptographic puzzle. As an example, the cryptographic puzzle may be a hash puzzle that requires Bob to provide the hash of the agreement or, alternatively, the agreement itself.

[0015] To accept the agreement, Bob generates a verification transaction that includes an input that includes the solution to the cryptographic puzzle. Due to the nature of the cryptographic puzzle, Alice's puzzle is unlocked only by a unique solution, e.g., the agreement or the hash of the agreement. Thus, by providing the unique solution, Bob gives his commitment to the agreement. On the other hand, if Alice and Bob have actually concluded different agreements (e.g., with different terms or conditions), Bob's solution will not unlock Alice's puzzle. This warns both Alice and Bob that the requested agreement has not been verified.

[0016] A particular use case of the present invention is in the field of license agreements, for example, the licensing of intellectual property (IP). Bob may be the owner of the IP, and Alice may want to license the IP. Alice can request a license for the IP by submitting a request transaction to a blockchain network. The request transaction includes a cryptographic puzzle based on a license agreement (LA) for the IP. For example, the hash puzzle may include the double hash of the LA. If Bob agrees to grant Alice a license for the IP under the terms of the LA, he submits a confirmation transaction containing the solution to the cryptographic puzzle, for example, the hash of the LA, to the blockchain network. The public disclosure of the request and confirmation transactions on the blockchain serves as an immutable record of the mutual commitment of both parties to the LA.

[0017] It was noted that although it was explained from the perspective of the licensee generating the request transaction and the licensor generating the confirmation transaction, the possibility that the roles could be reversed was not excluded. That is, the licensor may generate a request transaction that serves as an offer of the LA, and the licensee may generate a confirmation transaction that serves as an acceptance of the LA.

[0018] To assist in the understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, the accompanying drawings are referred to only by way of example.

Brief Description of the Drawings

[0019]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

[0020] Overview of Exemplary System FIG. 1 shows an exemplary system 100 for implementing a blockchain 150. The system 100 may be composed of a packet-switching network 101, typically a wide-area internetwork such as the Internet. The packet-switching network 101 includes a plurality of blockchain nodes 104 that may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switching network 101. Although not shown, the blockchain nodes 104 may be arranged as a near-complete graph. Thus, each blockchain node 104 is closely connected to other blockchain nodes 104.

[0021] Each blockchain node 104 includes peer computer devices, and different nodes among the nodes 104 belong to different peers. Each blockchain node 104 includes a processing device including one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors and / or field programmable gate arrays (FPGAs), and other devices such as application-specific integrated circuits (ASICs). Each node also includes a memory, i.e., computer-readable storage in the form of one non-transitory computer-readable medium or a plurality of non-transitory computer-readable media. The memory may include one or more memory media, such as magnetic media such as hard disks, electronic media such as solid state drives (SSDs), flash memories, or EEPROMs, and / or one or more memory units employing optical media such as optical disk drives.

[0022] The blockchain 150 includes a chain of data blocks 151, and a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 of the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing all of the blockchain 150. Instead, as long as each blockchain node 150 stores the block headers (discussed below) of each block 151, the blockchain 150 may be pruned of data. Each block 151 of the chain includes one or more transactions 152, and in this context, a transaction refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one specific 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 representing a digital asset as property, an example of which is a user 103 whose output is cryptographically locked (requiring the user's signature or other resolution to be unlocked and thereby fulfilled or consumed). Each input points backward to an output of a previous transaction 152, thereby linking the transactions.

[0023] Each block 151 also includes a block pointer 155 that points backward to the previously created block 151 in the chain to define a sequential order up to block 151. (Except for the coinbase transaction) Each transaction 152 includes a pointer back to the 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 goes back to the genesis block (Gb) 153 that was the first block of the chain. One or more initial transactions 152 of the initial chain 150 pointed to the genesis block 153 rather than a previous transaction.

[0024] Each of the blockchain nodes 104 is configured to transfer the transaction 152 to other blockchain nodes 104, thereby propagating the transaction 152 throughout the network 106. Each blockchain node 104 is configured to create a block 151 and store a respective copy of the same blockchain 150 in the respective memory of those blockchain nodes 104. Also, each blockchain node 104 maintains an ordered set 154 of transactions 152 that are waiting to be incorporated into the block 151. The ordered set 154 is often referred to as the "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 obliges the node 104 to accept as valid and not accept any other transaction that the node 104 attempts to consume the same output.

[0025] In a given current transaction 152j, each input includes a pointer that references an output of a preceding transaction 152i within the sequence of transactions, specifying that this output is to be fulfilled or "consumed" in the current transaction 152j. Generally, the preceding transaction can be any transaction within an ordered set 154 or any block 151. The preceding transaction 152i need not necessarily exist even at the time the current transaction 152j is created or when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be approved. Thus, "preceding" as used herein refers to a predecessor in a logical sequence linked by pointers and does not necessarily refer to the time of creation or transmission in a temporal sequence, and thus does not necessarily exclude the possibility that transactions 152i, 152j are created or sent out of order (see the discussion below regarding orphan transactions). The preceding transaction 152i may similarly be referred to as an antecedent or predecessor transaction.

[0026] The input of the current transaction 152j also includes authorization of the input, e.g., the signature of user 103a whose output of the previous transaction 152i is locked. And in turn, the output of the current transaction 152j can be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount defined by the input of the previous transaction 152i to the new user or entity 103b as defined by the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to divide the input amount among multiple users or entities, one of which may be the original user or entity 103a to pass on the change. In some cases, the transaction may also have multiple inputs to gather amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0027] According to an output-based transaction protocol such as Bitcoin, when an entity 103 such as a user or a machine wants to define a new transaction 152j, the entity sends a new transaction to the recipient from its computer terminal 102. The entity or the recipient ultimately sends this transaction to one or more of the blockchain nodes 104 of the network 106 (which are currently generally servers or data centers, but in principle could be other user terminals). It is also not excluded that the entity 103 that defines the new transaction 152j may send the transaction to one or more of the blockchain nodes 104 and, in some cases, not to the recipient. The blockchain node 104 that receives the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol generally requires that the blockchain node 104 check that the cryptographic signature of the new transaction 152j matches the expected signature that depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking that the cryptographic signature or other authorization of the entity 103 included in the input of the new transaction 152j matches the conditions defined by the output of the previous transaction 152i that the new transaction allocates, which generally includes at least checking that the cryptographic signature or other authorization of the input of the new transaction 152j unlocks the lock of the output of the previous transaction 152i to which the input of the new transaction is linked. The conditions may be at least partially defined by a script included in the output of the previous transaction 152i. Alternatively, the conditions may be determined solely by the blockchain node protocol or by a combination of these.In any case, if the new transaction 152j is valid, the blockchain node 104 transfers it to one or more other blockchain nodes 104 of the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and thus transfer the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0028] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated 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 previous transaction 152i that it attempts to allocate or fulfill has not already been allocated / fulfilled by another transaction. Again, if not valid, the transaction 152j is not propagated (unless flagged as invalid for warning purposes and propagated) and is not recorded on the blockchain 150. This prevents double-spending where a person making a transaction attempts to allocate the output of the same transaction more than once. On the other hand, an account-based model prevents double-spending by maintaining the balance of the account. Again, since there is a defined order of transactions, the balance of the account always has a single defined state.

[0029] In addition to approving transactions, blockchain node 104 will further compete to become the node that first creates a block of transactions in a process commonly called mining, which is supported by "proof of work". At blockchain node 104, new transactions are added to an ordered set 154 of valid transactions that do not yet appear in block 151 recorded on blockchain 150. Then, the blockchain node attempts to assemble a new valid block 151 of transactions 152 from the ordered set 154 of transactions by trying to solve a cryptographic puzzle. Generally, this involves searching for a "nonce" value such that when the nonce is concatenated with the representation of the ordered set 154 of transactions and hashed, the output of the hash meets a certain condition. For example, the certain condition may be that the output of the hash has a certain predefined number of leading zeros. It should be noted that this is just one particular type of proof of work puzzle, and other puzzles are not excluded. The characteristic of the hash function is that the hash function has an unpredictable output for its input. Therefore, this search can only be performed by brute force and thus consumes a significant amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0030] The first blockchain node 104 that solves the puzzle notifies this to the network 106 and provides a solution as a proof that can then be easily checked by the other blockchain nodes 104 of the network (it is easy to check whether a given solution of a hash satisfies the condition for the output of the hash). The first blockchain node 104 accepts the block and thus propagates the block until a consensus of the threshold of the other nodes that enforce the protocol rules. Then, the ordered set of transactions 154 comes to be recorded as a new block 151 on the blockchain 150 by each of the blockchain nodes 104. Also, a block pointer 155 that points backward to the previously created block 151n-1 in the chain is assigned to the new block 151n. The significant amount of effort, for example, in the form of a hash, required to create a proof of work, informs of 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 the transaction assigns the same output as a previously approved transaction, also known as double-spending. Once created, the block 151 is recognized and maintained at each of the blockchain nodes 104 of the blockchain network 106 and thus cannot be modified. Also, the block pointer 155 gives a sequential order to the blocks 151. Since the transactions 152 are recorded in the ordered blocks of each blockchain node 104 of the network 106, this thus provides an immutable public ledger of the transactions.

[0031] At any given time, different blockchain nodes 104 competing to solve a puzzle may do so based on different snapshots of an ordered set 154 of transactions that have not yet been published at that given time, depending on when those blockchain nodes 104 began searching for a solution or the order in which the transactions were received. Note that whoever solves their respective puzzle first defines which transactions 152 are included in the next new block 151n and in what order, and the current set 154 of unpublished transactions is updated. Then, the blockchain nodes 104 continue to compete to create a block from the newly defined set 154 of unprocessed, ordered, unpublished transactions, and so on. There is also a protocol for resolving any potential "forks" that occur, where a fork is the point at which two blockchain nodes 104 solve their blockchain node 104 puzzles within a very short time of each other, such that opposing views of the blockchain are propagated among the nodes 104. Briefly, the arm of the fork that becomes the longest of either will be the final blockchain 150. Note that this should not affect the network's users or agents since the same transactions appear in both forks.

[0032] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is given the ability to allocate an amount of digital assets recognized in a new special type of transaction that distributes a defined amount of digital assets (as opposed to an agent - to - agent or user - to - user transaction that transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction", but may also be called an "initiation transaction". This special type of transaction generally forms the first transaction of a new block 151n. Proof - of - work announces the intention of the node constructing the new block to follow the protocol rules that enable this special transaction to be fulfilled later. The rules of the blockchain protocol may require a maturity period, for example, 100 blocks, before this special transaction can be fulfilled. Often, a normal (non - generation) transaction 152 also specifies an additional transaction fee in one of its outputs to give further reward to the blockchain node 104 that created the block 151n in which the transaction was published. This fee is usually called a "transaction fee" and is discussed below.

[0033] Due to the resources involved in transaction approval and publication, generally, each of the blockchain nodes 104 takes the form of a server that includes 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 networked user terminals together.

[0034] The memory of each blockchain node 104 stores software configured to execute its respective one or more roles according to the blockchain node protocol and to be executed on the processing device of the blockchain node 104 to process the transaction 152. It will be understood that all actions attributable to the blockchain node 104 herein may be performed by software executed on the processing device of each respective computing device. The node software may be implemented in one or more applications of the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

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

[0036] Some or all of the stakeholders 103 may be connected as part of a network that is overlaid on a different network, such as the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be said to be part of a system that includes the blockchain network, but these users do not perform the roles required of a blockchain node and are not blockchain nodes 104. Instead, each stakeholder 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. For illustrative purposes, two stakeholders 103 and their respective devices 102 are shown, namely, a first stakeholder 103a and its respective computer device 102a, and a second stakeholder 103b and its respective computer device 102b. There may be many additional such stakeholders 103 and their respective computer devices 102 that exist and participate in the system 100, but it will be understood that, for the sake of convenience, they are not shown. Each stakeholder 103 may be an individual or an organization. For purely illustrative purposes, the first stakeholder 103a is referred to herein as Alice and the second stakeholder 103b is referred to as Bob, but this is not limiting, and it will be understood that all references herein to Alice or Bob may be replaced by "first stakeholder" and "second stakeholder", respectively.

[0037] The computer device 102 of each stakeholder 103 includes one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs, each processing device. The computer device 102 of each stakeholder 103 further includes a memory, i.e., computer-readable storage in the form of one 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, such as magnetic media like hard disks, SSDs, electronic media like flash memory or EEPROM, and / or optical media like optical disk drives. The memory of the computer device 102 of each stakeholder 103 stores software including respective instances of at least one client application 105 arranged to be executed on the processing device. It will be understood that all actions attributable to a given stakeholder 103 herein may be performed using software executed on the processing device of the respective computer device 102. The computer device 102 of each stakeholder 103 includes at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device such as a smartwatch. The computer device 102 of a given stakeholder 103 may also include one or more other networked resources, such as cloud computing resources accessible via the user terminal.

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

[0039] The client application 105 includes at least a "wallet" function. This has two main functions. One of these is to enable each stakeholder 103 to create, approve (e.g., sign) a transaction 152 and then propagate it across the network of blockchain nodes 104 so that it is sent to one or more Bitcoin nodes 104 to be included in the blockchain 150. The other is to return to each stakeholder a report of the amount of digital assets that the stakeholder currently owns. In an output-based system, this second function involves collating the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to the stakeholder in question.

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

[0041] Instances of client applications or software 105 on each computer device 102 are coupled to be operable with at least one of the blockchain nodes 104 of network 106. This enables the wallet function of client 105 to send transaction 152 to network 106. Also, client 105 can contact blockchain nodes 104 to query the blockchain 150 (or in an embodiment, since the blockchain 150 is a public facility that provides some trust for transactions by its public visibility, to indeed inspect the transactions of other parties within the blockchain 150) regarding any transaction where each respective party 103 is the recipient. The wallet function of each computer device 102 is configured to assemble and send transaction 152 according to a transaction protocol. As described above, each blockchain node 104 executes software configured to approve transaction 152 according to a blockchain node protocol and transfer transaction 152 to propagate transaction 152 throughout 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 blockchain 150. The same node protocol is used by all nodes 104 of network 106.

[0042] When a given party 103, e.g., Alice, wants to send a new transaction 152j to be included in the blockchain 150, that party 103 assembles a new transaction according to the relevant transaction protocol (using the wallet function of that party 103's client application 105). Then, that party 103 sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which it is connected. For example, this could be a blockchain node 104 that is optimally connected to Alice's computer 102. Any given blockchain node 104, when receiving a new transaction 152j, processes that 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 for it 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 transaction-by-transaction basis by a script included in the transaction 152. Alternatively, the conditions may simply be an embedded feature of the node protocol or defined by a combination of the script and the node protocol.

[0043] On the condition that the newly received transaction 152j passes the test to be considered valid (i.e., on the condition that the newly received transaction 152j is "approved"), all blockchain nodes 104 that receive the transaction 152j add the newly approved transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Further, all blockchain nodes 104 that receive the transaction 152j propagate 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, assuming that the transaction 152j is valid, this means that the transaction 152j is quickly propagated throughout the network 106.

[0044] Once placed in the ordered set 154 of transactions maintained at a given blockchain node 104, that blockchain node 104 starts a competition to solve the proof-of-work puzzle for the latest version of those ordered sets 154 of transactions that include the new transaction 152 (although other blockchain nodes 104 may be trying to solve puzzles based on different ordered sets 154 of transactions, recall that whoever succeeds first defines the ordered set of transactions included in the latest block 151. Eventually, the blockchain node 104 solves the puzzle for a part of the ordered set 154 that includes Alice's transaction 152j). When proof-of-work is performed on the ordered set 154 that includes the new transaction 152j, the ordered set 154 becomes part of one of the blocks 151 of the blockchain 150 in an immutable manner. Each transaction 152 includes a pointer back to the previous transaction and is thus recorded in an immutable order as well.

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

[0046] Alternative types of transaction protocols employed by some blockchain networks may be referred to as "account - based" protocols as part of an account - based transaction model. In the account - based case, each transaction defines the amount being transferred by referring to the absolute account balance, rather than by referring backward to the UTXOs of previous transactions within the sequence of past transactions. The current state of all accounts is stored and constantly updated by nodes of that network separate from the blockchain. In such a system, transactions are ordered using the running transaction tally (also called the "position") of an 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 signed with the transaction. This data field may point backward to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0047] UTXO - based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO - based protocol. Transaction 152 (abbreviated as "Tx") is a basic data structure of 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. Note that the exemplary UTXO - based protocol is described in relation to Bitcoin, but may be implemented similarly in other exemplary blockchain networks.

[0048] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure that contains one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source for an input 202 of another new transaction (if the UTXO has not already been spent). A UTXO includes a value that specifies an amount of digital assets. This represents the set number of tokens on the distributed ledger. A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also include a header 201 that may contain an indicator of the sizes of the input field 202 and the output field 203. The header 201 may also include the transaction ID. 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.

[0049] Suppose Alice 103a wants to create a transaction 152j to transfer an amount of the digital assets in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". Transaction 152j obtains the amount of digital assets locked to Alice in the output 203 of a preceding transaction 152i in the sequence and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction on the blockchain 151 or that Tx1 is the very next transaction in the pool 154. Tx1 may point backward to any preceding (i.e., ancestor) transaction that still has an unspent output 203 locked to Alice.

[0050] The prior transaction Tx0 may already be approved and included in block 151 of the blockchain 150 when Alice creates her new transaction Tx1 or at least until Alice sends that new transaction Tx1 to the network 106. The prior transaction Tx0 may then already be included in one of the blocks 151 or may still be waiting within the ordered set 154, in which case the prior transaction Tx0 is immediately included in the new block 151. 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 buffering of "orphan" transactions. The terms "prior" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions within the sequence as defined by the transaction pointers specified in the transactions (which transaction points to which other transaction backwards, etc.). Those terms may be equivalently replaced by terms such as "predecessor" and "successor", or "ancestor" and "descendant", "parent" and "child". 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 refers to a prior transaction (ancestor transaction or "parent") is not approved until the parent transaction is approved and is not approved unless it is approved. A child that arrives at the blockchain node 104 before its parent is considered an orphan. That child may be discarded or may be buffered for a certain time waiting for the parent, depending on the node protocol and / or the behavior of the node.

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

[0052] The lock script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A particular example of such a language is called "Script" (with a capital S) used by the blockchain network. The lock script specifies what information is required to consume the transaction output 203, for example, specifying the need for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to meet the criteria of the lock script. For example, the unlocking script may include Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0053] Thus, in the illustrated example, the UTXO0 of the output 203 of Tx0 includes a lock script [Checksig P A that requires Alice's signature Sig P A for the UTXO0 to be fulfilled (strictly speaking, for a subsequent transaction attempting to fulfill UTXO0 to be valid). Ais the public key P from Alice's public-private key pair A and includes a representation (i.e., a hash) thereof. The input 202 of Tx1 includes a pointer that points backward to Tx0 (e.g., in an embodiment, the Tx0 transaction ID, TxID0, which is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 within Tx0 to identify UTXO0 among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlock script <Sig P A > that includes Alice's cryptographic signature created by applying her private key from the key pair to a predefined portion of the data (which may be referred to as a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination thereof.

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

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

[0056] If the unlock script of Tx1 meets one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, when 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 set 154 of transactions. Also, the blockchain node 104 transfers 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. When Tx1 is approved and included in the blockchain 150, this defines the UTXO0 from Tx0 as used. Note that Tx1 can be valid only 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. Thus, the blockchain node 104 also needs to check whether the referenced UTXO of the previous transaction Tx0 has already been consumed (i.e., whether that UTXO has already formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose the order defined in the transaction 152. In practice, a given blockchain node 104 may maintain a separate database indicating which UTXO203 of which transaction 152 has been consumed, but ultimately, what defines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction within the blockchain 150.

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

[0058] Note that in a UTXO - based transaction model, a given UTXO must be used in its entirety. A given UTXO cannot "leave behind" a portion of the amount defined as used in the UTXO while another portion is consumed. However, the amount from a UTXO can be split among multiple outputs of the next 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 all of the amount defined in UTXO0, she can give herself change in the second output of Tx1 or pay someone else using the remainder.

[0059] In practice, Alice will usually also need to include a fee to the Bitcoin node that publishes her transaction 104. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104, and thus, strictly speaking, although valid, it may not be propagated and may not be included in the blockchain 150 (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., does not require a separate UTXO). Instead, any difference between the total amount indicated by the inputs 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 that transaction. For example, assume that the pointer to UTXO0 is the only input to Tx1 and Tx1 has only one output UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that publishes the block containing UTXO1. However, it is not necessarily excluded that, alternatively or additionally, the transaction fee may be explicitly specified in its own UTXO203 among the UTXOs 203 of the transaction 152.

[0060] The digital assets of Alice and Bob consist of UTXOs locked to Alice and Bob 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. Nowhere in the blockchain 150 is there a single number that defines the total balance of a given party 103. It is the role of the wallet function within the client application 105 to collate the values of all the various UTXOs locked to each party and not yet spent in another onward transaction. The wallet function can do this by querying a copy of the blockchain 150 stored in one of the Bitcoin nodes 104.

[0061] Note that script code is often represented schematically (i.e., not using exact language). For example, operation codes (opcodes) may be used to represent certain functions. "OP_..." refers to a specific opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that can create a non-consumable output of a transaction that can store data within the transaction when OP_FALSE precedes it at the start of the lock script, thereby recording the data in the blockchain 150 in a non-modifiable way. For example, the data could include a document that is desired to be stored on the blockchain.

[0062] Generally, the input of a transaction is the public key P AIt includes a digital signature corresponding thereto. In 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 part of the transaction input and part or all of the transaction output. The specific part of the output that the signature signs is determined according to the SIGHASH flag. The SIGHASH flag is usually a 4-byte code included at the end of the signature (and thus determined at the time of signing) to select which output is signed.

[0063] The lock script may be called "scriptPubKey", generally indicating the fact that it contains the public keys of the parties for which each transaction is locked. The unlock script may be called "scriptSig", generally indicating the fact that it supplies the corresponding signature. However, more generally, it is not essential in all applications of the blockchain 150 that the conditions for a UTXO to be fulfilled include authenticating the signature. More generally, a scripting language may be used to define any one or more conditions. Thus, the broader terms "lock script" and "unlock script" may be preferred.

[0064] As shown in FIG. 1, each client application of the computer devices 102a, 120b of Alice and Bob may include additional communication functions. This additional function enables Alice 103a to establish a separate side channel 107 with Bob 103b (either by the recommendation of a party or a third party). The side channel 107 enables the exchange of data separately from the blockchain network. Such communication is sometimes referred to as "off-chain" communication. For example, this may be used to exchange a transaction 152 between Alice and Bob while the transaction is (still) not registered in the blockchain network 106 or not progressing towards the chain 150 until one of the parties chooses to broadcast the transaction 152 to the network 106. Sharing a transaction in this way is sometimes referred to as "sharing a transaction template". The 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.

[0065] Side channel 107 may be established via the same packet switching network 101 as blockchain network 106. Alternatively or additionally, side channel 107 may be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless link between the devices 102a, 102b of Alice and Bob. Generally, any side channel 107 referred to herein may include one or more links via one or more networking technologies or communication media that are "off-chain", i.e., separate from blockchain network 106, for exchanging data. If two or more links are used, a bundle or set of off-chain links may be referred to as side channel 107 as a whole. Thus, it should be noted that when it is said that Alice and Bob exchange certain information or data via side channel 107, this does not necessarily imply that all of this data must be transmitted on exactly the same link or even the same type of network.

[0066] Client software Figure 3A shows an exemplary implementation of client application 105 for implementing embodiments of the presently disclosed approach. Client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. Transaction engine 401 is configured to implement transaction-related functions fundamental to client 105, such as assembling transaction 152, receiving and / or transmitting transactions and / or other data via side channel 107, and / or transmitting a transaction to one or more nodes 104 for propagation through blockchain network 106, in accordance with the approach discussed above and as will be discussed in further detail below. According to embodiments disclosed herein, the transaction engine 401 of each client 105 includes functionality 403 for generating one, some, or all of request transactions, confirmation transactions, refund transactions, revocation transactions, update transactions, and advertisement transactions, as will be discussed below.

[0067] The UI layer 402 is configured to provide a user interface via the user input / output (I / O) means of each user's computer device 102, including outputting information to each user 103 via the user output means of device 102 and receiving input coming back from each user 103 via the user input means of 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 haptic output devices for providing haptic output. The user input means may include, for example, one or more touch screens (the same or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech 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 including one or more mechanical buttons, switches, or joysticks.

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

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

[0070] By way of example, FIG. 3B shows 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.

[0071] For example, the UI element may include one or more selectable elements 501 that may be buttons on different screens or different options in a menu, etc. The user input means is arranged to enable a user 103 (in this case, Alice 103a) to select one of the options or otherwise operate it, such as by clicking or touching a UI element on the screen or by saying the name of the desired option (note that the term "manual" as used herein is only intended to contrast with automatic and is not necessarily limited to the use of one or more hands). The options can include the data required for one, some, or all of the user-requested transactions, confirmation transactions, refund transactions, cancellation transactions, update transactions, and advertising transactions, as discussed below.

[0072] Alternatively or additionally, the UI element may include one or more data input fields 502 through which the user can input the above-mentioned data. These data input fields are rendered on the screen, for example, via the user output means, and the data can be input into the fields via the user input means, such as a keyboard or touch screen. Alternatively, the data may be received orally, for example, based on voice recognition.

[0073] Alternatively or additionally, the UI element may include the output of one or more information elements 503 for outputting information to the user. For example, these may be rendered on the screen or audible.

[0074] It will be understood that the specific means of rendering various UI elements, selecting options, and entering data are not important. The functions of these UI elements will soon be examined in more detail. The UI 500 shown in FIG. 3 is only a schematic mock-up and it will also be understood that in practice it may include one or more additional UI elements not shown for the sake of simplicity.

[0075] Preparation Cryptographic hash function Hash functions are widely used in blockchain implementations as a means of mapping data of any length to a fixed-length string. Generally, cryptographic hash functions are used to ensure that this is done securely and that the outputs of these hash functions are unique. Generally, a hash function is considered to be cryptographically secure if it has the following properties. 1. Pre-image resistant -- Given h = H(m), it is computationally difficult to find m. 2. Second pre-image resistant -- Given h = H(m) and m, it is computationally difficult to find m' such that H(m') = h. 3. Collision resistant -- It is computationally difficult to find a pair of messages m and m' such that H(m) = H(m').

[0076] On the blockchain 150, the transaction identifier TxID is usually generated using the SHA-256 cryptographic hash function and thus inherits the digest properties of the hash function.

[0077] Hash puzzle A commonly used technique in constructing lock scripts is the hash puzzle. These puzzles are a simple scripted challenge that forces the assignee to provide the correct preimage X of a given hash digest H(X) set by the assignor. These puzzles are described as follows. [Hash Puzzle H(X)] = OP_SHA256 <H(X)> OP_EQUAL

[0078] Storage of Data on the Blockchain As the adoption of blockchain technology expands along with the scaling infrastructure to support it, there is a growing interest in inserting large amounts of data onto the blockchain 150. It is indeed possible to store data on the blockchain 150 through the use of various fields of the blockchain transaction 152. Storing data on the blockchain 150 can generally be done in one of two ways: either by using the non-consumable OP_RETURN opcode or by using the OP_DROP statement.

[0079] According to some blockchain protocols, since OP_RETURN causes the execution of the script to fail, the transaction output marked by the OP_RETURN opcode is known as a provably unspendable output. According to other blockchain protocols, transaction outputs are made provably unspendable by marking the output with the opcodes OP_FALSE OP_RETURN, or OP_0 OP_RETURN. As used herein, "OP_RETURN" is used as an abbreviation for "OP_FALSE OP_RETURN" or "OP_0 OP_RETURN". Thus, it is possible to store any data after such an opcode in a lock script of the following type. OP_RETURN <d> It is not a requirement for the blockchain node 104 to execute all scripts following the OP_RETURN opcode, that is, this method of storing data has the advantage that it does not need to meet any format requirements normally applied to the data stored in a part of the script.

[0080] An alternative method that can be used to store data in the blockchain transaction 152 is to use the OP_DROP opcode. This is OP_PUSHDATA D OP_DROP which can be used in a lock or unlock script of the form, which is usually <d>OP_DROP As such, the OP_PUSHDATA opcode can be more simply expressed by replacing it with curly brackets that enclose the data element pushed onto the stack.

[0081] However, note that the data stored in such a script is subject to script-level checks incorporated by script execution and transaction approval.

[0082] Use of Multisig Scripts It is possible to construct a transaction lock script that can be unlocked by providing any m-of-n signatures corresponding to m out of n specific public keys. The conditions for the lock script of such a multisig transaction are described as follows. [CheckMultisig m-of-n] = OP_m <p1>... <P n > OP_n OP_CHECKMULTISIG This multi-signature lock script can be used to embed data by replacing a subset of the public keys P1... P n with other data. The multi-signature lock script can be used to embed n - 1 data elements using only one valid public key P. This is described schematically as follows. [CheckMultisig 1-of-n] = OP_1 <d1>... <D n-1 > OP_n OP_CHECKMULTISIG

[0083] Consensus on the blockchain FIG. 4 shows an exemplary system 400 for implementing an embodiment of the present invention. As shown, system 400 includes a requesting side 401, a confirmation side 402, and a blockchain network 106 (i.e., one or more blockchain nodes 104). According to an embodiment, the requesting side 401 is configured to generate a request transaction and submit the request transaction to the blockchain network 106 (or otherwise cause the request transaction to be submitted to the blockchain network 106). The confirmation side 402 is configured to generate a confirmation transaction and submit the confirmation transaction to the blockchain network 106 (or otherwise cause the confirmation transaction to be submitted to the blockchain network 106). As also shown in FIG. 4, the confirmation side 402 may generate an advertisement transaction and submit the advertisement transaction to the blockchain network 106. In some examples, the requesting side 401 and the confirmation side 402 may communicate using off-chain communication methods.

[0084] The requesting side 401 and the confirmation side 402 may perform some or all of the actions associated with the above-described Alice 103a and / or Bob 103b. For example, the requesting side 401 may be regarded as equivalent to Alice 103a, the confirmation side 402 may be regarded as equivalent to Bob 103b, or vice versa. In that sense, each of the requesting side 401 and the confirmation side 402 may operate each of the computing devices 102 on which their respective client applications 105 are executed. It will be understood that all actions described as being performed by the requesting side 401 or the confirmation side 402 may be performed by their respective client applications 105 or, more broadly, by their respective computing devices 102.

[0085] In an embodiment, the requesting side 401 wishes to reach an agreement with the verifying side 402. The requesting side 401 wants to ensure that the verifying side 402 agrees to exactly the same agreement as desired by the requesting side 401. To do so, the requesting side generates a request transaction. The request transaction is a blockchain transaction. The request transaction includes one or more inputs and one or more outputs. At least one output (the first output) includes a hash puzzle based on the agreement. More generally, the hash puzzle is based on a data item (the first data item) representing the agreement. Here, the first data item may encode or otherwise compress the agreement. For example, the first data item may include at least the hash of the agreement (and optionally additional data). In other examples, the first data item may include the agreement (e.g., be the agreement).

[0086] In some examples, the "agreement" between the two may be based on static information such as standard terms and conditions, a confidentiality agreement, a waiver signed by any user, etc. In other words, the agreement may be generated by only one of the parties involved.

[0087] In other examples, the agreement may be generated by both. That is, both the requesting side and the verifying side may have contributed to what could have been an agreement based on an initial version proposed by one of the parties, e.g., a negotiated contract.

[0088] The hash puzzle included in the request transaction is in either case based on the final form of the agreement. The final form of the agreement may be the same as the advertised contract (discussed in more detail below). Alternatively, the final form may have been the result of mediation, negotiation, etc. by the requesting side 401, the verifying side 402, and / or an independent third party.

[0089] The first data item is known to both the requesting side 401 and the verification side 402. That is, both the requesting side 401 and the verification side 402 can access the agreement represented by the first data item.

[0090] The hash puzzle of the first data item A may take the following form. [Hash Puzzle H(A)] = OP_SHA256 <H(A)> OP_EQUAL The opcode OP_SHA256 is configured to hash the input using the SHA-256 hash function. Generally, a hash puzzle may include an opcode configured to hash the input using a different hash function. For example, the OP_SHA256 opcode of the above hash puzzle may be replaced with any one of OP_RIPEMD160, OP_SHA1, OP_HASH160, OP_HASH256, or any other hash opcode that may become available.

[0091] As described above, when executed together with the input script of a later transaction, the hash puzzle requires that the input script contain the first data item A.

[0092] The request transaction may include an input generated by the requesting side 401, for example, a signature generated using a private key owned by the requesting side 401. The signature may sign one or more inputs and / or one or more outputs of the request transaction.

[0093] In some examples, the first output of a request transaction may include one or more additional hash puzzles. For example, a hash puzzle based on the item to be agreed upon (the second data item) may be included in the first output. Here, the item to be agreed upon may take any form, such as an image file, a video file, an audio file, a text document, computer code, etc. More generally, the second data item may represent the content that is to be provided (e.g., purchased or licensed) under the terms of the agreement. The second data item may include the content itself or at least the hash of the content.

[0094] Additionally or alternatively, the first output may include a hash puzzle based on a third data item representing the identifier of the requesting side 401. For example, the identifier may be a public key corresponding to a private key owned by the requesting side 401. The identifier may take a more common form, such as a name, an address, an email address, etc. The third data may include the identifier or the third data item may include at least the hash of the identifier.

[0095] In order to unlock the first output, the requesting side 401 may further lock the first output with the public key of the verifying side 402 such that an input attempting to unlock the lock of the first output must include a signature generated based on the private key owned by the verifying side 402 corresponding to the public key.

[0096] The request transaction may further include one or more data elements. For example, the request transaction may include one, several, or all of the following: namely, the hash of the agreement, the double hash of the agreement, the hash of the identifier of the requesting side, the double hash of the identifier of the requesting side, the hash of the identifier of the confirming side, the double hash of the identifier of the confirming side, an indicator (e.g., a flag) indicating that the request transaction is a request transaction, and a reference to an advertisement transaction (e.g., its TxID) (discussed below). Some or all of the data elements may be included in the first output using, for example, the OP_DROP statement. Some or all of the data elements may be included in the second output. The second output may be a non-consumable output, for example, an output of OP_RETURN.

[0097] In some examples, the first output may include an additional part of the script that allows the first output to be unlocked in more than one way. For example, the first output may include an if-else statement (or equivalent). The first branch of the if-else statement may include the hash puzzle described above. The second branch may be locked to a public key, for example, the public key of the requesting side 401 or the public key of the confirming side 402. For example, an output locked to the public key of the requesting side 402 may be a P2PK or P2PKH output. In some examples, the second branch may include a multi-signature script locked to one or more of the public key of the requesting side and the public key of the confirming side.

[0098] The requesting side 401 sends the request transaction to one or more blockchain nodes 104. Instead, the requesting side 401 may send the request transaction to another party (e.g., the confirming side 402) for transfer to one or more blockchain nodes 104. Assuming that the request transaction meets the requirements of the blockchain protocol for being a valid transaction, the request transaction is published on the blockchain 150.

[0099] The verification side 402 obtains a reference to the request transaction, for example, the transaction identifier of the request transaction. The verification side 402 generates a verification transaction. The verification transaction includes one or more inputs and one or more outputs. The first input of the verification transaction references the first output of the request transaction. The first input includes a solution to a hash puzzle based on the first data item. That is, the first input includes the first data item.

[0100] The first input of the verification transaction may also include one or more additional solutions if the request transaction includes one or more additional hash puzzles. For example, the first input of the verification transaction may include a second data item and / or a third data item.

[0101] The first input of the verification transaction may also include a signature generated by a private key owned by the verification side 402, for example, if the first output of the request transaction is locked to a corresponding public key.

[0102] The verification transaction may include a first output locked to the public key of the verification side. For example, the output is a P₂PK or P₂PKH output. The public key may be the same public key to which the first output of the request transaction is locked, but preferably, it is a different public key.

[0103] The confirmation side 402 sends the request transaction to one or more blockchain nodes 104. Instead, the confirmation side 402 may send the request transaction to another party (e.g., the request side 401) for transfer to one or more blockchain nodes 104. Assuming that the confirmation transaction meets the requirements of the blockchain protocol for being a valid transaction, if the first input of the confirmation transaction contains the data required to unlock the lock of the first output of the request transaction, the request transaction is published on the blockchain 150.

[0104] Once the confirmation transaction is published on the blockchain 150, it evidences the mutual commitment to the agreement by both the request side 401 and the confirmation side 402. The mutual commitment is confirmed in the sense that the confirmation transaction is published if it contains the solution to the hash puzzle, and for this, both the request side 401 and the confirmation side 402 must have the same first data item generated based on the same agreement.

[0105] As discussed above, both the request transaction and the confirmation transaction may include their respective signatures generated by the request side 401 and the confirmation side 402 respectively. That is, the request transaction may include, in the input, a signature that signs part or all of the request transaction. Similarly, the confirmation transaction may include, in the input, a signature that signs part or all of the confirmation transaction.

[0106] Preferably, the signature of the request side signs the request transaction, i.e., the message including the first output of the transaction including the hash puzzle, and the signature of the confirmation side refers to the first input of the request transaction, i.e., the input that refers to the first output of the confirmation transaction and unlocks the lock, and signs the message including this input.

[0107] These signatures may be interpreted as signing the agreement itself, as opposed to signing a copy of the agreement on paper. This is because the message signed by the signature on the confirmation side generally must also necessarily include the first output script of the claim transaction. This means that the signature actually signs both the first output of the claim transaction (or at least the lock script of the first output). For further information, see https: / / wiki.bitcoinsv.io / index.php / OP_CHECKSIG. OP_CHECKSIG is an opcode that verifies ECDSA signatures. OP_CHECKSIG takes two inputs from the stack, the public key (at the top of the stack), and the ECDSA signature in its DER_CANONISED format concatenated with the sighash flag. OP_CHECKSIG outputs true or false to the stack based on whether the signature check passes or fails.

[0108] Note that the signature cannot sign itself, i.e., the signature usually does not sign the input script that contains the signature, so the data of the first input of the confirmation transaction, e.g., H(IP) or H(LA), is generally not signed by the signature on the confirmation side.

[0109] This concept effectively forces both parties to (at least partially) sign the same message, and the part of the message that both sign includes the representation of the agreement.

[0110] In some examples, the first output of the claim transaction may include one or more opcodes configured to separate a portion of the lock script. One such opcode is OP_CODESEPERATOR (OCS). See, for example, https: / / wiki.bitcoinsv.io / index.php / OP_CODESEPARATOR. OCS may be used to enable the verification side 402 to select only the agreement (or expression of agreement, e.g., the double hash of the first data item or the entire hash puzzle) from the first output of the claim transaction for signing. For example, a hash puzzle based on the first data item may be placed between the OCS opcode and the OP_CHECKSIG opcode. This enables the data between the OCS opcode and the OP_CHECKSIG opcode to be signed by the signature included in the first input of the verification transaction.

[0111] Two exemplary lock scripts that may be included in the first output of the claim transaction are given below. In the first example, OP_CODESEPARATOR is used to help a third party sign only a portion of the previous lock script. In an alternative example, the lock script enables the verification side to sign only a portion of the transaction that is of interest to the verification side. (Lock script (within claim transaction): OP_CHECKSIGVERIFY <H(LA)> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG (Unlock script (within verification transaction): <Sig B> <PK B> <Sig A> <PK A> Explanation: - PK A may be the public key of the verification side - <Sig A> signs the message including 「<H(LA)> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG」 - PK B is a public key of a third party, which may be, for example, a copyright attorney or a witness. - <Sig B> signs a message that does not include the entire script within the above brackets. - OP_CODESEPARATOR ensures that <Sig B> does not need to sign any of the previous lock scripts to the left of OP_CODESEPARATOR. Or, alternatively, (Lock script (within the request transaction)): OP_CHECKSIGVERIFY <OTHER DATA> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG <H(LA)> (Unlock script (within the confirmation transaction)): <Sig A> <PK A> <Sig B> <PK B> Explanation: - This is similar to the first scenario, but the order of the signers is reversed, and the lock script includes some <OTHER DATA> that the confirmation side does not need to sign. - <OTHER DATA> may be, for example, a witness declaration that needs to be signed by a witness but not by the chief signatory (i.e., the confirmation side). - <Sig B> (signed by a third party, such as a copyright attorney, witness, etc.) signs the entire script "OP_CHECKSIGVERIFY <OTHER DATA> <OP_DROP> OP_CODESEPARATOR OP_CHECKSIG <H(LA)>" obtained from the output of the request transaction. - <Sig A> (signed by the confirmation side) signs a message that includes the bit of interest <H(LA)> but excludes <OTHER DATA>, only the part of the request output script "OP_CHECKSIG <H(LA)>".

[0112] In some embodiments, the requesting side 401 may generate a refund (or cancel) transaction to unlock the first output of the request transaction. This has the effect of removing the first output from the set of unspent transaction outputs (UTXOs) on the blockchain. This also has the effect of preventing the confirmation side 402 from unlocking the first output by solving a hash puzzle.

[0113] If the first output of the request transaction includes a branch of a lock script locked to the public key of the requesting side 401, the first input of the refund transaction may include a signature generated using the corresponding private key. If the first output of the request transaction includes a branch of a lock script (e.g., a multi-signature script) locked to multiple public keys, the first input of the refund transaction may include multiple signatures, e.g., a signature generated using the private key owned by the requesting side 401 and a signature generated using the private key owned by the confirmation side 402.

[0114] In some examples, the requesting side 401 may generate a refund transaction template that includes an input referencing the first output of the request transaction, and then send the refund transaction to the confirmation side 402. Then, the confirmation side may add a signature to the first input of the refund transaction and refund the signed transaction to the request transaction. At that time, the requesting side 401 may include a signature in the first input of the request transaction. When the requesting side 401 wants to cancel the agreed-upon request, the requesting side 401 sends the completed refund transaction to the blockchain network 106 or to another party for transfer to the blockchain network 106.

[0115] As an optional feature, a refund transaction may include a time limit (or time lock). The time limit is configured to prevent the refund transaction from being published to the blockchain 150 until a specified period of time has elapsed. For example, the time limit may set a time (e.g., measured in UNIX time) before which the refund transaction cannot be published. Alternatively, the time limit may set a block (e.g., measured by block height) before which the refund transaction cannot be published.

[0116] Similarly, the confirmation side 402 may generate a cancellation transaction to unlock the lock of the first output of the confirmation transaction. If the first output of the confirmation transaction is locked to the public key of the confirmation side 402, the first input of the cancellation transaction may include a signature generated using the corresponding private key. The cancellation transaction is interpreted as a cancellation of the agreement between the request side 401 and the confirmation side 402. Thus, when the confirmation side 402 wants to cancel the agreement, the confirmation side 402 sends the cancellation transaction to the blockchain network 106 or to another party for transfer to the blockchain network 106.

[0117] In some embodiments, the confirmation side 402 may generate an advertisement transaction, for example, to advertise the agreement. The advertisement transaction has one or more inputs and one or more outputs. At least the first input of the inputs includes a signature generated using a private key owned by the confirmation side 402. As described above, the confirmation side 402 may use the same private key for all signatures generated by the confirmation side 402, or the confirmation side 402 may use different private keys for one or more signatures generated by the confirmation side 402. The advertisement transaction also includes a first output that includes an expression of the agreement and / or an encrypted version of the agreement.

[0118] The expression of the agreement may be the hash of the agreement or the double hash of the agreement. The agreement may be expressed in other ways. The encrypted version may be generated by encrypting the agreement using the public key owned by the verification side 402 or the public key owned by the request side 401. In some examples, the agreement may be encrypted using a key owned by both, for example, a symmetric key. In some examples, the output may include the agreement itself.

[0119] An advertising transaction may include one or more additional inputs each including a signature generated using a private key owned by each respective party, for example, an additional party to the advertised contract.

[0120] An advertising transaction may include an indicator (e.g., a flag) indicating that the advertising transaction is an advertisement of an agreement. The indicator may be included in the first output or a different output of the advertising transaction. The first output (or a different output) of the advertising transaction may include an expression (e.g., a hash or double hash) of the subject of the agreement and / or an encrypted version. In some examples, the output may include the subject of the agreement itself.

[0121] An advertising transaction may include an output (e.g., the first output or a different second output) locked to the public key of the verification side 402. For example, the output locked to the public key of the verification side 402 may be a P2PK or P2PKH output.

[0122] To advertise the agreement, the verification side 402 sends the advertising transaction to the blockchain network 106 or to another party for transfer to the blockchain network 106.

[0123] Additionally or alternatively, the confirmation side 402 may advertise the agreement (or potential agreement) off-chain, i.e., without using the blockchain network 106. For example, the confirmation side 402 may send the (potential) agreement directly to the request side 401 via, for example, the side channel 107. As another example, the confirmation side 402 may advertise the (potential) agreement on a website, such as a company website, a social media site, etc. It is not excluded that the confirmation side 402 notifies the request side 401 of the agreement in person or by phone.

[0124] Regardless of how the agreement is advertised, the advertised agreement may or may not be the same as the final agreement based on the hash puzzle. For example, the advertised agreement included in the advertisement transaction may be different from the "final agreement" used in the lock script of the request transaction and the unlock script of the confirmation transaction.

[0125] For example, the final agreement may be based on an initial agreement used as a starting point and may have gone through one or more revisions, for example, Final agreement = Agreement + Negotiated additions Or, alternatively, Final agreement = Agreement + Negotiated additions - Negotiated deletions = Agreement + Negotiated changes There may be.

[0126] The hash puzzle is important for enforcing mutual understanding of what the final form of the agreement actually is when the agreement is requested and confirmed, rather than when it is advertised.

[0127] The confirmation side 402 may want to update the advertised agreement, i.e., may want to change one or more terms of the agreement. To do so, the confirmation side 402 refers to the second output of the advertisement transaction and generates an update transaction that includes an input to unlock the lock. Thus, the input of the update transaction may include a signature generated using the private key corresponding to the public key for which the output of the advertisement transaction is locked. The update transaction also includes an output that includes a representation of the updated agreement and / or an encrypted version. The update transaction may include an indicator (e.g., a flag) indicating that the update transaction is an advertisement of the updated agreement. In some examples, the output may include the updated agreement. To update the agreement, the confirmation side 402 sends the update transaction to the blockchain network 106 or to another party for transfer to the blockchain network 106.

[0128] In the above-described embodiments, an example of a hash puzzle was used, but it should be noted that generally, all references to "hash puzzle" may be replaced with "cryptographic puzzle". That is, a hash puzzle is an example of a cryptographic puzzle, and embodiments of the present invention may use any form of cryptographic puzzle. Generally, a cryptographic puzzle may include any one-way function. For example, as described above, the cryptographic puzzle may be a hash puzzle that includes a hash function.

[0129] In other examples, the cryptographic puzzle may be an r-puzzle or an r-challenge. The r-puzzle is described in detail in PCT / IB2020 / 053807, and the reader is referred to this. A brief description of the r-puzzle will be given below.

[0130] The r-puzzle is based on a reference value corresponding to the r part of an ECDSA signature as the basis of a challenge (i.e., the puzzle). The reference value is included in the lock script of the request transaction as a challenge that requires the confirmation transaction to include a signature containing the specified r part to unlock the lock of the request transaction (i.e., in the unlock script of the confirmation transaction). By providing a solution to the r-puzzle in the confirmation transaction, this proves that the confirmation side must have known the corresponding ephemeral key k, but without the need to reveal k in the confirmation transaction. Thus, k can be used as an ephemeral private key, and r acts like the corresponding ephemeral public key.

[0131] In other words, the r-puzzle is a knowledge proof based on the verification function of the Elliptic Curve Digital Signature Algorithm ECDSA. The lock script of the request transaction includes an element specifying a reference instance of the r part of the first ECDSA signature. The confirmation transaction includes information containing at least the s part of the first ECDSA signature and the first public key. The first ECDSA signature signs a message based on the first private key corresponding to the first public key, and the message is part of the confirmation transaction. The request transaction unlocks the lock on the condition that the verification function of ECDSA applied to the first ECDSA signature verifies that the s part received in the confirmation transaction corresponds to the reference instance of the r part specified by the request transaction, given the message received in the confirmation transaction and the obtained first public key.

[0132] The elements included in the request transaction may be the reference instance itself of the r part, or its conversion result, for example, the hash of the component including the r part (the component to be hashed may be, for example, simply equal to the r part itself, or may be concatenated with other data value d). Therefore, it should be noted that "specified" in this context does not necessarily mean including an explicit value (although it is undoubtedly one possible implementation). More generally, the element may be equal to the reference instance of the r part or any element derived from the reference instance of the r part (for example, its hash) that enables checking whether the submitted instance of the s part corresponds effectively to the reference instance according to the verification algorithm of ECDSA.

[0133] The "solution to the r puzzle" proves that the verifying side must have known the ephemeral key k (it is considered impossible that the solution could be provided without the knowledge of k). The ephemeral key may be generated based on an agreement or otherwise may represent an agreement.

[0134] The function of the hash puzzle can be emulated by utilizing the r part of an ECDSA signature which may be an ephemeral random value. An ECDSA signature consists of two main parts r and s. As is well known to those skilled in the art, r = [k·G] x where. Instead of the normal hash puzzle h = H(d), the difficulty of finding the inverse of the elliptic curve addition can form a similar puzzle called the r puzzle herein. To solve this puzzle, it is necessary to obtain the solution value k, which is the ephemeral key corresponding to r.

[0135] In the normal hash puzzle, the risk is to reveal d on the blockchain when solving the puzzle. However, in the r puzzle, k is not revealed. Instead, r is revealed and from r together with the signature, the knowledge of k can be proven.

[0136] To emulate the functionality of a hash puzzle, since the creator of the r-puzzle must have k of a fixed size while the preimage data of the hash puzzle can be of any length (and one property of a hash function is to output a value of fixed length regardless of the length of the input data), first, some other preimage data may be hashed to obtain the value k. For example, when using a private / temporary key that is 256 bits in length, the preimage data of the r-puzzle should be hashed to obtain k. Alternatively, however, a value of some suitable length for k can be selected and used directly as a secret value itself (i.e., it need not be derived from some other preceding preimage).

[0137] In a script language, the OP_CHECKSIG opcode requires a signature and a public key on the stack (the public key is at the top of the stack and the signature is immediately below it). For the r-puzzle, the script is configured to check that the r value of the provided signature is the same r value used in the challenge of the r-puzzle. In other words, the script not only checks (through OP_CHECKSIG) that the signature is valid with respect to the public key, but also verifies that the signature was created using the r value of the r-puzzle that should have been made public on the blockchain beforehand.

[0138] Next, some exemplary implementations of the r-puzzle are considered. In each case, the prover, e.g., Bob, has already created the signature (r, s) by signing a part of Tx2. A signature of this form is sometimes also called "sig". In the context of cryptographic signatures, the signed part is also called the "message" (m). The signed part (message) m includes at least the output of Tx2 that locks the resulting payment to Bob. If there are two or more outputs, m may include some or all of the outputs. m may also include other parts such as locktime when used. However, m usually excludes the unlock script itself (and of course, at least the signature itself must be excluded). The part of Tx2 that is signed as message m can be set by Sighash or can be a default or a defined feature of the protocol.

[0139] In a simple implementation, the lock script of Tx1 includes a reference instance or r part, here labeled as r'. In this way, the unlock script of Tx2 only needs to include at least the s part of Bob's signature. The unlock script of Tx2 may also include the public key P corresponding to the private key V that Bob used to sign m. When the lock script of Tx1 is executed by the script engine of node 104, it obtains s and P from the unlock script of Tx2 and performs the following operations, namely, I) R' = H sig (m)s -1 ·G + r's -1 ·P, and II) [R'] x = r' is checked and is configured to perform, where r' is obtained from the lock script of Tx1, and s and m are obtained from the unlock script of Tx2. Bob's public key P may be obtained from the unlock script of Tx2 or may be known by other means. H sig is the hash function used to hash m when generating the first ECDSA signature. H sig can be any form of hash function. Whatever form it is, the form (type) of this hash function is predetermined and may be assumed to be known to both. G is a predetermined publicly known vector value.

[0140] The lock script is configured to return a "true" result on the condition that the check is true, and a "false" result otherwise. In the case of UTXO, a true (i.e., successful) result of executing the lock script together with the unlock script is a requirement for the validity of the transaction. Therefore, the validity of Tx2 can be used as a proxy for the result of the r-puzzle. In other words, the validity of Tx2 is conditional on providing a solution to the r-puzzle. That is, if Bob fails the r-puzzle, Bob's transaction Tx2 will not be propagated on the network 106 and will not be recorded in the blockchain 150 (and any payment defined in the output of Tx1 will not be fulfilled).

[0141] This example may be the simplest in a mathematical sense, but this does not necessarily mean that it is the easiest to integrate with any given node protocol or scripting language. Consumers who have <r, s> and In contrast, in the unlock script <s>and< / s> <s>When only providing this, the script must take this into account. Operations I) to II) are not the operations of a standard Checksig type opcode. The OP_CHECKSIG opcode expects the signature to be in DER format and thus, <s>If only values are provided in the unlock script, some additional opcodes (such as OP_CAT for concatenation) are required in the lock script to generate a valid signature in DER format. Note also that in all possible embodiments, it is not essential to include P in Tx2. In fact, from the knowledge of the message m and (r, s) or in this case (r', s), it is possible to calculate two possible values of the public key, P and -P (however, it is impossible to know which is which). Then, two verifications can be used to identify which is the correct one, or alternatively, a 1-bit flag can be included in Tx2 to indicate which of the two possible solutions should be used.

[0142] In other examples, the cryptographic puzzle may be a private key puzzle. The private key puzzle is described in detail in WO2020065460, and the reader is referred to this. A brief description of the private key puzzle will be given hereinafter.

[0143] A private key puzzle is a function of an unlock script that evaluates to true when an input that reveals the private key S1 of a given public key P1 is provided. This form of puzzle is desirable as it allows the exploitation of the algebraic properties of an elliptic curve cryptography (ECC) public / private key pair.

[0144] The private key of ECC

[0145]

Number

[0146] Consider the corresponding public key P1, where n is the order of the base point G of the elliptic curve. The public key and the private key are given by the equation P1 = S1·G associated by, and the operator "·" represents the multiplication of points on the elliptic curve. Given P1, even if the parameters of the elliptic curve are known, it is a computationally difficult problem to determine S1. In fact, there is a one-way deterministic function S1 → P1 exists.

[0147] Something equivalent to a hash puzzle can be constructed with respect to the public / private key pair. This private key puzzle is the corresponding private key <s1>It is a function <Solve P1> that is evaluated as true when operating based on <s1><Solve P1> = TRUE This requires an operator (e.g., opcode) that performs the multiplication of points on an elliptic curve. Such an operator is hereinafter labeled "OP_ECMULT". This means that a point on the elliptic curve, e.g., the generator point G, is multiplied by a positive integer, e.g.,

[0148] [Number]

[0149] which means being multiplied by <s1> <g>OP_ECMULT = <p1> In this case, the private key puzzle is given by the following. <Solve P1> = <g>OP_ECMULT <p1>OP_EQUALLVERIFY

[0150] Currently, a single opcode that can execute the OP_ECMULT function does not exist in some scripting languages (e.g., Script), but it is trivial to create and include such a function. Furthermore, those languages include all the operators required to perform elliptic curve multiplication within Script, i.e., to construct OP_ECMULT using other operators.

[0151] When the private key is generated based on or represents an agreement, it can be seen that for the private key puzzle to be successfully solved, both the verification side and the requesting side need the same knowledge about the agreement.

[0152] Blockchain Licensing Protocol The present invention may be used to implement a licensing protocol using blockchain 150. The Blockchain Licensing Protocol (BLP) includes two elements combined by a protocol to provide all the required functions of a system for processing license agreements (LAs) in a decentralized manner. These two elements are bilateral hash puzzle agreement and a system of different transaction types. The bilateral hash puzzle agreement facilitates agreement on the terms of the LA among multiple parties by evidencing the commitment of each party in the form of a hash puzzle. The transaction type system can be used to implement the bilateral hash puzzle agreement on the blockchain network 106 in such a way that the transaction system can describe the core functions related to the issuance and management of license agreements.

[0153] Hash puzzles are typically used as a proof of knowledge to force a party to prove that they have knowledge of a secret preimage or data. On the other hand, the present invention uses hash puzzles as a consent proof to ensure that two parties demonstrate mutual commitment and understanding of a public preimage or data. In the context of BLP, this public preimage is the terms of the license agreement itself.

[0154] In a typical hash puzzle, an important property utilized is the preimage computational intractability of the hash function. This is [Hash Puzzle H(X)] = OP_SHA256 <H(X)> OP_EQUAL with respect to the hash puzzle lock script of the form, because it is intended that the preimage X remain secret until the consumer reveals the preimage X as part of the unlock script.

[0155] For such a lock script to be cryptographically secure, it relies on the preimage computational intractability of the hash function H, that is, given H(X), it should be computationally infeasible to find X. This ensures that the challenge can be publicly broadcast without including the secret X, and only the desired consumer, upon obtaining the value X, can redeem the funds locked in this way.

[0156] Conversely, in a two-party hash puzzle agreement, an important property utilized is the second preimage computational intractability property. That is, with respect to a given challenge H(X) and knowledge of X, H(X') = H(X) and X' ≠ X it should be computationally infeasible to find an X' such that.

[0157] Regarding the two-party hash puzzle agreement (BHPA) between Alice and Bob, one of the two parties [Hash Puzzle H(A)] = OP_SHA256 <H(A)> OP_EQUAL It is intended to construct a lock script that includes , where A represents the terms of the agreement, and all the data of A can be made public.

[0158] This means that the details of the agreement can be known to both parties in advance. The construction and publication of a transaction containing this lock script is interpreted as Alice creating an offer to Bob. Then, the second party, Bob, can respond to this challenge by making the unlock script include A, as a way to indicate that he accepts the exact offer made by Alice. The important difference is that since A represents the terms of the agreement, it should be known to both parties in advance and thus is not treated as a secret. The terms could even be adapted from public resources, so A could potentially be public knowledge, something that anyone among the two parties trying to reach an agreement could know.

[0159] Therefore, rather than relying on preimage intractability to prevent unauthorized third parties from obtaining A, BLP relies on second-preimage intractability to ensure that Bob can only agree to the terms if he truly wants to accept the terms presented by Alice.

[0160] To express the motivation for diverting a simple hash puzzle to implement a two-party hash puzzle agreement, the phrase "proof of commitment" is used. BHPA is an effective means for the two parties to indicate their mutual commitment to a single piece of data, namely, the preimage of the hash. In other words, when Bob sees Alice's offer presented as the challenge [Hash Puzzle H(A)], Bob H(A') = H(A) and A'≠A Since it is not possible to generate any alternative agreement details A' that satisfy both simultaneously, Alice can only indicate acceptance of the offer she made.

[0161] This cleverly has the following two major advantages in implementing the two - party agreement using a hash puzzle. 1. If Alice makes an offer A based on the terms she chose, it is impossible for Alice to be inadvertently bound later by an alternative offer A' based on the terms chosen by Bob. 2. If Bob publishes the terms A of an offer that he is willing to accept, Bob may automate the process of verifying his acceptance of offers made by many first - parties such as Alice.

[0162] If Bob automates so that only offers that satisfy [Hash Puzzle H(A)] are accepted, Bob does not risk inadvertently automatically agreeing to alternative conditions A'.

[0163] The BLP utilizes the blockchain 150 in such a way that the proof of commitment achieved by the BHPA is recorded in an immutable public ledger and can be included as part of the consumption conditions required to allocate digital assets related to the exchange of value under the terms of a license agreement where both the licensee and the licensor prove their commitments.

[0164] The next section shows how the two - party hash - puzzle agreement can be integrated into a system of multiple blockchain transactions to facilitate a powerful license - agreement platform applicable to many use cases including IP's onward licensing and commercialization.

[0165] BLP also takes advantage of some additional benefits associated with using double hashing of the preimage in BHPA. The challenge in BHPA takes the following form, namely, [Hash Puzzle H 2 (A)] = OP_SHA256 <H 2 (A)> OP_EQUAL where A is the data of interest (e.g., a license agreement). These challenges can be met by providing the hash H(A) of the preimage, which is useful for reducing the storage burden associated with large contracts or documents.

[0166] Assuming both can access A, this has the same effect in realizing proof of commitment to the terms specified in A, but without requiring the parties to store all the data on the blockchain and broadcast it.

[0167] BLP specifies five configurable blockchain transactions that can be considered the "action types" of BLP. These transactions can be mapped to five functions of BLP that are relevant to most scenarios involving license agreements (LA). These functions are as follows. · Advertising of license terms, · Purchase / license request, · Purchase / license confirmation, · Update of license terms, and · Refund

[0168] The detailed responsibilities of each transaction type in realizing the respective functions of each transaction type are described in the table below. It will be understood that not all transaction types are required. In the example below, the buyer corresponds to the request side 401, and the copyright authority corresponds to the confirmation side 402. Note that this does not apply to all examples. That is, the confirmation side 402 (the party generating the confirmation transaction) does not necessarily have to be the same party owning the IP. It should also be noted that the term "copyright authority" is used merely as a label and does not necessarily mean that the party performing actions related to the copyright authority must own the copyright of the IP.

[0169] Advertising transaction (T A ) Advertising transactions are used to provide IP documents and IP license agreements. The raw IP data itself may be stored in the transaction, or preferably, an encrypted version of the IP may be stored. However, it is not necessary (or in some contexts, not desirable) to include the raw or encrypted form of the IP or LA in the transaction. Instead, a unique identifier for the IP / LA is stored in the transaction. This identifier may be represented as a double hash of the raw content of the IP, as described above. In some cases, the double hash may be used (instead of a single hash) because the fact that the party must provide the preimage of the IP / LA within the unlock script to confirm that the party is acting with knowledge of the exact IP / LA. If the unique identifier of the IP / LA were the hash of the actual IP / LA, the provision of the preimage of the hash on the blockchain would be the provision of the "raw" IP / LA. This, as described above, may not be desirable. Using a double hash means that providing the preimage is providing something that does not reveal the raw IP / LA.

[0170] This transaction is expected to be signed by at least one authorized person known to have legal authority over the IP. This could be the creator of the IP themselves, or someone else, such as a copyright agent (CA) who manages the licensing of the IP on behalf of a music label, for example.

[0171] Purchase transaction (T P ) A purchase transaction (also called a request transaction) is a transaction in which an entity wishing to license IP allocates those tokens to the designated owner / copyright holder of the IP under the terms of the advertised license agreement. The request transaction includes a reference to the IP for which the license is desired. It should be noted that the request transaction does not automatically grant a user license to the IP. The request transaction is a formal expression of the "request to license the IP" and the escrow by the buyer of the tokens advertised as the cost of the license. The CA still needs to accept the license before the license agreement is considered binding.

[0172] Confirmation transaction (T C ) A confirmation transaction is a transaction in which the copyright holder of the IP accepts the tokens from the requesting party and formally grants the party the right to use the IP as per the terms of the referenced license agreement.

[0173] Update transaction (T U ) An update transaction is intended to be used when an existing license agreement needs to be updated. For various reasons (plugging loopholes, meeting regulations, updating costs, etc.), the terms outlined in the license agreement may need to be changed for correction. An update transaction consumes the executable output of an existing advertising transaction and includes the LA and IP data that the advertising transaction has. In other words, an update transaction can be regarded as an "advertising transaction that consumes the executable output of an existing advertising / update transaction". After the update transaction consumes the output of the advertising transaction, the terms and conditions of the previous advertising transaction may no longer be considered valid by the CA or a potential licensee.

[0174] A refund transaction (T R ) A refund transaction is a transaction that can refund the funds of a party if the CA does not confirm that the party has been licensed by a request transaction before a specified point in time, where the party has expressed interest in licensing the IP by the request transaction. The CA would have "confirmed" by consuming the executable output of the request transaction. The refund transaction is optional but recommended.

[0175] Figure 6 schematically shows an exemplary advertising transaction T A especially when it is related to its input and output. At least one input of the transaction is signed by a person accepted as the legitimate owner / administrator of the rights to the IP. This person is called the Copyright Authority (CA). There may be other signatories to the transaction. These are signed inputs from other stakeholders in the IP who consider it appropriate to grant approval to the license agreement for the IP that the transaction is promoting. These are the stakeholders {P i : i ∈ [1, n]}.

[0176] There are two outputs shown in the advertising transaction. The basic pair that is agreed upon is (<H 2 (IP)>, <H 2 (LA)>), and the OP_RETURN output expression is first referenced, and these data are stored in the OP_RETURN output script. Note that the script for the OP_RETURN output is not "processed" as a component of the normal execution of the script, and thus, the script following OP_RETURN can be used to include data in the transaction. Another item included in the OP_RETURN script is the advertisement identifier shown as <Adv ID> in FIG. 6. This is an identifier selected and published by the copyright holder as a mark to inform existing or potential stakeholders that the transaction represents the promotion and / or representation of the IP and its license agreement. Parties can analyze the blockchain 150 for transactions containing this identifier to find these special "advertising" transactions.

[0177] In addition to the three data <H 2 (IP)>, <H 2 (LA)>, and <Adv ID>, there may optionally be other data included. Some are shown in FIG. 6. What is shown in the figure is as follows. - IP: This is the raw data of the IP that is actually licensed. The reason for its exclusion may relate to privacy issues or space-saving issues. If the raw IP (or LA) itself does not exist on the blockchain 150, it is expected that the raw file is accessible "offline" as desired. - e(IP): If one does not want to publish the IP itself on the blockchain 150, instead, an encrypted version e(IP) may be placed on the blockchain 150. Restrictions are imposed on who can decrypt the IP. - LA: The raw licensing agreement (Licensing Agreement) that governs the IP can also be included in the transaction. - e(LA): Optionally, an encrypted version of the LA may be included in the blockchain 150. - Additional information may be included in OP_RETURN.

[0178] The second output (referred to as the active output) is the output to which the digital asset from the input of the advertising transaction is "sent". Consuming this output requires the signature of the copyright holder. This signature is σ CA (T U ) as shown, and σ CA represents the digital signature created by the CA, and T U (update transaction) is what is signed. The advertising transaction allocates the digital asset to itself, that is, as a result, the CA can allocate that output at any time. The existence of this enables the CA to cancel or update the LA. By treating the unspent output (UTXO) of the advertising transaction as an active and valid LA (by mutual understanding of all participants in the licensing service), the CA can cancel or update the transaction by consuming the output of the active output. A simple cancellation is the consumption of the output of the advertising transaction that notifies that the LA is no longer considered valid with respect to the IP it references. An update is where the CA uses that UTXO as an input to the CA to a new advertising transaction, whereas the new advertising transaction is expected to include the updated LA (H 2 (LA v2.0 ))). "Update" cancels and updates the existing license agreement for the IP. Note that without a legal agreement to do so, cancellation or update of the LA by the CA does not automatically make a prior purchase of that version of the LA.

[0179] Figure 7 shows an exemplary purchase (or request) transaction. The purchase transaction T P is a transaction used by a person interested in purchasing / licensing IP to allocate the digital assets required for that purchase. The purchase transaction has at least one input containing a signature on the requesting side, as shown in Figure 7. This digital signature σ Buy (T P ) signs the purchase transaction. Similar to the advertisement transaction, the purchase transaction requires storage of data within the transaction. In this example, the data is stored in the output of OP_RETURN. The data includes the following. - H 2 (IP): This is the unique identifier of the IP / commodity that the buyer is interested in, represented as the double hash of the IP / commodity being purchased. - H 2 (LA): This is the double hash of the associated LA. - H 2 (Buy): This is the double hash of the buyer's identifier. The ID may be the buyer's public key or any other formal identification information. <The original text continues to describe other details which are not fully presented in the given input. However, the translation so far is as follows:

[0180] Similar to the advertisement transaction, the OP_RETURN script includes a purchase identifier <Purchase ID>. This is a publicly agreed identifier that notifies all existing licensees or licensors that this is a transaction representing the official interest of the party in purchasing the license of the IP / commodity. Another item within the OP_RETURN script is the advertisement identifier shown as <Adv ID> in Figure 7. This is an identifier selected and published by the copyright owner as a marker to notify existing or potential stakeholders that the transaction represents the promotion and / or representation of the IP and its LA. Parties can analyze the blockchain 150 for transactions containing this identifier to find these special "advertisement" transactions.

[0181] Furthermore, there may be included various other miscellaneous and / or optional data. The Adv Tr Ref is an example of such data and is the hash of a blockchain advertising transaction that promoted or "housed" the IP of interest and its LA. Another example of data that is applicable but optional to include is in the figure <proof>It is a proof of accomplishment represented as such. Obtaining a license may require the buyer to have achieved something, for example, the driver to have passed the driving license test. The proof may be in the form of a signature or certificate created by a reliable external party representing the achievement.

[0182] The second output of the purchase transaction includes a script that needs to be successfully executed to officially confirm that the buyer is granted a license to the IP. The buyer constructs this script such that there are two ways for the script to be successfully executed.

[0183] The first way (Method A) is a way in which the successful allocator of the digital asset locked by the output (expected to be the CA) must provide the CA's signature, the hash of the IP (H(IP)), the hash of the license agreement (H(LA)), and the hash of the buyer's identifier (H(Buy)). If the CA includes these four pieces of data in the consumption script, this serves as the official confirmation that the CA grants the specified IP license to that particular individual / organization under the specified terms and conditions of the LA.

[0184] The second way (Method B) requires the signatures of both the CA and the buyer. The purpose of this method is for the possibility of incorporating the use of a refund transaction. A refund transaction is, for example, a transaction where after a given period of time, the buyer can get back the digital assets they have committed. The buyer ensures that the refund transaction is signed by at least the CA before the buyer submits the purchase transaction to the blockchain 150.

[0185] This transaction T P The importance is to set a two-party hash puzzle agreement (BHPA) whose consumable output must be satisfied by a buyer who must provide a license contract (or its respective hash). In effect, this transaction is the "first aspect" of the BHPA that provides proof that the licensor (CA) has committed to the terms of the contract.

[0186] Figure 8 shows an exemplary confirmation transaction. A confirmation transaction is a transaction in which the CA confirms that it has indeed granted the buyer a license to the IP. The confirmation transaction confirms this by successfully consuming the executable output of the purchase transaction. This requires the CA to provide its signature σ CA (T C ), the hash of the IP, H(IP), the hash of the license contract, H(LA), and the hash of the buyer's ID, H(Buy). The CA determines where any incoming digital assets are allocated.

[0187] Similar to the advertisement transaction and the purchase transaction, the confirmation transaction may include an identifier labeled <Conf ID> that indicates to the parties that the transaction is a confirmation transaction of the BLP. Further, in scenarios where the IP / commodity is digital and may be protected by encryption, the CA may provide the decryption key to the buyer at this point. In certain implementations, it may be desirable to store either or both of (i) the encrypted data, (ii) the encryption / decryption key in the blockchain, and their locations may be referenced by the BLP transaction.

[0188] If cancellation is incorporated into the BLP, the fact that no executable output of the verification transaction is allocated may indicate that the license is still active. If no output is allocated, the license is interpreted as being active. Some implementations may give the CA sole authority when consuming the executable output of the verification transaction, but in some cases, interested parties may deem it appropriate that multiple parties' signatures are required to cancel the buyer's license. These additional signatures are the signature σ CA2 (T * ) represented in Figure 8, where T * represents a subsequent transaction that consumes the consumable output of T C .

[0189] The importance of this transaction T C is that its input satisfies the BHPA by providing either the license contract or its hash. In effect, this is the "second aspect" of the BHPA where the buyer provides proof of commitment to the terms of the contract.

[0190] Figure 9 shows an exemplary update transaction. The update transaction is used to provide two functions and can be used to cancel a non-recommended or obsolete previous version of the license contract and to establish an updated version of the contract (LA v2.0 ) to replace the previous version. The update transaction is mainly characterized by the fact that the update transaction releases the lock on the executable output of the previous advertisement transaction. The update transaction can be interpreted as a version of the advertisement transaction with the important feature that the input (of the update transaction) signed by the CA is from the "executable" output of the previous advertisement / update transaction.

[0191] Figure 10 shows an exemplary refund transaction. A refund transaction is a transaction that refunds funds from a purchase transaction to the buyer. This is the case when the CA fails to confirm or grant a license before a specified time (i.e., consumes the executable output of the purchase transaction). If this time elapses, the refund transaction can be successfully submitted to the blockchain 150. The time limit for the normal submission of a refund transaction may be enabled by assigning a value s to the nLockTime field of the blockchain transaction. nLockTime is a transaction parameter that allows a transaction to become executable only after a specified time has elapsed. The value s is an absolute value and is specified in UNIX time or block height.

[0192] Although not shown, a sixth transaction that may be included in the BLP design is a cancellation transaction T R of the transaction. This transaction is used when the IP administrator or regulatory authority deems it necessary to revoke a license previously granted to the buyer. The need for this license cancellation may be due to the passage of a predetermined period or the buyer's violation of one or more of the terms and agreements specified by the LA.

[0193] Cancellation may be accomplished in various ways. An example of an implementation is an example where the output of a confirmation transaction is used to indicate whether the license has been cancelled. If the specified output is consumed, the buyer's license is considered cancelled. If the output remains unconsumed, the license is considered valid. In this approach, the CA that creates and signs the confirmation transaction is entrusted with fairly determining the invalidation. To further enhance the reliability of the invalidation, the allocation of the output may be designed to require signatures from other trusted authorities or regulatory agencies.

[0194] Figure 5 shows the above five main transactions that form the basis of the system underlying the blockchain licensing protocol, and how these transactions are linked. The striped squares are the OP_RETURN outputs containing data. The solid arrows indicate the allocation of outputs. The squares on the left side of the transaction are inputs, and the squares on the right side are outputs. The clock represents a time-locked transaction, and LA' is the updated version of LA.

[0195] Figure 11 shows an exemplary sequence for the BLP. As shown, the CA sends an advertisement transaction to the blockchain 150. The buyer expresses interest in the LA, and the CA responds affirmatively and tentatively agrees, for example, to grant the buyer a license to the IP. Then, the buyer creates a purchase transaction and a refund transaction. The buyer sends the unsigned refund transaction to the CA, and the CA signs the transaction and returns it to the buyer. After receiving the signed refund transaction, the buyer submits the purchase transaction to the blockchain 150. The CA confirms the agreement by sending a confirmation transaction to the blockchain 150. Alternatively, the buyer may cancel the request to grant a license to the IP by sending the signed refund transaction to the blockchain 150. If the CA wants to update the proposed agreement, the CA sends an update to the blockchain 150.

[0196] Use Cases of BLP While the above example clearly focuses on its application to the licensing of intellectual property (IP), the blockchain licensing protocol (BLP) may be used for various types of agreements. There are many other potential applications that utilize the same technology, namely the two-party hash puzzle agreement (BHPA), and a set of transactions customized for a particular use case. Such use cases may include the following. · Directly licensing IP on-chain · Distribution and management of public licenses, and · Supply chain acknowledgement

[0197] On-chain IP licensing The use cases of BLP are that independent creators of digital content and media, which are themselves the creator's intellectual property, use the blockchain 150 to license their works. The important advantage here in using BLP is that it enables the creator to establish a unique license agreement for digital content that can be directly monetized using the native digital asset infrastructure of the blockchain itself. For example, consider the steps that Alice, a music artist who wants to license her music using BLP, might take. 1. Create a piece of music (IP) and uniquely represent it on the blockchain. 2. Define an LA for using Alice's music, which may involve more detailed agreements down to the level of individual songs or albums. These agreements may define different conditions for different types of use of Alice's music. 3. Use BLP to establish the LA on-chain. 4. A listener purchases a license to listen to / reuse / distribute Alice's music on a case-by-case basis.

[0198] Alice does not require a third party to mediate the process of reaching an agreement with the user (i.e., the licensee), because this is implemented using the BLP's BHPA mode, which further leaves a digitally signed proof of both parties' commitments. The advantage of this use case is that the proof of commitment in BHPA is tied to the transfer of digital assets related to licensing music to individual users, which enables Alice to receive payment as soon as the user agrees to the service / terms of use. This also has the advantage for users that it is not necessary to commit to a long-term subscription, but rather that payment for content can be granular, using small micropayments per song or per listen, depending on the details of the LA.

[0199] Distribution of regulated licenses The BLP mechanism may also be particularly suitable for the definition, issuance, and processing of licenses granted by regulatory authorities or government agencies. Such licenses may include, for example, television licenses, licenses to provide alcohol, or licenses to drive certain types of vehicles. BLP provides the necessary functions for issuance, purchase, renewal, and revocation that are normally required for these licenses. In this case, since the license in question is related to a regulatory authority (the licensor) granting a user or company (the licensee) the right to either use or provide certain goods, services, and activities, it may not be necessary to associate BLP with "intellectual property".

[0200] Supply chain approval The potential extended applications of BLP, and particularly BHPA which forms the basis of the system, are for use in complex supply chains. The concept here is that the proof of commitment provided by BHPA will be used as the "proof of acknowledgement" in the supply chain. In the context of a supply chain, proof of acknowledgement is proof that a given stakeholder or participant in that supply chain has accepted responsibility when receiving notice of a particular value, or that the stakeholder or participant should perform a particular task. The use of BHPA in this scenario is advantageous as it provides evidence that both the stakeholder receiving the instruction or goods and the supply chain stakeholder giving the instruction or goods agree to the circumstances under which this occurs. This is similar to evidencing the agreement of stakeholders in a supply chain. BLP improves this by evidencing standard stakeholder agreements in such a way that all of these agreements are provable using a blockchain, ensuring that they are created and accepted "on the fly" by being linked together.

[0201] When implementing BLP in the case of a supply chain, it may be desirable to concatenate multiple such sets of BLP transactions together to mimic the supply chain itself. Simply connecting one set of BLP transactions related to a particular agreement between stakeholders to the next set can be achieved by enforcing a consumption link between the transactions.

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

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

[0204] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, propagating, and storing the block 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. That is, a network entity may perform the function of propagating and / or storing a block without creating and publishing the block (recall that these entities are not considered nodes of the preferred Bitcoin network 106).

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

[0206] Even more broadly, any reference to the above term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element", and such an entity / element is configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functions of such a network entity / element may be implemented in hardware in the same manner as described above in relation to the blockchain node 104.

[0207] It will be understood that the above embodiments are illustrative only. More generally, a method, apparatus, or program may be provided by any one or more of the following statements.

[0208] Statement 1. A method implemented by a computer for recording an agreement between a requesting side and a confirming side on a blockchain, the method being executed by the requesting side, generating a request transaction, the request transaction including an input signed by the requesting side and a first output including a cryptographic puzzle based on at least a first data item known to both the requesting side and the confirming side, the first data item representing the agreement, A method implemented by a computer, including the step of causing a request transaction to be sent to one or more blockchain nodes.

[0209] The step of causing the sending may include sending the request transaction directly to the blockchain node or to another party (e.g., the verification side) for forwarding to the blockchain node.

[0210] In some embodiments, at least one condition for the input to unlock the first output is that the input must contain a data item.

[0211] Generally, the agreement represented by the first data item may be any contract, treaty, covenant, agreement, transaction, settlement, arrangement, promise, alliance, sale, etc. between the requesting side and the verification side. However, the agreement is not a public key.

[0212] Statement 2. The method of Statement 1 where the first data item includes the agreement or the first data item includes at least the hash of the agreement.

[0213] Statement 3. The method of Statement 1 or Statement 2 where the first output includes a second cryptographic puzzle based on a second data item known to both the requesting side and the verification side, and the second data item represents the identifier of the requesting side.

[0214] The second data item may include an identifier or the second data item may include the hash of the identifier.

[0215] Statement 4. The request transaction includes one or more additional data items, and the one or more additional data items are the double hash of the agreement, the double hash of the identifier of the requesting side, An indicator indicating that a request transaction represents a request for agreement, and A reference to an advertising transaction including an indicator indicating that the advertising transaction represents an agreed-upon advertisement A method of any of the foregoing statements including one, several, or all of them.

[0216] Statement 5. The method of statement 4 in which the request transaction includes a second output including one, several, or all of the additional data items.

[0217] The second output may be a non-consumable output.

[0218] Statement 6. A method of any of the foregoing statements in which the first output is configured to be unlocked by an input of a refund transaction on the condition that the input of the refund transaction includes respective signatures related to the requesting side and / or the confirmation side.

[0219] Statement 7. The method of statement 6 in which the first output includes a multi-signature lock script.

[0220] Statement 8. A step of obtaining a refund transaction, wherein the refund transaction refers to the first output of the request transaction and includes an input including respective signatures related to the requesting side and / or the confirmation side, and the refund transaction includes an output locked on the requesting side, and A method of statement 6 or statement 7 including a step of causing the refund transaction to be sent to one or more blockchain nodes.

[0221] For example, the output of the refund transaction may be locked to the public key of the requesting side.

[0222] Statement 9. generating an unsigned version of the refund transaction; A method of statement 8 including sending the unsigned version of the refund transaction to the verification side.

[0223] Statement 10. The step of obtaining the refund transaction includes receiving a version of the refund transaction including an input including respective signatures related to the verification side; A method of statement 9 including signing the input using respective signatures related to the requesting side.

[0224] Statement 11. A method according to any of statements 8 to 10, wherein the refund transaction includes a time limit configured to prevent the refund transaction from being published on the blockchain before a specified time has passed.

[0225] The specified time may be measured, for example, in UNIX time or block height.

[0226] Statement 12. A method according to any of the foregoing statements, wherein a first output of the request transaction includes, in the lock script, a separator opcode, a cryptographic puzzle based on a first data item following it, and a signature check opcode following it.

[0227] For example, the separator opcode may be OP_CODESEPERATOR, and the signature check opcode may be OP_CHECKSIG. Note that additional data other than the cryptographic puzzle may be included after the separator opcode. The cryptographic puzzle does not necessarily have to be immediately after the separator opcode, nor does it have to be immediately before the signature check opcode. Similarly, some data that does not need to be signed by the verifying party may be included before the separator opcode. In other words, unsigned data must be before OP_CODESEPARATOR in order to obtain the desirable effect that the verifying party does not have to sign all of the lock script.

[0228] Statement 13. A method of any of the foregoing statements where the cryptographic puzzle includes a one-way function.

[0229] Statement 14. A method of any of the foregoing statements where the cryptographic puzzle includes one of a hash puzzle, a private key puzzle, or an r-puzzle.

[0230] In some examples, the second cryptographic puzzle may include one of a hash puzzle, a private key puzzle, or an r-puzzle. The first cryptographic puzzle and the second cryptographic puzzle may include the same type of puzzle or different types of puzzles.

[0231] Statement 15. A method implemented by a computer that uses a blockchain to record an agreement between a requesting party and a verifying party, the method being executed by the verifying party, generating a verification transaction, the verification transaction including an input that references an output of a request transaction, the output of the request transaction being known to both the requesting party and the verifying party and including a cryptographic puzzle based on a first data item representing the agreement, the input of the verification transaction including the first data item, A method implemented by a computer, including the step of causing a confirmation transaction to be sent to one or more blockchain nodes.

[0232] The step of causing the sending may include sending the confirmation transaction directly to a blockchain node or to another party (e.g., the requesting party) for forwarding to the blockchain node.

[0233] Statement 16. The method of Statement 15, wherein the input of the confirmation transaction includes a signature related to the confirmation side.

[0234] Statement 17. The method of Statement 16, wherein the first output of the request transaction includes a separator opcode, a cryptographic puzzle based on a first data item following it, and a signature check opcode following it, and the signature related to the confirmation side is configured to sign only the data located after the separator opcode.

[0235] Note that the signature check opcode, e.g., OP_CHECKSIG, may be configured to check (i.e., verify) that the signature of the input of the second transaction signs the message using the private key corresponding to the public key included in the output of the first transaction referenced by the input of the second transaction.

[0236] Statement 18. The method of Statement 16 or Statement 17, wherein the output of the request transaction includes a cryptographic puzzle based on a second data item representing the identifier of the requesting party and known to both the requesting side and the confirmation side, and the input of the confirmation transaction includes the second data item.

[0237] Statement 19. The method of any one of Statements 15 to 18, wherein the confirmation transaction includes an output locked to the confirmation side.

[0238] The output of the confirmation transaction may be locked to the public key associated with the confirmation side.

[0239] Statement 20. A step of generating a cancellation transaction, the cancellation transaction including an input configured to unlock the lock of the output of the confirmation transaction, and A method of statement 19 including the step of causing the cancellation transaction to be sent to one or more blockchain nodes.

[0240] The input of the cancellation transaction may include a signature associated with the confirmation side.

[0241] Statement 21. A step of generating an advertisement transaction, the advertisement transaction including at least a first input signed by the confirmation side, and at least a first output including one or both of an expression of agreement and an encrypted version of the agreement, and A method according to any of statements 15 to 20 including the step of causing the advertisement transaction to be sent to one or more blockchain nodes.

[0242] The first output may be a non-consumable output.

[0243] Statement 22. A method of statement 21 in which the expression of agreement includes a hash of the agreement, or the expression of agreement includes a double hash of the agreement.

[0244] Statement 23. A method according to statement 21 or statement 22 in which the first output includes an indicator indicating that the advertisement transaction is an advertisement of the agreement.

[0245] Statement 24. A method in which an advertising transaction includes one or more additional inputs, each additional input being one of statements 21 to 23 signed by a different party.

[0246] Statement 25. A method in which an advertising transaction includes a second output locked to a confirmation side, being one of statements 21 to 24.

[0247] The second output of the advertising transaction may be locked to a public key associated with the confirmation side. The second output may or may not be a different output compared to the first output.

[0248] Statement 26. A step of generating an update transaction, the update transaction including an input configured to unlock the lock of the second output of the advertising transaction, and a first output including at least one or both of an updated representation of the agreement and an encrypted version of the updated agreement. A method of statement 25 including a step of causing the update transaction to be sent to one or more blockchain nodes.

[0249] Statement 27. A method of any of the foregoing statements in which the agreement is a license contract, for example, a license contract regarding intellectual property.

[0250] Statement 28. A memory including one or more memory units, 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 to execute a method of any of statements 1 to 27 when on the processing device.

[0251] Statement 29. A computer program embodied on a computer-readable storage and configured to perform any one of the methods of statements 1 to 27 when executed on a computer device.

[0252] According to another aspect disclosed herein, a method may be provided that includes actions on a request side and a confirmation side.

[0253] According to another aspect disclosed herein, a system may be provided that includes computer devices on a request side and a confirmation side.

Description of Reference Numerals

[0254] 100 System 101 Packet Switching Network 102 Computer Terminal, Computer Device, Device 102a Computer Device 102b Computer Device 103 User, Agent, Interested Party 103a User, First Interested Party 103b New User or Entity, Second Interested Party 104 Blockchain Node, Bitcoin Node 105 Client Application 106 Peer-to-Peer (P2P) Network, Bitcoin Network, Blockchain Network 107 Side Channel 150 Blockchain, Bitcoin Blockchain 151 Block of Data 152 Transaction 152i Previous Transaction 152j Current Transaction 153 Genesis Block (Gb) 154 Ordered Set 155 Block Pointer 201 Header 202 Input 203 Output 400 System 401 Transaction Engine, Request Side 402 User Interface (UI) Layer, Confirmation Side 403 Function 500 User Interface (UI) 501 UI Element 502 UI Element< / proof> < / g> < / g> < / s1> < / s> < / s> < / d> < / d>

Claims

1. A method implemented by a computer for recording an agreement between a requesting party and a verifying party on a blockchain, the method being executed by the requesting party, comprising the step of generating a request transaction, wherein the request transaction includes an input signed by the requesting party and a first output including a cryptographic puzzle based on at least a first data item known to both the requesting party and the verifying party, wherein the first data item represents the agreement, the step of causing the request transaction to be sent to one or more blockchain nodes and wherein the request transaction includes one or more additional data items, the one or more additional data items including a double hash of the agreement, a double hash of the identifier of the requesting party, an indicator indicating that the request transaction represents a request for the agreement, and a reference to the advertisement transaction including an indicator indicating that the advertisement transaction represents an advertisement for the agreement wherein the method is implemented by a computer and includes one, some, or all of the above.

2. The method according to claim 1, wherein the first data item includes the agreement or the first data item includes at least a hash of the agreement.

3. The method according to claim 1 or 2, wherein the first output includes a second cryptographic puzzle based on a second data item known to both the requesting party and the verifying party, wherein the second data item represents the identifier of the requesting party.

4. ​ ​ ​ ​ ​ ​ ​ The refund transaction includes an input that references the first output of the request transaction and includes respective signatures related to the requesting side and / or the confirmation side, The step that the refund transaction includes an output locked to the requesting side, The step of causing the refund transaction to be sent to one or more blockchain nodes The method according to claim 5 or claim 6, comprising:

8. The step of generating an unsigned version of the refund transaction, The step of sending the unsigned version of the refund transaction to the confirmation side The method according to claim 7, comprising:

9. The step of obtaining the refund transaction Receiving a version of the refund transaction that includes the input including the respective signatures related to the confirmation side, Signing the input using the respective signatures related to the requesting side The method according to claim 8, comprising:

10. The method according to any one of claims 7 to 9, wherein the refund transaction includes a time limit configured to prevent the refund transaction from being published on the blockchain before a specified time has passed.

11. The method according to any one of claims 1 to 10, wherein the first output of the request transaction includes in a lock script a separator opcode, followed by the cryptographic puzzle based on the first data item, followed by a signature check opcode.

12. The method according to any one of claims 1 to 11, wherein the cryptographic puzzle includes a one-way function.

13. The method according to any one of claims 1 to 12, wherein the cryptographic puzzle includes one of a hash puzzle, a private key puzzle, or an r-puzzle.

14. A method implemented by a computer for recording an agreement between a requesting side and a confirmation side using a blockchain, the method being executed by the confirmation side, The step of generating a confirmation transaction, The confirmation transaction includes an input that references an output of a request transaction, The output of the request transaction is known to both the requesting side and the confirmation side and includes a cryptographic puzzle based on a first data item representing the agreement. the input of the confirmation transaction includes the first data item, the input of the confirmation transaction includes a signature related to the confirmation side, and causing the confirmation transaction to be sent to one or more blockchain nodes A method implemented by a computer, including.

15. The first output of the request transaction includes a separator opcode, the cryptographic puzzle based on the first data item following it, and a signature check opcode in the lock script, The method according to claim 14, wherein the signature related to the confirmation side is configured to sign only the data located after the separator opcode.

16. The output of the request transaction is known to both the request side and the confirmation side, and includes a cryptographic puzzle based on a second data item representing an identifier of the request side, The method according to claim 14 or claim 15, wherein the input of the confirmation transaction includes the second data item.

17. The method according to any one of claims 14 to 16, wherein the confirmation transaction includes an output locked to the confirmation side.

18. generating a cancellation transaction, including the cancellation transaction includes an input configured to unlock the lock of the output of the confirmation transaction, and causing the cancellation transaction to be sent to one or more blockchain nodes The method according to claim 17, including.

19. generating an advertisement transaction, including the advertisement transaction includes at least a first input signed by the confirmation side and at least a first output including one or both of the representation of the agreement and the encrypted version of the agreement, and causing the advertisement transaction to be sent to one or more blockchain nodes The method according to any one of claims 14 to 18, including.

20. the representation of the agreement includes the hash of the agreement, or the representation of the agreement includes the double hash of the agreement, the method according to claim 19.

21. The method according to claim 19 or claim 20, wherein the first output includes an indicator indicating that the advertising transaction is the agreed-upon advertisement.

22. The method according to any one of claims 19 to 21, wherein the advertising transaction includes one or more additional inputs, and each additional input is signed by a different party.

23. The method according to any one of claims 19 to 22, wherein the advertising transaction includes a second output locked to the confirmation side.

24. Generating an update transaction, wherein the update transaction includes an input configured to unlock the lock of the second output of the advertising transaction, and a first output including at least one or both of an updated representation of the agreement and an encrypted version of the updated agreement; causing the update transaction to be sent to one or more blockchain nodes The method according to claim 23, comprising:

25. The method according to any one of claims 1 to 13, wherein the agreement is a license contract, including a license contract related to intellectual property.

26. A memory including one or more memory units, A processing device including one or more processing units, wherein the memory stores code configured to be executed on the processing device, and when the code is executed on the processing device, it is configured to execute the method according to any one of claims 1 to 13 or 25. A computer device including:

27. A computer program stored on a computer-readable storage and configured to execute the method according to any one of claims 1 to 13 or 25 when executed on a computer device.

28. The method according to any one of claims 14 to 24, wherein the agreement is a license contract, including a license contract related to intellectual property.

29. A memory including one or more memory units, A processing device including one or more processing units, wherein the memory stores code configured to be executed on the processing device, and when the code is executed on the processing device, it is configured to execute the method according to any one of claims 14 to 24 or 28. A computer device including [

30. ] A computer program stored on a computer-readable storage and configured to execute the method according to any one of claims 14 to 24 or 28 when executed on a computer device.

Images