Determining shared secret using blockchain

Abstract

A method for enabling a second party to determine a shared encryption key, the method comprising: generating a puzzle blockchain transaction, the puzzle blockchain transaction comprising one or more outputs, each output comprising a puzzle lock script, where each puzzle lock script comprises a target public key, the processor is coupled to the target public key and is configured to convert a candidate value into a candidate public key and require the candidate public key to be matched with the target public key when executed together with an unlocking script including the candidate value; and sending the puzzle blockchain transaction to one or more nodes of a blockchain network and / or the second party, where the first party is configured to generate the shared encryption key based on a first private key, a second public key, and each target public key, and wherein the second party is configured to generate the shared encryption key based on a second private key, a first public key, and each candidate value.

Description

Technical Field

[0001] The present disclosure relates to methods of determining a shared secret (i.e., a shared cryptographic key) using blockchain transactions, where the shared secret can be determined by two parties. Background Art

[0002] Blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely disclosed. The blockchain includes a series of data blocks, each of which includes one or more transactions. Except for the so-called "coinbase transaction", each transaction points to a previous transaction in a sequence, which can span one or more blocks back to one or more coinbase transactions. The coinbase transaction will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating a new block is generally referred to as "mining", which involves each of a plurality of nodes competing to perform "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and verified valid pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the publication of blocks can be achieved by publishing only the block header.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing time-stamped entries; and / or sorting index pointers by time. Blockchains can also be used to implement hierarchical additional functions on blockchains. For example, a blockchain protocol may allow additional user data or data indexes to be stored in a transaction. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in a blockchain.

[0004] The nodes of the blockchain network (commonly referred to as "miners") perform a distributed transaction registration and verification process, which will be described in more detail later. In summary, in this process, nodes verify transactions and insert them into block templates, which attempt to identify a valid proof-of-work solution for the block template. Once a valid solution is found, the new block is propagated to other nodes of the network, so that each node can record the new block on the blockchain. In order to record a transaction in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The nodes receiving the transaction can compete to find a proof-of-work solution that incorporates the verified valid transaction into the new block. Each node is configured to execute the same node protocol, which will include one or more conditions for confirming that the transaction is valid. Invalid transactions will not be propagated or incorporated into the block. Assuming that the transaction has been verified to be valid and thus accepted on the blockchain, the transaction (including any user data) will therefore be registered and indexed as an immutable public record on each node in the blockchain network.

[0005] The node that successfully solves the proof-of-work puzzle to create the latest block is usually rewarded with a new transaction called a "coinbase transaction" that distributes the amount of digital assets, i.e. the number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, which act as agents of the network and are incentivized to report and prevent improper behavior. The widespread publication of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the continued integrity of the blockchain.

[0006] In the "output-based" model (sometimes referred to as the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). Outputs may also include a locking script that specifies future redemption conditions for the output. A locking script is a predicate that defines the conditions necessary to verify and transfer a digital token or asset. Each input of a transaction (except for a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction, and may also include an unlocking script for unlocking the locking script pointing to the output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset, and includes a locking script that defines one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, the at least one input including a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0007] In such a model, when the second (target) transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but may register an invalid transaction) nor include the transaction in a new block to be recorded in the blockchain.

[0008] Another transaction model is the account-based model. In this case, each transaction is defined not by reference to the UTXO of the previous transaction in the past transaction sequence, but by reference to the absolute account balance. The current state of all accounts is stored individually by the node in the blockchain and is constantly updated. Summary of the invention

[0009] Diffie-Hellman (DH) key exchange is a method that enables two parties (each of which possesses a public-private key pair) to securely exchange encryption keys over a public channel without prior knowledge of the other party. After the exchange, the parties can use the keys as symmetric keys for future communications with each other. In the DH exchange, two parties (e.g., Alice and Bob) first exchange their respective public keys, and then each party (e.g., Alice) performs a function using the private key of that party (Alice) on the public key of the other party (Bob). The result of this function is a shared symmetric encryption key S that can be generated by either party with only knowledge of the public key of the other party. AB .

[0010] In some cases, one of the two parties may be required to satisfy certain conditions before the shared key can be calculated. For example, one party may be required to perform one or more actions before being able to calculate the shared key.

[0011] According to one aspect disclosed herein, there is provided a computer-implemented method for enabling a second party to determine a shared encryption key, wherein a first party has a first private key and a corresponding first public key, and the second party has a second private key and a corresponding second public key, and wherein the method is performed by the first party and includes: generating a puzzle blockchain transaction, wherein the puzzle blockchain transaction includes one or more respective outputs, each respective output including a respective puzzle locking script, wherein each respective puzzle locking script includes a respective target public key and is configured to, when executed together with a respective unlocking script including a respective candidate value, convert the respective candidate value into a respective candidate public key and require that the respective candidate public key match the respective target public key; and sending the puzzle blockchain transaction to one or more nodes of a blockchain network and / or the second party, wherein the first party is configured to generate the shared encryption key based on the first private key, the second public key, and each target public key, and wherein the second party is configured to generate the shared encryption key based on the second private key, the first public key, and each respective candidate value.

[0012] According to another aspect disclosed herein, there is provided a computer-implemented method of determining a shared cryptographic key, wherein a first party has a first private key and a corresponding first public key, and a second party has a second private key and a corresponding second public key, wherein a blockchain includes a puzzle blockchain transaction, wherein the puzzle blockchain transaction includes one or more respective outputs, each respective output including a respective puzzle locking script, wherein each respective puzzle locking script includes a respective target public key and is configured to, when executed with a respective unlocking script including a respective candidate value, convert the respective candidate value into a respective candidate public key and require the respective candidate public key to match the respective target public key, and wherein the method is performed by the second party and includes: obtaining one or more respective revealing blockchain transactions, wherein each respective revealing blockchain transaction includes one or more respective inputs, each respective input referencing a respective one of the one or more respective outputs of the puzzle blockchain transaction and including a respective unlocking script, each respective unlocking script including a respective candidate value; and generating the shared cryptographic key based on the second private key, the first public key, and each respective candidate value key, wherein the first party is configured to generate the shared cryptographic key based on the first private key, the second public key, and each respective target public key.

[0013] According to another aspect disclosed herein, there is provided a computer-implemented method for enabling a second party to determine a shared cryptographic key, wherein a first party has a first private key and a corresponding first public key, and the second party has a second private key and a corresponding second public key, wherein a blockchain comprises a puzzle blockchain transaction, wherein the puzzle blockchain transaction comprises one or more respective outputs, each respective output comprising a respective puzzle locking script, wherein each respective puzzle locking script comprises a respective target public key and is configured to, when executed with a respective unlocking script comprising a respective candidate value, convert the respective candidate value into a respective candidate public key and require the respective candidate public key to match the respective target public key, and wherein the method is performed by a third party and comprises: generating one or more respective candidate values; generating one or more respective revealing blockchain transactions, wherein each respective revealing blockchain transaction comprises one or more respective inputs, each respective input referencing one of the one or more respective outputs of the puzzle blockchain transaction and comprising a respective unlocking script, each respective unlocking script comprising a respective candidate value; and sending the one or more respective revealing blockchain transactions to one or more blockchain nodes of a blockchain network, the first party, and / or the second party.

