Cryptographically linked identities

Abstract

To provide a computer-implemented method of linking a first party and a second party.SOLUTION: A method is executed by a first party and includes the steps of: obtaining a first cryptographic public-private key pair comprising a first private key and a corresponding first public key; generating a first shared private key known to the first party and a second party; and generating a second cryptographic public-private key pair comprising a second private key and a corresponding second public key. The second private key is generated based on the first private key and the first shared private key.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a method for linking a first party and a second party using a cryptographic public-private key pair, and a method for verifying that link. In particular, the method allows a first party to prove that their public-private key pair is cryptographically linked to a public-private key pair of a second party. [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which multiple nodes in a peer-to-peer (P2P) network each maintain a duplicate copy of the blockchain. The blockchain contains a chain of blocks of data, where each block contains one or more transactions. Each transaction can point back to a previous transaction in a sequence that may span one or more blocks. Transactions can be submitted to the network for inclusion in a new block through a process known as "mining." This involves multiple mining nodes each competing to perform a "proof-of-work," i.e., solve a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Traditionally, transactions in a blockchain are used to convey digital assets, i.e., data that acts as a store of value. However, blockchains can also be used to layer additional functionality on top of the blockchain. For example, blockchain protocols allow for the storage of additional user data in the output of a transaction. Modern blockchains increase the maximum amount of data that can be stored within a single transaction, allowing more complex data to be incorporated. For example, this could be used to store electronic documents or even audio or video data within the blockchain.

[0004] Each node in the network can have any one, two, or all three roles: forwarding, mining, and storage. A forwarding node propagates transactions throughout the nodes of the network. A mining node mines transactions into blocks. A storage node stores its own copy of mined blocks in the blockchain. To record a transaction in the blockchain, a party sends the transaction to one of the nodes in the network to be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not propagated or mined into a block. Assuming the transaction is verified and thereby accepted into the blockchain, the additional user data therefore remains stored at each node in the P2P network as an immutable public record.

[0005] To avoid problems such as money laundering, identity theft, and corruption, identity management and verification are important in many business-to-business and business-to-consumer communications. However, it is not always possible to directly verify the identity of a party (e.g., an individual or business). Instead, trust in a party can be established through verified information and endorsement from a trusted third party. In this way, even anonymous peers can establish sufficient trust to communicate sensitive information. One such example is Transport Layer Security (TLS) certificates, which provide security over the Internet. Summary of the Invention

[0006] Blockchains provide a form of identification via public keys and addresses. These public keys and addresses are unique within the blockchain address space and are thus unique to each individual blockchain user. However, keys and addresses do not reveal information about the user's identity and are often insufficient to comply with regulations, such as know-your-customer (KYC) regulations. Additionally, blockchain keys and addresses typically do not interface with non-blockchain systems, which is required if blockchains are to be widely used and integrated within enterprise systems.

[0007] According to one aspect disclosed herein, there is provided a computer-implemented method for linking a first party and a second party, the method being performed by the first party and including the steps of obtaining a first cryptographic public-private key pair consisting of a first private key and a corresponding first public key, generating a first shared secret key known to the first party and the second party, and generating a second cryptographic public-private key pair consisting of a second private key and a corresponding second public key, where the second private key is generated based on the first private key and the first shared secret key.

[0008] This disclosure recognizes how one party can be cryptographically linked to another party using public key cryptography. Due to the cryptographic properties of public and private keys, the link between the first and second parties cannot be forged, and furthermore, the link can be verified by a third party. A second private key is generated based on the first private key and the shared secret key. Only the first party knows the second private key, and only the first and second parties know the shared secret key. Thus, only the first party can generate the second private key, but the first party can, if necessary, prove that the second public key was generated based on information that the second party can verify. If the second party is a trusted party, its trust can be associated with the first party by the fact that it established a shared secret key with the first party. This allows the identity of the first party to be trusted.

[0009] The public-private key pair may be a blockchain key pair. That is, the public key may be used as or may be used to generate an identifier (i.e., address) of a blockchain user. However, the present disclosure is not limited to blockchain systems. That is, the first party and / or second party need not be blockchain users, and the respective public-private key pairs need not be used for transactions over the blockchain.

[0010] According to another aspect disclosed herein, there is provided a computer-implemented method for verifying a link between a first party and a second party, the method being performed by a third party and including the steps of: obtaining from the second party i) a message signed with a first signature based on a first private key of the second party and ii) a first public key corresponding to the first private key; obtaining from the second party iii) a message signed with a second signature based on a second private key of the second party and iv) a second public key corresponding to the second private key; obtaining from the first party v) a message signed with a third signature based on a shared private key known only to the first and second parties and the corresponding shared public key; and determining whether the second public key of the second party was generated based on the first public key of the second party and the shared public key.

[0011] In this embodiment, a third party wishes to prove that a link exists between a first party and a second party. For example, the third party may trust the first party. By verifying the link between the first party and the second party, the third party can use its trust in the first party's identity to trust the second party's identity. The third party obtains (e.g., receives) two messages from the second party. One is signed with a signature based on a first private key known only to the second party, and the other is signed with a signature based on a second private key known only to the second party. The third party also obtains (e.g., receives) a message with a signature based on a private key known to both the first and second parties. If the public key corresponding to the second private key was generated based on the public key corresponding to the first private key and the public key corresponding to the shared secret key, the third party can verify that the first party established a shared secret key with the second party. The third party can then leverage its trust in the first party to trust the second party.

[0012] According to another aspect disclosed herein, there is provided a computer-implemented method for verifying a first signature used by a first party to sign a first message, wherein a blockchain includes recorded transactions, the recorded transactions including a registered value generated by applying a one-way function to a first value. The method is executed by the first party and includes generating the first signature by applying a one-way function to at least the first value and the first message; submitting the first transaction to one or more nodes of a blockchain network for inclusion in the blockchain, the first transaction including a message signed with the first signature; and submitting a second transaction to one or more nodes of the blockchain network for inclusion in the blockchain, the second transaction including the first value.

[0013] In public key cryptography, signatures are often generated using a private key and checked using the corresponding public key. This disclosure provides a method by which a signature can be generated without using the party's private key and by which the party can prove that only they could have provided the signature. The registration value is recorded (i.e., mined) on the blockchain and is therefore immutable. At this point, the first value is not recorded on the blockchain and is known only to the first party. The first party can generate a signature using the first value, sign a message using that signature, and submit a transaction including the message to the blockchain. The first party can then follow up with a second transaction that includes the first value, thereby proving the signature. This allows another party to apply a one-way function to the first value. If the result of applying the one-way function to the first value is the registration value, the verifying party can be sure that only the first party could have generated the signature. [Brief explanation of the drawings]

[0014] 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: [Figure 1] Figure 1 is a schematic block diagram of a system that implements blockchain. [Figure 2] Figure 2 shows a schematic example of a transaction that may be recorded in a blockchain. [Figure 3] FIG. 3 is a schematic block diagram of another system implementing a blockchain. [Figure 4] FIG. 4 illustrates schematically a method for cryptographically linking a first party and a second party. [Figure 5] FIG. 5 illustrates generally a method for verifying whether a first party is cryptographically linked to a second party. DETAILED DESCRIPTION OF THE INVENTION

[0015] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for generally implementing a blockchain 150. The system 100 includes a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each node 104 includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media. For example, 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.

