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] This disclosure relates to a method for linking a first party and a second party using a cryptographic public-key-private key pair, and a method for verifying such link. Specifically, the method enables a first party to prove that their public-key-private key pair is cryptographically linked to the second party's public-key-private key pair. [Background technology]

[0002] A blockchain refers to a form of distributed data structure where duplicate copies of the blockchain are maintained on each of the multiple nodes in a peer-to-peer (P2P) network. A blockchain contains a chain of data blocks, where each block contains one or more transactions. Each transaction can point back to a preceding transaction in a sequence that can span one or more blocks. Transactions can be submitted to the network to be included in a new block through a process known as "mining." This involves multiple mining nodes competing to perform "proof-of-work," that is, solving a cryptographic puzzle based on a pool of pending transactions waiting to be included in a block.

[0003] Traditionally, transactions within a blockchain have been used to carry digital assets, i.e., data that functions as a store of value. However, blockchains can also be used to layer additional functionality on top of them. For example, blockchain protocols allow for the storage of additional user data in the output of transactions. Modern blockchains have increased the maximum data capacity that can be stored within a single transaction, enabling the incorporation of more complex data. 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 of three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions throughout the network's nodes. Mining nodes perform the mining of transactions into blocks. Storage nodes store their own copies of the mined blocks in the blockchain. To have a transaction recorded on the blockchain, the parties send the transaction to one of the network nodes to which it should be propagated. Mining nodes receiving the 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 blocks. Assuming a transaction is verified and thus accepted into the blockchain, the additional user data is therefore stored on each node in the P2P network as an immutable public record.

[0005] Identity management and verification are crucial in many business-to-business and business-to-consumer communications to avoid problems such as money laundering, identity theft, and corruption. However, it is not always possible to directly verify the identity of the parties involved (e.g., individuals or businesses). Instead, trust in the parties can be confirmed through verified information and endorsements from trusted third parties. In this way, even anonymous peers can establish sufficient trust to communicate confidential information. One example of this is Transport Layer Security (TLS) certificates, which provide security over the internet. [Overview of the project]

[0006] Blockchain provides a form of identification via public keys and addresses. These public keys and addresses are unique within the blockchain address space and thus unique to each individual blockchain user. However, keys and addresses do not reveal information about the user's identity and are often insufficient for complying with rules, such as Know Your Customer (KYC) regulations. In addition, blockchain keys and addresses typically do not interface with non-blockchain systems. This is necessary when blockchain is widely used and integrated within enterprise systems.

[0007] According to one aspect disclosed herein, a computer implementation method for linking a first party and a second party is provided. The method includes the steps of: obtaining a first cryptographic public-private key pair, which is performed by the first party and consists of a first private key and a corresponding first public key; generating a first shared private key, which is known to the first party and the second party; and generating a second cryptographic public-private key pair, which consists of a second private key and a corresponding second public key, wherein the second private key is generated based on the first private key and the first shared private key.

[0008] This disclosure recognizes how one party may cryptographically link with another party using public-key cryptography. Due to the cryptographic nature of public and private keys, the link between the first and second parties cannot be forged and can be verified by a third party. The second private key is generated based on the first private key and the shared private key. Only the first party knows the second private key, and only the first and second parties know the shared private key. Therefore, only the first party can generate the second private key, but the first party can prove that the second public key was generated based on information that the second party can prove, if necessary. If the second party is a trusted party, that trust can be associated with the first party by the fact that the second party established the shared private key together with the first party. This makes the identity of the first party trustworthy.

[0009] A public-private key pair can be a blockchain key pair. That is, the public key may be used as an identifier (i.e., address) for a blockchain user, or may be used to generate one. However, this disclosure is not limited to blockchain systems. That is, the first and / or second parties do not have to be blockchain users, and each public-private key pair does not have to be used for a transaction via the blockchain.

[0010] In another aspect disclosed herein, a computer implementation method for verifying a link between a first party and a second party is provided. The method is performed by a third party and includes the steps of: obtaining from the second party: i) a message signed with a first signature based on the second party's first private key, and ii) a first public key corresponding to the first private key; iii) a message signed with a second signature based on the second party's second private key, and iv) a second public key corresponding to the second private key; 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 second party's first public key and the shared public key.

[0011] In this embodiment, the third party desires to prove that a link exists between the first party and the 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 the trust in the first party's identity to trust the second party's identity. The third party receives (e.g., receives) two messages from the second party: one signed with a signature based on a first private key known only to the second party, and the other signed with a signature based on a second private key known only to the second party. The third party also receives (e.g., receives) a message signed with 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 private key, the third party can verify that the first party established a shared private key with the second party. The third party can then use the trust in the first party to trust the second party.

[0012] Another embodiment disclosed herein provides a computer implementation method for verifying a first signature used by a first party to sign a first message, wherein the blockchain includes recorded transactions, the recorded transactions including registered values ​​generated by applying a one-way function to a first value. The method includes the steps of: generating the first signature by performing an action on the first party and applying a one-way function to at least the first value and the first message; sending the first transaction to one or more nodes of the blockchain network for inclusion in the blockchain, the first transaction including a message signed with the first signature; and sending 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 typically generated using a private key and checked using the corresponding public key. This disclosure provides a method for generating a signature without using the parties' private keys, and a method for a party to prove that only they could have provided the signature. The registered 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 use the first value to generate a signature, use that signature to sign a message, and send a transaction containing the message to the blockchain. The first party can then follow up with a second transaction containing 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 registered value, the verifying party can ensure that only the first party could have generated the signature. [Brief explanation of the drawing]

[0014] The accompanying drawings are provided for illustrative purposes only to aid in understanding the embodiments of this disclosure and to illustrate how such embodiments may be carried out. [Figure 1] Figure 1 is a schematic block diagram of a system that implements blockchain. [Figure 2] Figure 2 schematically illustrates an example of a transaction that may be recorded within the blockchain. [Figure 3] Figure 3 is a schematic block diagram of another system that implements blockchain. [Figure 4] Figure 4 schematically illustrates a method for cryptographically linking the first and second parties. [Figure 5] Figure 5 schematically illustrates a method for verifying whether the first party is cryptographically linked to the second party. [Modes for carrying out the invention]

[0015] Overview of the Exemplary System Figure 1 shows an exemplary system 100 for a typical implementation of blockchain 150. System 100 includes a packet-switched network 101, typically a wide-area internetnet such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes peer computer equipment, and different nodes of node 104 belong to different peers. Each node 104 includes one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable storage in the form of non-temporary computer-readable media or storage devices. The memory may include one or more memory units using one or more memory media. Examples include 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 disc drives.

