Using Blockchain to Determine Shared Secrets

Abstract

1. A method for enabling a second party to determine a shared encryption key, comprising: generating a puzzle blockchain transaction including one or more respective outputs, each output including a puzzle lock script, each including a respective target public key, and configured, when executed with a respective unlock script including a candidate value, to transform the candidate value into a candidate public key and request that the candidate public key match the target public key; and 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 respective target public key, and 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.

Description

[Technical Field]

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

[0002] A blockchain is a form of distributed data structure in which duplicate copies of the blockchain are maintained and publicly available at each of multiple nodes in a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain comprises a chain of blocks of data, with each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence that may span one or more blocks and extend back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to a blockchain network are included in new blocks. New blocks are created through a process often referred to as "mining," which involves multiple nodes competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, validated, outstanding transactions awaiting inclusion in a new block of the blockchain. Note that a blockchain may be pruned at some nodes, and publication of a block may be achieved through publication of only the block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: moving digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or temporally ordering index pointers. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes for data within transactions. Because there is no pre-specified limit on the maximum amount of data that can be stored in a single transaction, increasingly more complex data can be incorporated. For example, this could be used to store electronic documents or audio or video data on the blockchain.

[0004] Nodes (often called "miners") in a blockchain network perform a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a target block template in an attempt to identify a valid proof-of-work solution for the transaction. Once a valid solution is found, the new block is disseminated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network to be disseminated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not disseminated and are not included in blocks. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, usually called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of fraudulent transactions is performed by the actions of competing nodes that are incentivized to act on behalf of the network and report and prevent fraud. Widespread publication of information allows users to continuously audit node behavior. The simple publication of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of a digital asset derivable from the preceding sequence of transactions. A consumable output is sometimes called a UTXO (unspent transaction output). An output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit a digital token or asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output specifying the amount of a digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input, which comprises a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, valid transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not disseminate the target transaction (not as a valid transaction, but possibly disseminate it to register a fraudulent transaction) and will not include the target transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing back to the UTXO of a previous transaction in a sequence of past transactions, but by referencing an absolute account balance. The current state of every account is stored in the blockchain and constantly updated by multiple nodes separately. Summary of the Invention

[0009] DH (Diffie-Hellman) key exchange is a method by which two parties (each with a public-private key pair) can securely exchange cryptographic keys over a public channel without requiring prior knowledge of the other. After the exchange, the parties can use the keys as symmetric keys in future communications. In a DH exchange, both parties (e.g., Alice and Bob) first exchange their public keys, and then each party (e.g., Alice) performs a function on the other party's (Bob's) public key and its own (Alice's) private key. The result of this function is a shared symmetric cryptographic key S AB and can be generated by either party knowing only the other party's public key.

[0010] There are scenarios where it is desirable to allow one of the two parties to calculate a shared key only if certain conditions are met, for example requiring one party to perform one or more actions before the shared key can be calculated.

[0011] In one aspect disclosed herein, a computer-implemented method is provided 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 a second party has a second private key and a corresponding second public key, the method being performed by the first party, the method including generating a puzzle blockchain transaction, the puzzle blockchain transaction including one or more respective outputs, each respective output including a respective puzzle lock script, each respective puzzle lock script including a respective target public key and a respective unlock script including a respective candidate value. The method comprises: a step of, when executed with a cryptographic algorithm, converting the respective candidate values ​​into respective candidate public keys and requesting that the respective candidate public keys match the respective target public keys; and a step of sending the puzzle blockchain transaction to one or more blockchain nodes of a blockchain network and / or a second party, wherein the first party is configured to generate a shared encryption key based on the first private key, the second public key, and each respective target public key, and 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] In another aspect disclosed herein, a computer-implemented method for determining a shared encryption key is provided, the method including: a first party having a first private key and a corresponding first public key; a second party having a second private key and a corresponding second public key; a blockchain including puzzle blockchain transactions, the puzzle blockchain transactions including one or more respective outputs, each respective output including a respective puzzle lock script, each respective puzzle lock script including a respective target public key, configured, when executed with a respective unlock script including a respective candidate value, to transform the respective candidate value into a respective candidate public key and to require that the respective candidate public key match the respective target public key. and the method is executed by the second party, the method including the steps of: obtaining one or more respective reveal blockchain transactions, each respective reveal blockchain transaction including one or more inputs, each respective input referencing a respective one of the one or more respective outputs of the puzzle blockchain transaction and including a respective unlock script, each respective unlock script including a respective candidate value; and generating a shared encryption key based on the second private key, the first public key, and each respective candidate value, wherein the first party generates the shared encryption key based on the first private key, the second public key, and each respective target public key.

[0013] In another aspect disclosed herein, a computer-implemented method is provided for enabling a second party to determine a shared encryption key, the method comprising: a first party having a first private key and a corresponding first public key; a second party having a second private key and a corresponding second public key; a blockchain including puzzle blockchain transactions, the puzzle blockchain transactions including one or more respective outputs, each respective output including a respective puzzle lock script, each respective puzzle lock script including a respective target public key, configured, when executed with a respective unlock script including a respective candidate value, to transform the respective candidate value into a respective candidate public key and to require that the respective candidate public key match the respective target public key. The method is performed by a third party, and includes the steps of generating one or more respective candidate values; generating one or more respective reveal blockchain transactions, each respective reveal blockchain transaction including one or more 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 sending the one or more respective reveal blockchain transactions to one or more blockchain nodes of the 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 computing a shared key until a set of candidate values ​​(i.e., private keys) has been revealed on the blockchain. Because the private keys are known in advance to Alice, Alice can choose to compute and use the shared key before Bob can compute the same key, e.g., before he can encrypt a message. The private keys needed by Bob to generate the shared key are revealed in one or more reveal transactions, from which Bob can extract the private keys. In some examples, each revealed private key is linked to a condition, such that the private key needed to unlock the corresponding puzzle lock script is generated or available only if the condition is met.