[0016] The blockchain 150 includes a chain of blocks of data 151, with each copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain includes one or more transactions 152, where transaction in this context refers to a type of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the total amount of digital assets belonging to the user 103 to whom the output is cryptographically locked (requiring that user's signature to unlock and thereby redeem or spend). Each input points back to the output of a previous transaction 152, thereby linking the transactions.

[0017] At least some of the nodes 104 act as transfer nodes 104F, transferring and thereby propagating transactions 152. At least some of the nodes 104 act as miners 104M, mining blocks 151. At least some of the nodes 104 act as storage nodes 104S (sometimes also referred to as “full-copy” nodes), with each node storing a respective copy of the same blockchain 150 in its memory. Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a transfer node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0018] For a given current transaction 152j, the input (or each input) contains a pointer that references the output of a previous transaction 152i in the sequence of transactions and specifies that this output is redeemed, or "spent," in the current transaction 152j. In general, the previous transaction can be any transaction in the pool 154 or any block 151. The previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or even when it is sent to the network 106, but the previous transaction 152i must exist and be verified for the current transaction to be valid. Thus, "preceding" herein refers to preceding in the logical order linked by pointers, not necessarily to the time of creation or transmission in chronological order, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out-of-order (see later discussion of orphan transactions). The preceding transaction 152i may similarly be referred to as a preceding transaction or a preceding transaction.

[0019] The input of the current transaction 152j also includes the signature of the user 103a to whom the output of the previous transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user 103b. Thus, the current transaction 152j can transfer the total amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input total amount among multiple users (one of which may be the original user 103a to provide the changes). In some cases, a transaction may also have multiple inputs, collecting total amounts from multiple outputs of one or more previous transactions and redistributing them into one or more outputs of the current transaction.

[0020] The above is called an "output-based" transaction protocol, also sometimes called an unspent transaction output (UTXO) type protocol (where outputs are referred to as UTXOs). A user's total balance is not defined in any one number stored in the blockchain 151; instead, the user needs a special "wallet" application 105 to collate the values ​​of all of that user's UTXOs, which are scattered across many different transactions 152 in the blockchain 151.

[0021] An alternative type of transaction protocol, as part of the account-based transaction model, can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing back the UTXO of a previous transaction in a sequence of past transactions, but rather by referencing the absolute balance of the account. The current state of every account is stored by a separate miner on the blockchain and is constantly updated. In such a system, transactions are ordered using the account's running transaction tally (also called its "position"). This value is signed by the sender as part of the cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field can also be signed in the transaction. This data field can point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0022] In either type of transaction protocol, when a user 103 wants to enact a new transaction 152j, he / she sends the new transaction from his / her computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is typically a server or a data center, but could in principle be another user terminal). This node 104 checks whether the transaction is valid according to a node protocol applied at each node 104. The details of the node protocol form the overall transaction model and correspond to the type of transaction protocol used in the blockchain 150 in question. The node protocol typically requires the nodes 104 to check 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 the output-based case, this may involve checking that the user's cryptographic signature included in the input of the new transaction 152j matches a condition defined on the output of the previous transaction 152i to which the new transaction pays. Here, this condition typically includes at least checking that the cryptographic signature on the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input points. In some transaction protocols, the condition may be defined, at least in part, by custom script included in the inputs and / or outputs. Alternatively, it may be fixed solely in the node protocol, or a combination thereof. In either case, if the new transaction 152j is valid, the current node transfers it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also function as transfer nodes 104F, applying the same tests according to the same node protocol, and transferring the new transaction 152j to one or more additional nodes 104, etc.In this manner, the new transaction is propagated throughout the network of nodes 104.

[0023] In an output-based model, the definition of whether a given output (e.g., a UTXO) is paid or not is whether it has still been validly redeemed by another, onward transaction 152j input according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to pay or redeem has not already been paid / redeemed by another valid transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double spending, which is an attempt to spend the same transaction output more than once. On the other hand, an account-based model prevents double spending by maintaining account balances. Again, because there is a defined order of transactions, the account balance has a single, defined state at any time.

[0024] In addition to validating, at least some of the nodes 104M also compete to be the first to create a block of transactions in a process known as mining, which is underpinned by "proof of work." Mining nodes 104M add new transactions to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value so that, when the nonce is concatenated with the pool of transactions 154 and hashed, the hash output satisfies a specified condition. For example, the specified condition may be that the hash output has a predetermined number of leading zeros. A property of a hash function is that it has an unpredictable output given its input. This search can therefore only be performed by brute force and therefore consumes significant processing resources at each node 104M attempting to solve the puzzle.

[0025] The first minor node 104M to solve the puzzle announces this to the network 106 and provides its solution as a proof, which can be easily checked by other nodes 104 in the network (once the solution is given for the hash, it is easy to check that the hash output matches the conditions). The pool of transactions 154 for which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on checking the winner's announced solution at each such node. A block pointer 155 is also assigned to the new block 151n that points back to the previously generated block 151n-1 in the chain. Proof of work helps reduce the risk of double spending because it requires a great deal of effort to create a new block 151. And, because any block containing a double spend is likely to be rejected by other nodes 104, mining nodes 104M are incentivized not to allow double spends to be included in their blocks. Once created, blocks 151 cannot be modified because they are known and maintained by each storage node 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, this therefore provides an immutable public ledger of transactions.

[0026] Note that different 104M miners are competing at any given time, and may do so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they began searching for a solution. Whoever solves each puzzle first defines which transactions 152 will be included in the next new block 151n, and the current unmined transaction pool 154 is updated. Miners 104M then continue competing to generate blocks from the newly defined pending pool 154, and so on. A protocol also exists for resolving any "forks" that may arise, in which two miners 104M solve the puzzle within a very short time of each other, resulting in the propagation of inconsistent views of the blockchain. In essence, the longest branch of any fork becomes the final blockchain 150.

[0027] In most blockchains, winning miners 104M are automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of thin air (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). Thus, the winning node can be said to have “mined” an amount of digital assets. This special type of transaction is sometimes called a “generation” transaction. It automatically forms part of a new block 151n. This reward incentivizes miners 104M to participate in the proof-of-work competition. A regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs, further rewarding the winning miner 104M who produces the block 151n containing that transaction.

[0028] Due to the computational resources involved in mining, typically at least each of the minor nodes 104M takes the form of a server, including one or more physical server units or entire data centers. Each transfer node 104M and / or storage node 104S can also take the form of a server or data center. However, in principle, any given node 104 can take the form of a user terminal or a group of user terminals networked together.

[0029] The memory of each node 104 stores software configured to execute on the node's 104 processing unit to perform its role and process transactions 152 according to the node protocol. It will be understood that any action attributed to a node 104 herein may be performed by software executing on the processing unit of the respective computing device. Also, the term "blockchain" as used herein is a general term that refers to a general type of technology and is not limited to any particular proprietary blockchain protocol or service.

[0030] Also connected to the network 101 are computer devices 102 for each of multiple parties 103 in consuming user roles. These play the roles of payers and payees in transactions, but do not necessarily participate in mining or propagating transactions for other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and his / her respective computer device 102a, and a second party 103b and his / her respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 can exist and participate in the system, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be understood that this is not limiting and that references herein to Alice or Bob can be replaced with "first party" and "second party," respectively.

[0031] The computing equipment 102 of each party 103 includes a respective processing unit including one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or processors. The computing equipment 102 of each party 103 also includes memory, i.e., computer-readable storage devices in the form of non-transitory computer-readable media or mediums. This memory may include one or more memory units using one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to operate on the processing unit. It will be understood that any operations attributed to a given party 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 includes at least one user terminal. For example, 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 include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

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

[0033] The client application 105 has at least a "wallet" functionality. This has two main functions. One of these is to allow each user party 103 to create, sign, and send transactions 152 to be propagated throughout the network of nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the total amount of digital assets they currently own. In an output-based system, this second function involves reconciling the total amount defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to the party in question.