[0014] Embodiments of the present disclosure enable a first party (e.g., Alice) to prevent a second party (e.g., Bob) from being able to compute a shared key until a series of candidate values ​​(i.e., private keys) are revealed on a blockchain. Alice knows the private key in advance, so Alice can choose to compute the shared key and use the shared key before Bob is able to compute the same key, for example, to encrypt a message. The private key that Bob needs to generate the shared key is revealed in one or more reveal transactions, and Bob can extract the private key from the one or more reveal transactions. In some examples, each of the revealed private keys is linked to a condition so that the private key required to unlock the corresponding puzzle locking script is only generated or becomes available when the condition is met.

[0015] Knowing the revealed private key is not sufficient to compute the shared key. Similarly, knowing the corresponding public key included in the puzzle transaction is not sufficient to compute the shared key. Instead, only Alice and Bob can compute the shared key because only they have access to their own secret private keys.

[0016] In other words, the present disclosure provides a technique where an individual (Bob) does not know the private key required by one party (e.g., Bob) in an exchange until certain conditions are met that satisfy the other party (Alice). These conditions are enforced via the blockchain using the scripting capabilities of the blockchain. After the conditions are met, Bob is able to utilize the information found on the immutable chain to generate the public-private key pair that Alice uses in the DH exchange. This is achieved without compromising either Alice's or Bob's private keys or affecting the existing security of the DH exchange. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] To facilitate an understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0018] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0019] Figure 2 schematically illustrates some examples of transactions that may be recorded in a blockchain; and

[0020] Figure 3 An exemplary system for generating a shared encryption key is schematically illustrated. DETAILED DESCRIPTION

[0021] 1. Exemplary System Overview

[0022] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switched network 101, typically a wide area internet such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104, which may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0024] The blockchain 150 includes a series of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores a block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of a digital asset represented as a property, an example of which is an output that is cryptographically locked to a user 103 (requiring the user's signature or other solution to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0025] Each block 151 also includes a block pointer 155, which points to a previously created block 151 in the blockchain to define the order of blocks 151. Each transaction 152 (except for the coinbase transaction) includes a pointer to a previous transaction to define the order of the transaction sequence (Note: the sequence of transactions 152 can branch). The blockchain of blocks 151 is traced back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 earlier in the blockchain 150 point to the genesis block 153, not to the previous transaction.

[0026] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, so that transactions 152 are propagated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. Ordered pools 154 are often referred to as "memory pools". In this article, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid, and for which the node 104 is forced to not accept any other transaction that attempts to spend the same output.

[0027] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring a financial asset, although this is certainly a common application. More generally, spending can be described as consuming an output, or allocating it to one or more outputs in another subsequent transaction. In general, a previous transaction can be any transaction in an ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, it is not necessary for a previous transaction 152i to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this article, "previous" refers to the predecessor in a logical sequence linked by a pointer, and not necessarily the creation time or sending time in a time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of isolated transactions below). A previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0028] The inputs of the current transaction 152j also include input authorizations, such as the signature of the user 103a to whom the outputs of the previous transaction 152i are locked. In turn, the outputs of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amounts among multiple users or entities (one of which may be the original user or entity 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0029] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle it can also be other user terminals). It is also not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i that the new transaction spends (or "allocates"), where the condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or may be determined by a combination thereof. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, and therefore forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0030] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it is validly redeemed by the input of another subsequent 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 redeem has not been redeemed by another transaction. Similarly, if invalid, transaction 152j will not be propagated (unless marked as invalid and propagated for reminder) or recorded in the blockchain 150. This prevents double spending, that is, the transaction processor allocates the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at all times.

[0031] In addition to verifying that transactions are valid, blockchain nodes 104 compete to be the first node to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At a blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 that attempts to solve the puzzle.

[0032] The first blockchain node 104 that solves the puzzle announces the puzzle solution on the network 106, providing the solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution satisfies the output of the hash value). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the intention of the first node 104 to follow the blockchain protocol. These rules include not accepting a transaction as valid if it spends or allocates the same output as a previously verified valid transaction, otherwise it is called a double spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointers 155 also impose an order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an immutable public ledger of transactions is provided.

[0033] It should be noted that the different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the pool 154 of transactions that have not yet been published at any given time, depending on when they began searching for a solution or the order in which they received the transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool of unpublished transactions 154. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. In addition, there is a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve puzzles within a short time of each other, thereby propagating conflicting views of the blockchain between the nodes 104. In short, the fork direction that is the longest becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0034] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction", but may also be called a "starting transaction" or "generating transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the intention of the node that constructs the new block to follow the protocol rules, thereby allowing the particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is often called a "transaction fee" and is discussed below.

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

[0036] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role according to the blockchain node protocol and process transactions 152. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or a lower layer such as an operating system layer or a protocol layer, or any combination of these layers.

[0037] Computer devices 102 of each of the parties 103 acting as consuming users are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without acting as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from the blockchain node 104).

[0038] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be referred to as being part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced with "first party" and "second party" respectively.

[0039] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, specific application processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be executed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0041] The client application 105 includes at least a "wallet" function. This has two main functions. One of the functions is to enable the corresponding party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered in the blockchain 150.

[0042] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and rather, any client function described herein may be implemented in a suite consisting of two or more different applications, such as interfacing via an API or one application as a plug-in to another application. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

