cryptographic link identity

Abstract

A computer-implemented method of linking a first party and a second party is provided, the method being performed by the first party and comprising: obtaining a first cryptographic public-private key pair, the first cryptographic public-private key pair comprising a first private key and a corresponding first public key; generating a first shared private key pair known to the first party and the second party; and generating a second cryptographic public-private key pair, the second cryptographic public-private key pair comprising 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 shared private key.

Description

Technical Field

[0001] This disclosure relates to methods for linking a first party and a second party using encrypted public-private key pairs, and for verifying such linking. Specifically, these methods enable the first party to prove that its public-private key pair is encrypted with the second party's public-private key pair. Background Technology

[0002] A blockchain is a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain consists of a series of data blocks, where each block contains one or more transactions. Each transaction can refer back to previous transactions in the sequence, and can extend one or more blocks. Through a process called "mining," transactions can be included in new blocks by being committed to the network.

[0003] Transactions in blockchains are typically used to transfer digital assets, i.e., data used as a store of value. However, blockchains can also be used to implement layered, additional functionalities. For example, blockchain protocols can allow additional user data to be stored in the transaction output. Modern blockchains are constantly increasing the maximum data capacity that can be stored in a single transaction, thus enabling the incorporation of more complex data. For example, this can be used to store electronic documents, or even audio or video data, in the blockchain.

[0004] Each node in the network can have any one, two, or all of the following three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions throughout the network. Mining nodes mine transactions into blocks. Storing nodes each store their own copy of the mined blocks in the blockchain. To record a transaction in the blockchain, one party sends the transaction to one of the nodes in the network for propagation. Mining nodes receiving the transaction can compete to mine it into a new block. Each node is configured to adhere to the same node protocol, which includes one or more conditions for confirming the validity of a transaction. Invalid transactions will not be propagated or mined into blocks. Assuming the transaction has been verified as valid and thus accepted on the blockchain, the attached user data will therefore continue to be stored as an immutable public record at various nodes in the P2P network.

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

[0006] Blockchain provides a form of identity verification using public keys and addresses. These public keys and addresses are unique within the blockchain address space, and therefore unique to a single blockchain user. However, keys and addresses do not reveal information about the user's identity and are often insufficient for compliance with regulations such as Know Your Customer (KYC) regulations. Furthermore, blockchain keys and addresses typically do not interface with non-blockchain systems, which is necessary for the widespread use and integration of blockchain within enterprise systems.

[0007] According to one aspect disclosed herein, a computer-implemented method for linking a first party and a second party is provided, the method being performed by the first party and comprising: obtaining a first encrypted public-private key pair, the first encrypted public-private key pair including a first private key and a corresponding first public key; generating a first shared private key pair known to the first party and the second party; and generating a second encrypted public-private key pair, the second encrypted public-private key pair including 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 shared private key.

[0008] This disclosure identifies a method for one party to establish an encrypted link with another party using public-key cryptography. Due to the cryptographic nature of the public and private keys, the link between the first and second parties cannot be forged. Furthermore, the link 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 if needed, the first party can prove that it has generated the second public key based on information verifiable by the second party. If the second party is a trusted party, their trust can be associated with the first party because they have established a shared private key with the first party. This allows the identity of the first party to be trusted.

[0009] The public-private key pair can be a blockchain key pair. That is, the public key can be used as the identity (i.e., address) of a blockchain user, or it can be used to generate the identity (i.e., address) of a blockchain user. However, this disclosure is not limited to blockchain systems. That is, the first party and / or the second party need not be blockchain users, and their respective public-private key pairs need not be used to process transactions through the blockchain.

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

[0011] In this respect, the third party wants to prove the existence of a link between the first party and the second party. For example, the third party can trust the first party. By verifying the link between the first and second parties, the third party can use its 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) messages signed with signatures based on private keys known to both the first and second parties. If a public key corresponding to the second private key has been 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 determine that the first party has established the shared private key with the second party. Then, the third party can use its trust in the first party to trust the second party.

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

[0013] In public-key cryptography, signatures are typically generated using a private key and verified using the corresponding public key. This disclosure provides a method for generating signatures without using one party's private key, and a method by which that party can prove that only they can provide the signature. The record value has been recorded (i.e., mined) in 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 the signature to sign a message, and submit a transaction including the message to the blockchain. The first party can then follow up with a second transaction including the first value, thereby verifying the signature. This allows another party to apply the one-way function to the first value. If applying the one-way function to the first value yields a record value, the verifier can determine that only the first party could generate the signature. Attached Figure Description

[0014] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0015] Figure 1 This is a schematic block diagram of a system for implementing blockchain.

[0016] Figure 2 The illustration shows some examples of transactions that can be recorded in a blockchain;

[0017] Figure 3 This is a schematic block diagram of another system used to implement blockchain;

[0018] Figure 4 The method for encrypting a link between the first and second parties is illustrated schematically; and

[0019] Figure 5 The diagram illustrates a method for verifying whether a first party has an encrypted link with a second party. Detailed Implementation

[0020] Exemplary System Overview

[0021] Figure 1 An exemplary system 100 for implementing blockchain 150 is generally illustrated. System 100 includes a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device, and different nodes 104 belong to different peers. Each node 104 includes a processing device containing one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0022] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple nodes in the P2P network 160. Each block 151 in the blockchain includes one or more transactions 152, where a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain typically uses a specific transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount representing the value of digital assets belonging to user 103 whose output is cryptographically locked (requiring the user's signature to unlock, thereby enabling redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

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

[0024] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Typically, the current transaction can be any transaction in pool 154 or any block 151. Although the existence and verification of the validity of the previous transaction 152i are required to ensure the validity of the current transaction, the existence of the previous transaction 152i is not necessary when creating the current transaction 152j or even sending the current transaction 152j to network 106. Therefore, in this document, "previous" refers to the predecessor in the logical sequence linked by pointers, and not necessarily the creation or sending time in the time series; thus, the possibility of creating or sending transactions 152i or 152j out of order is not necessarily excluded (see the discussion of isolated transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0025] The input to the current transaction 152j also includes the signature of user 103a to whom the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Therefore, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for modification). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

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

[0027] As part of the account-based transaction model, another type of transaction protocol can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the mining nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction record (also known as a "position"). This value is signed by the sender as part of its cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to a previous transaction.

[0028] Regardless of the type of transaction protocol used, when user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal to one of the nodes 104 of the P2P network 106 (currently typically a server or data center, but in principle it could be another user terminal). This node 104 checks the validity of the transaction according to the node protocol applied at each node in the node 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the entire transaction model. The node protocol typically requires node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the case of output-based transactions, this may include checking whether the user's cryptographic signature contained in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, conditions may be defined, at least in part, by custom scripts included in the inputs and / or outputs. Alternatively, this may be determined solely by the node protocol, or by a combination thereof. Regardless of the approach, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of nodes 104.