[0034] An instance of a client application 105 on each computing device 102 is operatively coupled to at least one transfer node 104F of the P2P network 106. This enables the wallet functionality of the client 105 to transmit transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions for which the respective party 103 is a recipient (or, indeed, to inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. Each node 104 executes software configured to validate transactions 152 according to the node protocol and, in the case of a transfer node 104F, transfer transactions 152 for propagation throughout the network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow different subtypes of transactions). The same node protocol is used by all nodes 104 in the network 106 (although many nodes handle different transaction subtypes differently according to rules defined for that subtype, and also different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0035] As described above, the blockchain 150 includes a chain of blocks 151, where each block 151 includes a set of one or more transactions 152 created by the proof-of-work process, as described above. Each block 151 also includes a block pointer 155 that points back to a previously created block 151 in the chain, defining a sequential order for the blocks 151. The blockchain 150 also includes a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (in addition to the transaction generation) includes a pointer back to a previous transaction, defining the order of the transactions (note that the shields of transactions 152 allow for branching). The chain of blocks 151 leads all the way back to the genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153, not to a previous transaction.

[0036] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using a wallet function in her client application 105) according to the associated transaction protocol. She then sends the transaction 152 from her client application 105 to one of one or more transfer nodes 104F to which she is connected. For example, this may be the transfer node 104F that is closest or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being “valid,” examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation can be set on a per-transaction basis by 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.

[0037] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., is "validated"), any storage node 104S that receives the transaction 152j adds the newly validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained by that node 104S. Additionally, any transfer node 104F that receives the transaction 152j propagates the validated transaction 152 to one or more other nodes 104 in the P2P network 106. Because each transfer node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will soon propagate throughout the P2P network 106.

[0038] Once in pool 154 in the copy of blockchain 150 maintained on one or more storage nodes 104, minor nodes 104M begin competing to solve the proof-of-work puzzle for the latest version of pool 154 that contains new transaction 152j. (Other minor nodes 104M still try to solve the puzzle based on their old view of pool 154, but whoever gets there first defines where the next new block 151 ends and the new pool 154 begins, and eventually, someone solves the puzzle for the part of pool 154 that contains Alice's transaction 152j.) Once proof-of-work has been done for pool 154 that contains new transaction 152j, it becomes an immutable part of one of blocks 151 in blockchain 150. Because each transaction 152j contains a pointer back to previous transactions, the order of transactions is also immutably recorded.

[0039] UTXO-based model Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based protocol or a "UTXO"-based protocol. However, this is not intended to be limiting to all possible implementations.

[0040] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (unless the UTXO has already been redeemed). A UTXO specifies a sum of digital assets (a store of value). It may also include, among other information, the transaction ID of the transaction from which it came. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0041] Suppose Alice 103a wants to create transaction 152j to transfer the amount of digital assets in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." This in turn takes the amount of digital assets locked for Alice in the output 203 of the previous transaction 152i and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2; Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point back to any previous (i.e., antecedent) transaction that still has unpaid outputs 203 locked for Alice.

[0042] The preceding transaction Tx0 may already be validated and included in the blockchain 150 when Alice creates her new transaction Tx1, or at least when she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the pool 154, in which case it will be included. Alternatively, Tx0 and Tx1 may be created and submitted to the network 102 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence defined by transaction pointers specified in the transactions (e.g., which transaction pointers point back to other transactions). They may be equivalently referred to as "predecessor" and "successor," "antecedent" and "descent," "parent" and "child," etc. This does not necessarily imply the order in which they are generated, transmitted to the network 106, or arrive at any given node 104. Nevertheless, a successor transaction (a successor transaction or "child") that points to a predecessor transaction (a predecessor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. It may be discarded, or it may be discarded or buffered for a period of time to wait for its parent, depending on the node protocol and / or minor actions.

[0043] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled here as UTXO0. Each UTXO includes a value specifying the aggregate amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be satisfied 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 aggregate amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script defines the unlocking conditions, and typically includes a condition that the unlocking script in the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

[0044] A locking script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called “Script” (capital S). A locking script specifies the information needed to pay the transaction output 203, e.g., the requirements for Alice's signature. An unlocking script appears in the transaction output. An unlocking script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the locking script. For example, it may include Bob's signature. An unlocking script appears in the transaction input 202.

[0045] In the example shown, UTXO0 of output 203 of Tx0 is A ], which means that for UTXO0 to be redeemed (or more precisely, for a subsequent transaction that attempts to redeem UTXO0 to be valid), Alice's signature Sig P A [Checksig P A] is the public key P from Alice's public-private key pair. A The input 202 of Tx1 includes a pointer that points back to Tx1 (e.g., using its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. The input 202 of Tx1 also includes an unlocking script that includes Alice's cryptographic signature, created by applying Alice's private key from her key pair to a predetermined portion of the data. <Sig P A (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature is defined by the locking script, the node protocol, or a combination of these.

[0046] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" is a function composed of the unlocking script (a stack-based language in this example). Similarly, the scripts may be executed one after the other on a common stack rather than concatenating them. In either case, when executed together, the scripts authenticate that the locking script on the input of Tx1 contains Alice's signature signing the expected portion of the data, as included in the locking script on the output of Tx0, using Alice's public key PA. To perform this authentication, the expected portion of the data itself (the "message") must also be included in the Tx0 sequence. In an embodiment, the signed data comprises the entirety of Tx0 (thus a separate element must be included specifying the signed portion of the data in the clear, since it is already inherently present).

[0047] The details of authentication with public-private cryptography will be well known to those skilled in the art. Essentially, if Alice signs a message by encrypting it using her private key, then given Alice's public key and the message in the clear (unencrypted), another entity, such as node 104, can authenticate that the encrypted version of the message was signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature on a clear version of the message, thus allowing any holder of the public key to authenticate the signature.

[0048] If Tx1's unlocking script meets one or more conditions specified in Tx0's locking script (as shown in the example, if Alice's signature is provided in Tx1 and is authenticated), the node 104 considers Tx1 valid. For a mining node 104M, this means it is added to the transaction pool 154 awaiting proof of work. For a transfer node 104F, it transfers transaction Tx1 to one or more other nodes 104 in the network 106, which then propagates it throughout the network. Once Tx1 is validated and included in the blockchain 150, this defines Tx0 to UTXO0 as a payment. Note that Tx1 is only valid if it pays an outstanding transaction output 203. If it attempts to pay an output that has already been paid by another transaction 152, Tx1 is invalid, even if all other conditions are met. Therefore, node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has already been spent (whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In fact, a given node 104 may maintain a separate database marking UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO has been spent is whether it has already formed a valid input to another valid transaction in blockchain 150.

[0049] Note that the UTXO-based transaction model requires that a given UTXO be spent in its entirety. It is not possible to "leave behind" a fraction of the total amount defined in the UTXO while another fraction is paid. However, the total amount of a UTXO can be split across multiple outputs of subsequent transactions. For example, the total amount defined in UTXO0 in Tx0 can be split across multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire total amount defined in UTXO0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

[0050] In practice, Alice also usually needs to include a fee for the winning miner, because today, the generation transaction reward alone is typically not enough to incentivize mining. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner's node 104M, and thus, while technically valid, it will not yet be propagated and included in the blockchain 150 (the miner protocol does not force the miner to accept transaction 152 if it does not want to). In some protocols, the mining reward does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total sum indicated by input 202 and the total sum specified in the output 203 of a given transaction 152 is automatically given to the winning miner 104. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the total amount of digital assets specified in UTXO0 is greater than the total amount specified in UTXO1, the difference automatically goes to the winning miner 104M. Alternatively or additionally, however, it is not necessarily excluded that the miner reward may be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0051] Also note that if the total sum specified in all outputs 203 of a given transaction 152 is greater than the total sum specified in all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction will not be propagated or mined into a block 151.

[0052] Alice and Bob's digital assets consist of unpaid UTXOs locked in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are distributed across UTXOs in various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines the entire balance of a given party 103. It is the role of the wallet function in the client application 105 to reconcile together the values ​​of all the various UTXOs locked for each party and not yet paid in another onward transaction. This can be done by querying the copy of the blockchain 150 stored on any storage node 104S, e.g., the storage node 104S closest to or best connected to each party's computer device 102.

[0053] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, [Checksig P A ], [Checksig P A]=OP_DUP OP_HASH160<H(Pa)> OP_EQUALVERIFY might be written to mean OP_CHECKSIG. The "OP_..." refers to a specific opcode in a scripting language. OP_CHECKSIG (also known as "Checksig") is a Script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ("sig") are removed from the script, but additional requirements, such as a hash puzzle, remain in the transaction to be verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for generating a non-spendable output of a transaction, which can store metadata within the transaction and thereby immutably record the metadata on the blockchain 150. For example, the metadata could include a document that is desired to be stored on the blockchain.

[0054] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256K1. A digital signature signs a specific piece of data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific portion of the outputs to sign depends on the SIGHASH flag, which is a four-byte code included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0055] A locking script is sometimes referred to as a "scriptPubKey," referring to the fact that each transaction contains the public key of the party being locked. An unlocking script is sometimes referred to as a "scriptSig," referring to the fact that it provides a corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the conditions for redeeming a UTXO include authenticating a signature. More generally, a scripting language may be used to define any one or more conditions. Thus, the more general terms "locking script" and "unlocking script" are preferred.

[0056] Optional Side Channel FIG. 3 illustrates a further system 100 for implementing a blockchain 150. The system 100 is substantially the same as that described with respect to FIG. 1, except that additional communication functionality is included. Client applications on Alice's and Bob's computing devices 102a, 120b, respectively, are equipped with the additional communication functionality. That is, the side channel 301 allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the solicitation of either the parties or a third party). The side channel 301 allows for the exchange of data separately from the P2P network. Such communication is sometimes referred to as "off-chain." For example, this may be used to exchange a transaction 152 between Alice and Bob without it being published on the P2P network 106 or progressing on the chain 150 until one of the parties chooses to broadcast it to the network 106. Alternatively or additionally, the side channel 301 may be used to exchange other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0057] The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay 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 over a direct wired or wireless link between Alice's and Bob's devices 1021, 102b. In general, the side channel 301 referred to anywhere herein may include any one or more links through one or more network technologies or communication media for exchanging data “off-chain,” i.e., separately from the P2P overlay network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, note that when Alice and Bob are said to exchange particular information or data, etc., over the side channel 301, this does not necessarily mean that all of this data must be transmitted over the exact same link or the same type of network.