[0016] Blockchain 150 contains a chain of blocks of data 151, and each copy of Blockchain 150 is maintained on multiple nodes within the P2P network 160. Each block 151 in the chain contains one or more transactions 152, where a transaction in this context refers to a kind 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 of each transaction 152 contains at least one input and at least one output. Each output specifies an amount representing the total amount of digital assets belonging to user 103 that the output is cryptographically locked (requiring the user's signature to unlock and thereby redeem or consume). Each input points back to the output of a preceding transaction 152, thereby linking the transactions.

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

[0018] In a given current transaction 152j, the input (or each input) contains a pointer to the output of a preceding transaction 152i in the transaction sequence, specifying that this output is redeemed or “spent” in the current transaction 152j. Generally, a preceding transaction can be any transaction in pool 154 or any block 151. A preceding transaction 152i does not necessarily have to exist when the current transaction 152j is created or even sent to network 106, but for the current transaction to be valid, a preceding transaction 152i must exist and be validated. Thus, “preceding” here refers to a preceding transaction in a logical order linked by pointers, and not necessarily to a time in which it is created or sent. And, therefore, this does not necessarily preclude transactions 152i and 152j from being created or sent out of order (see the later explanation of orphan transactions). Preceding transaction 152i can similarly be called a preceding transaction or a preceding transaction.

[0019] The input to the current transaction 152j also includes the signature of user 103a, whose output of the preceding transaction 152i is locked. Then, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Thus, the current transaction 152j can transfer the sum defined in the input of the preceding transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, transaction 152j may have multiple outputs to divide the input sum among multiple users (one of which may be the original user 103a to make the changes). In some cases, a transaction may also have multiple inputs, collect sums from multiple outputs of one or more preceding transactions, and redistribute them to one or more outputs of the current transaction.

[0020] The above is called an “output-based” transaction protocol, and is sometimes also called an unused transaction output (UTXO) type protocol (where output is referred to as UTXO). A user’s total balance is not defined in any single number stored on blockchain 151; instead, a user requires a special “wallet” application 105 to collate the values ​​of all of their UTXOs, which are scattered across many different transactions 152 within blockchain 151.

[0021] An alternative type of transaction protocol may be called an “account-based” protocol as part of an account-based transaction model. In the account-based example, each transaction does not define the total transferred by referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing the absolute balance of the account. The current state of all accounts is stored in 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 the “position”). This value is signed by the sender as part of the cryptographic signature and hashed as part of the transaction reference calculation. In addition, an arbitrary data field can also be a signed transaction. This data field may point back to a previous transaction, for example, if the previous transaction ID is included in the data field.

[0022] In any type of transaction protocol, if user 103 wishes to formulate 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 is typically a server or data center today, but in principle could be any other user terminal). This node 104 checks whether the transaction is valid according to the 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 node 104 to check that the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In an output-based case, this may include checking that the user's cryptographic signature included in the input of the new transaction 152j matches the conditions defined in the output of the preceding transaction 152i that the new transaction pays. Here, this condition typically includes checking that the cryptographic signature in the input of the new transaction 152j unlocks the output of the preceding transaction 152i pointed to by the input of the new transaction. In some transaction protocols, the condition may be defined, at least partially, by custom scripts included in the input and / or output. Alternatively, it may be fixed by the node protocol alone, or by a combination of these. In any case, if the new transaction 152j is valid, the current node transfers it to one or more other nodes of node 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 further nodes 104, and so on.In this way, the new transaction is propagated throughout the entire network of node 104.

[0023] In an output-based model, the definition of whether a given output (e.g., UTXO) is payable is whether it has already been validly redeemed by another, node-protocol-compliant, forward transaction 152j. 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 it is not valid, transaction 152j is not propagated or recorded on the blockchain. This prevents double spending, where an attempt is made to pay the same transaction's output more than once. On the other hand, an account-based model prevents double spending by maintaining an account balance. Again, since there is a defined order of transactions, the account balance always has a single defined state.

[0024] In addition to verification, at least some of the nodes 104M are also competing to be the first to create a block of transactions in a process known as mining, which is supported by "proof of work". In mining nodes 104M, new transactions are added 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 transaction 152 from the transaction pool 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value, and as a result, when the nonce is concatenated with the transaction pool 154 and hashed, the output of the hash satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash has a predetermined number of leading zeros. A property of hash functions is that they have an output that is unpredictable with respect to the input. Therefore, this search can only be performed by brute force, and thus consumes a considerable amount of processing resources on each node 104M attempting to solve the puzzle.

[0025] The first mining node 104M, which solves the puzzle, notifies the network 106 of this and provides its solution as proof, which can be easily checked by other nodes 104 in the network (once a solution is given for a hash, it is easy to check that it satisfies the condition for the hash output). The pool of transactions 154 in which the winner solved the puzzle is then recorded as a new block 151 in blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on the fact that each of those nodes has checked the solution announced by the winner. The block pointer 155 is also assigned to a new block 151n that points back to previously generated block 151n-1 in the chain. Proof of work helps reduce the risk of double spending because it requires considerable effort to create a new block 151. And since any block containing double spending is likely to be rejected by other nodes 104, mining nodes 104M are motivated not to allow double spending to be included in those blocks. Once created, block 151 cannot be modified because it is recognized and maintained at each storage node 104S in the P2P network 106 according to the same protocol. The block pointer 155 also imposes a sequential order on block 151. Since transaction 152 is recorded in the ordered block at each storage node 104S in the P2P network 106, this therefore provides an immutable public ledger of transactions.

[0026] It should be noted that different 104M miners competing at any given time can be done at any given time based on different snapshots of the unmined transaction pool 154, depending on when they started looking for a solution. Whoever solves each puzzle first defines which transaction 152 will be included in the next new block 151n, and the current unmined transaction pool 154 is updated. The miners 104M then continue competing to generate a block from the newly defined pending pool 154, and so on. There also exists a protocol for resolving any possible “forks” that may occur. This involves two miners 104M solving the puzzle with each other in a very short time, resulting in the propagation of conflicting views of the blockchain. In short, whichever protrusion of the fork extends the longest will become the final blockchain 150.