[0029] In the output-based model, whether a given output (e.g., a UTXO) is spent is defined as whether it has been validly redeemed by the input of another subsequent transaction 152j, according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempted to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if invalid, transaction 152j will not be propagated or recorded in the blockchain. This prevents double-spending, i.e., a spender spending the same output of a transaction more than once. On the other hand, the account-based model prevents double-spending by maintaining account balances. Because a defined transaction order also exists, the account balance has a single defined state at any given time.

[0030] In addition to verification, at least some nodes in node 104M compete to create transaction blocks in a process called mining. At mining node 104M, new transactions are added to a pool of valid transactions that have not yet appeared in the block. The mining nodes then compete to assemble a new valid block 151 of transaction 152 from transaction pool 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "random number" value so that when the random number is concatenated with transaction pool 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a certain predefined number of leading zeros. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs.

[0031] The first mining node 104M to solve the puzzle announces the solution on network 106, providing the solution as proof. Other nodes 104 in the network can then easily check the solution (once a solution with a hash value is provided, it can be directly checked whether the solution makes the output of the hash value satisfy the condition). Based on the winner's announced solution being checked at each of these nodes, the winner's transaction pool 154, which has solved the puzzle, is subsequently recorded in blockchain 150 as a new block 151 by at least some of the nodes 104 acting as storage nodes 104S. A block pointer 155 is also assigned to a new block 151n pointing to the previously created block 151n-1 in the blockchain. Once created, block 151 is immutable because it is identified and maintained by each storage node 104S in the P2P network 106 according to the same protocol. Block pointer 155 also imposes order on block 151. Since transaction 152 is recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0032] It should be noted that different mining nodes 104M vying to solve the puzzle at any given time may perform this operation based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they begin searching for a solution. The person solving the corresponding puzzle first defines the transaction 152 contained in the new block 151n and updates the current unmined transaction pool 154. Then, mining nodes 104M continue to compete to create blocks from the newly defined unmined pool 154, and so on. Furthermore, there are protocols for resolving any potential "forks," where two mining nodes 104M solve the puzzle for each other in a very short time, thus propagating a conflicted view of the blockchain. In short, the fork with the longest possible direction becomes the final blockchain 150.

[0033] Therefore, the winning node is considered to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "generating" transaction, which automatically forms part of a new block 151n. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs. Due to the computational resources involved in mining, each mining node in at least the mining nodes 104M typically takes the form of a server, which includes one or more physical server units, or even an entire data center. Each forwarding node 104M and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 can take the form of a single user terminal or a group of user terminals networked together.

[0034] Each node 104's memory stores software configured to run on the node 104's processing device to perform its appropriate role and process transactions 152 according to the node protocol. It should be understood that any action attributed to node 104 herein can be performed via software running on the processing device of the corresponding computer device. Furthermore, the term "blockchain" as used herein refers to a general term for a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0035] Each of the multiple parties 103 acting as consumer users has its computer device 102 connected to network 101. They act as payers and receivers in transactions but do not necessarily participate in mining or disseminating transactions on behalf of other parties. They do not necessarily run mining protocols. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system, but for convenience, they are not shown. Each party 103 may be an individual or organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein may be replaced by "first party" and "second party," respectively.

[0036] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0038] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding user 103 to create, sign, and send transactions 152 intended to be propagated throughout the network of nodes 104 and thus included in the blockchain 150. The other function is to report the amount of digital assets currently held by the corresponding party. In an output-based system, this second function involves organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant parties scattered across the blockchain 150.

[0039] An instance of client application 105 on each computer device 102 is operatively coupled to at least one forwarding node among forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query in blockchain 150 any transaction for which the corresponding party 103 is the recipient (or actually check transactions of other parties in blockchain 150, since in this embodiment, blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify the validity of transaction 152 according to a node protocol and, in the case of forwarding node 104F, forward transaction 152 to propagate such transactions throughout network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes within it). All nodes 104 in network 106 use the same node protocol (although they may distinguish and process different transaction subtypes according to rules defined for that subtype, and different nodes may also play different roles, thus implementing different corresponding aspects of the protocol).

[0040] As described above, blockchain 150 includes a series of blocks 151, each block 151 comprising a set of one or more transactions 152. Each block 151 also includes a block pointer 155 pointing to previously created blocks 151 in the blockchain to define the order of blocks 151. Blockchain 150 also includes a pool of valid transactions 154, which await inclusion in new blocks. Each transaction 152 (except for a generating transaction) includes pointers to previous transactions to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more earlier original transactions 152 in blockchain 150 point to the genesis block 153, not to previous transactions.

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

[0042] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "valid"), any storage node 104S that receives transaction 152j will add the new valid transaction 152 to pool 154 in the replica of blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives transaction 152j will then propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will quickly propagate throughout the P2P network 106.

[0043] Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also recorded immutably.

[0044] UTXO-based model

[0045] Figure 2 An exemplary transaction protocol is illustrated. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to protocols based on outputs or UTXOs. However, this is not limited to all possible embodiments.

[0046] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). The UTXO specifies the amount of digital asset (a store of value). It may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this 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 original transaction 152 submitted to the mining node 104M.

[0047] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the sequence, Alice's new transaction 152j is marked "Tx1". This new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In this context, the previous transaction 152i is marked as "Tx0". Tx0 and Tx1 are just arbitrary markers, and they do not necessarily mean that Tx0 refers to the first transaction in the blockchain and Tx1 refers to the next transaction in pool 154. Tx1 can refer to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0048] When Alice creates her new transaction Tx1, or at least when she sends it to network 106, the previous transaction Tx0 may already be valid and included in blockchain 150. This transaction may at this point be included in a block of block 151, or it may still be waiting in pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 can be created and sent to the network together; or, if the node protocol allows buffering of “orphaned” transactions, Tx0 may even be sent after Tx1. The terms “previous” and “subsequent” as used in the context of transaction sequences in this paper refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They can also be replaced with “predecessor” and “successor,” “preceding” and “descending,” or “parent” and “child,” etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to a previous transaction (preceding transaction or "parent transaction") will not be valid unless the parent transaction is valid. Child transactions that arrive at node 104 before the parent transaction are considered orphaned transactions. Depending on the node protocol and / or the behavior of the mining node, they may be discarded or buffered for a period of time to wait for the parent transaction.

[0049] One of the outputs 203 of a previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script. This locking script defines the conditions that the unlocking script in the input 202 of a subsequent transaction must meet for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following condition: the unlocking script in the input of the subsequent transaction includes a cryptographic signature of the party to whom the previous transaction was locked.