[0058] public key cryptography Public key cryptography itself is well known and thus will only be briefly described here. Public key cryptography is used as the basis for protecting messages (e.g., transactions in many different blockchain architectures). Uses of public key cryptography include public key encryption and digital signature schemes. Public key cryptography is based on the principle that a given function is easy to compute but difficult to reverse without some special knowledge. Easy to compute means that it is computationally feasible to compute the result of the function for a given input (or set of inputs) in a reasonable time frame, and difficult to reverse means that it is computationally infeasible to infer the input (or inputs) from the result without knowledge of the inputs.

[0059] In the context of public key cryptography, a public-private key pair refers to a public key (which can be made freely available to anyone) and a corresponding private key (which is assumed to be secret in the sense that it is known only to a specific entity or group).

[0060] In a public key encryption context, encryption is performed using a public key, while decryption is performed using the corresponding private key. In a digital signature context, signature generation is performed using a private key, while signature verification is performed using the corresponding public key.

[0061] In the context of blockchain, digital signatures based on public key cryptography are used as the basis for cryptographically signing transactions and verifying transaction signatures.

[0062] Elliptic curve cryptography (ECC) is a form of public key cryptography that exploits the mathematical properties of elliptic curves. "Elliptic Curve Digital Signature Algorithm" (ECDSA) refers to a class of digital signature schemes that use ECC as the basis for digital signature generation and verification.

[0063] In the context of ECC, the operations of addition, subtraction, and multiplication are, respectively, elliptic curve point addition, denoted here as "+", elliptic curve point subtraction, denoted here as "-", and elliptic curve scalar multiplication, denoted here as "·". The addition and subtraction operations are each applied to two points on an elliptic curve and return a third point on the elliptic curve. However, the multiplication operation is applied to a scalar and a single point on an elliptic curve and returns a second point on the elliptic curve. Elliptic curve arithmetic offers the unique ability to obfuscate secret values ​​and forms the basis of many modern cryptosystems. In particular, reversing scalar multiplication of elliptic curve points over a finite field is an intractable problem (computationally infeasible).

[0064] The private key V takes the form of an integer, and the corresponding public key P is a point on an elliptic curve derived from the “generator point” G, which is also a point on an elliptic curve such that: P=V G=G+ +G (V additions) where "·" denotes elliptic curve scalar multiplication on an elliptic curve, defined by the elliptic curve parameters. For a sufficiently large V, it is difficult, i.e., computationally infeasible, to actually perform elliptic curve addition on V to derive P. However, if V is known, P can be computed more efficiently by exploiting the algebraic properties of elliptic curve arithmetic. One example of an efficient algorithm that can be used to compute P is the "double and add" algorithm - which can only be implemented if V is known.

[0065] Conversely, if V is unknown, there is no computationally feasible derivation (i.e., reversing the scalar multiplication) even if both G and P are known (this is the so-called “discrete-logarithm problem”). An attacker can attempt to “brute force” P by repeatedly performing elliptic curve point additions starting from G up to P. At that point, he will find that V is the number of elliptic curve point additions he had to perform, which proves computationally infeasible. Thus, V satisfies the trapdoor requirement in the above sense. In ECC, the public key P, the generator key G, and the elliptic curve are assumed to be public and known, while the private key V is secret.

[0066] In a blockchain system, a user or other entity typically holds a private key V that is used to prove their identity, and a corresponding public key P, calculated as follows: P=V·G

[0067] The private key V can be used to sign a piece of data m (a "message") using ECDSA. Further details of ECDSA are described, for example, in "RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)," Tools.ietf.org, 2019, which is incorporated herein by reference in its entirety.

[0068] Cryptographically Linked Identities Reference is now made to FIG. 4, which illustrates a method for cryptographically linking two parties. The following is described with respect to actions performed by a first party (e.g., Alice) 103a, but it will be understood that a second party (e.g., Bob) 103b may perform some or all of the same actions. The first and second parties may be the same first and second parties described with reference to FIGS. 1 through 3. Alternatively, the first and / or second parties may be non-blockchain users. Typically, each party operates a respective computing device configured to perform the respective party's actions.

[0069] The two parties can be linked by exploiting the cryptographic properties of public key cryptography. The following is described with respect to elliptic curve cryptography, but it will be understood that the teachings apply generally to other forms of public key cryptography. Elliptic curve mathematics can be used to securely link the identities of two parties using only their public keys and a public key generated from a shared secret key. As shown in Figure 4, Alice 103a and Bob 103b each have their own public and private key pair. Alice 103a shares a first private key S A0 , and the corresponding first public key P A0 Similarly, Bob has a first private key S B0 , and the corresponding first public key P B0 Alice 103a and Bob 103b also have a shared secret key S AB0 , and the corresponding first public key P AB0 The shared secret key may be established using a side channel 301, as shown in Figure 3. As implied by the name, the public key is assumed to be accessible by either party and / or an external third party. In contrast, the private key is assumed to be kept secret to the owner of the private key.