[0043] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This can enable a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions to which the corresponding party 103 is a recipient (or indeed to check other parties' transactions in the blockchain 150, because in an embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

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

[0045] If the newly received transaction 152j passes the validity test (i.e., under the “valid” condition), any blockchain node 104 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, it is assumed that the transaction 152j is valid, which means that the transaction will soon be propagated throughout the network 106.

[0046] Once in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 will begin racing to solve the proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152 (keep in mind that other blockchain nodes 104 can attempt to solve the puzzle based on different transaction pools 154. However, whoever solves the puzzle first will define the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j). Once the pool 154 including the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

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

[0048] Another type of transaction protocol operated by some blockchain networks as part of the account-based transaction model can be called an "account-based" protocol. In the account-based case, each transaction is defined not by reference to the UTXO of a previous transaction in the past sequence of transactions, but by reference to an absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes of the network and is continuously updated. In such systems, transactions are ordered using an account's running transaction record (also called a "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, a data field can point to a previous transaction if it contains the ID of the previous transaction.

[0049] 2. UTXO-based model

[0050] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 ("Tx" for short) is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other exemplary blockchain networks.

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

[0052] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 In the , Alice's new transaction 152j is marked as "Tx 1 ”. This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. Figure 2 In the previous transaction 152i, it is marked as "Tx 0 "Tx 0 and Tx 1 Just an arbitrary marker, it does not necessarily mean Tx 0 Refers to the first transaction in blockchain 151 and Tx 1 Refers to subsequent transactions in pool 154. Tx 1 Any previous (ie, predecessor) transaction that still has unspent output 203 locked to Alice may be pointed to.

[0053] When Alice creates her new transaction Tx 1 , or at least when she sends this new transaction to the network 106, the previous transaction Tx 0 may already be valid and included in block 151 of blockchain 150. The transaction may have been included in one of the blocks 151 at this time, or may still be waiting in ordered set 154, in which case the transaction will be included in a new block 151 soon. Alternatively, Tx 0 and Tx 1 can be created and sent together to the network 106; or, if the node protocol allows buffering of "orphan" transactions, Tx 0 Even in Tx 1 Sent afterwards. The terms "previous" and "successor" as used herein in the context of transaction sequences refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They may equally be replaced with "predecessor" and "successor", "predecessor" and "descendant" or "parent" and "child", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to previous transactions (predecessor transactions or "parent transactions") will not be valid unless the parent transaction is valid. A child transaction that arrives at a blockchain node 104 before a parent transaction is considered an orphan transaction. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for the parent transaction.

[0054] Previous transaction Tx 0 One of the one or more outputs 203 includes a particular UTXO, denoted as UTXO 0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that must be satisfied by the unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following conditions: The unlocking script in the input of a subsequent transaction includes a cryptographic signature of the party to whom the previous transaction was locked.

[0055] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "Script" (with a capital S), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, such as the requirement 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 locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0056] Thus in the example shown, Tx 0 Output 203 of the UTXO 0 Includes locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , to redeem UTXO 0 (Strictly speaking, this is to make it possible for attempts to redeem UTXO 0 Subsequent transactions are valid). A ] contains Alice's public key P from her public-private key pair A Representation (i.e. hash). Tx 1 The input 202 includes a pointer to Tx 1 A pointer to a transaction (e.g., by its transaction ID (TxID 0 ), which in the embodiment is the entire transaction Tx 0 Tx 1 The input 202 includes the Tx 0 Identify UTXO 0 The index of the 0 It is identified among any other possible outputs of Tx 1 The input 202 further includes an unlocking script <Sig P A>, the unlocking script includes Alice's cryptographic signature, which is created by Alice by applying the private key of her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0057] When a new transaction Tx 1 Upon reaching the blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing the two scripts:

[0058] <Sig PA> <pa>||[Checksig PA]