[0050] A locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "script" (S capitalized). The locking script specifies the information required for the transaction output 203, such as the requirement 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 locking script standard. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0051] Therefore, in the example shown, UTXO0 in the output 203 of Tx0 includes the locking script [Checksig P] A This locking script requires Alice's signature (Sig P).A This is to redeem UTXO0 (strictly speaking, to make subsequent transactions attempting to redeem UTXO0 valid). [Checksig P] A The public key P in Alice's encrypted public-private key pair is included. A Input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in this embodiment is the hash of the entire transaction Tx0). Input 202 of Tx1 includes an index identifying UTXO0 in Tx0, to identify it in any other possible output of Tx0. Input 202 of Tx1 further includes an unlock script. <Sig P A The unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0052] When a new transaction Tx1 arrives at node 104, that node applies the node protocol. This includes running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria). In this embodiment, this involves concatenating two scripts:

[0053] <Sig P A > <P A >||[Checksig P A ]

[0054] Here, "||" indicates concatenation, "<...>" indicates placing data on a stack, and "[...]" indicates a function consisting of the unlock script (in this example, a stack-based language). Similarly, scripts can be run one after another using a shared stack, instead of concatenating them. Regardless of the method used, when run together, the scripts use Alice's public key P. A (Included in the locking script at the output of Tx0) to authenticate whether the locking script at the input of Tx1 contains the signature when Alice signs the expected portion of the data. The expected portion of the data itself (“message”) also needs to be included in Tx0 in order to perform this authentication. In this embodiment, the signed data includes the entire Tx0 (therefore, it is not necessary to include a separate element to plaintext specify the portion of the signed data, as it already exists on its own).

[0055] Those skilled in the art will be familiar with the details of authentication via encrypted public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), any entity, such as Node 104, capable of authenticating an encrypted version of the message must have already signed it by Alice. Signing typically involves hashing the message, signing the hash value, and attaching this to the plaintext version of the message as a signature, thus enabling any holder of the public key to authenticate the signature.

[0056] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (therefore, in the example shown, if Alice's signature is provided and authenticated in Tx1), then node 104 considers Tx1 valid. If it is a mining node 104M, this means it will be added to the transaction pool 154. If it is a forwarding node 104F, it will forward transaction Tx1 to one or more other nodes 104 in network 106, thus propagating it throughout the network. Once Tx1 is valid and included in blockchain 150, this defines UTXO0 in Tx0 as spent. Note that Tx1 is only valid if it spends an unspent transaction output 203. If an attempt is made to spend an output that has already been spent by another transaction 152, Tx1 will be invalid even if all other conditions are met. Therefore, node 104 also needs to check if the UTXO referenced in the previous transaction Tx0 has already been spent (has formed a valid input for another valid transaction). This is one of the reasons why the order in which blockchain 150 imposes definitions on transaction 152 is important. In practice, a given node 104 can maintain a separate database that marks the UTXO 203 of a spent transaction 152, but the final definition of whether a UTXO has been spent depends on whether a valid input to another valid transaction is formed in blockchain 150.

[0057] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined in a UTXO as spent while simultaneously spending another portion. However, the amount in a UTXO can be split across multiple outputs in the next transaction. For example, the amount defined in UTXO0 of Tx0 can be split across multiple UTXOs in Tx1. Therefore, if Alice doesn't want to give Bob all the amount defined in UTXO0, she can use the remainder to make change herself in the second output of Tx1, or pay the other party.

[0058] Also note that if the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another failure criterion in most transaction models. Therefore, such a transaction will not be propagated or mined into block 151.

[0059] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 at any point in blockchain 150. Therefore, typically, the assets of the given party 103 are scattered across the UTXOs of various transactions 152 throughout blockchain 150. No single number defining the total balance of the given party 103 is stored anywhere in blockchain 150. The wallet function of the client application 105 serves to consolidate the various UTXO values ​​locked to the corresponding party and not yet spent in other subsequent transactions. This is achieved by querying a copy of blockchain 150 stored at any storage node 104S (e.g., the storage node 104S most recently or best connected to the corresponding party's computer device 102).

[0060] Please note that script code is typically represented using diagrams (i.e., non-precise language). For example, it might be written as [ChecksigP A ] indicates [Checksig P A ] = OP_DUP OP_HASH160<H(Pa)> OP_EQUALVERIFY and OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting 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 occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in transactions verified by the 'sig' input. Similarly, OP_RETURN is a scripting language opcode used to create a non-spent output for a transaction, which can store metadata within the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata may include files that need to be stored in the blockchain.

[0061] Signature P A This is a digital signature. In this embodiment, it is based on ECDSA using elliptic curve secp256k1. The digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input and all or part of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select the output to be signed (and therefore fixed at the time of signing).

[0062] A locking script, sometimes called a "scriptPubKey," refers to the fact that it includes the public key of the party to whom the corresponding transaction is locked. An unlocking script, sometimes called a "scriptSig," refers to the fact that it provides the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature authentication. Furthermore, a scripting language can be used to define one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0063] Optional side channel

[0064] Figure 3 Another system 100 for implementing blockchain 150 is shown. In addition to additional communication functions, system 100 is connected to… Figure 1 The content shown is essentially the same. The client applications on each of Alice and Bob's computer devices 102a and 120b include additional communication capabilities. That is, this allows Alice 103a to establish a side channel 301 separate from Bob 103b (at the instigation of either party or a third party). Side channel 301 enables data exchange independently of the P2P network. Such communication is sometimes referred to as "off-chain" communication. For example, when exchanging transaction 152 between Alice and Bob, if they do not want to publish the transaction (yet) to the P2P network 106 or mine block 150, they can use this communication until one of them chooses to broadcast the transaction to network 106. Alternatively or additionally, this side channel 301 can be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0065] Side channel 301 can be established via the same packet-switching network 101 as P2P overlay network 106. Alternatively, side channel 301 can be established via a different network such as a mobile cellular network, or a local area network such as a local wireless network, or even a direct wired or wireless connection between Alice and Bob's devices 1021, 102b. Generally, side channel 301 as referred to herein can include any one or more links via one or more networking technologies or communication media for exchanging data "off-chain" (i.e., independently of P2P overlay network 106). When multiple links are used, the entire bundle or set of off-chain links can be referred to as side channel 301. Therefore, it is important to note that while Alice and Bob exchange specific information or data fragments or similar items via side channel 301, this does not necessarily mean that all these data fragments must be sent via the same link or even the same type of network.

[0066] Public-key cryptography

[0067] Public-key cryptography is well-known and will therefore be described only briefly here. In many different blockchain architectures, public-key cryptography serves as the foundation for securing messages (e.g., transactions). Uses of public-key cryptography include public-key encryption and digital signature schemes. Public-key cryptography is based on the principle that certain functions are easy to compute but difficult to invert without special knowledge. Ease of computation means that it is computationally feasible to compute the result of a function given an input (or a set of inputs) within a reasonable timeframe, while difficulty in inversion means that it is computationally infeasible to deduce from the result that the input (or those inputs) is computationally infeasible without knowledge of the input.

[0068] In the context of public-key cryptography, a public-private key pair refers to a public key (which anyone can freely obtain) and a corresponding private key (presumably a private key, since this is only known to a specific entity or group).

[0069] In the context of public-key cryptography, encryption is performed using the public key, and decryption is performed using the corresponding private key. In the context of digital signatures, signatures are generated using the private key, and signature verification is performed using the corresponding public key.

[0070] In the context of blockchain, digital signatures based on public-key cryptography serve as the basis for cryptographically signing and verifying transactions.

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

[0072] In the context of ECC, addition, subtraction, and multiplication are respectively elliptic curve point addition (denoted as "+" in this paper), elliptic curve point subtraction (denoted as "-" in this paper), and elliptic curve scalar multiplication (denoted as "·" in this paper). Addition and subtraction are applied to two points on an elliptic curve, respectively, and return a third point on the elliptic curve; however, multiplication is applied to a scalar and a single point on an elliptic curve, and returns a second point on the elliptic curve. Elliptic curve arithmetic provides the unique ability to hide secret values ​​and forms the basis of many modern cryptographic systems. In particular, inverting scalar multiplication at elliptic curve points over a finite field is a challenging problem (computationally infeasible).

[0073] The private key V is in integer form, and the corresponding public key P is a point P on the elliptic curve derived from the "generation point" G. This point is also a point on the elliptic curve, as shown below:

[0074]

[0075] Here, "·" denotes elliptic scalar multiplication on an elliptic curve defined by its parameters. For sufficiently large V, practically performing the derivation of V-elliptic curve addition to P is difficult, i.e., computationally infeasible. However, if V is known, P can be computed more efficiently by leveraging the algebraic properties of elliptic curve operations. An example of an efficient algorithm that can be used to compute P is the "double addition" algorithm, which, importantly, is only possible when V is known.

[0076] Conversely, if V is unknown, there is no computationally feasible way to derive V (i.e., to perform inverse scalar multiplication) even if G and P are known (this is the so-called "discrete logarithm problem"). An attacker could try to "brute-force" P by starting with G and repeatedly performing elliptic curve point additions until P is reached; at this point, he would know that V is the number of elliptic curve point additions he must perform; however, this proves computationally infeasible. Therefore, V satisfies the trapdoor requirement in the aforementioned sense. In ECC, the public key P, the generator key G, and the elliptic curve are public and assumed to be known, while the private key V is secret.

[0077] In a blockchain system, users or other entities typically hold a private key V to prove their identity, and the corresponding public key P is calculated using the following equation:

[0078] P = V·G

[0079] The private key V can be used to sign data m (“message”) using ECDSA. For example, more information about ECDSA can be found in the following, the entire contents of which are incorporated herein by reference: “RFC 6979 - Deterministic Use of Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)”, Tools.ietf.org, 2019.