[0070] The shared secret key can be established using a Diffie-Hellman key-exchange or an extension thereof. One technique for establishing a shared secret key is for each party to generate a shared secret key using their own private key (which may or may not be the first private key) and the other party's public key (which may or may not be the first public key). For example, Alice 103a may generate her private key S A and Bob's public key P B Similarly, Bob uses his private key S B and Alice's public key P A is used as follows: S AB0 =[S A S B G]x=[S A P B ]x=[S B P A ]x Here, [ ]x indicates the x coordinate of the elliptic curve point.

[0071] Only Alice 103a knows her private key S A and only Bob 103b has access to his private key S B If Alice 103a and Bob 103b know AB0 The shared secret key S AB0 can be established without divulging sensitive information, namely the private key.

[0072] The table below shows the public and private keys owned by Alice 103a and Bob 103b. In this example, the public key is related to the private key by elliptic curve multiplication, P=V·G, where G is the elliptic curve generating point. [Table 1]

[0073] Alice 103a then obtains her first private key S A0 and a shared secret key SAB0 and a second private key S, referred to herein as the identity-linked key. A1 For example, Alice's identity link key can be generated as S A1 =S A0 +S AB0 Only Alice 103a can generate S A0 Since only Alice knows S A1 and P A1 can be generated.

[0074] However, the public key P A0 and P AB0 Since P is publicly known, the public key can be verified by anyone. A1 can be derived by Alice 103a using her private key and by another party using a public key. P A1 =S A1 G P A1 =(S A0 +S AB0 )·G P A1 =(S A0 G)+(S AB0 G) P A1 =P A0 +P AB0

[0075] Similarly, Bob 103b has a first private key S B0 and a shared secret key S AB0 Using both, the identity link key S B1 For example, Bob's identity link key can be generated as S B1 =S A0 +S B0 Only Bob can generate S B0 Since only Bob knows S B1 and P B1 can be generated. A0 and S AB0 Using the more complex equation for SA1 Similarly, S B0 and S AB0 Using the more complex equation for S B1 can be generated.

[0076] Each party has a shared secret S AB0 The identity of the other party can be verified using a secret S that is shared only by Alice 103a and Bob 103b. AB0 Since Alice knows AB0 If Alice receives a message signed with P, she can verify that the message is from Bob. AB0 If Alice receives a message signed with the public key, she can be sure it is from Alice. Recall that the corresponding private key is required to sign a message with the public key.

[0077] For security reasons, an identity link key should only be used once. To update an identity link key, Alice 103a and Bob 103b must establish an updated shared secret key. Alice 103a and Bob 103b can communicate with each other to establish the updated shared secret key. Alternatively, Alice 103a and Bob 103b can each apply the same one-way function (e.g., a hash function) to the initial shared secret key. Applying the one-way function a predetermined number of times (e.g., once) generates an updated shared secret key. Applying the one-way function a predetermined number of times (e.g., once) to the first updated shared secret key generates a second updated secret key. This method allows Alice 103a and Bob 103b to generate updated shared secret keys on low-power devices using computationally efficient techniques. This method also generates a hierarchy of shared secret keys. Now, each updated secret key can be linked back to the original shared secret key.

[0078] One way to generate a sequence of shared public-private key pairs is by repeatedly hashing an initial shared secret. P AB0 =S AB0 G P AB1 =h(S AB0 )·G P AB2 =h 2 (S AB0 )·G | P ABi =h i (S AB0 )·G

[0079] Another method for generating the sequence of updated shared keys is as follows. 1. P i =[h i (S0)+h i (P A-1 -P B-1 )]·G 2. P i =h(S i-1 |S i-2 )·G

[0080] Each updated shared secret key can be used to generate a respective updated identity link key. For example, the identity link keys of Alice 103a and Bob 103b can be updated as follows: P A(i+1) =P ABi +P A0 P B(i+1) =P ABi +P B0

[0081] These keys are updated so that each party can A(i+1) or P B(i+1)The parties only know the identity of the other party and are unaware of the other party's identity. However, the identity of one party (e.g., Alice 103a) can be linked at any stage, if desired, via a signature challenge.

[0082] Alice 103a uses her identity link key P to sign the message. Ai and then send that message to Bob 103b or a third party. In the context of blockchain, Alice 103a can use one of her identity link keys to sign part or all of a blockchain transaction. For example, Alice 103a can sign the input of a transaction. Alice 103a can then send that transaction to Bob, a third party, or one or more nodes in the blockchain network, where it can be mined into the blockchain 150. The identity link key allows Alice 103a to sign any part of a blockchain transaction. Furthermore, the identity link key allows one or more parties to sign parts of a transaction. For example, Alice 103a can sign (part of) a transaction and then send that transaction to Bob 103b, who also signs (part of) the same transaction, and then Alice 103a or Bob can send the transaction to the blockchain network.

[0083] Cryptographically linked party verification Figure 5 illustrates a method a third party (Charlie) 103c can use to verify whether a first party and a second party are cryptographically linked. Although not shown in Figure 5, Charlie includes a computing device having one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing devices including field-programmable gate arrays (FPGAs). The computing device also includes memory, i.e., computer-readable storage devices in the form of non-transitory computer-readable media or media. The memory may include one or more memory units using 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.

[0084] As shown in FIG. 5, Alice 103a has a first secret key S A0 , shared secret key S AB0 , and a second private key (i.e., her identity link key) S A1 Similarly, Bob 103b possesses a first private key S B0 , shared secret key S AB0 , and a second private key (i.e., her identity link key) S B1In this example, one of Alice 103a or Bob 103b can be a trusted party. If Alice 103a is the trusted party, Charlie 103c can use his trust in Alice's identity to trust Bob's identity. To do this, Charlie 103c can verify that Bob has an identity link key linked to Alice. Charlie 103c can use the dependency of the identity link key on the shared secret key to have Bob 103b prove his relationship to Alice 103a. Charlie 103c obtains a message from Bob 103b signed using Bob's first public key-private key pair. Charlie 103c also obtains a message from Bob 103b signed using his identity link public key-private key pair. Bob 103b can select a message to send to Charlie 103c. Alternatively, Charlie 103c can send a message (e.g., a challenge) to Bob 103b to sign. Charlie 103c also gets a message from Alice 103a that was signed using the shared public-private key pair. Again, Alice 103a can send the message by deciding on the message with Bob 103b, or Charlie 103c can send the message to Alice 103a. Charlie 103c can first get the message from Bob 103b or Alice 103a. Once Charlie 103c has the signed message, Charlie 103c verifies that Bob's identity link key was generated based on the shared secret key. Charlie 103c verifies this by checking and determining whether the identity link public key was generated based on Bob's first public key and the shared public key, e.g., P B1 =P AB0 +P B0 .

[0085] Charlie can obtain signed messages from Alice and / or Bob over the Internet, for example, using side channel 301 as shown in FIG.

[0086] Once verified, this proves an unforgettable connection between Alice 103a and Bob 103b. Charlie 103c may also perform checks to verify that the signatures generated by Alice and Bob are valid signatures. Furthermore, Charlie 103c can cause Alice 103a and Bob 103b to send messages using one or more blockchain transactions. For example, the signed message may be included in the output of the blockchain transaction. Charlie 103c can then create a transaction with that output as an input to his transaction. The input may include a script to verify the relationship between Alice's 103a's public key and Bob's public key. Once verified, the relationship is immutably stored on the blockchain 150.

[0087] While the above techniques have been described with reference to Alice 103a and Bob 103b, in general, the first and second parties can be the same entity (e.g., the same individual, company, organization, etc.). For example, the first party may wish to cryptographically bind its (trusted) identity to another's identity, such as by linking one of its public keys with a secret known only to it. Similarly, each party's first private key need not utilize the same public key cryptosystem. For example, Alice 103a may utilize elliptic curve cryptography, while Bob may utilize RSA or DSA encryption. Similarly, Alice's and / or Bob's first private key and shared secret key may utilize different cryptosystems. In some examples, if different cryptosystems are used, at least one of the private keys may require padding or truncation to reflect the other's private scheme.