[0027] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of nowhere (as opposed to a normal transaction that transfers a total amount of digital assets from one user to another). Thus, it can be said that the winning node "mined" the total 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 the miner 104M to participate in the proof-of-work competition. A normal (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs, further rewarding the winning miner 104M that generated block 151n containing that transaction.

[0028] Due to the computing resources involved in mining, typically each miner node 104M takes the form of a server, including one or more physical server units or an entire data center. Each transfer node 104M and / or storage node 104S may 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 connected together on a network.

[0029] The memory of each node 104 stores software configured to run on the processing unit of node 104 in order to perform its respective role and process transaction 152 in accordance with the node protocol. It will be understood here that any action attributed to node 104 may be performed by software running on the processing unit of each computer device. Furthermore, the term “blockchain” as used herein 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 the computer devices 102 of each of the multiple parties 103 who have the role of consuming users. These play the roles of payers and payees in a transaction, but do not necessarily participate in the mining or propagation of the transaction on behalf of the other parties. They do not necessarily execute a mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: the first party 103a and their respective computer device 102a, and the second party 103b and their respective computer device 102b. It will be understood that many more such parties 103 and their respective computer devices 102 can exist in the system and participate, but for convenience they are not shown. Each party 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a is referred to here as Alice, and the second party 103b is referred to as Bob, but this is not restrictive, and it will be understood that the references to Alice or Bob here can be replaced with “the first party” and “the second party,” respectively.

[0031] Each computer device 102 of party 103 has its own processing unit, which includes one or more processors. For example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or. Each computer device 102 of party 103 also has memory, i.e., a computer-readable storage device in the form of a non-temporary computer-readable medium or media. This memory may include one or more memory units using one or more memory media. For example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each computer device 102 of party 103 stores software, which includes each instance of at least one client application 105 arranged to run on the processing unit. It will be understood here that any operation attributed to a given party 103 may be performed using software running on the processing unit of each computer device 102. Each computer device 102 of party 103 has at least one user terminal. Examples include desktop or laptop computers, tablets, smartphones, or wearable devices such as smartwatches. The computer 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 first be provided to the computer equipment 102 of any given party 103 on a storage medium or media readable by a suitable computer. For example, this could be 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” function, which has two main functions. One is to enable each user party 103 to create, sign, and send transactions 152 so that they are propagated across the entire network of nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the total of the digital assets they currently own. In an output-based system, this second function includes matching the totals defined in the outputs of various transactions 152 scattered across the entire blockchain 150 belonging to the party in question.

[0034] An instance of the client application 105 on each computer device 102 is operably coupled to at least one of the transfer nodes 104F of the P2P network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transaction in which each party 103 is the recipient (or, in practice, to examine the transactions of other parties within the blockchain 150, since in this embodiment the blockchain 150 is a public facility that is partially visible to the public and provides trust in transactions). The wallet function on each computer device 102 is configured to form and send transaction 152 according to the transaction protocol. Each node 104 runs software configured to verify transaction 152 according to the node protocol, and in the case of a transfer node 104F, it transfers transaction 152 to propagate it throughout the network 106. Transaction protocols and node protocols are interconnected, and a given transaction protocol, together with a given node protocol, implements a given transaction model. The same transaction protocol is used for all transactions 152 within blockchain 150 (however, the transaction protocol may allow different subtypes of transactions). The same node protocol is used by all nodes 104 within network 106 (however, many nodes handle different subtypes of transactions differently according to rules defined for their subtypes, and different nodes may assume different roles and thus implement different corresponding aspects of the protocol).

[0035] As described above, blockchain 150 contains a chain of blocks 151, where each block 151 contains a set of one or more transactions 152 created by the proof-of-work process, as described above. Each block 151 also contains a block pointer 155 that points back to a previously generated block 151 in the chain, thus defining the sequential order to block 151. Blockchain 150 also contains a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (besides transaction generation) contains a pointer back to a previous transaction, thus defining the order of transactions (note that the shield of transaction 152 is allowed to branch). The chain of blocks 151 travels all the way back to the generating block (genesis block 4, Gb) 153, which was the first block in the chain. One or more original transactions 152 in the early stages of chain 150 pointed to the generating block 153, rather than a preceding transaction.

[0036] If a given party 103, for example Alice, wishes to send a new transaction 152j to be included in blockchain 150, she formulates the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). She then sends transaction 152 from her client application 105 to one of the one or more transfer nodes 104F to which she is connected. For example, this could be the transfer node 104F closest to 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 involves first checking whether the newly received transaction 152j meets certain conditions for being "valid," an example of which will be briefly and in more detail. In some transaction protocols, the conditions for validation can be set per transaction by a script included in transaction 152. Alternatively, the conditions may simply be built-in functions of the node protocol, or they may be defined by a combination of script and node protocol.

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