[0080] Encrypted link identity

[0081] Now for reference Figure 4 This illustrates a method for encrypting a link between two parties. The actions performed by the first party (e.g., Alice) 103a will be described below, but it should be understood that the second party (e.g., Bob) 103b may perform some or all of the same actions. The first and second parties can be referenced. Figures 1 to 3 The same first and second parties are mentioned above. Alternatively, the first and / or second parties may be non-blockchain users. Typically, each party operates a corresponding computer device configured to perform the actions of that party.

[0082] By leveraging the cryptographic properties of public-key cryptography, two parties can be linked. Elliptic curve cryptography will be described below, but it should be understood that this teaching is generally applicable to other forms of public-key cryptography. Elliptic curve algorithms can be used to provably link the identities of two parties using only their public keys and a public key generated from a shared key. For example... Figure 4 As shown, Alice 103a and Bob 103b each possess their own public-private key pairs. Alice 103a possesses the first private key S. A0 and the corresponding first public key P A0 Similarly, Bob possesses the first private key S. B0 and the corresponding first public key P B0 In addition, Alice 103a and Bob 103b established a shared key S. AB0 and the corresponding first public key P AB0 .like Figure 3 As shown, a shared key can be established using side channel 301. As the name suggests, the public key is assumed to be accessible to any party and / or external third parties. Conversely, the private key is assumed to be kept secret from its owner.

[0083] A shared key can be established using Diffie-Helman key exchange or its extensions. One technique for establishing a shared key is that each party generates a shared key using its own private key (which may or may not be its first private key) and the other party's public key (which may or may not be its first public key). For example, Alice 103a uses her private key S A And Bob's public key P B Similarly, Bob used his private key S B And Alice's public key P A As shown below:

[0084] S AB0 =[S A S B G] x =[S A P B ] x =[S B P A ] x

[0085] in,[] x This represents the x-coordinate of a point on an elliptic curve.

[0086] Assume that only Alice 103a knows her private key S A And only Bob 103b knows his private key S B Then only Alice 103a and Bob 103b can calculate S. AB0A shared private key SAB0 can be established without disclosing sensitive information (i.e., the private key).

[0087] The following table shows the public and private keys held by Alice 103a and Bob 103b. In this example, the public key is associated with the private key via elliptic curve multiplication (P = S·G), where G is the elliptic curve generation point.

[0088]

[0089] Then, Alice 103a can use her first private key S A0 and shared private key S AB0 Generate a second private key S A1 This is referred to as the identity linking key in this paper. For example, Alice's identity linking key can be generated as S. A1 =S A0 +S AB0 Since only Alice 103a knows S A0 Therefore, only Alice can generate S. A1 and P A1 .

[0090] However, due to public key P A0 and P AB0 The public key can be publicly known, so it can be verified by anyone. The following equation shows how Alice 103a can use her private key and how another party can derive P using the publicly known key. A1 An example:

[0091] P A1 =S A1 ·G

[0092] P A1 =(S A0 +S AB0 )·G

[0093] P A1 =(S A0 ·G)+(S AB0 ·G)

[0094] P A1 =P A0 +P AB0

[0095] Similarly, Bob 103b can use his first private key S B0 and shared private key S AB0 To generate identity link key S B1 For example, Bob's identity link key can be generated as S B1 =S A0 +S B0Since only Bob knew S B0 Therefore, only Bob can generate S. B1 and P B1 S can be used. A0 and S AB0 More complex equations to generate S A1 Similarly, S can be used. B0 and S AB0 More complex equations to generate S B1 .

[0096] By using the shared key S AB0 Each party can verify the identity of the other. Since only Alice 103a and Bob 103b know the shared key S... AB0 Therefore, if Alice receives P AB0 If she signs the message, she can be certain it came from Bob. Similarly, if Bob 103b receives a message using P... AB0 By signing the message, she can confirm that it came from Alice. Remember, a corresponding private key is required to sign the message using the public key.

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

[0098] One method to generate a sequence of shared public-private key pairs is to repeatedly hash the initial shared key:

[0099] P AB0 =S AB0 ·G

[0100] P AB1 =h(S AB0 )·G

[0101] P AB2 =h 2 (S AB0 )·G

[0102]

[0103] P ABi =h i (S AB0 )·G

[0104] Other methods for generating the updated shared key sequence are:

[0105] 1.P i =[h i (S0)+h i (P A-1 -P B-1 )]·G