[0059] Where "||" means concatenation, "<…>" means putting data on the stack, and "[…]" means a function consisting of locked scripts (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack instead of concatenating the scripts. In either case, when run together, the scripts use Alice's public key P A (Included in Tx 0 ) to authenticate Tx 1 The unlocking script in the input contains the signature of Alice when she signed the expected part of the data. The expected part of the data itself (the "message") also needs to be included in order to perform this authentication. In an embodiment, the signed data includes the entire Tx 1 (Therefore there is no need to include a separate element to specify in plain text the portion of the data being signed, since that already exists).

[0060] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Basically, if Alice has signed a message using her private key cryptographically, then given Alice's public key and the message in plain text, other entities such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and marking this to the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a particular data fragment or transaction portion, etc., may mean signing the hash value of that data fragment or transaction portion.

[0061] If Tx 1 The unlocking script in satisfies Tx 0 One or more conditions specified in the locking script of tx (so, in the example shown, if 1 Alice's signature is provided and authenticated), then blockchain node 104 considers Tx 1 This means that blockchain node 104 will send Tx 1 Add to the pending transaction ordered pool 154. Blockchain node 104 also sends transaction Tx 1 Forwarded to one or more other blockchain nodes 104 in the network 106 so that it will be propagated throughout the network 106. 1 Valid and included in blockchain 150, which will make UTXO 0 From Tx 0 It should be noted that Tx 1 It is only valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then even if all other conditions are met, Tx 1 Therefore, blockchain node 104 also needs to check the previous transaction Tx 0 152 has been spent (i.e., has it formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXO 203 of a spent transaction 152, but ultimately defining whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in the blockchain 150.

[0062] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for failure in most transaction models. Therefore, such a transaction will not be propagated or included in block 151.

[0063] Note that in a UTXO-based transaction model, a given UTXO needs to be spent as a whole. You cannot "leave" a portion of a UTXO defined as spent while spending another portion. However, the amount of a UTXO can be split between multiple outputs of subsequent transactions. For example, Tx 0 UTXO 0 The amount defined in Tx 1 Therefore, if Alice does not want to split UTXO 0 All the amount defined in Tx 1 You can use the second output of the coin to make change for yourself, or pay it to another party.

[0064] In practice, Alice will also typically need to include a fee for Bitcoin node 104 that successfully includes Alice’s transaction 104 in block 151. If Alice does not include such a fee, then Tx 0 May be rejected by blockchain nodes 104, and therefore, although technically valid, may not be propagated and included in blockchain 150 (if blockchain node 104 does not wish to accept transaction 152, the node protocol does not force blockchain node 104 to accept). In some protocols, transaction fees do not require their own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 issuing the transaction. For example, assuming that the amount pointed to UTXO 0 The pointer is Tx 1 The only input, and Tx 1 Has only one output UTXO 1 If in UTXO 0 The amount of digital assets specified in the UTXO 1 The amount specified in the , can be created by winning the proof-of-work competition to contain UTXO 1 The node 104 of the block of allocates (or spends) the difference. Alternatively or additionally, this does not necessarily exclude that the transaction fee can be explicitly specified in one of the UTXO 203 of its own transaction 152.

[0065] Alice and Bob's digital assets consist of the UTXO locked to them in any transaction 152 anywhere in the blockchain 150. Therefore, in general, the assets of a given party 103 are scattered among the UTXOs of various transactions 152 throughout the blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in the blockchain 150. The role of the wallet function of the client application 105 is to collate the various UTXO values ​​locked to the respective parties and not yet spent in other subsequent transactions. To achieve this, it can query a copy of the blockchain 150 stored at any one Bitcoin node 104.

[0066] It should be noted that script code is often represented schematically (i.e., using an imprecise language). For example, an opcode (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode of the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a file to be stored in the blockchain.

[0067] Typically, the inputs to a transaction contain a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In an embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects the output to be signed (and is therefore fixed at the time of signing).

[0068] The locking script is sometimes referred to as "scriptPubKey", which means that it usually includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", which means that it usually provides the corresponding signature. However, more generally speaking, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily include verification of the signature. More generally speaking, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0069] 3. Side Channels

[0070] like Figure 1 As shown, the client application on each of Alice and Bob's computer devices 102a, 120b can include additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of any party or third party). The side channel 107 enables data to be exchanged away from the blockchain network. Such communications are sometimes referred to as "off-chain" communications. For example, this can be used to exchange transactions 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this way is sometimes referred to as sharing "transaction templates". 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 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0071] The side channel 107 may be established via the same packet switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 107 referred to anywhere in this document may include any one or more links via one or more networking technologies or communication media that are used to exchange data "off-chain", i.e., off-chain. The bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Therefore, it should be noted that if Alice and Bob are said to exchange certain information or data, etc., via a side channel 107, this does not necessarily mean that all of this data must be sent over exactly the same link or even the same type of network.

[0072] 4. Encryption Technology

[0073] 4.1 Elliptic Curves

[0074] An elliptic curve (EC) is a set of points described by the following equation

[0075] y 2 ≡x 3 +ax+b(mod p)

[0076] in and p is a prime number. The parameters of the elliptic curve utilized in Bitcoin and its variants are the secp256k1 standard.

[0077] For EC cryptography, given a private key v, the corresponding public key is

[0078] Q=vG

[0079] Where G is a base point on the elliptic curve.

[0080] 4.2 Diffie-Hellman

[0081] The Diffie-Hellman exchange is described here with respect to elliptic curves.

[0082] Both parties (Alice 103a and Bob 103b) wish to establish a shared secret between them and be able to establish this shared secret while communicating over a public channel. To do this, they do the following.

[0083] 1. Each party uses secp256k1 to create their public-private key pair. Bob (v B ,P B )、Alice(v A ,P A ), where P B =v B G, and P A =v A G.

[0084] 2. Each party shares its public key with the other party. Bob provides Alice with the key P B , Alice provides Bob with the key P A . This can be done through public channels.

[0085] 3. Each party multiplies the other party’s public key by its (the original party’s) private key. Bob computes v B P A Alice calculates v A P B .

[0086] 4. Both parties now have a shared key that can be used for symmetric encryption.

[0087] S AB =v B P A =v A P B =v B v A G=v A v B G

[0088] Neither party needs to know the other party’s private key, and a third party cannot determine S AB Because they don't know the private key v A or v B .

[0089] 4.3 Elliptic Curve Homomorphism

[0090] The public-private key relationship of EC encryption is homomorphic. This is to add the base point G:

[0091] mG+nG=(m+n)G

[0092] Where m is the public key P M = mG's private key, n is the public key P n =nG's private key, and G is a base point on the elliptic curve.

[0093] 4.4 Elliptic Curve Operation Codes

[0094] PCT / IB2018 / 052407 shows that the Bitcoin protocol is capable of performing EC finite field arithmetic. This includes multiplying scalars by points on EC. That is, the calculation vG (where G is the base point) can be calculated in script.

[0095] An exemplary function (e.g., opcode or pseudo-opcode) that performs elliptic curve multiplication is referred to herein as OP_ECPMULT. OP_ECPMULT takes an encoded elliptic curve point and a number and performs elliptic curve multiplication as a scalar, outputting the result as an encoded elliptic curve point. It should be noted that OP_ECPMULT is just a label for a function that performs these actions, and any other equivalent function with a different label may be used.

[0096] 5. Determine the shared key

[0097] Embodiments of the present disclosure relate to determining a shared key between two parties. The shared key can be used as a symmetric encryption key and can also be used for a device. Figure 3 An exemplary system 300 for determining a shared secret key is shown. In this example, the system 300 includes a first party (e.g., Alice 103a), a second party (e.g., Bob 103b), a third party (e.g., Charlie 103c), and one or more blockchain nodes 104 of a blockchain network 106. In some examples, the third party may be the same as the first party or the second party. Although only one third party is shown, the system 300 may include multiple corresponding third parties, each of which is configured to perform equivalent actions. It should be noted that although the first party and the second party are respectively referred to as Alice 103a and Bob 103b, this is merely for convenience, and generally the first party and the second party only need to be able to perform the actions described below as performed by Alice 103a and Bob 103b, respectively. In addition, in general, each of the first party and the second party can perform the actions referred to above. Figure 1 and Figure 2 Any action described by Alice 103a and / or Bob 103b is performed. Alice 103a and Bob 103b each have their own public-private key pair. These may be referred to as their master key pair or primary key pair.

[0098] Alice 103a wishes to enable Bob 103b to compute a shared secret at some time in the future, e.g., after one or more conditions are satisfied (or only if one or more conditions are satisfied). Each condition may be linked to (e.g., mapped to) a corresponding private key. These private keys (e.g., 256-bit integers) may be referred to as secondary private keys. These private keys will be revealed on blockchain 150 at some point in time.

[0099] Alice 103a creates a puzzle transaction (a specific example of a puzzle transaction is shown in Table 1 below). The puzzle transaction includes one or more outputs. Each output includes a locking script, which will be referred to as a "puzzle locking script". It should be noted that the puzzle transaction may include additional outputs that do not include these locking scripts. Each puzzle locking script includes a corresponding public key corresponding to one of the secondary private keys. Therefore, these public keys can be referred to as "secondary public keys". These public keys are also referred to as "target public keys" in this article. Each puzzle locking script is configured to require that the unlocking script executed with the puzzle locking script includes a candidate value that matches one of the secondary private keys. In order to achieve this requirement, the puzzle locking script converts the candidate value (provided as an input from the unlocking script of the spending transaction) into a public key ("candidate public key"), and requires that the candidate public key matches the target public key included in the puzzle locking script.

[0100] Converting the candidate value to a candidate public key may involve performing an elliptic curve multiplication on the candidate value and an elliptic curve generator point (e.g., a base point). The puzzle locking script may include a dedicated function (e.g., an opcode such as OP_ECPMULT) for performing the multiplication.

[0101] Determining whether a candidate public key matches a target public key may involve comparing the candidate public key to the target public key. The puzzle locking script may include a dedicated function for this purpose (e.g., an opcode such as OP_EQUALVERIFY).

[0102] In some examples, the puzzle lock script requires a part of the script that forces the unlocking script executed with the puzzle lock script to require a signature corresponding to a specific public key. Here, if the signature is generated using a private key corresponding to a public key, the signature corresponds to the public key. This allows Alice 103a to specify who can unlock each puzzle lock script in the puzzle lock script. One, part or all of the puzzle lock scripts in the puzzle lock script may require a signature generated by the same entity (e.g., the same third party, such as Charlie 103c). Alternatively, one, part or all of the puzzle lock scripts in the puzzle lock script may require signatures generated by different entities. In some examples, Alice 103a needs to generate at least one signature in the signature. In some examples, Bob 103b needs to generate a signature in the signature. Generating a signature can be considered to mean that the entity that generates the signature also provides a candidate value (i.e., a secondary private key) included in the same unlocking script as the signature.

[0103] In some examples, the puzzle lock script requires multiple signatures to unlock. This can be enforced using a multi-signature lock (sub) script. The multi-signature lock script includes multiple public keys, and requires that the unlocking script attempting to unlock the multi-signature lock script include a signature that matches (partially or fully) the provided public key. In some examples, at least one of the public keys is Alice's (e.g., her master public key), so that Alice 103a must provide the corresponding signature to unlock the puzzle lock script. A specific example of a puzzle transaction that requires multiple signatures is shown in Table 3 below.

[0104] Alice 103a submits the puzzle transaction to the blockchain network 106. Additionally or alternatively, Alice 103a may send the puzzle transaction to Bob 103b and / or Charlie 103a, either of whom may send the puzzle transaction to the blockchain network 106.

[0105] Alice 103a can generate a shared key before or after sending the puzzle transaction to the blockchain network 106 and / or other parties. Alice 103a can generate a shared key using her master private key, Bob's master public key, and each secondary public key (i.e., the target public key). The shared key can be generated by adding each of the public keys (Bob's master public key and the secondary public key) and multiplying the result with Alice's master private key. It should be noted that all arithmetic here is elliptic curve arithmetic.

[0106] Alice 103a can encrypt the message using the shared key. For example, before submitting the puzzle transaction to the blockchain network 106, the encrypted message can be sent to Bob 103b.

[0107] Turning now to revealing the secondary private key that enables Bob 103b to compute the shared secret key. Once the puzzle transaction is published on blockchain 150, one or more reveal transactions may be submitted to blockchain 150 that together reveal the desired secondary private key. In some examples, a single reveal transaction is generated that includes each of the secondary private keys. In other examples, multiple reveal transactions may be generated, where each reveal transaction includes at least one of the secondary private keys.

[0108] One or more reveal transactions may be generated by Charlie 103c. In some examples, Charlie 103c generates each reveal transaction. In other examples, Charlie 103c generates one or more of the reveal transactions, and one or more different third parties generate one or more of the reveal transactions. In some examples, a single reveal transaction is generated, but multiple parties (e.g., multiple third parties, Alice 103a, and / or Bob 103b) participate.

[0109] In the case of generating a single reveal transaction, Charlie 103c generates (or at least obtains) at least one of the secondary private keys and includes the secondary private key in an input of the reveal transaction that references one of the outputs of the puzzle transaction, i.e., in the unlocking script of the input. The reveal transaction has corresponding inputs that reference the corresponding outputs of the puzzle transaction, each corresponding input including a corresponding unlocking script that includes a corresponding secondary private key. Charlie 103c can obtain each candidate value by itself. Alternatively, one or more candidate values ​​can be obtained from different parties (e.g., Alice 103a or Bob 103b). The reveal transaction is sent to the blockchain network 106 directly by Charlie 103c or through different parties (e.g., Alice 103a or Bob 103b). The case of generating multiple reveal transactions is similar. The difference is that each reveal transaction only includes part of the secondary private keys instead of all of the secondary private keys.

[0110] In some examples, each unlocking script needs to include a signature corresponding to a specific public key. For example, Charlie 103c can generate a signature using a private key corresponding to one of his public keys included in the puzzle locking script of the puzzle transaction. In examples where Alice 103a and / or Bob 103b provide secondary private keys, they can also generate signatures to include in corresponding unlocking scripts including the corresponding secondary private keys. In some examples, Alice 103a can sign a reveal transaction only if the reveal transaction includes a lock time.

[0111] The secondary private key may be generated (or obtained) in any suitable manner. For example, Alice 103a may provide one or more secondary private keys to Charlie 103c. As another example, each secondary private key may be mapped to a corresponding value (e.g., a real-world event) such that by knowing (or determining) the value, the corresponding secondary private key may be obtained.

[0112] Submitting one or more reveal transactions to the blockchain enables Bob 103b to determine the shared secret key. That is, Bob 103b is able to obtain the secondary private key. Once the one or more reveal transactions are recorded on the blockchain 150, these secondary private keys become publicly available. Bob 103b can obtain the one or more reveal transactions (from which he can extract the secondary private key), or he can obtain only the secondary private key. Bob 103b can receive the transaction from one or more blockchain nodes 104, or from Alice 103a, or from Charlie 103c.

[0113] After obtaining the secondary private key, Bob 103b uses his master private key, Alice's master public key, and each secondary private key (i.e., the value included in one or more unlocking scripts of one or more revealing transactions) to generate a shared key. The shared key can be generated by adding each of the private keys (Bob's master private key and the secondary private key) and multiplying the result with Alice's master public key.

[0114] Bob 103b may use the shared key to perform one or more actions. For example, Alice 103a may send a message to Bob 103b that has been encrypted using the shared key. Bob 103b may decrypt the encrypted message using the shared key. Similarly, Bob 103b may encrypt a message using the shared key and send the encrypted message to Alice 103a. Thus, Alice 103a and Bob 103b may communicate securely using the shared key.

[0115] The shared key may be used for purposes other than encryption. For example, Bob 103b being able to generate a key may be used to indicate that Bob 103b (or an entity controlled or associated with Bob 103b) has performed one or more actions, each of which results in one of the secondary private keys being revealed.

[0116] 6. Conditional DH key exchange

[0117] This section provides specific exemplary implementations of the described embodiments. It should be understood that some of these examples are optional. Any of the examples described in this section can be used in combination with the examples described in the previous section.

[0118] 6.1 Basic version

[0119] The premise of this disclosure is that both parties (Alice 103a, Bob 103b) securely determine a public key S AB , where it is assumed that the communication between the two parties is over a public channel. Importantly, for one party (e.g., Bob 103b), they should not be able to determine the secret S before certain conditions set by the other party (Alice 103a) are met. AB .

[0120] The n criteria set by Alice 103a can be arbitrary, on-chain or off-chain. For this example, it is assumed that the criteria are met such that entities that meet the criteria can use one or more integer values, each of which can serve as a private key of an EC public-private key pair.

[0121] While these conditions can be met off-chain, proof of knowledge of these values ​​must be provided on-chain. It should be noted that it is not necessarily Bob 103b who is required to meet the criteria or provide this on-chain proof, but if this proof is provided on-chain by any third party, it is assumed that Bob 103b is able to determine v i value.

[0122] With this in mind, the exemplary steps of the protocol are as follows:

[0123] 1. Each party creates its public-private key pair. Bob (v B ,P B )、Alice(v A ,P A ), where P B =v B G, and P A =v A G.

[0124] 2. Each party shares its public key with the other party. Bob 103b provides Alice 103a with the key P B , Alice 103a provides the key P to Bob 103b A .

[0125] 3. Alice 103a creates the standard set {C i |i∈[1,n]}, where C i The solution is v i , and v i is an integer such that 1≤v i ≤m-1, where m is the order of the subgroup with base point G.

[0126] 4. Alice 103a creates blockchain transaction TxID Puzzles (Table 1), where the locking script of one or more outputs of the transaction needs to know v i In the example transaction shown in Table 1, a v is requested for each output. i Value. Successfully spent TxID Puzzles The unlocking script of the transaction for the i output needs to include v i Value, which is multiplied by the EC base point G to produce the public key P i =v i G. Alice 103a knows that for each v i values ​​or at least their corresponding P i value.

[0127] Verify that the correct v is generated in the unlocking script using opcodes such as OP_ECPMULT i value.

[0128]

[0129] Table 1: Puzzle transactions.

[0130] 5. Alice 103a informs Bob 103b of these criteria and the availability of the transaction.

[0131] 6. Alice 103a informs Bob 103b of the encryption key S that they want to share AB will be Alice's private key times, of which Equal to "P B +P i Alice's private key v A Not shared with Bob 103b.

[0132]

[0133] Alice 103a performs the calculation.

[0134] 7. To determine the secret key S AB , Bob 103b needs to calculate

[0135]

[0136] in

[0137]

[0138] As shown below

[0139]

[0140]

[0141] However, Bob 103b does not yet know the value v 1 ,v 2 ,…,v n , so he cannot determine S AB If the transaction TxID Puzzles Output C i is spent and thus visible on the blockchain, Bob will get these v i Each of these outputs is expected to be spent by an entity (e,i) (e.g., Charlie 103c). These "entities" can be unique individuals (including Alice 103a) or can be entities that can spend multiple C i An entity to output.

[0142] In this example, to spend the output, the entity must use its personal private-public key pair (v e,1 ,P e,i ) to provide the generation of P i =v i G's v i value and signature. The latter requirement of the signature is to ensure that only the intended entity can spend the output. In some examples, each value v i are all hashes of numbers.

[0143] Table 2 shows the cost of one or more C i Output disclosure transaction (TxID v_reveal ) in Table 2.

[0144]

[0145] Table 2: v_reveal transactions

[0146] It should be noted that in the unlock script, v i Value. The v_ reveals that the transaction was submitted to the blockchain.

[0147] Symbol P2PKH P i Used to represent the public key P i The standard P2P2KH locking script is:

[0148] P2PKH i =OP_DUP OP_HASH160 <H(P i )>OP_EQUALVERIFY OP_CHECKSIG

[0149] 8. When TxID Puzzles All C i Outputs are all spent, i.e. TxID v_reveal When a transaction is submitted to the blockchain, all v i The values ​​are available to any interested party. In this case, the interested party is Bob 103b, who now calculates

[0150]

[0151] Bob 103b now calculates the shared secret key

[0152]

[0153] The security of the exchange is maintained because neither party knows the other's private key (Bob 103b does not know v A , Alice 103a don't know v B ); and a third party cannot determine S AB Because they don't know the private key v A or v B It should be noted that v B It is calculated Required.