[0038] Once a miner node 104M enters pool 154 within a copy of blockchain 150 maintained by one or more storage nodes 104, the miner nodes 104M begin a race to solve the proof-of-work puzzle of the latest version of pool 154 containing the new transaction 152 (other miner 104M are still trying to solve the puzzle based on the 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 part of the puzzle of pool 154 containing Alice's transaction 152j). Once proof-of-work is done for pool 154 containing the new transaction 152j, it becomes part of one of the immutable blocks 151 in blockchain 150. The order of transactions is also immutably recorded, as each transaction 152 contains a pointer back to a previous transaction.

[0039] UTXO-based model Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description refers to output-based protocols or "UTXO"-based protocols. However, this is not limited to all possible embodiments.

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

[0041] Suppose Alice 103a wants to create transaction 152j that transfers the total of the digital assets in question to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". This means that it sequentially takes the total of the digital assets locked in Alice in output 203 of the preceding transaction 152i and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2, and Tx0 and Tx1 are merely arbitrary labels. These do not necessarily mean that Tx0 is the first transaction on blockchain 151, or that Tx1 is the next immediate transaction in pool 154. Tx1 could point back to any preceding (i.e., antecedent) transaction that still has the unpaid output 203 locked in Alice.

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

[0043] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, hereby labeled UTXO0. Each UTXO contains a value specifying the total value of the digital assets represented by the UTXO, and a locking script that defines the conditions that must be satisfied by the unlocking script in the input 202 of 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 total value for a specific party (the beneficiary of the transaction in which it is contained). That is, the locking script defines the unlocking conditions, which typically include the condition that the unlocking script in the input of the subsequent transaction contains the cryptographic signature of the party to which the preceding transaction is locked.

[0044] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the Node protocol. A specific example of such a language is called “Script” (Capital S). The locking script specifies the information required to pay transaction output 203, for example, the requirements for Alice’s signature. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the criteria of the locking script. For example, it may include Bob’s signature. The unlocking script appears in transaction input 202.

[0045] In the illustrated example, UTXO0 of output 203 of Tx0 is the locking script [Checksig P A This includes, and this means that for UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem UTXO0 to be valid), Alice's signature Sig P A [Checksig P A] is the public key P from Alice's public key and private key pair. A The input 202 of Tx1 includes a pointer that points back to Tx1 (for example, using TxID0, which is its transaction ID, and in an embodiment is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index (index) that identifies the UTXO0 in Tx0 in order to identify it among any other possible outputs of Tx0. The input 202 of Tx1 also includes an unlocking script containing Alice's cryptographic signature, which is created by applying Alice's private key from the key pair to a default portion of the data. <Sig P A This includes (sometimes called a “message” in cryptography). The data (or “message”) that Alice needs to sign to provide a valid signature is defined by a 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. This involves executing the locking script and the unlocking script together and checking whether the unlocking script satisfies the conditions defined in the locking script (where these conditions may include one or more criteria). In embodiments, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] Here, "||" represents concatenation, "<...>" means placing data on the stack, and "[...]" is a function consisting of an unlocking script (a stack-based language in this example). Similarly, the scripts may be executed one after another on a common stack, rather than concatenating them. In any case, if executed together, the scripts use Alice's public key PA to authenticate that the locking script for the input of Tx1 contains Alice's signature to sign the expected portion of the data, so that it is included in the locking script for the output of Tx0. To perform this authentication, the expected portion of the data itself ("message") must also be included in the Tx0 sequence. In embodiments, the signed data includes the entirety of Tx0 (therefore, a separate element must be included in specifying the signed portion of the data in the clear, since that already exists in essence).

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

[0048] Node 104 considers Tx1 valid if the unlocking script for Tx1 satisfies one or more conditions specified in the locking script for Tx0 (for example, if Alice's signature is provided and authenticated in Tx1). If it is a mining node 104M, this means it will be added to the transaction pool 154 waiting for proof of work. If it is a transfer node 104F, it will transfer transaction Tx1 to one or more other nodes 104 in network 106, and as a result it will propagate throughout the network. Once Tx1 is verified and included in blockchain 150, this defines UTXO0 from Tx0 as a payment. Note that Tx1 is only valid if it is paying an outstanding transaction output 203. If it attempts to pay an output already paid by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, node 104 also needs to check whether the UTXO referenced in the preceding transaction Tx0 has already been used (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transaction 152. In fact, given node 104 could maintain a separate database marking the UTXO 203 to which transaction 152 was paid, but ultimately, what defines whether a UTXO has been paid is whether a valid input to another valid transaction within blockchain 150 has already been formed.

[0049] Note that in a UTXO-based transaction model, a given UTXO must be used as a whole. While a fraction of the total defined in a UTXO is being paid, a fraction cannot be "left behind." However, the total of a UTXO can be split across multiple outputs of subsequent transactions. For example, the total defined in UTXO0 within Tx0 can be split across multiple UTXOs within Tx1. Therefore, if Alice does not wish to give Bob the entire total defined in UTXO0, she can use the remaining amount to give herself change in the second output of Tx1, or to pay another party.

[0050] In practice, Alice also usually needs to include a reward (fee) for the winning miner, because today, the reward for the generation transaction alone is typically not enough to incentivize mining. If Alice does not include a reward for the miner, Tx0 is likely to be rejected by the miner node 104M, and therefore, although technically valid, it is not propagated and is included in blockchain 150 (the miner protocol does not force the miner to accept transaction 152 if they do not wish 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 all the sums indicated by input 202 and all the sums specified by 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 of the digital assets specified in UTXO0 is greater than the total of the assets specified in UTXO1, the difference is automatically awarded as minus 104M. Alternatively or additionally, however, it is not necessarily excluded that the minus reward may be explicitly specified in its own UTXO 203 of transaction 152.

[0051] Also note that if the total of all outputs 203 specified in a given transaction 152 is greater than the total of all inputs 202 specified in that same transaction, this is another basis for invalidity in most transaction models. Thus, such transactions are not propagated or mined into block 151.

[0052] Alice and Bob's digital assets are composed of unspent locked UTXOs in any transaction 152 anywhere within the blockchain 150. Thus, typically, a given party 103's assets are distributed across all the UTXOs of various transactions 152 throughout the blockchain 150. Nowhere within the blockchain 150 is there a single number that defines all of a given party 103's balance. Collating together the values of all the various UTXOs that are locked for each party and have not yet been paid in another onward transaction is the role of the wallet function in the client application 105. This can be done by querying a copy of the blockchain 150 stored at any storage node 104S, for example, the storage node 104S closest to or best connected to each party's computing device 102.

[0053] Note that script code is often represented schematically (i.e., not in exact language). For example, [Checksig P A is represented as [Checksig P A]=OP_DUP OP_HASH160<H(Pa)> It is possible to write OP_EQUALVERIFY to mean OP_CHECKSIG. "OP_..." refers to a specific opcode in a scripting language. OP_CHECKSIG (also called "Checksig") is a script opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrence of signatures ("sig") is removed from the script, but additional requirements, such as hash puzzles, remain within the transaction, verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for generating an inpayable output of a transaction, which can store metadata within the transaction, and thereby immutably record the metadata on the blockchain. For example, metadata may include documents that are desirable to be stored on the blockchain.

[0054] signature P A This is a digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256K1. A digital signature signs a specific piece of data. In embodiments, for a given transaction, the signature signs a portion of the transaction input and all or part of the transaction output. Which specific portion of the output to sign depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature that selects which output to sign (and thus which is fixed at the time of signing).

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

[0056] Optional side channels Figure 3 shows a further system 100 for implementing blockchain 150. System 100 is substantially the same as that described with respect to Figure 1, except that it includes additional communication capabilities. The client applications on Alice and Bob's computer equipment 102a and 120b, respectively, have additional communication capabilities. That is, Alice 103a is able to establish a separate side channel 301 with Bob 103b (by solicitation from either the parties or a third party). The side channel 301 enables the exchange of data separately from the P2P network. Such transmissions are sometimes called “off-chain”. For example, this could be used to exchange a transaction 152 between Alice and Bob without being published on the P2P network 106 or going up on chain 150 until one of the parties chooses to broadcast it to network 106. Alternatively or additionally, the side channel 301 can be used to exchange other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0057] Side channel 301 is established via the same packet-switched network 101 as the P2P overlay network 106. Alternatively or additionally, side channel 301 may be established via a different network, such as a mobile cellular network, or a local area network, such as a local radio network, or via a direct wired or wireless link between Alice and Bob's equipment 1021, 102b. Generally, side channel 301 as referred to anywhere herein may include any one or more links via one or more network technologies or communication media for exchanging data “off-chain,” i.e., separately from the P2P overlay network 106. If two or more links are used, the bundle or collection of off-chain links as a whole may be referred to as side channel 301. Thus, when it is said that Alice and Bob exchange certain information or data etc. via side channel 301, this does not necessarily mean that all of this data must be transmitted via exactly the same link or the same type of network.

[0058] Public-key cryptography Public-key cryptography itself is well known, and therefore only a brief explanation is given here. Public-key cryptography is used as the foundation for protecting messages (e.g., transactions in many different blockchain architectures). The use of public-key cryptography includes 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 impossible to infer the input (or multiple inputs) from the result without knowledge of the input.

[0059] In the context of public-key cryptography, a public-private key pair means a public key (which can be freely made 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 cryptography 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 utilizes the mathematical properties of elliptic curves. The "Elliptic Curve Digital Signature Algorithm" (ECDSA) refers to a class of digital signature schemes that use ECC as the basis for generating and verifying digital signatures.

[0063] In the context of ECC, addition, subtraction, and multiplication are, respectively, elliptic curve point addition (indicated here as "+"), elliptic curve point subtraction (indicated here as "-"), and elliptic curve scalar multiplication (indicated here as "·"). Addition and subtraction are applied to two points on the elliptic curve, respectively, and return a third point on the elliptic curve. Multiplication, however, is applied to scalars and single points on the elliptic curve, and returns a second point on the elliptic curve. Elliptic curve arithmetic offers a unique ability to obscure secret values ​​and forms the basis of many modern cryptographic systems. In particular, reversing scalar multiplication of elliptic curve points over a finite field is an intractable problem (computationally unfeasible).

[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. It is also a point on an elliptic curve as follows: P = V·G = G + ... + G (V additions) Here, "·" represents elliptic curve scalar multiplication on an elliptic curve, defined by the elliptic curve parameters. For sufficiently large V, it is difficult, or rather computationally impossible, to actually derive P by performing elliptic curve addition on V. However, if V is known, P can be computed more efficiently by utilizing the algebraic properties of elliptic curve operations. One example of an efficient algorithm that can be used to compute P is the "double and add" algorithm, which is only implementable if V is known.

[0065] Conversely, if V is unknown, even if both G and P are known, there is no computationally possible derivation method (i.e., reversing scalar multiplication) (this is the so-called "discrete-logarithm problem"). An attacker can attempt a "brute force" P by repeatedly performing elliptic curve point additions starting from G up to P. At that point, he will know that V is the number of elliptic curve point additions he had to perform, but that this proves computationally impossible. Thus, V satisfies the requirements of a trapdoor in the sense described above. In ECC, it is assumed that the public key P, the generated key G, and the elliptic curve are public and known, while the private key V is secret.

[0066] In a blockchain system, users or other entities typically hold a private key V used to prove their identity, and the corresponding public key P is calculated as follows: P=V·G

[0067] The private key V can be used to sign a piece of data m ("message") using ECDSA. Further details of ECDSA are provided, for example, below, where the entire document is incorporated by reference: “RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)” Tools.ietf.org, 2019.

[0068] Cryptographically linked identities Next, refer to Figure 4, which illustrates a method for cryptographically linking the two parties. The following describes an action performed by the first party (e.g., Alice) 103a, but it will be understood that the second party (e.g., Bob) 103b may perform some or all of the same action. The first and second parties may be the same first and second parties described with reference to Figures 1 through 3. Alternatively, the first and / or second parties may be non-blockchain users. Generally, each party operates a computer device configured to perform the actions of each party.

[0069] These two parties can be linked by utilizing the cryptographic properties of public-key cryptography. The following explanation will be based on elliptic curve cryptography, but it will be understood that this teaching generally applies to other forms of public-key cryptography as well. Elliptic curve computation can be used to reliably link the identities of two parties using only their public keys and the public key generated from their shared secret key. As shown in Figure 4, Alice 103a and Bob 103b each process their respective public-key and secret key pairs. Alice 103a uses the first secret key S A0 , and the corresponding first public key P A0 He possesses the 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 A shared private key can also be established. The shared private key can be established using side channel 301, as shown in Figure 3. As the name implies, the public key is assumed to be accessible to either party and / or an external third party. In contrast, the private key is assumed to be kept secret from the owner of the private key.

[0070] A shared secret key can be established using the Diffie-Helman key exchange or its extensions. One technique for establishing a shared secret key is for each party to generate it 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, Alice103a uses her private key S A and Bob's public key P B And similarly, Bob uses his private key S B and Alice's public key P A Use it as follows: S AB0 =[S A S B G]x=[S A P B ]x=[S B P A ]x Here, []x represents the x-coordinate of the elliptic curve point.

[0071] Only Alice 103a has her secret key S A He knows it, and only Bob103b has his private key S B If we assume that only Alice 103a and Bob 103b know, AB0 The shared secret key S can be calculated. AB0 This can be established without divulging confidential information, i.e., private keys.

[0072] The table below shows the public and private keys owned by Alice103a and Bob103b. In this example, the public key is associated with the private key by elliptic curve multiplication, P=V·G, where G is an elliptic curve generator point. [Table 1]

[0073] Alice 103a then uses her first private key S A0 and shared private key SAB0 Using both, the second private key S is called the identity-linked key. A1 It is possible to generate this. For example, Alice's identity link key is S A1 =S A0 +S AB0 It is generated as follows. Only Alice103a is S A0 Since I know, only Alice is S A1 and P A1 It can generate [this].

[0074] However, public key P A0 and P AB0 Since it is publicly known, the public key can be verified by anyone. The following equation shows how P A1 However, one example is given of how her private key can be derived by Alice 103a, and how a publicly known key can be derived by another party. 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, Bob103b has the first private key S B0 and shared private key S AB0 Using both, Identity Link Key S B1 It is possible to generate this. For example, Bob's identity link key is S B1 =S A0 +S B0 It is generated as S. Only Bob is S B0 Since I know, only Bob is S B1 and P B1 It can generate S A0 and S AB0 Using a more complex equation, SA1 It is possible to generate S. B0 and S AB0 Using a more complex equation, S B1 It can generate [this].

[0076] Each party has a shared secret S AB0 This can be used to verify the identity of the other party. Secret S is shared only by Alice 103a and Bob 103b. AB0 Knowing this, Alice said, P AB0 If Alice receives a message signed using P, she can verify that the message is from Bob. Similarly, if Bob 103b, AB0 If you receive a message signed using this method, you can verify that it is a message from Alice. Remember that the corresponding private key is required to sign the message using the public key.

[0077] For security reasons, an identity link key should only be used once. To update the 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 a low-power device using computationally efficient techniques. This method also generates a hierarchy of shared secret keys. Here, each updated private key can be linked back to the original shared private 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 way to generate a 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 an updated identity - link key respectively. 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] Since these keys are updated, each party has P A(i+1) or P B(i+1)They only know one party's identity 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 necessary, via a signature challenge.

[0082] Alice103a uses her identity link key P to sign the message. Ai Alice can use either of these and send the message to Bob 103b or a third party. In the context of the 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 to a transaction. Alice 103a can then send that transaction to Bob, a third party, or one or more nodes on the blockchain network, so that the transaction can be mined into blockchain 150. By identity link key, Alice 103a can sign any part of a blockchain transaction. Furthermore, by identity link key, one or more parties can sign part of a transaction. For example, Alice 103a can sign part of a transaction and then send that transaction to Bob 103b, who can also sign part of the same transaction, and then either Alice 103a or Bob can send the transaction to the blockchain network.

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

[0084] As shown in Figure 5, Alice 103a has the first secret key S A0 , shared secret key S AB0 , and the second secret key (i.e., her identity link key) S A1 He possesses the first private key S. B0 , shared secret key S AB0 , and the second secret key (i.e., her identity link key) S B1He owns. In this example, either Alice 103a or Bob 103b could be the 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 the identity link key linked with Alice. Charlie 103c can use the dependency of the identity link key in the shared secret key to get Bob 103b to prove his relationship with Alice 103a. Charlie 103c receives a message from Bob 103b signed using Bob's first public key-private key pair. Charlie 103c also receives a message from Bob 103b signed using his identity link public key-private key pair. Bob 103b can choose which message to send to Charlie 103c. Alternatively, Charlie 103c could send Bob 103b a message (e.g., a challenge) to sign. Charlie 103c also receives a message from Alice 103a signed using a shared public-private key pair. Again, Alice 103a can send the message by deciding in the message with Bob 103b, or Charlie 103c can send the message to Alice 103a. Charlie 103c can first receive a message from either Bob 103b or Alice 103a. Once Charlie 103c has a signed message, Charlie 103c verifies that Bob's identity link key was generated based on the shared private key. Charlie 103c verifies this by checking and deciding whether the identity link public key was generated based on Bob's first public key and shared public key, for example, P B1 =P AB0 +P B0 .

[0085] Charlie can, for example, use a side channel 301, as shown in Figure 3, to retrieve signed messages from Alice and / or Bob via the internet.

[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 use one or more blockchain transactions to have Alice 103a and Bob 103b send a message. For example, a signed message may be included in the output of a blockchain transaction. Charlie 103c can then create a transaction with that output as input to his transaction. The input may include a script to verify the relationship between Alice 103a's public key and Bob's public key. Once verified, that relationship is immutably stored on blockchain 150.

[0087] While the techniques described above have been explained with reference to Alice 103a and Bob 103b, generally speaking, 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 link their (trusted) identity to another identity, for example, by linking one of their public keys to a secret known only to them. Similarly, the first private keys of each party do not need to utilize the same public-key cryptography system. For example, Alice 103a may use elliptic curve cryptography, while Bob may use RSA or DSA encryption. Likewise, the first private keys and shared private keys of Alice and / or Bob can utilize different cryptographic systems. In some examples, when different cryptographic systems are used, at least one of the private keys may need to be padded or truncated to reflect the other private scheme.

[0088] For example, consider a non-blockchain system such as a government or bank that has a sufficiently strict Know Your Customer (KYC) system. A known user, for example, Alice103a, has a public key P A0 The secret key connected to her identity via (S A0 ) has. This can be verified by a bank or government and publicly certified. Alice103a uses the above method to create her blockchain identity (S B0 ,P B0 ) can certainly be linked to this off-chain system, and her identity link key, as above, P B1 =( S B0 +S AB0 By calculating as )·G, a subsequent key or key hierarchy is derived, which can then be used as her blockchain identity, and P AB0 Using P A0 This can be reliably linked. This not only gives her blockchain identity KYC features, but also gives her blockchain capabilities to her off-chain accounts with governments and banks. In other words, she can use her identity link key to participate in the blockchain system, and this can be used by banks or governments to update her off-chain accounts (e.g., credit or debit) without exposing them to blockchain 150.

[0089] Access Chain By utilizing the data storage capabilities of blockchain, parties can leverage intrinsic cryptographic signature schemes to act as signatures for encapsulating data. However, the underlying protocols of blockchains are typically fixed and therefore cannot be adapted to specific applications. This requires parties to possess 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 the parties' private keys. This disclosure provides a second-tier signature protocol that can be included within blockchain transactions, allowing multiple parties to be included in a single transaction.

[0090] One-way functions (e.g., cryptographic hash functions) provide an efficient, deterministic method of obscuring the input, so that, given the output, it is impossible to find the input. Hash functions (or general one-way functions) can be used to generate “tokens” that can be supplied 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, for example, with a service provider, by making it public on blockchain 150. The parties can then redeem the token by providing a pre-image sensor of the value registered on blockchain 150, which becomes a new registered value. For example, token t n =h n If (K) is currently public on blockchain 150, then t n-1=h n-1 The token can be redeemed by supplying (K).

[0092] At any given time, a token holder may transfer the remaining tokens to another party, for example, by finding a willing buyer and agreeing on a price for the tokens. If Alice103a is the currently registered token holder, Alice103a will provide the service provider with her latest pre-image along with the newly generated and registered access chain value of the new party to prove her identity.

[0093] These tokens are linked to the root secret key S0 and chain t. i A new private key S with each redemption as the sum of the following pre-images within i By generating (S i =S0+t i ), it can also be linked to a public key in a verifiable way.

[0094] In addition to providing tokens, access chains provide a way to link signatures for a predetermined number of messages. These signatures can be applied directly to chunks of data, rather than to entire transactions. For example, consider a hash chain of length n, which looks like this: 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 chains, n =h(t n-1 ) forms a hash chain. Final value t nThis is registered to a given public key (or address) by making it public to blockchain 150. Providing a pre-image that resolves the most recently registered value can act as a signature for any message 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, once they see the signature value, can generate a malicious transaction.

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

[0097] A first party, for example, Alice 103a, has a preimage (first value) for a token (registration value) recorded on blockchain 150. The registration value is generated by applying a one-way function (hash function, etc.) to the first value. When Alice 103a wants to sign a message, it can generate a signature for the message by applying a one-way function to at least the first value and the message. Alice 103a can then construct a transaction containing the signed message and send that transaction to blockchain network 106. Alice 103a can then construct a second transaction containing the first value (i.e., a preimage for the registration value) and send that transaction to blockchain network. The first and second transactions may be the same transaction or different transactions.

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

[0099] In some examples, instead of hashing the preimage and message, Alice 103a hashes the hashes of the preimage and message. For example, Alice 103a hashs the access chain generated using t0,...,t1 as defined above, and the nth (n) to be signed. th ) Message m n It can generate the value t. n+1 =h(t n ) is currently registered on blockchain 150, and thus Alice uses both the hash of the message and the preimage of the latest registration value to send the message m as follows: n It is possible to construct a signature. h(t n +h(m n ))

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

[0101] By providing this value, both access chains can use h(t n )=t n+1 The fact that, and also, h(t i +h(m i )) can be verified by checking that it matches the data provided in the signed (first) transaction. This two-step signing process is nominally certified by the user, and once completed, the verification and certification are sent.

[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 message m and key K to provide message verification. HMAC is a category of message authentication codes (MACs) that utilize collision resistance between a preimage and a cryptographic hash function to prevent the exposure of the key used to compute the HMAC. This is widely applied 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 on the value x. HMAC is defined as follows:

number

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

[0105] Using a private key, K, an access chain level of n levels deep can be formed. That is, as follows: t1 = h(K) t² = h 2 (K) | t n =h n (K) Here, K is the ultimate secret, and t n This is the initial registration value in blockchain 150. Alice 103a then uses HMAC(t) as the signature of m. n-1 ,m) can be used. The verifying party (e.g., Bob) then uses the newly exposed value to actually H(t n-1 )=t n Check that it is so, and then HMAC'(t n-1 It can be calculated that ,m) matches the registered value. Exposure of the preimage acts as proof of 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 a signature a finite lifespan until the next value in the access chain is exposed. This also enables the delegation of signatures, as the signer (Alice 103a) can provide one or more of the next 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 agent, as the raw key is owned by the agent. The agent may be required to submit at least one signed transaction using the public key to which it may be connected. Thus, if an agent misuses the key, they can be identified using the transaction signature.

[0107] One use case is that in many legal scenarios, contract terms may be changed periodically to conform to new laws introduced in various jurisdictions. This often requires changing many contracts similarly or in almost the same way. The scheme described above provides a way to apply signatures to a finite and predetermined number of documents using an access chain. For example, consider a signer with a legally binding contract m0 and secret K. The signer accesses blockchain 150 to t n =h n (K) can be published. The published h n A signature can be generated using the pre-image of (K). n-1 The proof is provided by the message (h(t n-1 Use the hash of the preimage +h(m0)) or, for additional security, use the HMAC scheme HMAC(t n-1This is done by using m) or either. If a contract needs to be amended, the amendment (m1) can be signed by the signer using the following value in the chain. Thus, a complete record of all contract states is permanently recorded and timestamped in blockchain 150. Since they are applied directly to the data (in this case, the contract amendment) and then certified, multiple signatures can also be combined into a single transaction to efficiently manage a large number of contracts.

[0108] Identity Link Access Chain As described above, Alice 103a and Bob 103b can each derive an identity link key that is indeed related to the other party. Instead of directly using the identity link key, Alice and Bob can each use their respective identity link keys to derive a new shared secret key. As described above, Alice 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 here, Alice 103a and Bob 103b can each calculate the 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' Here, [ ] xThis indicates the x-coordinate of the elliptic curve point. This newly derived shared secret key, or any key derived from it, can then function as a seed in the access chain. Ultimately, the root of the access chain is exposed, so using the derived key allows access to the initial shared secret S. AB0 Since it does not compromise, a new chain can be created again. For example, the new chain is S AB1 It 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 includes it in the transaction and sends the transaction to the blockchain network so that it will be stored on blockchain 150. 100 It can be publicly registered. Bob 103b then calculates his own value (he also, S AB1 (Since we also know this), we can verify Alice's identity.

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

number

number

[0113] The following describes exemplary use cases. 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 when the business produces products that ultimately end up in the hands of consumers. Currently, many of these auditors do not have the option to integrate with blockchain systems. By using IdentityLinked Access Chains, the authenticity of proof can be verified using linked identities and updated as frequently as required by the auditing body.

[0114] The review body is public key P A1 It is necessary to declare that the public key has a sufficiently strict KYC procedure. The auditor will examine the calculated shared key pair (S AB1 ,P AB1 ), for example, through the calculation by the Diffie-Hellman exchange, his or her identity can be linked to the verification body. This is based on the initial value t n The access chain is registered by the certification body. n =h n (S AB1 ) can function as a route. Individual auditors can then perform the required compliance audit and provide proof of compliance m0 using the signing method described above, recording a pre-image of the latest registration value on blockchain 150. This certificate can be given an expiration date during which another compliance audit must be performed. With each update, 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 accompanied by a verifiable relationship with the auditing body.

[0115] conclusion It should be understood that the above embodiments are described merely as examples.

[0116] More generally, a computer implementation method for linking a first party and a second party may be provided by a first instantiation of the teaching disclosed herein. The method includes the steps of: obtaining a first cryptographic public-private key pair consisting of a first private key and a corresponding first public key, performed by the first party; generating a first shared private 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, wherein the second private key is generated based on the first private key and the first shared private key.

[0117] A method following the first instantiation may be provided by an optional second instantiation of the teaching disclosed herein. This method comprises the steps of generating one or more updated shared secret keys, each of which is known to the first and second parties, and generating one or more updated second cryptographic public-private key pairs, each comprising an updated second private key and a corresponding updated second public key, each of which is generated based on the first private key and one of the one or more updated shared secret keys.

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

[0119] A third, optional instantiation of the teaching disclosed herein may provide a method according to the second instantiation, wherein the one or more updated shared secret keys form a sequence of keys beginning 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] A fourth, optional instantiation of the teaching disclosed herein may provide a method that follows any one of the first to third instantiations. This method includes the steps of obtaining the second public key of the second party, the second public key of the second party being generated based on the first private key and the first shared private key of the second party, and generating a derived shared private 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 teaching disclosed herein, the method comprises the step of generating a sequence of values, wherein the 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 each subsequent value in the sequence is generated by applying a one-way function to at least the previous value in the sequence.

[0122] A method following the fifth instantiation may be provided according to an optional sixth instantiation of the teaching disclosed herein. This method includes the steps of sending a blockchain transaction to one or more nodes of a blockchain network for inclusion in the blockchain, wherein the blockchain transaction includes the latest value in the sequence of values.

[0123] For example, the latest value in a sequence can be the final (i.e., last) value. Alternatively, the latest value in a sequence can be the previous value in the sequence. For example, the final nth value is submitted to the blockchain, followed by the (n-1)th value, then the (n-2)th value, and so on.

[0124] A seventh instance of the teaching disclosed herein may be provided, which is a method in accordance with the sixth instance. The method includes the steps of receiving a challenge message from the second party, the challenge message being encrypted based on the first shared secret key; generating a response to the challenge message, the response being based on the challenge message and the value immediately preceding the most recent value in the sequence of values; and sending the response to the second party.

[0125] An optional eighth instantiation of the teaching disclosed herein may provide a method in accordance with the seventh instantiation. This method includes the step of receiving the response from the second party in an expected format, wherein the expected format is encrypted based on the first shared secret key, and the generated response is further based on the expected format.

[0126] According to an optional ninth instantiation of the teaching disclosed herein, the first shared secret key is generated based on the secret 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 can 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] A method can be provided according to any one of the first through ninth instantiations of the teaching disclosed herein, where the first party and the second party are the same party.

[0129] An optional 11th instantiation of the teaching disclosed herein may provide a method according to any one of the 1st through 9th instantiations, where the first party and the second party are different parties.

[0130] A method may be provided according to any 12th instance of the teaching disclosed herein, following any one of the 1st through 11th instances. This method includes the steps of signing a message using a signature based on the 2nd private key of the 1st party, and sending the signed message to the 2nd party and / or a different third party.

[0131] A method is provided that conforms to any one of the first to twelfth instantiations of the teaching disclosed herein, according to an optional thirteenth instantiation of the teaching disclosed herein. The method includes the steps of signing at least a portion of a blockchain transaction using a signature based on the second private key of the first party, and sending the blockchain transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0132] A computer implementation method for verifying a link between a first party and a second party may be provided, 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 the second party's first private key, and ii) a first public key corresponding to the first private key; iii) a message signed with a second signature based on the second party's second private key, and iv) a second public key corresponding to the second private key; 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 second party's first public key and the shared public key.

[0133] According to an optional 15th instantiation of the teaching disclosed herein, a method in accordance with the 14th instantiation may be provided, 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 teaching disclosed herein, a method in accordance with the fourteenth or fifteenth instantiation may be provided. This method includes the step of sending the message to the first party and the second party.

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

[0136] According to an optional 18th instantiation of the teachings disclosed herein, a method in accordance with the 14th or 16th instantiation may be provided, where the first party and the second party are different parties.

[0137] According to the 19th instantiation of the teaching disclosed herein, a computer implementation method can be provided for proving a first signature used by a first party to sign a first message, wherein the blockchain includes recorded transactions, the recorded transactions including registered values ​​generated by applying a one-way function to a first value. The method includes the steps of: generating the first signature by performing an action on the first party and applying a one-way function to at least the first value and the first message; sending the first transaction to one or more nodes of the blockchain network for inclusion in the blockchain, the first transaction including a message signed with the first signature; and sending 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] A method can be provided according to an optional 20th instantiation of the teaching disclosed herein, which follows the 19th instantiation, where the first value is an updated registration value and is generated by applying a one-way function to the second value. The method includes the steps of: generating a second signature by applying a one-way function to at least the second value and the second message; sending a third transaction to one or more nodes of the blockchain network for inclusion in the blockchain, wherein the third transaction includes 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, wherein the fourth transaction includes the second value.