[0106] 2.P i =h(S i-1 |S i-2 )·G

[0107] Each updated shared private key can be used to generate a corresponding updated identity linking key. For example, the identity linking keys for Alice 103a and Bob 103b can be updated as follows:

[0108] P A(i+1) =P ABi +P A0

[0109] P B(i+1) =P ABi +P B0

[0110] After these keys are updated, the corresponding party will not know the identity of the other party; it will only know P. A(i+1) or P B(i+1) However, if needed, the identity of one party (e.g., Alice 103a) can be challenged at any stage via signature.

[0111] Alice 103a can use her identity to link the key P AiAlice 103a can use any of her identity linking keys to sign a message and transmit it to Bob 103b or a third party. In the context of the blockchain, Alice 103a can use one of her identity linking keys to sign part or all of a blockchain transaction. For example, Alice 103a can sign the input of a transaction. Alice 103a can then transmit the transaction to Bob, a third party, or one or more nodes in the blockchain network, allowing the transaction to be mined into the blockchain 150. The identity linking key enables Alice 103a to sign any part of a blockchain transaction. Furthermore, the identity linking key allows more than one party to sign a part of a transaction. For example, Alice 103a can sign (a part) of a transaction and then transmit it to Bob 103b, who will also sign (a part) of the same transaction. Alice 103a or Bob can then transmit the transaction to the blockchain network.

[0112] Verify encrypted link

[0113] Figure 5 This demonstrates a method that a third party (Charlie) 103c can use to verify whether a first-party and a second-party encrypted link are used. Although Figure 5 Not shown, but Charlie includes computer equipment including processing devices, such as one or more processors, including one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). The computer equipment also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memory (EEPROMs), and / or optical media such as optical disc drives.

[0114] like Figure 5 As shown, Alice 103a possesses her first private key S. A0 Shared private key S AB0 and her second private key (i.e., her identity linking key) S A1 Similarly, Bob 103b possesses his first private key S. B0 Shared private key S AB0 And his second private key (i.e., his identity linking key) S B1In 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 possesses the identity-linked key linked with Alice. Charlie 103c can then have Bob 103b use the dependency of the identity-linked key on the shared key to prove his relationship with Alice 103a. Charlie 103c obtains from Bob 103b a message signed using Bob's first public-private key pair. Charlie 103c also obtains from Bob 103b a message signed using his identity-linked public-private key pair. Bob 103b can choose which message to transmit to Charlie 103c. Alternatively, Charlie 103c can transmit a message (e.g., a challenge) to Bob 103b for signing. Charlie 103c also obtains messages signed with a shared public-private key pair from Alice 103a. Similarly, Alice 103a can decide to transmit messages to Bob 103b, or Charlie 103c can transmit messages to Alice 103a. Charlie 103c can obtain messages first from Bob 103b or from Alice 103a. Once Charlie 103c has the signed message, it verifies that Bob's identity linking key has been generated based on the shared private key. Charlie 103c determines this by verifying whether Bob's first public key and the shared public key (e.g., P) have been used. B1 =P AB0+ P B0 Generate an identity link public key to verify this.

[0115] For example, Charlie can use such as Figure 3 The side channel 301 shown receives the signed message from Alice and / or Bob via the Internet.

[0116] Once verified, this proves the unforgeable connection between Alice 103a and Bob 103b. Furthermore, Charlie 103c can perform checks to verify that the signatures generated by Alice and Bob are valid. Additionally, Charlie 103c can enable Alice 103a and Bob 103b to transmit messages using one or more blockchain transactions. For example, the signed message can be included in the output of the blockchain transaction. Charlie 103c can then create a transaction with the output as its transaction input. The input can contain a script used to verify the relationship between Alice 103a and Bob's public keys. Once verified, this relationship is immutably stored on blockchain 150.

[0117] While the techniques described above have been referenced to Alice 103a and Bob 103b, the first and second parties can often be the same entity (e.g., the same person, company, organization, etc.). For example, the first party might want to cryptographically link its (trusted) identity to another identity, for instance, by linking one of its public keys with a key known only to them. Similarly, each party's first private key does not need to utilize the same public-key cryptography system. For example, Alice 103a could utilize elliptic curve cryptography, while Bob might utilize RSA or DSA encryption. Likewise, the shared private key and Alice's and / or Bob's first private key can utilize different cryptographic systems. In some examples, if different cryptographic systems are used, at least one of the private keys may need to be padded or truncated to reflect the other private-key scheme.

[0118] For example, consider non-blockchain systems such as governments or banks with sufficiently robust Know Your Customer (KYC) systems. Known users (e.g., Alice 103a) will possess public key P. A0 The private key (S) connected to her identity A0 This can be verified by a bank or government and can be publicly confirmed. Alice103a can use the above methods to verify her blockchain identity (S). B0 ,P B0 It is provably linked to the off-chain system, and as described above via P B1 =(S B0 +S AB0 G calculates her identity linking key to derive subsequent keys or key hierarchies that can all be linked to her off-chain identity. This can then be used as her blockchain identity and can be used with P. AB0 Provably linked to P A0 This not only provides KYC features for her blockchain identity but also enables blockchain functionality for her off-chain accounts with government and banks. In other words, she can participate in the blockchain system using her identity-linked key, which can be used to update (e.g., credit or debit) her off-chain accounts without requiring banks or governments to publish them to Blockchain150.

[0119] Access Chain

[0120] Leveraging the data storage capabilities of blockchain, a party can use an inherent cryptographic signature scheme as a signature for encapsulated data. However, the underlying protocol of blockchain 150 is typically fixed and therefore cannot be customized for specific applications. This requires all parties to possess valid private keys, restricting their use on things already part of the system. Similarly, signature authorization cannot be granted without exposing one party's private key. This disclosure provides a second-layer signature protocol that can be included within blockchain transactions, allowing multiple parties to participate in a single transaction.

[0121] One-way functions (e.g., cryptographic hash functions) provide an efficient deterministic method to obfuscate inputs, making it impossible to find the input given the output. Hash functions (or commonly referred to as one-way functions) can be used to generate "tokens" that can be provided to, redeemed by, and transferred between different parties. Tokens can be generated by repeatedly hashing a seed value, thus forming a so-called chain of access.

[0122] By using a pre-agreed number of events (n) requiring token access, the user applies the key (K) n times (h). n (K)) Hash function (h). Then, the value is registered with a service provider, for example, by publishing the value on blockchain 150. Then, a party can redeem the token by providing a preimage of the registered value on blockchain 150, which becomes the new registered value. For example, if token t n =h n (K) Currently published on Blockchain 150, it can be accessed by providing t n-1 =h n-1 (K) to redeem the token.

[0123] For example, by finding a willing buyer and agreeing on a price for the tokens, the token owner can transfer any remaining tokens to another party at any time. If Alice103a is the current owner of the registered tokens, Alice103a provides her latest preimage to prove her identity to the service provider, while also providing the new party with a newly generated registration value for the access chain.