[0088] For example, consider a non-blockchain system such as a government or bank that has a sufficiently rigorous know-your-customer (KYC) system. A known user, say Alice 103a, has a public key P A0 A private key (S) connected to her identity via A0 ), which can be verified and publicly certified by a bank or government. Alice 103a can then use the methods described above to create her blockchain identity (S B0 ,P B0 ) can be reliably linked to this off-chain system, and her identity link key can be calculated as P B1 =(S B0 +S AB0 ) G, deriving a subsequent key or hierarchy of keys that can all be linked to her off-chain identity. This can then be used as her blockchain identity, and P AB0 Using P A0 This not only gives KYC features to her blockchain identity, but also gives blockchain capabilities to her off-chain accounts with governments and banks: she can use her identity linking key to join the blockchain system, which can then be used by the bank or government to update her off-chain accounts (e.g., credit or debit) without exposing them to the blockchain 150.

[0089] Access Chain By using the data storage capabilities of a blockchain, parties can utilize inherent cryptographic signature schemes to act as signatures for encapsulating data. However, for the most part, the protocols underlying blockchain 150 are fixed and therefore cannot be tailored to specific applications. This requires parties to have valid private keys, limiting their use to those already part of the system. Similarly, there is no way to delegate the ability to sign without exposing a party's private key. The present disclosure provides a second-layer signature protocol that can be included within blockchain transactions, allowing multiple parties to be involved in a single transaction.

[0090] One-way functions (e.g., cryptographic hash functions) provide an efficient, deterministic way to obfuscate an input, so that it is impossible to find the input given the output. Hash functions (or one-way functions in general) can be used to generate "tokens" that can be provided to a party, redeemed by that party, and transferred between different parties. Tokens can be generated through repeated hashing of a seed value to form what is called an access chain.

[0091] Using a pre-agreed number (n) of events that require a token to access a user involves applying a hash function (h) to a secret key (K) n times (h n (K)). This value is then registered, e.g., with a service provider, by publishing it on the blockchain 150. A party can then redeem the token by providing a pre-image of the registered value on the blockchain 150, which becomes the new registered value. For example, token t n =h n If (K) is currently published on the blockchain 150, then t n-1=h n-1 Tokens can be redeemed by providing (K).

[0092] At any point, the token holder can transfer their remaining tokens to another party, for example, by finding a willing buyer and agreeing on a price for the tokens. If Alice 103a is the currently registered token holder, she provides her latest pre-image to the service provider along with the value of the new party's newly generated and registered access chain to prove her identity.

[0093] These tokens are created by the root private key S0 and the chain t i A new private key S with each redemption as the sum of the next preimage in i By generating (S i =S0+t i ), which can also be provably linked to a public key.

[0094] In addition to providing a token, the Access Chain provides a way to link signatures over a predetermined number of messages. These signatures can be applied directly to chunks of data, rather than the entire transaction. For example, consider a hash chain of length n, i.e.: t n =h n (K) t n-1 =h n-1 (K) | t i =h i (K) | t1=h(K) t0=h(K)

[0095] In such a chain, t n =h(t n-1 ) form a chain of hashes. The final value t nis registered to a given public key (or address) by publishing it to the blockchain 150. Providing a pre-image that resolves to the most recent registered value can act as a signature for messages or other data that may be included in a transaction. This signature is publicly verifiable and can only be provided by the token owner. However, this method is susceptible to replay attacks, where an attacker can generate malicious transactions once they see the signature value.

[0096] The techniques described herein provide a secure, two-stage signing process in which one transaction is used to provide a signature and another transaction is used to certify the signature.

[0097] A first party, for example, Alice 103a, has a pre-image (first value) of a token (registered value) recorded in the blockchain 150. The registered value is generated by applying a one-way function (such as a hash function) to the first value. When Alice 103a wants to sign a message, she can generate a signature for the message by applying the one-way function to at least the first value and the message. Alice 103a can then construct a transaction including the signed message and submit the transaction to the blockchain network 106. Alice 103a can then construct a second transaction including the first value (i.e., the pre-image to the registered value) and submit the transaction to the blockchain network. The first and second transactions may be the same transaction or different transactions.

[0098] From this, the first value is also recorded in the blockchain 150 and is thus the newly registered value (or updated registered value). Alice 103a can repeat the above process to sign a second message. That is, Alice 103a generates a signature by hashing the newly registered value and a pre-image of the message. Alice 103a sends a transaction containing the signed message (this transaction may be the same as the second transaction or a different transaction) to the blockchain network 106. Alice 103a then sends a transaction containing a pre-image for the updated registered value to the blockchain network. This process can be repeated until the seed value is revealed.

[0099] In some examples, instead of hashing the preimage and the message, Alice 103a hashes the hash of the preimage and the message. For example, Alice 103a hashes the access chain created using t0, . . . , t1 as defined above, and the nth (n th )'s message m n can generate the value t n+1 =h(t n ) is currently registered in the blockchain 150, and thus Alice can use both the hash of the message and a preimage of the most recently registered value to generate a message m n A signature can be constructed for h(t n +h(m n ))

[0100] Here again, t n+1 =h(t n) At this point, if the transaction containing the signature is included in a block, the signature cannot be verified. To do this, Alice 103a constructs an attestation transaction, where t is the latest value in the access chain registered in the blockchain 150. n is provided and registered.