[0139] According to an optional 21st instantiation of the teaching disclosed herein, a method can be provided that follows the 19th or 20th instantiation, where the first signature is generated by applying a one-way function to at least i) the first value and ii) the result of applying the one-way function to the first message.

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

[0141] According to an optional 22nd instantiation of the teaching disclosed herein, a method can be provided that follows any one of the 19th to 21st instantiations, where the first signature is a hash-based message authentication code.

[0142] A method can be provided according to any 23rd instantiation of the teaching disclosed herein, which follows any one of the 19th to 22nd instantiations, wherein the step of sending the second transaction includes sending the second transaction to one or more nodes of the blockchain network after the first transaction has been included in the blockchain.

[0143] An optional 24th instantiation of the teaching disclosed herein may provide a method according to any one of the 19th to 23rd instantiations, where the registered 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 the previous value in the sequence.

[0144] According to an optional 25th instantiation of the teaching disclosed herein, a method in accordance with the 24th instantiation may be provided. This method includes the step of sending one or more values ​​of the sequence of values ​​to a second party.

[0145] An optional 26th instantiation of the teaching disclosed herein may provide a method according to any one of the 19th through 25th instantiations, where 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 teaching disclosed herein, a method can be provided that follows any one of the first to 26th instantiations, where the one-way function is a cryptographic hash function.