[0124] By generating a new private key S on each redemption i As the root private key S0 and chain t i The sum of the next preimages in, i.e. (S i =S0+t i These tokens can also be provably linked to public keys.

[0125] In addition to providing tokens, accessing the chain also provides a method for signing a predetermined number of messages. These signatures can be applied directly to data blocks, rather than the entire transaction. Consider a hash chain of length n as an example. That is:

[0126] t n =h n (K)

[0127] t n-1 =h n-1 (K)

[0128]

[0129] t i =h i(K)

[0130]

[0131] t1 = h(K)

[0132] t0 = K

[0133] In this type of chain, t n =h(t) n-1 A hash chain is formed by the final value t. n The final value is published to Blockchain150 and registered with a given public key (or address). Providing a preimage of the latest registered value serves as a signature for any messages or other data that may be included within the transaction. This signature is publicly verifiable and can only be provided by the token owner. However, this method is vulnerable to replay attacks, where an attacker could create malicious transactions after viewing the signature value.

[0134] The technique described in this article provides a secure two-phase signing process, in which one transaction is used to provide a signature and another transaction is used to verify the signature.

[0135] A first party (e.g., Alice 103a) possesses a preimage (first value) of the token (record value) recorded on blockchain 150. The record value is generated by applying a one-way function (e.g., a hash function) 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 transmit the transaction to blockchain network 106. Alice 103a can then construct a second transaction including the first value (i.e., the preimage of the record value) and transmit the transaction to the blockchain network. The first and second transactions can be the same transaction or different transactions.

[0136] Now, the first value is also recorded on blockchain 150, and is therefore the new registration value (or the updated registration value). Alice 103a can repeat the above process to sign the second message. That is, Alice 103a generates a signature by hashing the message and the preimage of the new registration value. Alice 103a transmits the transaction including the signed message (which may be the same transaction as the second transaction or a different transaction) to blockchain network 106. Then, Alice 103a transmits the transaction including the preimage of the updated registration value to the blockchain network. This process can be repeated until the seed value is revealed.

[0137] In some examples, Alice 103a hashes the hash values ​​of the preimage and the message, rather than hashing the preimage and the message. For example, Alice 103a might have generated t0,…,t as defined above. nThe access chain and the nth one to be signed th message m n Value t n+1 =h(t) n Currently registered on blockchain 150, Alice can construct message m using both the message's hash and the preimage of the latest registered value. n The signature is as follows:

[0138] h(t n +h(m n ))

[0139] Similarly, t n =h n (k). At this point, if a transaction containing a signature is included in a block, and when a transaction containing a signature is included in a block, the signature cannot be verified. To address this, Alice 103a constructs a verification transaction in which t is provided. n And register it as the latest value in the access chain registered on Blockchain 150.

[0140] By providing this value, it can be checked that h(t) n )=t n+1 and h(t) i +h(m i The access chain is verified by checking whether the data provided in the signing (first) transaction is consistent with the data provided in the first transaction. This two-phase signing process sends verification and confirmation once the user has nominally confirmed the transaction and the confirmation is complete.

[0141] The one-way function used by Alice 103a can be a hash-based message authentication code (HMAC). HMAC is a table value that uses a message m and a key K to provide verification of the message. HMAC is a type of message authentication code that utilizes the preimage and collision resistance of a cryptographic hash function to prevent the exposure of the key used to compute the HMAC. This is widely used for secure message transmission and transmission error detection because subtle changes in the input can often lead to significant changes in the output of the hash function.

[0142] Let h(x) be a hash function evaluated with respect to the value x. HMAC is defined as:

[0143]

[0144] This can be used as a secure signature scheme that can be directly applied to data fragments (in this case, message m). It can be published to blockchain 150 and then verified by providing a key K that can validate the signature.

[0145] By using key K, an access chain with a depth of n levels can be formed. That is to say:

[0146] t1 = h(K)

[0147] t2=h 2 (K)

[0148]

[0149] t n =h n (K)

[0150] Where K is the final key, t n This is the initial registration value on blockchain 150. Then, Alice 103a can use HMAC(t) n-1 H(t) is used as the signature of m. Then, the verifier (e.g., Bob) can use the new exposure value to check if H(t) is actually present. n-1 )=t n And calculate HMAC′(K) n-1 The preimage (m) matches the registered value. The exposure of the preimage serves as confirmation of the signature. Similarly, this process can be repeated to generate and confirm a new signature for each message to be signed.

[0151] This relationship gives the signature a finite lifespan until the next value in the access chain is exposed. Furthermore, this relationship enables the authorization of signatures because the signer (Alice 103a) can provide (without exposing the root of the access chain) the next or more values ​​in the access chain to a second party (e.g., Bob 103b) who can submit the signature on her behalf. This process requires a certain level of trust between the access chain holder and the delegator, as the original key will be held by the delegator. The delegator may need to submit at least one transaction signed using a public key that can be linked to them. Therefore, if a delegator misuses the key, they can be identified using transaction signatures.

[0152] As an exemplary use case, in many legal scenarios, contract terms may change periodically to accommodate new legislation introduced in different jurisdictions. This often requires modifying many contracts in similar or nearly identical ways. The above scheme provides a method for applying signatures to a limited, predetermined number of documents using an access chain. Consider a legally binding contract m0 and a signer with a key K. The signer can use t... n =h n (K) is published to Blockchain 150. This is achieved through the use of the published preimage h. n (K) can use the hash value (h(t) of the message preimage. n-1 +h(m0)), then by providing t n-1 Or by using the HMAC scheme HMAC(t) n-1The signature is generated through verification performed to enhance security. If the contract needs to be amended, the signer can use the next value in the chain to sign the amendment (m1). Therefore, a complete record of all contract states is immutably recorded on blockchain 150 and timestamped. Because they are directly applied to the data (in this case, contract amendments) and subsequently verified, multiple signatures can also be batched into a single transaction, thus efficiently managing a large number of contracts.

[0153] Identity Link Access Chain

[0154] As described above, Alice 103a and Bob 103b can each derive an identity linking key that is provably associated with the other party. Instead of directly using the identity linking key, Alice and Bob can each use their respective identity linking keys to derive a new shared key. As described above, the corresponding identity linking keys for Alice and Bob are generated as follows:

[0155] P A1 =(S A0 +S AB0 )·G

[0156] P B1 =(S B0 +S AB0 )·G

[0157] Therefore, Alice 103a and Bob 103b can each calculate their derived shared key (“the first derived shared private key”) using the following equation:

[0158] S AB1 =[S A1 S B1 G] x =[S A1 P B1 ] x =[S B1 P A1 ] x ,

[0159] in,[] x This represents the x-coordinate of a point on the elliptic curve. This newly derived shared key, or a key derived from it, can then be used as a seed in the access chain. Since the root of the access chain will eventually be exposed, using the derived key does not compromise the initial shared key S. AB0 This ensures that new chains can be created again. For example, S can be used. AB1 To calculate the new chain.