[0101] By providing this value, both access chains can n )=t n+1 and h(t i +h(m i The signature can be verified by checking that the data provided in the first transaction matches the data provided in the first transaction. This two-step signing process is one in which the user nominally attests, and, once complete, sends a verification and attestation.

[0102] The one-way function used by Alice 103a may be a hash-based message authentication code (HMAC). An HMAC is a tabulated value that utilizes a message m and a key K to provide message verification. HMAC is a category of message authentication code (MAC) that utilizes a preimage and the collision resistance of a cryptographic hash function to prevent exposure of the key used to compute the HMAC. It has wide application in secure message transmission and transmission error detection because small changes in the input typically result in significant changes in the output of the hash function.

[0103] Let h(x) be a hash function evaluated at a value x. HMAC is defined as follows:

number

[0104] This can serve as a secure signature scheme that can be applied directly to a piece of data (in this case, a message m), which is published to the blockchain 150, followed by authentication by providing a key K that can verify the signature.

[0105] Using the private key, K, an access chain level can be formed that is n levels deep, i.e.: t1=h(K) t2=h 2 (K) | t n =h n (K) where K is the ultimate secret, and t n is the initial registration value in the blockchain 150. Alice 103a then uses HMAC(t n-1 , m). The verifying party (e.g., Bob) can then use the newly exposed value to actually verify H(t n-1 )=t n Check that HMAC'(t n-1 ,m) matches the registered value. The exposure of the pre-image acts as a proof for the signature. Again, this process can be repeated to generate and prove a new signature for each message to be signed.

[0106] This relationship gives the signature a finite lifetime until the next value in the access chain is exposed. It also enables delegation of signatures, since a signer (Alice 103a) can provide the next one or more values ​​in the access chain (without revealing the root of the access chain) to a second party (e.g., Bob 103b) who can submit a signature on her behalf. This process requires a degree of trust between the access chain holder and the proxy, since the raw key is owned by the proxy. The proxy may be required to submit at least one signed transaction using the public key to which it can be connected. Therefore, if a proxy misuses the key, transaction signatures can be used to identify them.

[0107] As one use case, in many legal scenarios, contract terms may be changed periodically to comply with new laws introduced in various jurisdictions. This often requires many contracts to be changed in the same or nearly the same way. The above scheme provides a way to apply signatures to a finite and predetermined number of documents using an access chain. For example, consider a signer who has a legally binding contract m0 and a secret K. The signer then stores the contract in the blockchain 150. n =h n (K) can be published. n Using the preimage of (K), we can generate a signature. n-1 The message (h(t n-1 +h(m0)) or for additional security use the HMAC scheme HMAC(t n-1, m). When a contract needs to be amended, the amendment (m1) can be signed by the signer using the next value in the chain. Thus, a complete record of all contract states is permanently recorded and time-stamped in the blockchain 150. Multiple signatures can also be combined into a single transaction to efficiently manage multiple contracts, as they are applied directly to the data (in this case the contract amendment) and then verified.

[0108] Identity Link Access Chain As described above, Alice 103a and Bob 103b can each derive an identity link key that is securely associated with the other party. Instead of using the identity link keys directly, Alice and Bob can each use their respective identity link keys to derive a new shared secret key. As described above, Alice's and Bob's respective identity link keys are generated as follows: P A1 =(S A0 +S AB0 )·G P B1 =(S B0 +S AB0 )·G

[0109] From this, Alice 103a and Bob 103b can each calculate a derived shared private key (“a first derived shared private key”) as follows: S AB1 =[S A1 S B1 G] x =[S A1 P B1 ] x =[S A1 P A1 ] x' where [ ] xdenotes the x-coordinate of the elliptic curve point. This newly derived shared secret key, or a key derived from it, can then serve as a seed in the access chain. Finally, since the root of the access chain is exposed, using the derived key will AB0 Since this does not compromise S, a new chain can be created again. For example, a new chain can be created by AB1 can be calculated using

[0110] For example, t n =h n (S AB1 Considering a 100 level deep access chain, Alice 103a can generate the following: t 100 =h 100 (S AB1 ) t 99 =h 99 (S AB1 ) | t1=h 1 (S AB1 ) t0=S AB1

[0111] Alice can then include t in a transaction and submit the transaction to the blockchain network to be stored in the blockchain 150. 100 Bob 103b can then publicly register S by calculating his own value (he also AB1 (since they also know Alice's identity) they can verify Alice's identity.

[0112] One party is S AB1If Bob 103b suspects that the other party has been compromised by the exposure of m, they can request a challenge solution that requests a next value that only the two original parties are required to be able to execute. Bob 103b sends a challenge message (m c ) and the expected format, both of which can be sent using S AB0 A key that is encrypted using or derived from S AB0 Since t is not used in the compromised access chain, it cannot be compromised either, and thus no one other than Alice 103a can know the required format of the challenge message and response. n+1 is the most recent value recorded in the blockchain 150, the required response can take one of the following forms:

number

number

[0113] We now describe an exemplary use case. Audits provide an independent assessment of a wide range of business processes, including financial reporting, regulatory compliance, and product quality. Third-party auditors can form a critical part of the supply chain, especially if the business produces products that ultimately reach consumers. Currently, many of these auditors do not have the option to integrate with blockchain systems. Using an identity-linked access chain, the authenticity of the attestation can be verified using the linked identities and can be updated at any frequency required by the auditing body.

[0114] The certification authority will issue a public key P A1 The public key must be declared and have a sufficiently strict KYC procedure. The auditor must AB1 ,P AB1 ), for example, calculated by a Diffie-Hellman exchange, can link his or her identity to the authority. n The access chain is registered by a certification body. n =h n (S AB1 ) can act as the root of the compliance audit. Individual auditors can then perform the required compliance investigation and provide proof of compliance m0 using the signing method described above, recording a pre-image of the latest registration value on the blockchain 150. This certificate can be given an expiration date after which another compliance audit must be performed. At each renewal, the required reporting conditions can be verified, and if the conditions are not met, the signature is withheld. This provides an immutable record of compliance that is traceable back to individual auditors and with a verifiable relationship to the certification body.

[0115] conclusion It will be understood that the above-described embodiments have been described by way of example only.

[0116] More generally, according to a first instantiation of the teachings disclosed herein, there may be provided a computer-implemented method for linking a first party and a second party, the method being performed by the first party and including the steps of obtaining a first cryptographic public-private key pair consisting of a first private key and a corresponding first public key, generating a first shared secret key known to the first party and the second party, and generating a second cryptographic public-private key pair consisting of a second private key and a corresponding second public key, where the second private key is generated based on the first private key and the first shared secret key.

[0117] According to an optional second instantiation of the teachings disclosed herein, there may be provided a method according to the first instantiation, the method including: generating one or more updated shared secret keys, each updated shared secret key known to the first party and the second party; and generating one or more updated second cryptographic public-private key pairs, each updated second private key and a corresponding updated second public key, each updated second private key generated based on the first private key and a different one of the one or more updated shared secret keys.

[0118] In some embodiments, a plurality of updated shared secret key pairs are generated, and a plurality of updated second cryptographic public key pairs are generated, where each updated second private key is generated based on the first private key and a different one of the plurality of updated shared private keys.

[0119] According to an optional third instantiation of the teachings disclosed herein, there may be provided a method according to the second instantiation, wherein the one or more updated shared secret keys form a sequence of keys starting with the first shared secret key, and each subsequent secret key in the sequence is generated by applying a one-way function to at least the previous shared secret key in the sequence.

[0120] According to an optional fourth instantiation of the teachings disclosed herein, there may be provided a method according to any one of the first to third instantiations, the method including obtaining a second public key of the second party, the second public key of the second party being generated based on a first private key of the second party and the first shared secret key, and generating a derived shared secret key based on the second private key of the first party and the second public key of the second party.

[0121] According to an optional fifth instantiation of the teachings disclosed herein, the method includes generating a sequence of values, wherein an initial value in the sequence is a derived shared secret key or is generated by applying a one-way function to the derived shared secret key, and wherein each subsequent value in the sequence is generated by applying a one-way function to at least the previous value in the sequence.

[0122] According to an optional sixth instantiation of the teachings disclosed herein, there may be provided a method according to the fifth instantiation, the method including: sending a blockchain transaction to one or more nodes of a blockchain network for inclusion in the blockchain, the blockchain transaction including a most recent value in the sequence of values.

[0123] For example, the most recent value in a sequence may be the final (i.e., last) value. Alternatively, the most recent value in a sequence may be the previous value in the sequence. For example, the final nth value is submitted to the blockchain, then the n-1th value, then the n-2th value, etc.

[0124] According to an optional seventh instantiation of the teachings disclosed herein, there may be provided a method according to the sixth instantiation, the method including receiving a challenge message from the second party, the challenge message encrypted based on the first shared secret key, generating a response to the challenge message, the response based on the challenge message and the value immediately preceding the most recent value in the sequence of values, and transmitting the response to the second party.

[0125] According to an optional eighth instantiation of the teachings disclosed herein, there may be provided a method according to the seventh instantiation, the method including receiving the response from the second party in an expected format, the expected format being encrypted based on the first shared secret key, and the generated response being further based on the expected format.

[0126] According to an optional ninth instantiation of the teachings disclosed herein, the first shared secret key is generated based on the private key of the first party's third cryptographic public-private key pair and the public key of the second party's cryptographic public-private key pair.

[0127] The first shared secret key may also be generated from the third public key of the first party's third cryptographic public-private key pair and the private key of the second party's cryptographic public-private key pair.

[0128] According to an optional tenth instantiation of the teachings disclosed herein, there may be provided a method according to any one of the first to ninth instantiations, wherein the first party and the second party are the same party.

[0129] According to an optional eleventh instantiation of the teachings disclosed herein, there may be provided a method according to any one of the first to ninth instantiations, wherein the first party and the second party are different parties.

[0130] According to an optional twelfth instantiation of the teachings disclosed herein, there may be provided a method according to any one of the first to eleventh instantiations, the method including signing a message with a signature based on the second private key of the first party, and sending the signed message to the second party and / or a different third party.

[0131] According to an optional thirteenth instantiation of the teachings disclosed herein, there may be provided a method according to any one of the first through twelfth instantiations, the method including signing at least a portion of a blockchain transaction with a signature based on the second private key of the first party, and transmitting the blockchain transaction to one or more nodes of a blockchain network for inclusion in a blockchain.

[0132] According to a fourteenth instantiation of the teachings disclosed herein, there may be provided a computer-implemented method for verifying a link between a first party and a second party, the method being performed by a third party and comprising the steps of: obtaining from the second party i) a message signed with a first signature based on a first private key of the second party and ii) a first public key corresponding to the first private key; obtaining from the second party iii) a message signed with a second signature based on a second private key of the second party and iv) a second public key corresponding to the second private key; obtaining from the first party v) a message signed with a third signature based on a shared private key known only to the first and second parties and the corresponding shared public key; and determining whether the second public key of the second party was generated based on the first public key of the second party and the shared public key.