[0015] Just as knowing a revealed private key is not enough to compute the shared key, knowing the corresponding public key contained in a puzzle transaction is not enough to compute the shared key: only Alice and Bob can compute the shared key, because only they have access to their private keys.

[0016] In other words, this disclosure provides a technique whereby the private key required by one party in an exchange (e.g., Bob) remains unknown to that individual (Bob) until certain conditions are met to the satisfaction of the other party (Alice). Enforcement of these conditions occurs on the blockchain using the blockchain's scripting capabilities. Once the conditions are met, Bob can use information on the immutable chain to generate a public-private key pair for Alice to use in the DH exchange. This is accomplished without compromising Alice's or Bob's private keys or compromising the existing security of the DH exchange.

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

[0018] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 illustrates a schematic diagram of an exemplary system for generating a shared secret key. DETAILED DESCRIPTION OF THE INVENTION

[0019] 1. System Overview Example 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104 that may be adapted to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

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

[0021] A blockchain 150 comprises a chain of blocks of data 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned 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 of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing an amount of digital assets, such as a user 103 to which the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points to the output of a preceding transaction 152, thereby chaining transactions together.

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

[0023] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." As used herein, this term is not limited to a particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and for which the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0024] For a given current transaction 152j, the (or each) input comprises a pointer referencing the output of a previous transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming does not necessarily mean the transfer of a financial asset, although this is certainly a common usage. More generally, consumption 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 the ordered set 154 or any block 151. The previous transaction 152i does not necessarily exist at the time the current transaction 152j is created or even sent to the network 106, but the previous transaction 152i must exist and be validated for the current transaction to be valid. Thus, as used herein, "preceding" refers to something that precedes in a logical sequence connected by pointers, and not necessarily to a time of creation or transmission in a chronological order, and does not necessarily preclude transactions 152i, 152j from being created or transmitted in a different order (see the discussion of orphan transactions below). A preceding transaction 152i may be equivalently referred to as an ancestor transaction or a predecessor transaction.

[0025] The input of the current transaction 152j also comprises the input's authorization, e.g., the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user or entity 103b as defined in the output of the current transaction 152j. In some cases, a transaction 152j can have multiple outputs to divide the input amount among multiple users or entities (one of which can be the original user or entity 103a to provide change). In some cases, a transaction can also have multiple inputs to aggregate amounts from multiple outputs of one or more preceding transactions and redistribute them into one or more outputs of the current transaction.

[0026] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to establish a new transaction 152j (either manually or through an automated process utilized by the party), the establishing party transmits the new transaction from its computer terminal 102 to a recipient. The establishing party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but could in principle be other user terminals). It is not excluded that the party 103 establishing the new transaction 152j may transmit the transaction directly to one or more of the blockchain nodes 104, and in some instances may not transmit it to a recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is legitimate according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that the cryptographic signature or other authorization of party 103 included in the input of new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction consumes (i.e., "allocates"), which condition typically comprises at least verifying that the cryptographic signature or other authorization in the input of new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may be determined solely by the blockchain node protocol, or by a combination of these. 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 tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0027] In an output-based model, the definition of whether a given output (e.g., a UTXO) is allocated (or "spent") is whether it has not already been validly redeemed by the input of another, earlier transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not disseminated (unless flagged as fraudulent and disseminated as a warning) or recorded in the blockchain 150. This protects against double spending, where a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining an account balance. Again, because there is no defined order to transactions, an account balance has a single defined state at any given time.

[0028] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is aided by "proof of work." At blockchain nodes 104, new transactions that have not yet appeared in a block 151 recorded in the blockchain 150 are added to an ordered pool 154 of legitimate transactions. Blockchain nodes then compete to assemble a new legitimate block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool of outstanding transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a defined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. The nature of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0029] The first blockchain node 104 that solves the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the solution causes the hash output to satisfy a condition). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and enforce the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n, which points to the previously created block 151n-1 in the chain. The large amount of effort required to produce the proof-of-work solution, e.g., in the form of a hash, indicates the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it consumes or allocates the same output as a previously validated transaction (also known as double-spending). Once created, blocks 151 cannot be altered because they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this becomes an immutable public ledger of transactions.