[0160] Taking a 100-level deep access chain as an example, where t n =h n (S AB1Alice 103a can generate:

[0161] t 100 =h 100 (S AB1 )

[0162] t 99 =h 99 (S AB1 )

[0163]

[0164] t1=h(S AB1 )

[0165] t0 = S AB1

[0166] Alice can use t 100 It is publicly registered by including the transaction in the transaction and transmitting it to the blockchain network for storage on blockchain 150. Then, Bob 103b can verify Alice's identity by calculating his own value (because he himself also knows S). AB1 ).

[0167] If one party suspects that the other party has been exposed as S AB1 If they are harmed, they can request a challenge scheme that requires the next desired value that only the original two parties can execute. Bob 103b can send a challenge message (m) to Alice 103a. c ) and expected form, both using S AB0 Or it can be encrypted using a key derived from it. Because the compromised access chain did not use S... AB0 Therefore, it cannot be compromised. Thus, no one other than Alice 103a could know the query message and the required response format. If t n+1 If it is the latest value recorded on blockchain 150, then the required response can take one of the following forms:

[0168] y = h(h) n (S AB1 )||m c )

[0169]

[0170] Where || represents cascading, This refers to the XOR operation. Here, h n (S AB1 ) is the value in the sequence immediately preceding the most recent value recorded on the blockchain. For example, if t 100 Recorded on the blockchain, then h n (SAB1 )=t 99 If Alice 103a reports using that key, Bob 103b can verify her identity. However, for the rest of the chain, Bob 103b can also request Alice 103a to respond in this manner. Despite the potential security vulnerabilities, the chain can continue to be used. However, a new access chain can be created using a newly derived key if either party requires it.

[0171] Exemplary use cases will now be described. Auditing provides independent assessments of various business processes, including financial reporting, regulatory compliance, and product quality. Specifically, third-party auditors can form a vital part of the supply chain as products manufactured by a company ultimately reach consumers. Currently, many of these auditors cannot be integrated with blockchain systems. By accessing the chain through identity links, linked identities can be used to verify the authenticity of confirmed claims and be updated at any frequency required by the auditing firm.

[0172] The auditing firm must declare the public key P A1 The public key will have a sufficiently strict KYC process. Auditors can compute (e.g., via Diffie-Helman exchange) the shared key pair (S AB1 ,P AB1 Link his or her identity to the auditing firm. This can serve as the root of the access chain, t n =h n (S AB1 ), where the initial value t n The registration is handled by the auditing firm. Individual auditors can then perform the necessary compliance investigations and provide a compliance certification m0 using the aforementioned signature method, thus recording a preimage of the latest registered value on blockchain 150. This certification may expire when another compliance audit is required. The required reporting conditions can be verified upon each renewal; if these conditions are not met, the signature is denied. This provides an immutable compliance record, traceable back to the individual auditor, and establishes a verifiable link with the auditing firm.

[0173] in conclusion

[0174] It should be understood that the above embodiments are described by way of example only.

[0175] More generally, based on a first example of the teachings disclosed herein, a computer implementation method for linking a first party and a second party is provided, the method being performed by the first party and comprising: obtaining a first cryptographic public-private key pair, the first cryptographic public-private key pair including a first private key and a corresponding first public key; generating a first shared private key pair known to the first party and the second party; and generating a second cryptographic public-private key pair, the second cryptographic public-private key pair including 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 shared private key.

[0176] According to an optional second example of the teachings disclosed herein, a method according to the first example may be provided, comprising: generating one or more updated shared private keys, each updated shared private key pair being known to the first party and the second party; and generating one or more updated second encrypted public-private key pairs, each of the second encrypted public-private key pairs including a corresponding updated second private key and a corresponding updated second public key, wherein each corresponding updated second private key is generated based on a different updated shared private key among the first private key and the one or more updated shared private keys.

[0177] In some embodiments, multiple updated shared private key pairs are generated, and multiple updated second encrypted public-private key pairs are generated, wherein each corresponding updated second private key is generated based on a first private key and a different shared private key from the multiple updated shared private keys.

[0178] According to an optional third example of the teachings disclosed herein, a method according to the second example may be provided, wherein one or more updated shared private keys form a key sequence, the key sequence being the first shared private key, and wherein each next private key in the sequence is generated by applying a one-way function to at least the previous shared private key in the sequence.

[0179] According to an optional fourth example of the teachings disclosed herein, a method according to any one of the first to third examples may be provided, comprising: obtaining a second public key of the second party, wherein the second public key of the second party is generated based on the first shared private key and the first 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.

[0180] According to an optional fifth example of the teachings disclosed herein, a method according to the fourth example may be provided, comprising: generating a sequence of values, wherein the initial value in the sequence is the derived shared private key, or is generated by applying a one-way function to the derived shared private key, and wherein each next value in the sequence is generated by applying a one-way function to at least the previous value in the sequence.

[0181] According to an optional sixth example of the teachings disclosed herein, a method according to a fifth example may be provided, the method comprising: transmitting a blockchain transaction to one or more nodes of a blockchain network to include the blockchain transaction in the blockchain, wherein the blockchain transaction includes the latest value in a sequence of values.

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

[0183] According to an optional seventh example of the teachings disclosed herein, a method according to the sixth example may be provided, comprising: receiving a challenge message from a second party, the challenge message being encrypted based on a first shared private key; generating a response to the challenge message, wherein the response is based on the challenge message and a value in the value sequence immediately preceding the latest value; and transmitting the response to the second party.

[0184] According to an optional eighth example of the teachings disclosed herein, a method according to the seventh example may be provided, the method comprising receiving the response in a predetermined form from a second party, the predetermined form being encrypted based on the first shared private key, and wherein the generated response is further based on the predetermined form.

[0185] According to an optional ninth example of the teachings disclosed herein, a method according to any one of the first to eighth examples may be provided, wherein the first shared private key is generated based on the private key of the third cryptographic public-private key pair of the first party and the public key of the cryptographic public-private key pair of the second party.

[0186] In addition, the first shared private key can also be generated from the third public key of the first party's third encrypted public-private key pair and the private key of the second party's encrypted public-private key pair.

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

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

[0189] According to an optional twelfth instance of the teachings disclosed herein, a method according to any one of the first to eleventh instances may be provided, comprising: signing a message with a signature based on the second private key of the first party; and transmitting the signed message to the second party and / or a third different party.

[0190] According to an optional thirteenth example of the teachings disclosed herein, a method according to any one of the first to twelfth examples may be provided, comprising: signing at least a portion of a blockchain transaction with a signature based on the first party's second private key; and transmitting the blockchain transaction to one or more nodes of a blockchain network to include the blockchain transaction in the blockchain.

[0191] According to the fourteenth example of the teachings disclosed herein, a computer-implemented method for verifying a link between a first party and a second party is provided, the method being performed by a third party, and the method comprising: obtaining from the second party i) a message signed with a first signature based on a first private key of the second party, and ii) a first public key corresponding to the first private key; obtaining from the second party iii) the message signed with a second signature based on a second private key of the second party, and iv) a second public key corresponding to the second private key; obtaining from the first party v) the message signed with a third signature, the message signed with the third signature being based on a shared private key and a corresponding shared public key known only to the first party and the second party; and determining, based on the shared public key and the second party's first public key, whether the second party's second public key has been generated.

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