[0133] According to an optional fifteenth instantiation of the teachings disclosed herein, there may be provided a method according to the fourteenth instantiation, wherein the determining step includes determining whether the first signature, the second signature, and the third signature are valid signatures.

[0134] According to an optional sixteenth instantiation of the teachings disclosed herein, there may be provided a method according to the fourteenth or fifteenth instantiation, the method including sending the message to the first party and the second party.

[0135] According to an optional seventeenth instantiation of the teachings disclosed herein, there may be provided a method according to the fourteenth or sixteenth instantiation, wherein the first party and the second party are the same party.

[0136] According to an optional eighteenth instantiation of the teachings disclosed herein, there may be provided a method according to the fourteenth or sixteenth instantiation, wherein the first party and the second party are different parties.

[0137] According to a nineteenth instantiation of the teachings disclosed herein, there may be provided a computer-implemented method for verifying a first signature used by a first party to sign a first message, wherein a blockchain includes recorded transactions, the recorded transactions including a registered value generated by applying a one-way function to a first value. The method is executed by the first party and includes generating the first signature by applying a one-way function to at least the first value and the first message; submitting the first transaction to one or more nodes of a blockchain network for inclusion in the blockchain, the first transaction including a message signed with the first signature; and submitting a second transaction to one or more nodes of the blockchain network for inclusion in the blockchain, the second transaction including the first value.

[0138] According to an optional twentieth instantiation of the teachings disclosed herein, there may be provided a method according to a nineteenth instantiation, wherein the first value is an updated registration value and is generated by applying a one-way function to a second value. The method includes generating a second signature by applying the one-way function to at least the second value and a second message; sending a third transaction to one or more nodes of a blockchain network for inclusion in the blockchain, the third transaction including the second message signed with the second signature; and sending a fourth transaction to one or more nodes of the blockchain network for inclusion in the blockchain, the fourth transaction including the second value.

[0139] According to an optional twenty-first instantiation of the teachings disclosed herein, there may be provided a method according to the nineteenth or twentieth instantiation, wherein the first signature is generated by applying a one-way function to at least i) the first value and ii) a result of applying the one-way function to the first message.

[0140] For example, the first signature may be generated by hashing the first message and then hashing the combination of the first value and the hash of the first message.

[0141] According to an optional twenty-second instantiation of the teachings disclosed herein, there may be provided a method according to any one of the nineteenth to twenty-first instantiations, wherein the first signature is a hash-based message authentication code.

[0142] According to an optional 23rd instantiation of the teachings disclosed herein, there may be provided a method according to any one of the 19th to 22nd instantiations, wherein transmitting the second transaction includes transmitting the second transaction to one or more nodes of the blockchain network after the first transaction has been included in the blockchain.

[0143] According to an optional 24th instantiation of the teachings disclosed herein, there may be provided a method according to any one of the 19th to 23rd instantiations, wherein the registration value and the first value are part of a sequence of values, and each subsequent value in the sequence is generated by applying a one-way function to a previous value in the sequence.

[0144] According to an optional twenty-fifth instantiation of the teachings disclosed herein, there may be provided a method according to the twenty-fourth instantiation, the method including transmitting to a second party one or more values ​​of the sequence of values.

[0145] According to an optional 26th instantiation of the teachings disclosed herein, there may be provided a method according to any one of the 19th to 25th instantiations, wherein the first transaction and the third transaction are the same transaction, and / or the second transaction and the fourth transaction are the same transaction.

[0146] According to an optional 27th instantiation of the teachings disclosed herein, there may be provided a method according to any one of the 1st to 26th instantiations, wherein the one-way function is a cryptographic hash function.

[0147] According to a 28th instantiation of the teachings disclosed herein, there is provided a first party computing device, the computing device including a memory including one or more memory units, and a processing device having one or more processing units, wherein the memory stores code configured to execute on the processing device, the code configured to execute any one of the first through thirteenth instantiations on the processing device.

[0148] According to a twenty-ninth instantiation of the teachings disclosed herein, there is provided a computer program stored on a computer-readable storage device, the computer program configured to perform any one of the first through thirteenth instantiations when executed on the first party's computing device.

[0149] According to a thirtieth instantiation of the teachings disclosed herein, there is provided a third party computing device, the computing device including a memory including one or more memory units, and a processing device having one or more processing units, wherein the memory stores code configured to execute on the processing device, the code configured to execute any one of the fourteenth through eighteenth instantiations on the processing device.

[0150] According to a thirty-first instantiation of the teachings disclosed herein, there is provided a computer program stored on a computer-readable storage device, the computer program configured to perform any one of the fourteenth through eighteenth instantiations when executed on the third party's computing device.

[0151] According to a thirty-second instantiation of the teachings disclosed herein, there is provided a first party computer device, the computer device including a memory including one or more memory units, and a processing device having one or more processing units, wherein the memory stores code configured to execute on the processing device, the code configured to execute any one of instantiations 19 through 27 on the processing device.

[0152] According to a thirty-third instantiation of the teachings disclosed herein, there is provided a computer program stored on a computer-readable storage device, the computer program being configured, when executed on the first party's computing device, to perform any one of instantiations ...

[0153] According to another instantiation of the teachings disclosed herein, a method may be provided that includes first party, second party, and / or third party actions.

[0154] According to another instantiation of the teachings disclosed herein, a first party, second party, and / or third party computer device may be provided.

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

Claims

1. 1. A computer-implemented method for verifying a link between a first party and a second party, comprising: The method is performed by a third party; and obtaining from the second party: i) a message signed with a first signature under a first private key of the second party; and ii) a first public key corresponding to the first private key; obtaining from the second party, iii) a message signed with a second signature under a second private key of the second party, and iv) a second public key corresponding to the second private key; v) obtaining from the first party a message signed with a third signature based on a shared private key known only to the first party and the second party, and a corresponding shared public key; determining whether the second public key of the second party was generated based on the first public key of the second party and the shared public key; A method comprising:

2. the determining step includes determining whether the first signature, the second signature, and the third signature are valid signatures. The method of claim 1.

3. The method comprises: sending said message to said first party and to said second party; The method of claim 1 or 2, comprising:

4. the first party and the second party are the same party; 4. The method according to claim 1 .

5. the first party and the second party are different parties; 4. The method according to claim 1 .

6. said third party's computing device, a memory including one or more memory units; a processing device comprising one or more processing units, the memory stores code configured to execute on the processing unit; The code is configured to execute, on the processing device, a method according to any one of claims 1 to 5. Computer equipment.

7. A computer program stored on a computer readable storage device, comprising:

6. A method for performing a method according to any one of claims 1 to 5, when executed on a computing device. Computer program.

Images