[0030] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There are also protocols for resolving any possible "forks," which are situations in which two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to spread between the nodes 104. That is, the fork with the longest branch becomes the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0031] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional acceptable amount of digital assets in a new, special type of transaction (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional specified amount of digital assets. This special type of transaction is typically called a "coinbase transaction," but may also be named an "initial transaction" or "generation transaction." It typically forms the first transaction in a new block 151n. The proof of work indicates the node constructing the new block's willingness to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, an ordinary (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction is published. This fee is typically called a "transaction fee" and is discussed below.

[0032] Depending on the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

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

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

[0035] Some or all of the parties 103 may be connected as part of a different network, for example, a network superimposed on the blockchain network 106. Users of the blockchain network (often referred to as “clients”) are sometimes said to be part of a system that includes the blockchain network 106, but 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 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and its respective computer device 102a, and a second party 103b and its respective computer device 102b. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. By way of example only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not intended to be limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

[0036] The computing equipment 102 of each party 103 comprises a respective processing unit comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing equipment 102 of each party 103 further comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, e.g., 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 of the computing equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 adapted to run on the processing unit. It will be understood that any action attributed herein to a given party 103 may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via a user terminal.

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

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

[0039] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and any client function described herein may instead be implemented in a suite of two or more separate applications that interface, for example, via an API, or one that is a plug-in to the other. More generally, client functions may be implemented at the application layer, at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to a client application 105, it will be understood that this is not limiting.

[0040] An instance of client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to inquire about any transactions of which the respective party 103 is the recipient (or, in embodiments, to actually investigate other parties' transactions in the blockchain 150, since the blockchain 150 is a public institution that lends credibility to transactions in part by being publicly visible). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As discussed above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward transactions 152 for dissemination throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol is attached to a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. The same node protocol is used by all nodes 104 in the network 106.

[0041] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, Alice organizes the new transaction (using the wallet functionality of Alice's client application 105) according to the associated transaction protocol. Alice then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this may be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it handles the transaction 152j according to the blockchain node protocol and its respective role. This involves first verifying whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity verification may be configurable per transaction via a script included in the transaction 152. Alternatively, the conditions may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0042] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., for it to be "validated"), every blockchain node 104 that receives the transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, the transaction 152j will soon be propagated throughout the network 106.

[0043] Once admitted to the ordered pool of outstanding transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle for the latest version of each pool 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, but whoever solves first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Because each transaction 152 includes a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0044] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views about which instance is "valid" before an 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 an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as fraudulent) the instance it originally accepted (i.e., the one not published in block 151).

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

[0046] 2. UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation on all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0047] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which may be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value specifying an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201, which may include an indication of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0048] Suppose Alice 103a wishes to create transaction 152j that transfers an amount of a target digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It has the amount of digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediately following transaction in the pool 154. Tx1 may refer to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0049] By the time Alice creates new transaction Tx1, or at least by the time she submits it to network 106, the currently preceding transaction Tx0 may already have been validated and included in block 151 of blockchain 150. It may already be included in one of the blocks 151 at that time, or it may still be waiting in ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and submitted to network 106 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “successor” as used herein in the context of a sequence of transactions refer to the order of transactions in the sequence as defined by transaction pointers specified in the transactions (e.g., which transaction points to which other transaction). They may be equivalently substituted with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a blockchain node 104 before its parent is considered an orphan. It may be discarded or buffered for a period of time to wait for its parent, depending on the node protocol and / or node behavior.

[0050] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines a condition that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the recipient of the transaction in which the locking script is included). That is, the locking script defines an unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

[0051] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S) used by blockchain networks. A lock script specifies what information is needed to consume the transaction output 203, for example, the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to meet the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0052] So, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A ], which means that Alice's signature Sig P must exist in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A The Tx1 input 202 comprises a pointer to Tx1 (e.g., pointed to by transaction ID TxID0, where in an embodiment TxID0 is a hash of the entire transaction Tx0). The Tx1 input 202 comprises an index that identifies UTXO0 within Tx0, in order to identify UTXO0 among all other possible outputs of Tx0. The Tx1 input 202 further comprises an unlock script <Sig P A >, which comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or a combination of these.