[0193] According to an optional sixteenth instance of the teachings disclosed herein, a method according to the fourteenth or fifteenth instance may be provided, comprising: transmitting the message to the first party and the second party.

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

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

[0196] According to the nineteenth example of the teachings disclosed herein, a method is provided for verifying a computer implementation of a first signature used by a first party to sign a first message, wherein the blockchain includes recorded transactions, the recorded transactions including a registration value generated by applying a one-way function to the first value; the method is performed by the first party, and the method includes: generating the first signature by applying a one-way function to at least the first value and the message; transmitting a first transaction to one or more nodes of the blockchain network to include the first transaction in the blockchain, the first transaction including the message signed with the first signature; and transmitting a second transaction to one or more nodes of the blockchain network to include the second transaction in the blockchain, the second transaction including the first value.

[0197] According to an optional twentieth example of the teachings disclosed herein, a method according to the nineteenth example can be provided, wherein the first value is an updated registration value and is generated by applying a one-way function to a second value, wherein the method includes: generating a second signature by applying a one-way function to at least the second value and the second message; transmitting a third transaction to one or more nodes of the blockchain network to include the third transaction in the blockchain, the third transaction including the second message signed with the second signature; and transmitting a fourth blockchain transaction to one or more nodes of the blockchain network to include the fourth blockchain transaction in the blockchain, the fourth transaction including the second value.

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

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

[0200] According to the optional twenty-second example of the teachings disclosed herein, a method according to the nineteenth to twenty-first examples may be provided, wherein the first signature is a hash-based message authentication code.

[0201] According to an optional twenty-third example of the teachings disclosed herein, a method according to the nineteenth to twenty-second examples may be provided, wherein the transmission of the second transaction includes: after the first transaction is included in the blockchain, transmitting the second transaction to one or more nodes of the blockchain network.

[0202] According to an optional twenty-fourth example of the teachings disclosed herein, a method according to the nineteenth to twenty-third examples can be provided, wherein the recorded value and the first value are part of a sequence of values, and wherein each next value in the sequence is generated by applying a one-way function to the previous value in the sequence.

[0203] According to an optional twenty-fifth example of the teachings disclosed herein, a method according to a twenty-fourth example may be provided, the method comprising transferring one or more values ​​of the value sequence to a second party.

[0204] According to an optional twenty-sixth example of the teachings disclosed herein, a method according to the nineteenth to twenty-fifth examples may be provided, wherein the first transaction and the third transaction are the same transaction, and / or wherein the second transaction and the fourth transaction are the same transaction.

[0205] According to the optional twenty-seventh example of the teachings disclosed herein, a method according to the nineteenth to twenty-sixth examples may be provided, wherein the one-way function is a cryptographic hash function.

[0206] According to the twenty-eighth example of the teachings disclosed herein, a first-party computer device is provided, the computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to execute the method according to any one of the first to thirteenth examples when run on the processing means.

[0207] According to the twenty-ninth example of the teachings disclosed herein, a computer program is provided, which is contained on a computer-readable storage medium and configured to perform the method according to any one of the first to thirteenth examples when run on a first party's computer device.

[0208] According to the thirtieth example of the teachings disclosed herein, a third-party computer device is provided, the computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to execute the method according to any one of the fourteenth to eighteenth examples when run on the processing means.

[0209] According to the thirty-first example of the teachings disclosed herein, a computer program is provided, which is contained on a computer-readable storage medium and configured to perform the method according to any one of the fourteenth to eighteenth examples when run on a third-party computer device.

[0210] According to the thirty-second example of the teachings disclosed herein, a first-party computer device is provided, the computer device comprising: a memory including one or more memory cells; and a processing means including one or more processing units, wherein the memory stores code configured to run on the processing means, the code being configured to execute the method according to any one of the nineteenth to twenty-seventh examples when run on the processing means.

[0211] According to the thirty-third example of the teachings disclosed herein, a computer program is provided, which is contained on a computer-readable storage medium and configured to perform the method according to any one of the nineteenth to twenty-seventh examples when run on a first party's computer device.

[0212] Based on another example of the teachings disclosed herein, a method may be provided that includes actions by a first party, a second party, and / or a third party.

[0213] According to another example of the teachings disclosed herein, a system may be provided that includes computer devices of a first party, a second party, and / or a third party.

[0214] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.

Claims

1. A computer-implemented method of verifying a first signature of a first party for signing a first message, wherein a blockchain comprises recorded transactions, the recorded transactions comprising a registration value, the registration value being generated by applying a one-way function to a first value; The method is performed by the first party and comprises: generating the first signature by applying a one-way function to at least the first value and the first message; transmitting a first transaction to one or more nodes of a blockchain network for inclusion of the first transaction in the blockchain, the first transaction comprising the first message signed with the first signature; and transmitting a second transaction to one or more nodes of the blockchain network for inclusion of the second transaction in the blockchain, the second transaction comprising the first value.

2. The method of claim 1, wherein the first value is an updated registration value and is generated by applying a one-way function to a second value, wherein the method comprises: generating a second signature by applying a one-way function to at least the second value and a second message; transmitting a third transaction to one or more nodes of a blockchain network for inclusion of the third transaction in the blockchain, the third transaction comprising the second message signed with the second signature; and transmitting a fourth transaction to one or more nodes of the blockchain network for inclusion of the fourth transaction in the blockchain, the fourth transaction comprising the second value.

3. The method of claim 1, wherein the first signature is generated by applying a one-way function to at least: i) the first value; and ii) a result of applying a one-way function to the first message.

4. The method of claim 1, wherein the first signature is a hash-based message authentication code. The second transaction is transmitted to one or more nodes of the blockchain network after the first transaction is included in the blockchain.

5. The method of claim 1, wherein the transmission of the second transaction comprises:

6. The method of claim 1, wherein the registration value and the first value are part of a sequence of values, and wherein each next value in the sequence is generated by applying a one-way function to a previous value in the sequence.

7. The method of claim 6, comprising transmitting one or more values of the sequence of values to a second party.

8. The method of claim 2, wherein the first transaction and the third transaction are the same transaction, and / or wherein the second transaction and the fourth transaction are the same transaction.

9. The method of claim 1, wherein the one-way function is a cryptographic hash function.

10. A computer device of a first party, the computer device comprising: a memory comprising one or more memory units; and a processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when running on the processing apparatus to perform the method of any one of claims 1 to 9.

11. A computer program product comprising a computer program embodied on a computer readable storage means and configured so as when running on a computer device of a first party to perform the method of any one of claims 1 to 9. ​

Images