[0147] According to the 28th instantiation of the teaching disclosed herein, the first party's computer device is provided. The computer device includes a memory comprising one or more memory units, and a processing unit comprising one or more processing units, wherein the memory stores code configured to run on the processing unit, and the code is configured to run any one of the first to thirteen instantiations on the processing unit.

[0148] According to the 29th instantiation of the teaching disclosed herein, a computer program stored in a computer-readable storage device is provided. The computer program is configured to perform any one of the first to 13 instantiations when executed on the computer equipment of the first party.

[0149] According to the 30th instantiation of the teaching disclosed herein, the third-party computer device is provided. The computer device includes a memory comprising one or more memory units, and a processing unit comprising one or more processing units, wherein the memory stores code configured to run on the processing unit, and the code is configured to run one of the 14th to 18th instantiations on the processing unit.

[0150] According to the 31st instantiation of the teaching disclosed herein, a computer program stored in a computer-readable storage device is provided. The computer program is configured to perform any one of the 14th to 18th instantiations when executed on the third-party computer equipment.

[0151] According to the 32nd instantiation of the teaching disclosed herein, the first party's computer device is provided. The computer device includes a memory comprising one or more memory units, and a processing unit comprising one or more processing units, wherein the memory stores code configured to run on the processing unit, and the code is configured to run on the processing unit one of the 19th to 27th instantiations.