[0053] When new transaction Tx1 arrives at blockchain node 104, the node applies the node protocol, which involves running the lock script and the unlock script together to see if the unlock script meets the conditions defined in the lock script (where the conditions may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' denotes concatenation, '<...>' means putting data on the stack, and '[...]' is the functionality the lock script contains (a stack-based language in this example). Equivalently, the scripts may be executed one after the other using a common stack rather than concatenating the scripts. Either way, when executed together, these scripts will create a lock script containing Alice's public key P as contained in the lock script in the output of Tx0. Athat the unlock script in Tx1's input contains Alice's signature signing the expected portion of data. The expected portion of data itself (the "message") must also be included to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx1 (thus, a separate element specifying the signed portion of data in plaintext need not be included, as it is essentially already present).

[0054] The details of public-private cryptographic authentication will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, then with Alice's public key, the plaintext, and the plaintext message, another entity, such as node 104, can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature with the message, thereby allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing particular data, portions of a transaction, etc., may, in embodiments, mean signing a hash of that data or portion of a transaction.

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

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

[0057] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety. Part of the amount defined in the UTXO is "left behind" as unspent, while another part is not. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself or pay another party the change in the second output of Tx1.

[0058] In practice, Alice is typically also required to include a fee for Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain nodes 104 and therefore may not be propagated or included in the blockchain 150, even if technically valid (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require a unique, separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by inputs 202 of a given transaction 152 and the total amount specified in outputs 203 is automatically given to the blockchain node 104 that issues the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

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

[0060] Note that script code is often represented generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

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

[0062] A lock script may be referred to as a "scriptPubKey," which refers to the fact that the lock script typically includes the public key of the party to which the respective transaction is locked. An unlock script may be referred to as a "scriptSig," which refers to the fact that the unlock script typically provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may be used to define any condition or conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

[0063] 3. Side Channels As shown in FIG. 1, the client applications on each of Alice's computing device 102a and Bob's computing device 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish (either at the instigation of the first party or a third party) a separate side channel 107 with Bob 103b. The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 without the transactions 152 being registered on the blockchain network 106 or entering the chain 150 until either Alice or Bob chooses to broadcast the transaction 152 between Alice and Bob to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." A transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

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

[0065] 4. Encryption technology 4.1 Elliptic Curves An elliptic curve (EC) is a set of points described by the following formula:

number

number

[0066] In EC encryption, given a private key v, the corresponding public key is Q=vG, where G is the base point of the elliptic curve.

[0067] 4.2 Diffie-Hellman Here we describe the Diffie-Hellman exchange in terms of elliptic curves.

[0068] Two parties, Alice 103a and Bob 103b, want to establish a shared secret between them and want to be able to establish this shared secret while communicating over a public channel. To do this, they perform the following operations: 1. Each party creates a public-private key pair using secp256k1. Bob(v B ,P B ), Alice(v A ,P A ), where P B =v B G and P A =v A It's G. 2. Both parties share each other's public keys. Bob gives Alice the key P B Alice gives Bob the key P A This can be done through public channels. 3. Each party multiplies the other party's public key by their own (the original party's) private key. Bob obtains v B P A Calculate v A P B Calculate. 4. Now both parties have a shared key that can be used for symmetric encryption. S AB =v B P A =v A P B =v B v A C=v A v B G

[0069] Neither party needs to know the other's private key; a third party only needs the private key v A and v B Since we do not know either of AB cannot be determined.

[0070] 4.3 Elliptic curve homomorphism The relationship between public and private keys in EC encryption is homomorphic, which is true for the addition of a base point G: mG+nG=(m+n)G. Here, m is the private key for the public key PM=mG, n is the private key for the public key Pn=nG, and G is the base point on the elliptic curve.

[0071] 4.4 Elliptic Curve Opcodes PCT / IB2018 / 052407 shows that the Bitcoin protocol can perform EC finite field arithmetic, which includes multiplication of a scalar by a point on EC, i.e., the calculation of vG, where G is the base point, can be computed in script.

[0072] An example function (opcode, pseudo-opcode, etc.) that performs elliptic curve multiplication is referred to herein as OP_ECPMULT. OP_ECPMULT takes an encoded elliptic curve point and a numeric value and performs elliptic curve multiplication by a scalar. The result is output as an encoded elliptic curve point. Note that OP_ECPMULT is simply a label for the function that performs these actions, and other equivalent functions with different labels can be used instead.

[0073] 5. Determining the Shared Key Embodiments of the present disclosure relate to determining a shared key between two parties. The shared key may be used as a symmetric encryption key or to generate a symmetric encryption key. FIG. 3 illustrates an example system 300 for determining a shared key. 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 is the same as the first or second party. Although only one third party is shown, the system 300 may include multiple third parties, each configured to perform equivalent actions. The first and second parties are referred to as Alice 103a and Bob 103b, respectively, but this is merely for convenience; generally, the first and second parties need only be able to perform the actions described below that are performed by Alice 103a and Bob 103b, respectively. Furthermore, the first and second parties can generally each perform any of the actions identified as being performed by Alice 103a and / or Bob 103b with reference to Figures 1 and 2. Alice 103a and Bob 103b each have their own public-private key pair. These may be referred to as their respective primary or fundamental key pairs.

[0074] Alice 103a desires that Bob 103b be able to compute the shared secret at some point in the future, e.g., after (or only if) one or more conditions are met. Each condition may be linked (e.g., mapped) to a respective private key. These private keys (e.g., 256-bit integers) may be called secondary private keys. These private keys will, at some point, be revealed on the blockchain 150.

[0075] Alice 103a creates a puzzle transaction (an example puzzle transaction is shown in Table 1 below). A puzzle transaction includes one or more outputs. Each output includes a lock script, which is referred to as a "puzzle lock script." Note that a puzzle transaction may include additional outputs that do not include these lock scripts. Each puzzle lock script includes a respective public key that corresponds to one of the secondary private keys. Therefore, these public keys are sometimes referred to as "secondary public keys." They are also referred to herein as "target public keys." Each puzzle lock script is configured to require that an unlock script executed in conjunction with the puzzle lock script have a candidate value that matches one of the secondary private keys. To implement this requirement, the puzzle lock script converts the candidate value (provided as input from the unlock script of the spend transaction) into a public key (a "candidate public key") and requires that the candidate public key match the target public key included in the puzzle lock script.

[0076] Converting the candidate value to a candidate public key may include performing an elliptic curve multiplication of the candidate value with an elliptic curve generation point (e.g., a reference point). The puzzle lock script may include a dedicated function (e.g., an opcode such as OP_ECPMULT) to perform this multiplication.

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

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

[0079] In some examples, a puzzle lock script requires multiple signatures to be unlocked. This can be enforced using a multi-signature lock (sub)script. A multi-signature lock script contains multiple public keys and requires that an unlock script attempting to unlock the multi-signature lock script contain signatures that match some or all of the provided public keys. In some examples, at least one of the public keys is Alice's (e.g., Alice's primary public key), in which case Alice 103a must provide the corresponding signature to unlock the puzzle lock script. An example of a puzzle transaction requiring multiple signatures is shown in Table 3 below.

[0080] Alice 103a sends the puzzle transaction to the blockchain network 106. Alternatively or additionally, 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.

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

[0082] Alice 103a can encrypt a message using the shared key, which can be sent to Bob 103b, for example, before sending the puzzle transaction to the blockchain network 106.

[0083] Next, we describe the revelation of the secondary private keys that allow Bob 103b to calculate the shared key. Once the puzzle transaction is published to the blockchain 150, one or more reveal transactions are submitted to the blockchain 150 that together reveal the necessary secondary private keys. In some examples, a single reveal transaction is generated, which includes all of the secondary private keys. In other examples, multiple reveal transactions are generated, with each reveal transaction including at least one of the secondary private keys.

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