[0154] 6.2 Time Lock Version

[0155] In the basic version above, Bob 103b is able to retrieve the transaction TxID v_reveal Generated when successfully submitted to the blockchain Required v i Therefore, Bob has AB The determination of S depends on the time when the transaction was uploaded. This enables Alice 103a to obtain S from Bob 103b. AB Imposing a time delay (albeit limited).

[0156] Alice 103a may include a TxID v_reveal The value of the transaction's nTimeLock parameter. nLockTime is a transaction parameter that allows a transaction to execute only after a specified time has elapsed. This means that, despite knowing v i value, and even created a complete TxID v_reveal The transaction itself cannot be successfully included in the blockchain until time s has passed. The nLockTime value can be a Unix time value or a block height of the blockchain.

[0157] To achieve this, the TxID Puzzles The transaction is changed to i Each output includes an m / n multi-signature locking script (m ≥ 2), where one of the signatures must be Bob’s. Revised TxID Puzzles This is shown in Table 3. Multi-signature prevents entities from removing the time lock from a spending transaction by requiring Alice 103a to sign the transaction.

[0158]

[0159] Table 3: Puzzle transaction (multi-signature)

[0160] Alice's required signature on the m / n locking script can be based on the P used in the secret key exchange A For increased security, Alice 103a may use another of her public keys to make the signature. For simplicity, any of these other public keys of Alice 103a is referred to as a common P Alice .