[0152] According to the 33rd instantiation of the teaching disclosed herein, a computer program stored in a computer-readable storage device is provided. The computer program is configured to execute one of the 19th to 27th instantiations on the processing device when executed on the computer equipment of the first party.

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

[0154] According to another instance of the teaching disclosed herein, computer equipment belonging to the first party, the second party, and / or a third party may be provided.

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

Claims

1. A computer implementation method for verifying a link between a first party and a second party, The aforementioned method is performed by a third party's computer equipment. The computer device includes a memory comprising one or more memory units, and a processing unit comprising one or more processing units. The memory stores code configured to be executed on the processing unit. When the code is executed on the processing unit, it will be sent to the third-party computer equipment. The steps of obtaining from the second party: i) a message signed with a first signature based on the second party's first private key, and ii) a first public key corresponding to the first private key, The steps of obtaining from the second party: iii) a message signed with a second signature based on the second private key of the second party, and iv) a second public key corresponding to the second private key, The steps of obtaining from the first party a message signed with a third signature based on a shared secret key known only to the first and second parties, and the corresponding shared public key, A step of 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, To have it implemented method.

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

3. The above method further, The step of sending the message to the first party and the second party, The method according to claim 1 or 2, which enables the implementation of the method.

4. The aforementioned first party and the aforementioned second party are the same party. The method according to any one of claims 1 to 3.

5. The aforementioned first party and the aforementioned second party are different parties. The method according to any one of claims 1 to 3.

6. A computer program stored in a computer-readable storage device, The computer program is stored in the computer-readable storage device of a computer device including a processing unit having one or more processing units. When the computer program is executed on the processing unit, the computer device is made to carry out the method according to any one of claims 1 to 5. Computer program.

Images