[0085] When a single reveal transaction is generated, Charlie 103c generates (or at least obtains) at least one of the secondary private keys and includes that secondary private key in an input of the reveal transaction that references one of the outputs of the puzzle transaction, along with that input's unlock script. The reveal transaction has a respective input that references each output of the puzzle transaction, and each input includes a respective unlock script that contains the respective secondary private key. Charlie 103c can obtain each candidate value himself. Alternatively, one or more candidate values ​​can be obtained from a different party (e.g., Alice 103a or Bob 103b). The reveal transaction is sent to the blockchain network 106 by Charlie 103c directly or through another party (e.g., Alice 103a or Bob 103b). The process is similar when multiple reveal transactions are generated. The difference is that each reveal transaction contains only some of the secondary private keys, not all of them.

[0086] In some examples, each unlock script must include a signature corresponding to a particular 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 lock script of the puzzle transaction. If Alice 103a and / or Bob 103b provide secondary private keys, they can also generate signatures for inclusion in their respective unlock scripts that include their respective secondary private keys. In some examples, Alice 103a may sign a reveal transaction only if the reveal transaction includes a lock time.

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

[0088] Submitting the reveal transaction to the blockchain allows Bob 103b to determine the shared key, which means Bob 103b can obtain the secondary private key that is made public after the reveal transaction is recorded on the blockchain 150. Bob 103b can obtain the reveal transaction and extract the secondary private key from it, or he can obtain just the secondary private key. Bob 103b can receive transactions from one or more blockchain nodes 104, or from Alice 103a or Charlie 103c.

[0089] After obtaining the secondary private keys, Bob 103b generates a shared key using his primary private key, Alice's primary public key, and each secondary private key (i.e., the values ​​that were included in the unlock script for the reveal transaction). The shared key may be generated by summing each private key (Bob's primary private key and secondary private key) and multiplying the result by Alice's primary public key.

[0090] Bob 103b can perform one or more actions using the shared key. For example, Alice 103a can send Bob 103b a message encrypted using the shared key. Bob 103b can decrypt the message encrypted using the shared key. Similarly, Bob 103b can encrypt a message using the shared key and send the encrypted message to Alice 103a. In this way, Alice 103a and Bob 103b can communicate securely using the shared key.

[0091] The shared key can be used for purposes other than encryption. For example, Bob 103b's ability to generate the key can be used to indicate that Bob 103b (or an entity controlled by or associated with Bob 103b) has performed one or more actions, each of which reveals one of the secondary private keys.

[0092] 6. Conditional DH Key Exchange This section provides specific examples of implementations of the described embodiments. Note that some examples are optional. Any of the examples described in this section can be used in combination with the examples described in the previous sections.

[0093] 6.1 Basic version The premise of this disclosure is that two parties (Alice 103a and Bob 103b) share a common key S ABThe objective of this paper is to securely determine the secret key S, and assume that communication between the two parties is over a public channel. The key is that one party (say Bob 103b) will not share the secret key S until a condition set by the other party (Alice 103a) is met. AB The purpose is to prevent the determination of

[0094] The n criterion set by Alice 103a can be any value on-chain or off-chain. In this example, we assume that meeting the criterion makes available to the entity that meets the criterion one or more integer values, each of which can be used as the private key in an EC public-private key pair.

[0095] While the conditions may be met off-chain, proof of knowledge of these values ​​must be provided on-chain. It is not necessarily Bob 103b who is required to meet the criteria or provide this on-chain proof, but if the proof is provided on-chain by any third party, Bob 103b can prove v i Assume that the value can be determined.

[0096] With this in mind, an example protocol procedure is as follows: 1. Each party creates a 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 It's G. 2. Both parties share their public keys. Bob 103b sends Alice 103a the key P B Alice 103a gives Bob 103b the key P A Hand over. 3. Alice 103a has a reference set {C i |i∈[1,n]}, where C i The solution is vi and v i is 1≦v i is an integer ≦m−1, where m is the order of the subgroup with base point G. 4. Alice 103a is the blockchain transaction TxID Puzzles (Table 1) and lock one or more outputs for this transaction. In the script, you use v to consume the output. i It requires knowledge of a set of values. In the example transaction shown in Table 1, there is one v per output. i A value is required. TxID Puzzles The unlocking script for a successful transaction that consumes the i output of the EC base point G multiplied by the public key P i =v i v to generate G i must contain a value. Alice 103a must i values, or at least their corresponding P i Know the value. 5. Ensure that unlock scripts that use opcodes such as OP_ECPMULT are configured correctly. i Verify that a value is generated. [Table 1] 6. Alice 103a notifies Bob 103b of these criteria and the availability of the transaction. 6. Alice 103a sends Bob 103b the encryption key S AB is Alice's private key P B * Here, P B * is "(PB)+(P i Alice's private key v A is not shared with Bob 103b.

number

[0097] However, Bob still has values ​​v1, v2,..., v n Because we do not know AB It is not possible to determine the transaction TxID. Puzzles C i When outputs are consumed and made visible on the blockchain, these v i Each of these outputs is expected to be consumed by an entity (e,i), say Charlie 103c. These "entities" may be unique individuals (including Alice 103a), or one entity may consume multiple C i In some cases, the output can be consumed.

[0098] In this example, to consume the output, the entity i =v i v to generate G i values ​​and their private and public key pairs (v e,1 ,P e,i ) and a signature using the signature. The latter requirement of the signature ensures that only the intended entity can consume the output. In some examples, each value vi is a hash of numbers.