[0161] Transaction TxID v_reveal will also be changed to accommodate TxID Puzzles The multi-signature revision of the transaction (see Table 4). Construct TxID v_reveal When executing the transaction, Alice 103a sets the nLockTime parameter to s.

[0162]

[0163] Figure 4: v_reveal transaction (timelock)

[0164] TxID v_reveal Used to unlock TxID Puzzles C i The output input scripts now require Alice 103a's signature. Alice 103a provides these signatures to Alice 103a who has the public key P e,i The corresponding entity of the blockchain signature (e.g., Alice's signature) signs (a double hash of) a message extracted from the transaction being signed. While the extracted component of the transaction is optional (based on the sighash flag used), other components such as the nLockTime value are always included. This means that Alice's signature enforces that Alice 103a signed the transaction TxID v_reveal The nLockTime=s limit imposed in .

[0165] Each entity can then begin generating its signature <sigP e,i > and determine v i value.

[0166] Even if all three values ​​( <v i >、 <SigP e,i >、 <SigP Alice >) can be used for TxID v_reveal For all n outputs of a transaction, the transaction cannot be successfully submitted to the blockchain for at least a period of time s. After time s, the transaction can be successfully submitted. This limitation will lead to v i The time delay of revealing the value.

[0167] When v i When the value is available, Bob 103b can then calculate the secret value.

[0168]

[0169] 6.3 Example Use Cases

[0170] Bob 103b provides a service, and the entity is an IoT device that automatically generates a digital signature when certain conditions are met. For example, Bob 103b is transporting goods (applicable to Alice 103a) with the following requirements: a) maintained at a certain temperature; b) arriving at a certain location within a specified time; and c) quality approved upon arrival. If all conditions are met (essentially a checklist), the inputs to one or more v_reveal transactions are signed by the IoT device, and Bob 103b can calculate a shared secret. This shared secret can be used to perform actions or communicate with Alice 103a.

[0171] Another use case is where Bob 103b needs verification to access certain media that Alice 103a has encrypted, for example, age-restricted TV shows. Alice 103a requires Bob 103b to pass a number of checks including: minimum age, current UK address, valid TV license. She encodes these conditions in a puzzle transaction and requires an appropriate third party to prove that Bob 103b meets these criteria by signing the inputs of the v_reveal transaction. Bob 103b is then able to obtain the shared secret S that is used as the symmetric key for media encryption / decryption AB .

[0172] 7. Further comments

[0173] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.

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

[0175] 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 functions described in creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions but not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing blocks (remember that these entities are not considered to be nodes of the preferred Bitcoin network 106).

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

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

[0178] Some embodiments have been described in terms of a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments any type of suitable consensus mechanism may be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has a chance to produce the next block 151. The selected node is often referred to as a verifier. A blockchain node may lock its token for a period of time in order to have a chance to become a verifier. Typically, the node that has locked the largest stake for the longest time is most likely to become the next verifier.