[0099] One or more C i Reveal transaction (TxID) that consumes the output v_reveal ) are shown in Table 2. [Table 2]

[0100] Unlock script v i Note that a value is specified: this v_reveal transaction will be sent to the blockchain.

[0101] P2PKH P i is the public key P i It is used to represent the standard P2P2KH locking script, i.e., P2PKH P i = OP_DUP OP_HASH160 <H(P i )> OP_EQUALVERIFY OP_CHECKSIG. 8. TxID Puzzles All C's i When the power is consumed, i.e., TxID v_reveal When a transaction is sent to the blockchain, all v i The value is made available to all interested parties. In this case, interested parties can B * =v B +v1+v2+...+v n This is Bob 103b, who calculates

[0102] Bob 103b has shared key S AB =v B * P A =(v B +v1+v2+...+v n )P A Calculate.

[0103] Since neither party knows the other's private key (Bob 103b) AWithout knowing, Alice 103a B , v ), the security of the exchange is maintained and the third party does not know the private key, v A and v B Since I don't know either of them, AB cannot be determined. B is v B * Note that this is necessary for the calculation of

[0104] 6.2 Time Lock Version In the basic version described above, Bob 103b receives the transaction TxID v_reveal When is successfully sent to the blockchain, v B * v required to generate i Therefore, Bob's S AB The decision of depends on when this transaction is uploaded. This allows Alice 103a to know that Bob 103b has AB It is possible to impose a time delay (but with a limit) on obtaining the

[0105] Alice 103a is TxID v_reveal It may contain 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 v i The value is known and the complete TxID v_reveal This means that even if you create a transaction, the transaction itself cannot be successfully included in the blockchain until the time has passed. The nLockTime value can be either a Unix time value or the block height of the blockchain.

[0106] To implement this, TxID Puzzles The transaction is C iIn each output, it is modified to contain m-of-n multisig lock scripts (m ≥ 2), where one of the signatures must be from Bob. Puzzles is shown in Table 3. Multisig prevents entities from removing the time lock from a spending transaction by requiring Alice 103a to sign the transaction. [Table 3]

[0107] The signature required by Alice for the m-of-n lock script is P A used in the private key exchange. For added security, Alice 103a may use a different public key for this signature. For simplicity, any of these other public keys of Alice 103a may be used as the general public P Alice It is called.

[0108] Transaction TxID v_reveal Also, the TxID Puzzles It is changed to accommodate multisig modifications of transactions (see Table 4). v_reveal In constructing the transaction, the nLockTime parameter is set to s by Alice 103a. [Table 4]

[0109] TxID Puzzles C i TxID to unlock the output v_reveal The input scripts require Alice 103a's signature. Alice 103a can then sign these signatures using her public key P e,ito the corresponding entity that owns the transaction TxID. A blockchain signature (such as Alice's) signs (a double hash of) a message extracted from the transaction being signed. The transaction extraction component is optional (based on the sighash flags used), but other elements such as the nLockTime value are always included. This means that Alice's signature is used to sign the transaction TxID. v_reveal means to enforce the nLockTime=s limit set by Alice 103a.

[0110] Each entity then sends a signature, 〈sigP e,i 〉 and v i Determine the value.

[0111] TxID v_reveal For all n outputs of the transaction, three values ​​(〈v i 〉,〈SigP e,i 〉,〈SigP Alice 〉) is available, the transaction cannot be successfully submitted to the blockchain until at least time s has passed. After time s, the transaction can be successfully submitted. This restriction ensures that v i There is a time delay in detecting the value.

[0112] v i Once the value is available, Bob 103b obtains the secret value S AB =v B * P A =(v B +v1+v2+...+v n )P A can be calculated.

[0113] 6.3 Example Use Cases 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 can a) transport goods (for Alice 103a) at a certain temperature, b) arrive at a specified location by a specified time, and c) receive a quality approval upon arrival. Once all conditions are met (essentially a checklist), the input of the v_reveal transaction is 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.

[0114] Another use case is when Bob 103b needs verification to access media encrypted by Alice 103a, for example, an age-restricted television program. Alice 103a requires Bob 103b to meet several conditions, including a minimum age, a current UK address, and a valid television license. Alice encodes these conditions into a puzzle transaction and requires a third party to properly authenticate that Bob 103b meets these conditions by signing the input of the v_reveal transaction. Bob 103b then uses the shared secret S AB This shared secret is used as the symmetric key for encryption / decryption of the media.

[0115] 7. Appendix Other variations or use cases of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein. The scope of the present disclosure is limited only by the appended claims, not by the described embodiments.

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

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

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

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

[0120] Some embodiments are described for blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is just one type of consensus mechanism, and general embodiments may use any type of suitable consensus mechanism, 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 randomized process to determine which blockchain nodes 104 will be given the opportunity to generate the next block 151. The selected nodes are often called validators. Blockchain nodes can lock tokens for a certain period of time to earn the chance to become a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0121] It will be understood that the above embodiments are described by way of example only. More generally, a method, apparatus, or program may be provided according to any one or more of the following statements:

[0122] Statement 1. A computer-implemented method for enabling a second party to determine a shared encryption key, wherein the 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, the method being performed by the first party, the method comprising: generating a puzzle blockchain transaction, the puzzle blockchain transaction including one or more respective outputs, each respective output including a respective puzzle lock script, each respective puzzle lock script including a respective target public key and configured, when executed with a respective unlock script including a respective candidate value, to transform the respective candidate value into a respective candidate public key and to require that each candidate public key match the respective target public key; transmitting the puzzle blockchain transaction to one or more blockchain nodes of a blockchain network and / or a second party; 1. A method, comprising: a first party configured to generate a shared encryption key based on a first private key, a second public key, and each respective target public key; and a second party configured to generate a shared encryption key based on the second private key, the first public key, and each respective candidate value.

[0123] Each unlock script containing each candidate value may be part of a respective reveal transaction, which may include one of the respective unlock scripts or some (e.g., all) of the respective unlock scripts.

[0124] Statement 2. The method of statement 1, comprising generating a shared encryption key.

[0125] Statement 3. The method of statements 1 or 2, wherein each respective puzzle lock script includes a generating point of an elliptic curve and a function configured to perform elliptic curve multiplication of each candidate value and the generating point of the elliptic curve.

[0126] Statement 4. The method of any of statements 1 to 3, wherein each respective puzzle lock script is configured to request a respective signature corresponding to a respective public key.

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

[0128] Statement 6. The method of statement or 5, wherein at least one of the respective puzzle lock scripts is configured to require that the respective unlock script include a respective signature corresponding to a respective public key associated with a second party.

[0129] Statement 7. The method of any of statements 1 to 6, wherein each respective puzzle lock script is configured to require that the respective unlock script include a plurality of respective signatures, each of the signatures corresponding to a respective public key, and at least one respective public key is associated with the first party.

[0130] Statement 8. The method of statements 5 or 7, wherein each public key associated with the first party is a first public key.

[0131] Statement 9. Encrypting a message using a shared encryption key to generate an encrypted message; making the encrypted message available to a second party; A method according to any one of statement 2 or statements 3 to 8 dependent on statement 2, comprising:

[0132] Statement 10. The method of any of statements 1 to 9, comprising providing one or more of the respective candidate values ​​to at least one party for inclusion in one or more respective unlock scripts, each respective unlock script configured to unlock a respective puzzle lock script of the puzzle blockchain transaction.

[0133] STATEMENT 11. A method as recited in Statement 7 or any of Statements 8 to 10 dependent on Statement 7, wherein the reveal blockchain transaction includes one or more respective unlock scripts and is configured to unlock one or more respective puzzle lock scripts of the puzzle blockchain transaction, the method comprising providing respective signatures corresponding to respective public keys associated with the first party for inclusion in the respective unlock scripts.

[0134] Statement 12. The method of statement 11, wherein the reveal blockchain transaction includes a timelock value, and the timelock value prevents the reveal blockchain transaction from being recorded on the blockchain until a time corresponding to the timelock value has elapsed.

[0135] Statement 13. A computer-implemented method for determining a shared encryption key, wherein a first party has a first private key and a corresponding first public key, a second party has a second private key and a corresponding second public key, a blockchain includes puzzle blockchain transactions, the puzzle blockchain transactions include one or more respective outputs, each respective output including a respective puzzle lock script, each respective puzzle lock script including a respective target public key and configured, when executed with a respective unlock script including a respective candidate value, to transform the respective candidate value into a respective candidate public key and to require that the respective candidate public key match the respective target public key, the method being executed by the second party; The method includes obtaining one or more respective reveal blockchain transactions, each respective reveal blockchain transaction including one or more inputs, each respective input referencing a respective one of one or more respective outputs of the puzzle blockchain transaction, and including a respective unlock script, each respective unlock script including a respective candidate value; generating a shared encryption key based on the second private key, the first public key, and each respective candidate value, wherein the first party generates the shared encryption key based on the first private key, the second public key, and each respective target public key; A method comprising:

[0136] Statement 14. Generating at least one respective candidate value; providing at least one respective candidate value for inclusion in a respective unlock script of a respective reveal blockchain transaction; The method of statement 13, comprising:

[0137] Statement 15. Obtaining an encrypted message; decrypting the encrypted message using the shared encryption key; 15. The method of claim 13 or 14, comprising:

[0138] Statement 16. Encrypting a message using a shared encryption key to generate an encrypted message; making the encrypted message available to the first party; 16. The method of any of statements 13 to 15, comprising:

[0139] Statement 17. A computer-implemented method for enabling a second party to determine a shared encryption key, the method comprising: a first party having a first private key and a corresponding first public key; a second party having a second private key and a corresponding second public key; a blockchain comprising puzzle blockchain transactions, the puzzle blockchain transactions comprising one or more respective outputs, each respective output comprising a respective puzzle lock script, each respective puzzle lock script comprising a respective target public key and configured, when executed with a respective unlock script comprising a respective candidate value, to transform the respective candidate values ​​into respective candidate public keys and to require that each candidate public key match the respective target public key; the method is executed by a third party; and generating one or more respective candidate values; generating one or more respective reveal blockchain transactions, each respective reveal blockchain transaction including one or more inputs, each respective input referencing a respective one of the one or more respective outputs of the puzzle blockchain transaction, and including a respective unlock script, each respective unlock script including a respective candidate value; sending the one or more respective reveal blockchain transactions to one or more blockchain nodes of the blockchain network, the first party, and / or the second party; A method comprising:

[0140] Statement 18. The method of statement 17, wherein each respective puzzle lock script is configured to require that a respective signature correspond to a respective public key, and wherein at least one of the respective unlock scripts includes a respective signature corresponding to a third public key associated with a third party.

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

[0142] Statement 20. A computer device, a memory including one or more memory units; 20. A computing device comprising: a processing device including one or more processing units; and a memory storing code configured for execution on the processing device, the code configured, when executed on the processing device, to perform the method of any of statements 1 to 19.

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

[0144] In another aspect disclosed herein, a method may be provided that includes actions of a first party and a second party. In another aspect disclosed herein, a system may be provided that includes computer devices of a first party and a second party.

[0145] In another aspect disclosed herein, a method may be provided that includes actions of a first party and a third party. In another aspect disclosed herein, a system may be provided that includes computer devices of a first party and a third party.

[0146] In another aspect disclosed herein, a method may be provided that includes actions of a second party and a third party. In another aspect disclosed herein, a system may be provided that includes computer devices of a second party and a third party. [Explanation of symbols]

[0147] 101 Internet, packet-switched networks 102 Computer terminals and equipment 103 users 104 blockchain nodes 105 Client Applications 106 P2P networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output

Claims

1. 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, the method being performed by the first party, the method comprising: generating a puzzle blockchain transaction, the puzzle blockchain transaction including one or more respective outputs, each respective output including a respective puzzle lock script, each respective puzzle lock script including a respective target public key and configured, when executed with a respective unlock script including a respective candidate value, to transform the respective candidate value into a respective candidate public key and to require the respective candidate public key to match the respective target public key; transmitting the puzzle blockchain transaction to one or more blockchain nodes of a blockchain network and / or the second party; the first party is configured to generate the shared encryption key based on the first private key, the second public key, and each respective target public key, and 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.

2. The method of claim 1 , comprising generating the shared encryption key.

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

4. 4. The method of claim 1, wherein each respective puzzle lock script is configured to require a respective signature corresponding to a respective public key.

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

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

7. 7. The method of claim 1, wherein each respective puzzle lock script is configured to require that the respective unlock script include a plurality of respective signatures, each of the signatures corresponding to a respective public key, and at least one respective public key being associated with the first party.

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

9. encrypting a message using the shared encryption key to generate an encrypted message; making the encrypted message available to the second party; 9. The method of claim 2 or any one of claims 3 to 8 dependent on claim 2, comprising:

10. 10. The method of claim 1, further comprising providing one or more of the respective candidate values ​​to at least one party for inclusion in one or more respective unlock scripts, each respective unlock script configured to unlock a respective puzzle lock script of the puzzle blockchain transaction.

11. 11. A method according to claim 7 or any one of claims 8 to 10 dependent on claim 7, wherein the reveal blockchain transaction includes one or more respective unlock scripts and is configured to unlock one or more respective puzzle lock scripts of the puzzle blockchain transaction, the method comprising providing respective signatures corresponding to respective public keys associated with the first party for inclusion in the respective unlock scripts.

12. 12. The method of claim 11, wherein the reveal blockchain transaction includes a timelock value, the timelock value preventing the reveal blockchain transaction from being recorded on the blockchain until a time corresponding to the timelock value has elapsed.

13. 1. A computer-implemented method for determining a shared encryption key, wherein a first party has a first private key and a corresponding first public key, a second party has a second private key and a corresponding second public key, a blockchain comprising puzzle blockchain transactions, the puzzle blockchain transactions comprising one or more respective outputs, each respective output comprising a respective puzzle lock script, each respective puzzle lock script comprising a respective target public key, configured, when executed with a respective unlock script comprising a respective candidate value, to transform the respective candidate value into a respective candidate public key and to require the respective candidate public key to match the respective target public key, the method being performed by the second party, the method comprising: obtaining one or more respective reveal blockchain transactions, each respective reveal blockchain transaction including one or more inputs, each respective input referencing a respective one of the one or more respective outputs of the puzzle blockchain transaction, and including a respective unlock script, each respective unlock script including a respective candidate value; generating the shared encryption key based on the second private key, the first public key, and each respective candidate value, wherein the first party generates the shared encryption key based on the first private key, the second public key, and each respective target public key; A method comprising:

14. generating at least one respective candidate value; providing the at least one respective candidate value for inclusion in a respective unlock script of a respective reveal blockchain transaction; The method of claim 13, comprising:

15. obtaining the encrypted message; decrypting the encrypted message using the shared encryption key; 15. The method of claim 13 or 14, comprising:

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

17. 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, a blockchain comprising puzzle blockchain transactions, the puzzle blockchain transactions comprising one or more respective outputs, each respective output comprising a respective puzzle lock script, each respective puzzle lock script comprising a respective target public key and configured, when executed with a respective unlock script comprising a respective candidate value, to transform the respective candidate values ​​into respective candidate public keys and to require the respective candidate public keys to match the respective target public keys, the method being performed by a third party, the method comprising: generating one or more respective candidate values; generating one or more respective reveal blockchain transactions, each respective reveal blockchain transaction including one or more inputs, each respective input referencing a respective one of the one or more respective outputs of the puzzle blockchain transaction, and including a respective unlock script, each respective unlock script including a respective candidate value; sending the one or more respective reveal blockchain transactions to one or more blockchain nodes of a blockchain network, the first party, and / or the second party; A method comprising:

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

19. 19. The method of claim 17 or 18, wherein the third party includes the first party or the second party.

20. A computer device comprising: a memory including one or more memory units; 20. A computing device comprising: a processing device including one or more processing units; and the memory storing code configured for execution on the processing device, the code configured, when executed on the processing device, to perform the method of any one of claims 1 to 19.

21. 20. A computer program on a computer readable storage configured to perform the method of any one of claims 1 to 19 when executed on one or more processors.

Images