[0179] It should be understood that the above embodiments are described by way of example only. In more general terms, a method, apparatus or program may be provided according to any one or more of the following statements.

[0180] Statement 1. A computer-implemented method for enabling a second party to determine a shared encryption key, wherein a first party has a first private key and a corresponding first public key, and the second party has a second private key and a corresponding second public key, and wherein the method is performed by the first party and comprises:

[0181] generating a puzzle blockchain transaction, wherein the puzzle blockchain transaction comprises one or more respective outputs, each respective output comprising a respective puzzle locking script; wherein each respective puzzle locking script comprises a respective target public key and is configured to, when executed with a respective unlocking script comprising a respective candidate value, convert the respective candidate value into a respective candidate public key and require the respective candidate public key to match the respective target public key; and

[0182] sending the puzzle blockchain transaction to one or more blockchain nodes of a blockchain network and / or the second party,

[0183] wherein the first party is configured to generate the shared encryption key based on the first private key, the second public key and each corresponding target public key, and wherein the second party is configured to generate the shared encryption key based on the second private key, the first public key and each corresponding candidate value.

[0184] The corresponding unlocking script including the corresponding candidate value may be part of the corresponding revealing transaction. The revealing transaction may include a single corresponding unlocking script or multiple (eg, all) corresponding unlocking scripts.

[0185] Statement 2. The method of statement 1, comprising: generating the shared encryption key.

[0186] Statement 3. The method of statement 1 or 2, wherein each respective puzzle locking script comprises an elliptic curve generation point and a function configured to perform elliptic curve multiplication on the respective candidate value and the elliptic curve generation point.

[0187] Statement 4. A method as described in any of the preceding statements, wherein each respective puzzle locking script is configured to require a respective signature corresponding to a respective public key.

[0188] Statement 5. The method of statement 4, wherein at least one of the respective puzzle locking scripts is configured to require that the respective unlocking script include a respective signature corresponding to a respective public key associated with the first party.

[0189] Statement 6. A method according to statement 4 or 5, wherein at least one of the corresponding puzzle locking scripts is configured to require that the corresponding unlocking script includes a corresponding signature corresponding to a corresponding public key, and the corresponding public key is associated with the second party.

[0190] Statement 7. A method according to any of the preceding statements, wherein each respective puzzle locking script is configured to require that the respective unlocking script includes a plurality of respective signatures, each respective signature corresponding to a respective public key, and wherein at least one respective public key is associated with the first party.

[0191] Statement 8. The method of statement 5 or 7, wherein the corresponding public key associated with the first party is the first public key.

[0192] Statement 9. A method according to statement 2 or any dependent statement thereof, said method

[0193] include:

[0194] encrypting a message using the shared encryption key to generate an encrypted message; and

[0195] The encrypted message is provided to the second party.

[0196] Statement 10. A method according to any of the preceding statements, the method comprising:

[0197] One or more of the respective candidate values ​​are provided to at least one party for inclusion in one or more respective unlocking scripts, each respective unlocking script being configured to unlock a respective puzzle locking script of the puzzle blockchain transaction.

[0198] Statement 11. A method according to statement 7 or any dependent statement thereof, wherein revealing a blockchain transaction includes one or more corresponding unlocking scripts, the one or more corresponding unlocking scripts being configured to unlock one or more corresponding puzzle locking scripts of the puzzle blockchain transaction, and wherein the method includes providing a corresponding signature corresponding to the corresponding public key for inclusion in the corresponding unlocking script, the corresponding public key being associated with the first party.

[0199] Statement 12. The method of statement 11, wherein the revealing blockchain transaction includes a time lock value, wherein the time lock value prevents the revealing blockchain transaction from being recorded on the blockchain until a time corresponding to the time lock value has passed.

[0200] Statement 13. A computer-implemented method for determining a shared cryptographic key, wherein a first party has a first private key and a corresponding first public key, and a second party has a second private key and a corresponding second public key, wherein a blockchain comprises a puzzle blockchain transaction, wherein the puzzle blockchain transaction comprises one or more corresponding outputs, each corresponding output comprising a corresponding puzzle locking script; wherein each corresponding puzzle locking script comprises a corresponding target public key and is configured to, when executed with a corresponding unlocking script comprising a corresponding candidate value, convert the corresponding candidate value into a corresponding candidate public key and require that the corresponding candidate public key match the corresponding target public key, and wherein the method is performed by the second party and comprises:

[0201] Obtaining one or more respective revealing blockchain transactions, wherein each respective revealing blockchain transaction comprises one or more respective inputs, each respective input references one of the one or more respective outputs of the puzzle blockchain transaction and comprises a respective unlocking script, each respective unlocking script comprising a respective candidate value; and

[0202] The shared encryption key is generated based on the second private key, the first public key, and each corresponding candidate value key, wherein the first party is configured to generate the shared encryption key based on the first private key, the second public key, and each corresponding target public key.

[0203] Statement 14. The method of statement 13, comprising:

[0204] generating at least one corresponding candidate value; and

[0205] The at least one respective candidate value is provided for inclusion in a respective unlocking script of a respective revealing blockchain transaction.

[0206] Statement 15. The method of statement 13 or 14, comprising:

[0207] Obtaining encrypted messages; and

[0208] The encrypted message is decrypted using the shared encryption key.

[0209] Statement 16. The method of any one of statements 13 to 15, comprising:

[0210] encrypting a message using the shared encryption key to generate an encrypted message; and

[0211] The encrypted message is provided to the first party.

[0212] Statement 17. A computer-implemented method for enabling a second party to determine a shared cryptographic key, wherein a first party has a first private key and a corresponding first public key, and the second party has a second private key and a corresponding second public key, wherein a blockchain comprises a puzzle blockchain transaction, wherein the puzzle blockchain transaction comprises one or more respective outputs, each respective output comprising a respective puzzle locking script, wherein each respective puzzle locking script comprises a respective target public key and is configured to, when executed with a respective unlocking script comprising a respective candidate value, convert the respective candidate value into a respective candidate public key and require the respective candidate public key to match the respective target public key, and wherein the method is performed by a third party and comprises:

[0213] generating one or more corresponding candidate values;

[0214] generating one or more respective revealing blockchain transactions, wherein each respective revealing blockchain transaction comprises one or more respective inputs, each respective input referencing one of the one or more respective outputs of the puzzle blockchain transaction and comprising a respective unlocking script, each respective unlocking script comprising a respective candidate value; and

[0215] The one or more corresponding revealing blockchain transactions are sent to one or more blockchain nodes of a blockchain network, the first party, and / or the second party.

[0216] Statement 18. A method according to statement 17, wherein each corresponding puzzle locking script is configured to require a corresponding signature corresponding to a corresponding public key, and wherein at least one of the corresponding unlocking scripts includes a corresponding signature corresponding to a third public key, and the third public key is associated with the third party.

[0217] Statement 19. The method of statement 16 or 17, wherein the third party comprises the first party or the second party.

[0218] Statement 20. A computer device, the computer device comprising:

[0219] a memory, the memory comprising one or more memory cells; and

[0220] A processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured to execute a method according to any one of statements 1 to 19 when executed on the processing device.

[0221] Statement 21. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform the method of any one of statements 1 to 19.

[0222] According to another aspect disclosed herein, a method may be provided, the method comprising actions of the first party and the second party. According to another aspect disclosed herein, a system may be provided, the system comprising computer devices of the first party and the second party.

[0223] According to another aspect disclosed herein, a method may be provided, the method comprising actions of the first party and the third party. According to another aspect disclosed herein, a system may be provided, the system comprising computer devices of the first party and the third party.

[0224] According to another aspect disclosed herein, a method may be provided, the method comprising actions of the second party and the third party. According to another aspect disclosed herein, a system may be provided, the system comprising computer devices of the second party and the third party.< / pa>

Claims

1. A computer-implemented method for enabling a second party to determine a shared encryption key, wherein a first party has a first private key and a corresponding first public key, and the second party has a second private key and a corresponding second public key, and wherein the method is performed by the first party and comprises: generating a puzzle blockchain transaction, wherein the puzzle blockchain transaction comprises one or more respective outputs, each respective output comprising a respective puzzle locking script, wherein each respective puzzle locking script comprises a respective target public key and is configured to, when executed together with a respective unlocking script comprising a respective candidate value, convert the respective candidate value into a respective candidate public key and require the respective candidate public key to match the respective target public key; as well as sending the puzzle blockchain transaction to one or more blockchain nodes of a blockchain network and / or the second party, wherein the first party is configured to generate the shared encryption key based on the first private key, the second public key and each corresponding target public key, and wherein the second party is configured to generate the shared encryption key based on the second private key, the first public key and each corresponding candidate value.

2. The method according to claim 1, comprising: The shared encryption key is generated.

3. The method of claim 1 or 2, wherein each respective puzzle locking script comprises an elliptic curve generation point and a function configured to perform elliptic curve multiplication on the respective candidate value and the elliptic curve generation point.

4. A method according to any preceding claim, wherein each respective puzzle locking script is configured to require a respective signature corresponding to a respective public key.

5. The method of claim 4, wherein at least one of the respective puzzle locking scripts is configured to require that the respective unlocking script include a respective signature corresponding to a respective public key associated with the first party.

6. The method of claim 4 or 5, wherein at least one of the respective puzzle locking scripts is configured to require that the respective unlocking script includes a respective signature corresponding to a respective public key associated with the second party.

7. A method according to any preceding claim, wherein each respective puzzle locking script is configured to require that the respective unlocking script comprises a plurality of respective signatures, each respective signature corresponding to a respective public key, and wherein at least one respective public key is associated with the first party.

8. The method of claim 5 or 7, wherein the corresponding public key associated with the first party is the first public key.

9. The method according to claim 2 or any claim dependent thereon, comprising: encrypting a message using the shared encryption key to generate an encrypted message; as well as The encrypted message is provided to the second party.

10. A method according to any preceding claim, comprising: One or more of the respective candidate values ​​are provided to at least one party for inclusion in one or more respective unlocking scripts, each respective unlocking script being configured to unlock a respective puzzle locking script of the puzzle blockchain transaction.

11. A method according to claim 7 or any claim dependent thereon, wherein revealing a blockchain transaction comprises one or more corresponding unlocking scripts, the one or more corresponding unlocking scripts being configured to unlock one or more corresponding puzzle locking scripts of the puzzle blockchain transaction, and wherein the method comprises providing a corresponding signature corresponding to the corresponding public key for inclusion in the corresponding unlocking script, the corresponding public key being associated with the first party.

12. The method of claim 11, wherein the revealing blockchain transaction includes a time lock value, wherein the time lock value prevents the revealing blockchain transaction from being recorded on the blockchain until a time corresponding to the time lock value has passed.

13. A computer-implemented method for determining a shared cryptographic key, wherein a first party has a first private key and a corresponding first public key, and a second party has a second private key and a corresponding second public key, wherein a blockchain comprises a puzzle blockchain transaction, wherein the puzzle blockchain transaction comprises one or more respective outputs, each respective output comprising a respective puzzle locking script, wherein each respective puzzle locking script comprises a respective target public key and is configured to, when executed with a respective unlocking script comprising a respective candidate value, convert the respective candidate value into a respective candidate public key and require the respective candidate public key to match the respective target public key, and wherein the method is performed by the second party and comprises: Obtaining one or more respective revealing blockchain transactions, wherein each respective revealing blockchain transaction comprises one or more respective inputs, each respective input references one of the one or more respective outputs of the puzzle blockchain transaction and comprises a respective unlocking script, each respective unlocking script comprising a respective candidate value; as well as The shared encryption key is generated based on the second private key, the first public key, and each corresponding candidate value key, wherein the first party is configured to generate the shared encryption key based on the first private key, the second public key, and each corresponding target public key.

14. The method according to claim 13, comprising: generating at least one corresponding candidate value; as well as The at least one respective candidate value is provided for inclusion in a respective unlocking script of a respective revealing blockchain transaction.

15. The method according to claim 13 or 14, comprising: Get encrypted messages; as well as The encrypted message is decrypted using the shared encryption key.

16. The method according to any one of claims 13 to 15, comprising: encrypting a message using the shared encryption key to generate an encrypted message; as well as The encrypted message is provided to the first party.

17. A computer-implemented method for enabling a second party to determine a shared cryptographic key, wherein a first party has a first private key and a corresponding first public key, and the second party has a second private key and a corresponding second public key, wherein a blockchain comprises a puzzle blockchain transaction, wherein the puzzle blockchain transaction comprises one or more respective outputs, each respective output comprising a respective puzzle locking script, wherein each respective puzzle locking script comprises a respective target public key and is configured to, when executed with a respective unlocking script comprising a respective candidate value, convert the respective candidate value into a respective candidate public key and require the respective candidate public key to match the respective target public key, and wherein the method is performed by a third party and comprises: generating one or more corresponding candidate values; generating one or more respective revealing blockchain transactions, wherein each respective revealing blockchain transaction comprises one or more respective inputs, each respective input referencing one of the one or more respective outputs of the puzzle blockchain transaction and comprising a respective unlocking script, each respective unlocking script comprising a respective candidate value; and The one or more corresponding revealing blockchain transactions are sent to one or more blockchain nodes of a blockchain network, the first party, and / or the second party.

18. The method of claim 17, wherein each respective puzzle locking script is configured to require a respective signature corresponding to a respective public key, and wherein at least one of the respective unlocking scripts comprises a respective signature corresponding to a third public key associated with the third party.

19. The method of claim 16 or 17, wherein the third party comprises the first party or the second party.

20. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores a code arranged to be executed on the processing device, the code being configured to execute the method according to any one of claims 1 to 19 when executed on the processing device.

21. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 19.

Images