Method and apparatus for automatic digital certificate verification

Abstract

The public key may be recorded on the blockchain by the certificate authority in such a manner that any third party may quickly and easily verify that the public key is authenticated by the certificate authority and that authentication has not been revoked. The certificate authority may revoke authentication almost immediately, and / or may authenticate a new key for the same entity while revoking an old key. Verification may be incorporated into a new transaction such that there is no interval between dependency on the certificate and verification of validity thereof. In some cases, each transaction in which a certificate is used may also be used as an authentication transaction that updates the certificate to enable a subsequently used linked.

Description

[0001] This application is a continuation of Chinese application No. 202080082098.3 (PCT International Application No. PCT / IB2020 / 060767), filed on November 16, 2020, entitled “Method and apparatus for automated digital certificate verification”. TECHNICAL FIELD

[0002] The present disclosure relates to blockchain networks and, in particular, to facilitating digital certificate verification using blockchain. BACKGROUND

[0003] In a public key infrastructure, a computing device can have a public-private key pair to facilitate secure communications, digital signatures, non-repudiation, and other functions. As part of the public key infrastructure, a computing device can register its public key with a certification authority, which provides the computing device with a digital certificate confirming ownership and authorization of the public key.

[0004] A problem with using a certification authority is that once a digital certificate is issued by the certification authority, it is valid until its specified expiration date. However, a public key can be compromised, requiring revocation of the certification. To address this problem, the certification authority maintains a “revocation list” detailing which digital certificates should be considered revoked, and they periodically update and publish these lists. An entity wishing to verify a public key can rely on the digital certificate, but must also obtain and review the corresponding certificate revocation list to understand whether the digital certificate has been deemed invalid by the certification authority. This system and its inherent delays mean that some digital certificates can be revoked, but the revocation can not yet be published or yet available for use by an entity intending to rely on the digital certificate. BRIEF DESCRIPTION OF DRAWINGS

[0005] Reference will now be made, by way of example, to the accompanying drawings, which show example embodiments of the present application and wherein: Figure 1 An example system for managing a public key infrastructure is schematically illustrated; Figure 2 An example method for registering a public key with a certification authority is illustrated in the form of a flow diagram; Figure 3 An example method for verifying a public key is illustrated in the form of a flow diagram; Figure 4 An example method for verifying a digital certificate is illustrated in the form of a flow diagram; Figure 5 Another example method for verifying a digital certificate is illustrated in the form of a flow diagram; Figure 6 Another example method of verifying a digital certificate using a chain of authenticated transactions is illustrated in the form of a flowchart; and Figure 7 A simplified example of a node that can implement at least a portion of one of the described methods is illustrated in the form of a block diagram.

[0006] The same reference numbers are used in different drawings to represent the same elements or features. DETAILED DESCRIPTION

[0007] In one aspect, a computer-implemented method for verifying a first public key associated with a first node can be provided, the method comprising: receiving a transaction template from the first node, the transaction template containing a first input referencing a current key registration transaction output; identifying a last transaction in a chain of linked transactions based on a last transaction containing the current key registration transaction output; tracing through the chain of linked transactions to identify and obtain a key registration transaction, the key registration transaction including the first public key associated with the first node, and verifying that the key registration transaction is signed by a third party key; and propagating the transaction template on a blockchain network, wherein the propagated transaction template includes a second input transferring a resource to an output address, whereby the transaction template will be verified by nodes on the blockchain network if the current key registration transaction output is contained in an unspent transaction output set.

[0008] In some implementations, the transaction template includes an input from the first public key associated with the first node.

[0009] In some implementations, the propagating includes adding an output to a second public key associated with a second node to the transaction template prior to the propagating.

[0010] In some implementations, the transaction template includes an output to the first public key associated with the first node.

[0011] In some implementations, the propagating includes adding an input from a second public key associated with a second node to the transaction template prior to the propagating.

[0012] In some implementations, the key registration transaction output includes a pay-to-public-key output in the last transaction.

[0013] In some implementations, the key registration transaction output is one of a plurality of pay-to-public-key outputs in the last transaction, and wherein each pay-to-public-key output in the last transaction involves a different respective public key.

[0014] In some implementations, the obtaining further comprises: verifying that the key registration transaction output is a multi-signature output, allowed signers of the multi-signature output including the third party key.

[0015] In some implementations, the set of unspent transaction outputs includes all transaction outputs that have not yet been used as an input to another transaction, and wherein the set of unspent transaction outputs is maintained by the blockchain network.

[0016] In some implementations, the obtaining includes sending a request for the key registration transaction to a node in the blockchain network and receiving a response containing the key registration transaction.

[0017] In some implementations, the obtaining includes receiving, from the first node, a copy of the last transaction and a Merkle path associated with the last transaction, and wherein the method further includes verifying that the last transaction is recorded in the blockchain based on the copy of the last transaction, the Merkle path, and the set of block headers of the blockchain.

[0018] In another aspect, a computer-implemented method of managing a public key infrastructure using a blockchain network can be provided. The method can include generating a digital certificate for a first entity having a first public key by creating an attestation transaction, wherein the attestation transaction includes a digital signature from a certificate authority, a first output to an address based on a second public key, and a second output having an information field containing the first public key; determining an attestation transaction identifier from a hash of the attestation transaction; and propagating the attestation transaction on the blockchain network. The digital certificate includes the first public key and the attestation transaction identifier.

[0019] In some implementations, the second output includes an OP_RETURN field containing at least the first public key. In some implementations, the first output includes a pay-to-public-key-hash (P2PKH) operation referencing an address obtained as a hash of the second public key. In some implementations, the certificate authority holds a second private key corresponding to the second public key.

[0020] In some implementations, the method can further include verifying the digital certificate. Verifying the digital certificate can include obtaining a copy of the attestation transaction from the blockchain based on the attestation transaction identifier in the digital certificate; determining that the first output is an unspent transaction output; and determining that the first public key contained in the second output of the attestation transaction matches the public key in the digital certificate. In some such implementations, determining that the first output is an unspent transaction output includes determining that the first output exists in a pool of unspent transaction outputs of the blockchain network. In some such implementations, the input of the attestation transaction can further include a certificate authority public key, and wherein verifying the digital certificate can further include determining that the attestation transaction is signed by the certificate authority based on the certificate authority public key.

[0021] In some implementations, the method may further include: revoking a digital certificate by generating a revocation transaction and propagating the revocation transaction on a blockchain network, the revocation transaction including a first output of an authentication transaction as input.

[0022] In some implementations, the method may further include: replacing the digital certificate with a new digital certificate using the new public key. This replacement may include: creating a new authentication transaction, wherein the new authentication transaction includes a first output of the authentication transaction as input, a first new output to a new address based on a third public key, and a second new output having an information field containing the new public key; determining a new authentication transaction identifier by hashing the new authentication transaction; and propagating the new authentication transaction on the blockchain network. The new digital certificate may include the new public key and the new authentication transaction identifier.

[0023] In some implementations, the information field is the OP_RETURN output.

[0024] In some implementations, the authentication transaction includes input referencing an unspent transaction output address obtained from a hash of the certificate authority's public key, and wherein the authentication transaction includes an unlocking script for the unspent transaction output address, the unlocking script including the certificate authority's public key and a digital signature, and wherein the digital signature is generated based on a private key corresponding to the certificate authority's public key.

[0025] In some implementations, the first output includes a multi-signature locking script that enables any of two or more private keys to utilize the first output.

[0026] On the other hand, this application describes a computer-implemented method for verifying digital certificates using a blockchain network. The digital certificate includes a first public key and an authentication transaction identifier. The method may include: receiving the digital certificate from a first entity and obtaining a copy of the authentication transaction from the blockchain based on the authentication transaction identifier in the digital certificate, wherein the authentication transaction includes a digital signature from a certificate authority, a first output to an address based on a second public key, and a second output having an information field. The method may further include: determining that the information field contains a public key matching the first public key in the digital certificate; querying a pool of unspent transaction outputs to determine that the first output in the authentication transaction has not yet been used for any subsequent transactions; and based on these determinations, verifying that the first public key is validly authenticated.

[0027] In another aspect, this application describes a computer-implemented method for verifying a certificate associated with a first node. The method may include: receiving a transaction template from the first node, the transaction template containing a first input referencing an authenticated transaction output and signed by an authenticated transaction key; obtaining a copy of the authenticated transaction and determining that the authenticated transaction includes a certificate associated with the first node and that the authenticated transaction was signed by an authentication authority key; and propagating the transaction template on a blockchain network, wherein the propagated transaction template includes a second input transferring resources to an output address. If the authenticated transaction output is included in the set of unspent transaction outputs, the transaction template will be verified by nodes on the blockchain network.

[0028] In some implementations, the transaction template includes input from a first public key associated with the first node, and the certificate includes the first public key. In some cases, propagation includes adding an output to the transaction template containing a second public key associated with the second node before propagation.

[0029] In some implementations, the transaction template includes an output to a first public key associated with the first node, and the certificate includes the first public key. In some cases, propagation includes adding an input from a second public key associated with the second node to the transaction template prior to propagation.

[0030] In some implementations, the authentication transaction output includes the payment-to-public-key output within the authentication transaction. In other cases, the authentication transaction output is one of multiple payment-to-public-key outputs within the authentication transaction, and each payment-to-public-key output in the authentication transaction involves a different corresponding public key.

[0031] In some implementations, obtaining the authentication transaction involves identifying the last transaction in a series of linked transactions based on the last transaction containing the authentication transaction output, and tracing through this series of linked transactions to identify the authentication transaction. In some cases, obtaining the authentication transaction output also includes verifying that it is a multi-signature output, wherein the permitted signer of the multi-signature output includes a certified authority key.

[0032] In some implementations, the unspent transaction output set includes all transaction outputs that have not yet been used as inputs to other transactions, and the unspent transaction output set is maintained by the blockchain network.

[0033] In some implementations, the authentication transaction output is in a transaction with a transaction identifier, wherein the first input in the transaction template references the transaction identifier, and wherein the authentication transaction key is a private key associated with the transaction identifier and the index.

[0034] In some implementations, obtaining involves sending a request for authentication of a transaction to a node in the blockchain network and receiving a response containing the authentication transaction.

[0035] In some implementations, obtaining includes receiving a copy of the authentication transaction and the Merkle path associated with the authentication transaction from the first node, and the method further includes verifying the existence of the authentication transaction in the blockchain based on a set of the copy of the authentication transaction, the Merkle path, and the block header of the blockchain.

[0036] On the other hand, a computing device for implementing nodes in a network can be provided. This computing device may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processor to perform one or more of the methods described herein.

[0037] In another aspect, a computer-readable medium may be provided storing processor-executable instructions for operating nodes in a network, the processor-executable instructions including, when executed by one or more processors, causing the processors to perform at least one method described herein.

[0038] Other exemplary embodiments of this disclosure will be apparent to those skilled in the art upon review of the following detailed description in conjunction with the accompanying drawings.

[0039] In this application, the term "and / or" is intended to cover all possible combinations and sub-combinations of the listed elements, including any one, any sub-combination, or all of the elements listed individually, and does not necessarily exclude additional elements.

[0040] In this application, the phrase “...or at least one of ...” is intended to cover any one or more of the listed elements, including any one of the individually listed elements, any sub-combination, or all elements, without excluding any additional elements or requiring all elements.

[0041] This application relates to hashing or hash functions, and aims to include any of a plurality of cryptographic hash functions that, when applied to any set of data or “messages,” deterministically produce a unique, fixed-length alphanumeric string. The result of a hash function may be referred to as a hash value, fingerprint, hash result, or equivalent. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0042] In this document, the term "blockchain" is understood to include all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. It should be noted that this invention is not limited to use with a specific blockchain, and alternative blockchain implementations and protocols fall within the scope of this invention.

[0043] A blockchain is a peer-to-peer electronic ledger implemented using a computer-based, decentralized, distributed system. A blockchain consists of blocks, and blocks are composed of transactions. Each transaction is a data structure that, among other possible information, encodes the transfer of control of digital assets among participants in the blockchain system and includes at least one input and at least one output. Each block header contains a summary of the block's content, for example, in Merklegen form, and each block header contains a hash of the previous block header, allowing blocks to be chained together to create a permanent, immutable record of all transactions written to the blockchain from their inception. Transactions contain applets called scripts embedded in their inputs and outputs, specifying how and by whom the transaction's output can be accessed. On some platforms, these scripts are written using stack-based scripting languages.

[0044] Blockchain is implemented on a network of nodes. Each node is a computing device with network connectivity and executing software that implements the applicable blockchain protocol. Nodes verify transactions and propagate them to other nodes in the network. Specialized network nodes (called "mining nodes") collect a set of unconfirmed transactions (i.e., pending transactions) into a block and attempt to "mine" that block. In these examples, mining refers to solving a Proof-of-Work (PoW) before any other mining node in the network successfully solves it for its corresponding block. In some examples, PoW involves hashing a block header containing a nonce until the result is less than a threshold set by a difficulty parameter. The nonce is repeatedly incremented and the hashing process is repeated until the result is less than the threshold or until the mining node receives notification that another mining node has succeeded. Variations in the mining process are familiar to those skilled in the art.

[0045] Among the various things checked during transaction verification, nodes determine whether the transaction's inputs are valid. Specifically, nodes evaluate whether the unlock script evaluates to true and determine if the input references an "unspent transaction output" (UTXO) from an earlier transaction. Some nodes may maintain a running list or pool of UTXOs to quickly determine if a referenced transaction output is in a UTXO. This list or pool of UTXOs can be referred to as the "set of unspent transaction outputs." The blockchain network is configured to update and maintain this set of unspent transaction outputs to prevent double-spending attacks. Transactions can be identified by their unique transaction identifier (TxID), which in some implementations is a hash of the transaction. Some transactions may have more than one output, so a unique transaction output (i.e., an output point) can be identified by its TxID and an index pointing to one of the outputs from the transaction's ordered set of outputs. If a transaction output exists in a UTXO pool or set, then that transaction's output is "unspent" and can be used as input.

[0046] The unlocking script for a transaction output defines how "control" over that output can be proven for its use. In many cases, the address associated with the transaction output is a hash of the public key. To prove control over the output, the unlocking script typically requires the public key and a digital signature generated using the corresponding private key. In this way, the node controlling the private key can control when and how the transaction output is used in any subsequent input. As will be discussed further below, this leads to the conclusion that when a transaction input corresponding to a particular public key includes a digital signature generated using the corresponding private key, the entity associated with that particular public key has effectively signed or authenticated the transaction content.

[0047] Public-key cryptography has become ubiquitous in online communication. In many cases, processes and policies are needed to provide certainty that a public key is owned by an entity associated with a particular entity. The most common method to ensure that a public key is authentic and not compromised is Public Key Infrastructure (PKI). PKI relies on trusted third parties to “verify” the validity of a public key. These entities are “Certificate Authorities” (CAs). CAs provide the registration and issuance of digital certificates that confirm the binding between a public key and a specific owner. The holder of the public key provides its public key and its digital certificate to another entity. The other entity can then verify the authenticity of the public key by confirming that a trusted CA has digitally signed the public key belonging to the holder.

[0048] One problem with existing PKI systems is that public keys can sometimes be compromised, for example, if the private key is lost or made public before the certificate's specified expiry date. For this reason, CAs maintain a certificate revocation list. Any entity that wants to rely on a certificate associated with a public key must also find out and check the associated certificate revocation list to confirm that the certificate has not been revoked by the CA. This compromises the ability to authenticate keys offline and creates risks due to the delay between revocation and the publication of a new certificate revocation list (typically 24 hours or longer).

[0049] According to one aspect of this application, a blockchain network can be used to improve public key infrastructure by providing fast and secure verification, revocation, and renewal of digital certificates. Public keys can be recorded on the blockchain by a certificate authority, in such a way that any third party can quickly and easily verify that the public key was certified by the certificate authority and that the certification has not been revoked. By recording public keys in a manner that allows the certificate authority to revoke certification almost instantly, or to certify a new key for the same entity while revoking an old key, can this ability to revoke certification be granted in some cases to the owner of the public key, or in others to one or even a group of other entities.

[0050] Now refer to Figure 1 The diagram schematically illustrates an example system 100 for managing public key infrastructure. This example system 100 includes a first computing device 102, a second computing device 104, and a server 106. The first computing device 102 and the second computing device 104 can be implemented using any network-enabled computing device, including servers, personal computers, tablets, smartphones, connected cars, Internet of Things devices, or any other such device. The server 106 is operated by a Certificate Authority (CA) and is configured to receive and respond to requests for digital certificates. Although the CA is depicted as being implemented by server 106, it should be understood that CA functionality can be implemented by one or more servers or other computing devices.

[0051] System 100 also includes a blockchain network 108. Blockchain network 108 comprises a network of nodes operating according to an applicable blockchain protocol. In some implementations, one or more of the first computing device 100, the second computing device 104, and / or the server 106 may also be nodes in blockchain network 108, although in this example they are depicted as nodes separate from blockchain network 108 for ease of explanation.

[0052] In this example system 100, a first computing device 102, labeled "Alice," has a public-private key pair for use in asymmetric encrypted communication. To use the public key in certain encryption scenarios, Alice may need a corresponding digital certificate that authenticates the public key and its association with Alice. Therefore, in operation 110, Alice sets the public key PK... A The public key is provided to the CA, which then submits a registration request. The CA can perform some level of authentication to ensure Alice's identity as the owner of the public key. In some cases, this authentication can be an automated online operation performed by server 106 based on the data provided in operation 110. In some cases, the authentication may also include, or alternatively include, offline authentication operations. Two-factor authentication and other such techniques can be employed.

[0053] Once the CA determines the public key PK A Once authenticated, it generates a blockchain transaction, known as a "Certified Transaction" (CTX), which includes the public key PK. A The transaction is then signed by the CA. The authentication transaction also includes outputs controlled by the CA. As shown in operation 112, the transaction is submitted to blockchain network 108. The CA then provides Alice with the authentication transaction identifier TxID in operation 114. CTX_PKA In some implementations, Alice can obtain a copy of the certified transaction from blockchain network 108 based on the transaction identifier to confirm that it conforms to expectations and contains the public key PK. A .

[0054] Transaction Identifier (TxID) CTX_PKA PK with public key A Together, Alice's digital certificate is effectively formed. Combined with certain communications with the second communication device 104 (labeled "Bob" in this example), Alice can send her digital certificate to Bob in operation 116. Bob is then able to authenticate the public key PK. A The authentication was verified as not to have been revoked based on a blockchain maintained by blockchain network 108.

[0055] Specifically, in operations 118 and 120, Bob can request and receive a copy of the authentication transaction. Based on this authentication transaction, Bob can verify that it contains the public key PK claimed by Alice. A Furthermore, it has been signed by a trusted certification authority. Bob can also verify that the certification has not been revoked by querying whether the transaction output controlled by the CA remains "unspent," i.e., whether the transaction output point exists in the UTXO pool 130 of blockchain network 108, as shown in operations 122 and 124. UTXO pool 130 is a pool of "unspent" transaction output points maintained by any one of the multiple nodes of blockchain network 108.

[0056] Now refer to Figure 2 The diagram illustrates, in flowchart form, an example method 200 for registering a public key with a certification authority. This example method 200 is implemented by an authorized certification authority and can be implemented by one or more servers appropriately programmed to perform the described functions.

[0057] In Operation 202, the Certification Authority receives a public key PK from Alice. A A request for authentication is made. The Certification Authority (CA) may execute authentication or authorization protocols according to its applicable policies. These protocols may include automated, computer-implemented operations and / or administrator-facilitated operations. Regardless of the specific authentication operation, it is determined in operation 204 whether it is an Alice authentication public key. If it is not an Alice authentication public key, method 200 ends. If authentication is to be granted, in operation 206, the CA creates an authentication transaction. As described above, the authentication transaction includes inputs including the CA's public key and a digital signature from the CA, outputs controlled by the CA, and the public key PK. A To give a concrete example, the input can be a UTXO with a nominal or arbitrary value, and the certification authority has a private key for that UTXO to generate a signature in a valid unlocking script. The UTXO may be associated with enough digital values ​​to offset any transaction fees that should be paid for mining the certification transaction.

[0058] Authentication transactions can include two outputs: a public key PK based on a CA selected and controlled by the authentication authority. CTX_PKA The first output and the public key PK contained in, for example, a non-operation information field. A The second output. An example of the second output is the OP_RETURN function. OP_RETURN is actually an output that, once a transaction is mined, can be filled with arbitrary data to be recorded on the blockchain.

[0059] For example, the first output could be a P2PKH (Pay to Public Key Hash) operation, which specifies a transfer to a public key hash (e.g., an address) chosen and controlled by an authorized authority.

[0060] The certification authority, through its digital signature in the transaction, authorizes the input of the UTXO to the transaction to satisfy the unlocking script, and also provides the public key PK that the certification authority has certified and that appears in the OP_RETURN output. A Verifiable evidence. Note that in some implementations, additional information (e.g., Alice's digital signature or other such data) may appear in the OP_RETURN output field.

[0061] Once the authentication transaction has been created, the authentication authority hashes the transaction in Operation 208 to find the transaction identifier TxID. CTX_PKA And as shown in Operation 210, the transaction is propagated on the blockchain network. It should be understood that "propagating" a transaction involves submitting it to a node in the blockchain network, where the transaction is verified and then transmitted to all other nodes, which in turn verify and transmit the transaction again, until the transaction has reached almost all nodes in the network. In some embodiments, the certification authority itself is one of the nodes in the blockchain network.

[0062] In operation 212, the certification authority waits to mine the block containing the certified transaction, i.e., the "confirmation" of the transaction, and then in operation 214, the transaction identifier TxID is... CTX_PKA Send it to Alice. In some implementations, the authenticating authority can provide Alice with a transaction identifier before the transaction is mined.

[0063] Then, Alice can provide any third party with Alice's public key PK. A and Authentication Transaction Identifier (TxID) CTX_PKA The digital certificate. Therefore, a third party can verify that Alice's public key is certified by the CA.

[0064] A simplified example of a certified transaction is shown below:

[0065] It should be noted that the input unlock script includes the public key of the authentication authority and the signature generated by the authentication authority. Alice's public key PK A The first output appears as the second output in the OP_RETURN field. The first output is any public key hash controlled by the certification authority.

[0066] Now for reference Figure 3 This illustrates an example method 300 for verifying a public key. The operations described in example method 300 can be performed by a computing device that attempts to... Figure 2 The example illustrates the process of verifying a public key that is claimed to be authenticated. The example computing device includes any network-enabled computing device.

[0067] Method 300 includes, in operation 302, receiving another entity (e.g., a first computing device 102 labeled "Alice"). Figure 1 A digital certificate must include at least a public key (PK). A and Authentication Transaction Identifier (TxID) CTX_PKAIn Operation 304, a certified transaction is obtained from the blockchain network using a certified transaction identifier. It should be understood that a certified transaction can be obtained from a copy of the blockchain, whether that copy is local to the computing device or maintained by nodes in the blockchain network. In the unlikely event that a transaction has not yet been confirmed (i.e., not yet in a mined block), the transaction may exist in a mempool of unconfirmed transactions; however, in many implementations, the certification authority may only provide the certified transaction identifier to Alice after the certified transaction has been mined.

[0068] A computing device can verify certain things based on an authentication transaction. Specifically, in Operation 306, the computing device can verify that the authentication transaction was signed by an authentication authority. The computing device may have or be authorized to access a list of recognized or qualified authentication authorities and their corresponding public keys, which enables the computing device to verify digital signatures. As described, a digital signature can form part of the input of an authentication transaction. By confirming that the authentication transaction was signed by a trusted or recognized authentication authority, the computing device can confirm that the authentication is legitimate. Note that if the transaction is on a blockchain, the computing device does not necessarily need to verify the digital signature in the input, because the transaction has already been confirmed and verified by dedicated network nodes (mining nodes). Instead, the computing device can simply verify that the public key identified in the input is associated with an authentication authority.

[0069] The computing device can also verify that one of the output points of the authentication transaction is still "unspent," that is, that the output point is found in the UTXO pool, as shown in operation 308. This verification operation confirms that the authentication is still valid and has not been revoked. As mentioned above, in most embodiments, the output point is controlled by the authentication authority (alternatives are described below), which allows the authentication authority to cancel authentication if the key is compromised, expired, or otherwise no longer valid. By having the authentication authority "spend" the output point, thereby removing the output point from the UTXO pool, revocation or cancellation is facilitated easily. Confirmation of the output point's existence in the UTXO pool can be performed, for example, by querying the UTXO pool based on the TxID number and the output index. In some examples, the computing device can query the UTXO pool through an intermediary such as a node in a blockchain network.

[0070] In operation 310, the computing device confirms the public key PK in the second output of the authentication transaction. A PK with the public key received as part of Alice's digital certificate A match.

[0071] If operations 306, 308, and 310 are all confirmed, then in operation 312, the computing device determines the public key PK from the digital certificate received from Alice. A It is effective.

[0072] By using a blockchain network to record public key authentication, a certification authority can quickly and easily revoke authentication by "spending" an output point, causing the verification at operation 308 to fail. Therefore, a certification authority can revoke authentication of a public key by generating and propagating a transaction that uses the first output of the authentication transaction. As discussed above, the first output can be a P2PKH operation that transfers the nominal digital asset to the public key hash address specified in the first output. In these examples, the unlocking script for this first output may require a digital signature from the certification authority, which needs to be consistent with the CA public key PK used in the P2PKH operation. CTX_PKA Control is achieved using the corresponding private key.

[0073] In some cases, a certification authority may not simply revoke certification, but may instead be required to replace / update the certified public key. For example, if the private key is lost or compromised, the owner (e.g., Alice) can request the certification authority to PK with the new public key. A_new Update or replace the previously authenticated public key. The Certification Authority (CA) authenticates the request using any online or offline authentication mechanism. If the CA determines that an update operation is necessary, it will create a new Certification Transaction (CTX). new To revoke the old certification and issue a new one.

[0074] The new authentication transactions are characterized by having the same type of output, that is, using a new public key chosen by the CA (e.g., PK). CTX_new P2PKH operations and those containing PK A_new The OP_RETURN field. However, the input can include the TxID from the original certified transaction. CTX_PKA The CA-controlled output point. Revocation is achieved by removing the output point from the UXTO pool, using it as the input "spend" for a new authentication transaction. Advantageously, the revocation of the old public key authentication and the registration of the new public key authentication occur in a single transaction. Furthermore, the Certification Authority does not need to maintain or make available a separate, periodically published list of revocation certificates.

[0075] As mentioned above, in many cases, the first output point of an authentication transaction can be controlled by the authentication authority, allowing only the authentication authority to revoke the authentication of the public key. Revocation is based on "spending" the first output point using the private key corresponding to that output point. However, in some situations, it may be advantageous to construct authentication transactions to allow other entities to revoke authentication.

[0076] For example, in some cases, the owner of the public key (e.g., Alice) may have the right to revoke their own public key. In this arrangement, the first output point in the authentication transaction is controlled by Alice, i.e., referencing Alice's public key (public key hash) with its corresponding private key. That is, the unlocking script for the first output point requires a digital signature from Alice. This arrangement may be advantageous for certain public key authentication scenarios (e.g., registering with an online service). An example of an online service is a social media account on a social media platform. The platform can use the above mechanism to register users' public keys for its own use, enabling users to interact with the platform and / or other users on a trusted basis, as their digital certificates are backed by authentication transactions. Users can then revoke authentication without the platform's cooperation, thereby terminating their accounts.

[0077] In another scenario, more than one output point can be provided, any one of which can be "spent" to terminate authentication. In this scenario, a third party is configured to test whether two (or all) of these output points of the authentication transaction exist in the UTXO pool as unspent transaction outputs.

[0078] Alternatively, if the goal is to facilitate revocation from any of the multiple parties, the first output can be configured to use multiple signatures, i.e., where any one of the multiple signatures can be used to "spend" the output. For this purpose, multi-signatures can be used in the output.

[0079] In another scenario, multisignature can be configured to ensure that at least a threshold number of entities agree to revoke authentication. Multisignature can be configured to require n out of m signatures to unlock the output, where n ≤ m. For example, in the case of an organization (e.g., a business, partnership, or other collection of such entities), the authenticated public key associated with the organization can only be revoked if all or at least a threshold number of certain entities (e.g., the CEO, COO, CTO, or other executives or individuals involved in the business) sign off on the revocation.

[0080] It should be understood that some or all of the operations described above in the various example methods may be performed in a different order than those shown and / or may be performed simultaneously without changing the overall operation of these methods.

[0081] Automated authentication verification The methods described above provide mechanisms for issuing digital certificates guaranteed by a blockchain network. These mechanisms enable rapid verification of the validity of digital certificates and allow for near-instantaneous revocation of digital certificates. As mentioned above, to verify the validity of a digital certificate, the node attempting to verify the certificate checks whether the origin of the authentication transaction is in the UTXO set and whether the public key in the digital certificate being verified matches the public key in the OP_RETURN field of the authentication transaction.

[0082] A potential drawback of the described method is that there may be a time delay between the verification of a digital certificate and any subsequent transactions that rely on that verification. During this interval, the digital certificate may be revoked for some reason. Furthermore, the verification of a digital certificate relies on accessing and inspecting the UXTO set, which may be difficult or impossible for some nodes (e.g., Lightweight Simplified Payment Verification (SPV) nodes, such as digital wallets). This may require these nodes to rely on third-party nodes for verification, which raises security and reliability issues. Additionally, nodes whose verification origins are in the UXTO set must be online and have active access to the blockchain network, which many nodes (e.g., Lightweight SPVs) may not be at certain times.

[0083] According to another aspect of this application, digital certificate verification can be incorporated into transactions, ensuring that transactions only proceed if the digital certificate is valid. This enables lightweight SPVs and similar nodes to collaborate with other nodes to generate transactions that incorporate automatic digital certificate verification. Advantageously, this eliminates the time interval between digital certificate verification and the reliance on that verification when submitting a transaction.

[0084] In some of the examples below, a node can have its public key authenticated by a certification authority node in the form of an authentication transaction, which can take the form shown in this example:

[0085] The example above shows the public key PK of authentication node A. A The authentication transaction. Note that the OP_RETURN output contains the public key PK. A The certificate. In some examples, this can simply be the public key itself. In some cases, it can be a hash of the public key. In some cases, additional data can be included along with the public key from the certificate, which is included in the OP_RETURN output.

[0086] It should also be noted that the input is a transaction output controlled by an authorized authority, and its unlocking script is signed by the authorized authority. The output is the certified transaction public key. Payments are made via a public key hash (P2PKH). The public key... It possesses a corresponding private key. In some cases, the private key can be generated by the certification authority when creating the certification transaction. The certification authority can share the private key with node A. That is, when node A requests certification of its public key PK... A At that time, the certification authority can return the transaction identifier of the certification transaction. And the private key that enables the authentication of transactions.

[0087] This type of certificate can be invalidated or revoked using the exit point in a subsequent transaction, which involves using the public key of the authentication transaction. The signature of the corresponding private key. In this example, both the authentication authority node and node A possess this key.

[0088] As mentioned above, authentication transactions can be used to automate the verification of digital certificates. Specifically, automation lies in checking the UXTO set. For example, a new transaction (such as a payment transaction) includes the existence of the authentication transaction's origin in the UXTO set as a prerequisite. This ensures that the new transaction is only valid while the certificate is still valid and has not been revoked.

[0089] Typically, a node with a digital certificate authenticating its public key (e.g., Alice) generates a transaction template that includes the certificate's output as input. The input is signed with an authentication transaction key (e.g., using the private key corresponding to the P2PKH output of the authentication transaction). This transaction template is provided to another node participating in the transaction (e.g., Bob). The other node (i.e., Bob) obtains the authentication transaction based on the reference to the authentication transaction's TXID in the transaction template's input, verifying the claimed public key PK. A In essence, the transaction template is completed by adding any inputs / outputs to the certified transaction key. The transaction template can then be propagated on the blockchain network. If an input signed by the certified transaction key fails because the output has already been used in another transaction (i.e., the output is not in the UTXO set), the entire transaction fails and will not be propagated or mined. If the input signed by the certified transaction key is valid because it is in the UTXO set, the transaction will be verified, propagated, and added to the mempool, eventually making it into the mined block.

[0090] In one example, this mechanism can be used to verify the recipient's address. For instance, if Alice requests digital assets or some other transfer from Bob, Bob might want to verify Alice's identity, for example, verifying that her claimed public key is authenticated before submitting to such a transaction. In this case, Alice can prepare a transaction template that includes a payment for her public key, with inputs for an authenticated transaction referencing that public key. Upon receiving the transaction template, Bob can retrieve the authenticated transaction from the blockchain, verify that it authenticates Alice's public key, and confirm that the authenticated transaction was digitally signed by an authorized authority. Bob can then add the inputs to the transaction template for transferring digital assets, and the transaction template can then be propagated on the blockchain. If Alice's digital certificate remains valid—that is, it has not been revoked—the transaction will proceed. An example of such a transaction is as follows:

[0091] In the example transaction above, the fact that Bob can rely on is if from If the outgoing point of the reference is not in the UXTO set as an unspent transaction output, the transaction will be rejected as invalid.

[0092] In another example, this mechanism could be used to verify the sender's address to comply with Know Your Customer (KYC) requirements. For instance, Alice might be transferring assets to Bob, and Bob wants to verify Alice's identity before accepting the transfer. In this case, Alice prepares a transaction template that includes the transfer of digital assets and a PK check using Alice's public key. A The associated inputs. The transaction template also includes an authentication transaction that authenticates the public key as input. Upon receiving the transaction template, Bob can obtain the authentication transaction, verify that it was signed by an authorized authority, and verify that it authenticates Alice's public key. If so, Bob completes the transaction template by adding outputs to transfer the digital assets to a public key address controlled by Bob. Such an example transaction could take the following form:

[0093] It should be understood that in each of the two detailed examples above, the digital certificate becomes invalid as soon as it is used in the transaction to prove the validity of the public key. That is, a certificate can only be used once and is automatically revoked once used. This can be applied in certain situations, such as transferring a large amount of assets to or from a verified address in a single transaction. Such transactions can be used for car sales, real estate transactions, stock sales, or other high-value transfers of equipment. However, for small, everyday transactions, returning to the certification authority to obtain a new certificate every time it is used can be cumbersome. Therefore, reusable certificates can be constructed, as described below.

[0094] First, refer to Figure 4 The diagram illustrates an example method 400 for verifying a certificate associated with a first node. This method can be implemented by a computing device such as a mobile phone, tablet, or personal computer. The computing device includes one or more processor units and associated memory storing computer-executable instructions that, when executed by the processing unit, cause the processing unit to perform the described operations. In some cases, the computer-executable instructions may be stored in the form of an application (e.g., a wallet application).

[0095] Method 400 provides an example of automated certificate verification for authenticating the recipient's identity. In this example transaction, node A is the recipient and node B is the sender. The nodes can communicate via wired and / or wireless networks. In some cases, nodes may communicate using near-field communication, for example, via a point-of-sale terminal. Method 400 begins in operation 402 with node A creating a transaction template. This transaction template includes inputs referencing the identity from authenticating node A (e.g., authenticating node A's public key PK). A The output of the authentication transaction is the payment to the public key operation, which references the authentication transaction public key. The corresponding private key can be called the authentication transaction key. The input to the transaction template is used to generate a signature using the authentication transaction key. The transaction template also includes the public key (PK) for transferring resources to node A. A The output.

[0096] As shown in operation 404, node A sends the transaction template to node B. The transaction template does not yet contain input from node B and / or if it does contain input, it is not signed by node B.

[0097] Upon receiving the transaction template, in operation 406, Node B identifies the certified transaction based on the reference to the certified transaction in the transaction template input. Because this reference includes the transaction identifier of the certified transaction, Node B is able to retrieve a copy of the certified transaction. If Node B stores a local copy of the blockchain, it can obtain the certified transaction by searching within that local copy. If not, Node B can send a query or request to the blockchain node based on the transaction identifier to obtain a copy of the certified transaction. In some cases, this verification can be accomplished as proof of the existence of the certified transaction. That is, if a copy of the certified transaction and a Merkel proof (Merkel path) are provided to Node B, it can verify the existence of the certified transaction in the blockchain based on the block header. SPV nodes or other lightweight implementations may have copies of their available block headers, even offline, which allows Node B to verify the existence and content of the certified transaction without necessarily needing real-time access to the blockchain network. Therefore, Node A can provide Node B with a copy of the certified transaction, its Merkel path, and the transaction template.

[0098] Once node B has a copy of the certified transaction, in operation 408, it verifies that the certified transaction was signed by a certification authority using its key. It also verifies node A's public key PK. A This appears in the OP_RETURN output field of the authentication transaction, confirming that the authentication authority has verified the authenticity of Node A's public key. Node B can also verify the structure of the authentication transaction, specifically its payment to public key output, which references the authentication transaction's public key. And it should be consistent with the input in the transaction template.

[0099] It should be understood that if these checks fail—for example, if node A's public key cannot be verified as authenticated, or if the authentication transaction is not constructed as expected—method 400 will terminate because node B will not complete the transaction. However, assuming node B verifies that the authentication transaction is valid, then in operation 410, it modifies the transaction template to add input from an address controlled by node B. That is, node B adds resource input to the transaction template and signs the input. This completes the transaction template, which node B can then propagate on the blockchain network. Alternatively, node B can send the completed transaction template to node A, which can then propagate it on the blockchain network.

[0100] In any given situation, one of two scenarios will occur, as shown in operation 412. If... If the certified transaction output is included in the UTXO set, meaning it is an unspent output, then the transaction will be verified by nodes in the blockchain network, propagated throughout the network, and added to the mempool of unconfirmed transactions for mining and inclusion in a block, as shown in Operation 414. However, if... If the certified transaction output is not in the UTXO set, for example because the certificate has already been used or revoked, the transaction will not be verified, will not be propagated, and will be rejected by the blockchain network, as shown in Operation 416. Thus, a transaction between node A and node B only occurs if node A's certificate is valid when the transaction is submitted to the blockchain network. Therefore, there is no time interval between verifying the certificate and relying on that verification when entering a transaction.

[0101] Now refer to Figure 5 It illustrates another example method 500 for automatically verifying digital certificates in the form of a flowchart. Figure 4 Same, Figure 5 The method 500 shown can be executed by a computing device that implements a first node (node ​​A) and a second node (node ​​B). In the example of method 500, a transaction is generated to transfer resources from node A to node B. For example, node B attempts to verify the identity of node A before accepting the resource transfer, such as as part of a "Know Your Customer" or anti-fraud record keeping requirement.

[0102] In Operation 502, Node A creates a transaction template and includes inputs that reference the authentication transaction output of the authentication transaction from the public key of Authentication Node A. The inputs are signed by Node A using the authentication transaction key, which corresponds to the authentication transaction public key referenced in the authentication transaction output. Node A also adds its authenticated public key PK. A Input for transferring resources. In operation 504, node A sends the transaction template to node B.

[0103] In Operation 506, Node B retrieves a copy of the certified transaction from the blockchain, regardless of whether it is stored locally or remotely. The certified transaction is identified by the transaction identifier referenced in the transaction template input.

[0104] In Operation 508, Node B verifies that the authentication transaction was signed by the Certification Authority using its key. It also verifies Node A's public key (PK). A This appears in the OP_RETURN output field of the authentication transaction, confirming that the authentication authority has authenticated the authenticity of Node A's public key. Node B can also verify the structure of the authentication transaction, specifically verifying that it includes a payment to the public key output, which references the authentication transaction's public key. And it should be consistent with the input in the transaction template.

[0105] It should be understood that if these checks fail—for example, if node A's public key cannot be verified as authenticated, or if the authentication transaction is not constructed as expected—method 500 will terminate because node B will not complete the transaction. However, assuming node B verifies that the authentication transaction is valid, then in operation 510, it can modify the transaction template to add the output to an address controlled by node B. In some cases, node A may have already added the output to transfer resources to node B; in this case, node B only needs to verify that the output is correct in operation 510. This completes the transaction template, which node B can then propagate on the blockchain network. Alternatively, node B can send the completed transaction template to node A, which can then propagate it on the blockchain network.

[0106] After a transaction is sent to a node in the blockchain network, one of two scenarios will occur, as shown in operation 512. If the transaction is sent to... If the certified transaction output is included in the UTXO set, meaning it is an unspent output, then the transaction will be verified by nodes in the blockchain network, propagated throughout the network, and added to the mempool of unconfirmed transactions for mining and inclusion in a block, as shown in Operation 514. However, if... If the certified transaction output is not in the UTXO set, for example because the certificate has already been used or revoked, the transaction will not be verified, will not be propagated, and will be rejected by the blockchain network, as shown in Operation 516. Thus, a transaction between node A and node B only occurs if node A's certificate is valid when the transaction is submitted to the blockchain network. Therefore, there is no time interval between verifying the certificate and relying on that verification when entering a transaction.

[0107] Multiple use certificate As mentioned earlier, in the examples discussed above, it was assumed that once a digital certificate was used in a transaction to prove the validity of the public key, the digital certificate became invalid because the authentication transaction output would be "costed." That is, a certificate can only be used once and is automatically revoked once used. In some cases, it might be desirable to have certificates that can be used multiple times without requiring nodes to obtain a new certificate from a certification authority after each use.

[0108] In one example, a multi-use certificate can be created by providing multiple authentication transaction outputs to the authentication transaction. The authentication transaction can be constructed to provide m possible uses. Each output can be used once in the authentication operation. Once each output has been "spent," it is no longer available. An example of such an authentication transaction is provided below:

[0109] Public Key The keys can be the same public key, completely independent public keys, or provably linked public keys. When node A uses the authentication transaction in the transaction template, such as in the example above, node A ensures that the authentication transaction output referenced as an outgoing point in the transaction template is one of the m outputs that has not yet been used.

[0110] Node A can revoke its own certificate by submitting a transaction for all remaining unspent transaction outputs of the certificate. A Certification Authority (CA) can also do this to revoke a certificate; however, if a CA cannot reliably know which outputs in the certification transactions have been spent, it will submit a separate transaction for each output to ensure certificate revocation.

[0111] The advantage of the reusable certificate in the above example is that it can be used by node A up to m times; however, after all outputs have been exhausted, node A must obtain a new certificate from the certification authority. In another example, an authentication verification process can be constructed such that each verification also generates a new output linking to the authentication transaction, thereby establishing a transaction chain tracing back to the original authentication transaction.

[0112] In one example implementation, if the certification authority does not need the ability to revoke a certificate, the certificate of the form described above can be used. Each time node A uses the certificate in a transaction, it ensures that the transaction generates a new pay-to-public-key output, and then uses this new pay-to-public-key output as the certified transaction output in any subsequent transaction using its certificate.

[0113] In another example implementation, a multi-signature output is used to ensure that the Certification Authority (CA) can revoke certificates, certified transactions, and every subsequent transaction in the chain. The multi-signature output allows for a 1-of-2 signature to unlock the output, and it includes the public keys of both the Certification Authority and Node A. An illustrative example is shown below:

[0114] It should be understood that, with the public key of the authentication transaction The holder of the corresponding authentication transaction key can use the output to verify or revoke the transaction. This key is held by node A. It should also be understood that the authentication authority has the ability to revoke the key because it has a key that is compared to its public key. CA The corresponding private key.

[0115] To use the certificate, node A creates a transaction template that includes a binary multi-signature output referencing a certification authority and a new authentication transaction key. In this way, a transaction using a certified transaction becomes the next transaction in the chain that links back to the certified transaction.

[0116] As an example, consider a transaction between node A and node B, where node B transfers resources to node A, and node A uses its digital certificate to prove the validity of its public key. This transaction can take the following form:

[0117] In the example transaction above, it should be noted that one of the inputs comes from the public key PK controlled by node B. B After node B confirms that the transaction template structure is valid and node A's certificate is verified, the input is added to the transaction template by node B.

[0118] The transaction is structured to transfer resource y to public key PK. A As shown in the first output point. Another input references the authenticated transaction output. From this input, node B is able to identify and authenticate transactions. Retrieve a copy of the authentication transaction and confirm that it authenticated node A's public key PK. A And it is signed by a certified authority. Node B can also verify that the certified transaction and any subsequent transactions in the chain each contain a certified transaction output, which is a binary multi-signature output, with the certified authority as one of the possible signatories. That is, the certified authority has the ability to revoke certification.

[0119] Optionally, node B can also evaluate whether node A has correctly constructed the certified transaction output in the current transaction template to provide node A with an updated certification key and enable the certification authority to revoke certification if necessary; however, node B does not necessarily need to confirm this in order to continue the transaction.

[0120] After submitting the above transaction to the blockchain network, node A can then use the public key of the new link. To prove its identity. For example, in a subsequent transaction with node C, node A can provide a transaction template that includes the public key transmitted via the new link as input. References to the output of the certified transaction and transaction identifiers Node C retrieves linked transactions. It was confirmed that the referenced output point is a two-way multi-signature output operation, and the authorized signer of this multi-signature output operation is the public key of the new connection. PK with public keys of certification authorities CA Then node C recognizes the input authentication transaction identifier. Retrieve a copy of the authentication transaction to confirm that it was signed by an authentication authority and that the public key PK was authenticated. A Furthermore, it confirms that the authentication transaction output is a two-way multi-signature output operation, and the authorized signer of this multi-signature output operation is the authentication transaction public key. PK with public keys of certification authorities CA .

[0121] Subsequent transactions involving the authentication of node A are processed in the same manner, with another node tracing back through a series of linked transactions to ensure that its authentication transaction output is correctly constructed until the original authentication transaction is reached.

[0122] Now refer to Figure 6 The flowchart illustrates a portion of method 600 for verifying digital certificates using linked transactions. Method 600 provides an example of automated certificate verification for verifying the identity of a recipient. In this example transaction, node A is the recipient and node B is the sender. Method 600 begins in operation 602 with node A creating a transaction template. In this example, the transaction template includes inputs referencing the authentication transaction output from the last transaction in a series of linked authentication transactions that trace back to verifying the identity of node A (e.g., authenticating node A's public key PK). A The original authentication transaction. The output of the final authentication transaction is the payment to public key operation, which references the public key of the authentication transaction. The corresponding private key can be referred to as the current authentication transaction key. The input to the transaction template is used to generate a signature. The current certified transaction key is used for signing. The transaction template also includes the public key PK for transferring resources to node A. A The output.

[0123] In operation 604, node A sends the transaction template to node B. The transaction template does not yet contain input from node B and / or, if it does contain input, it is not signed by node B.

[0124] In operation 606, Node B has received the transaction template and then obtains a copy of the transaction referenced in the input of the transaction template. If Node A has never used its certificate before, the transaction could be either the original authentication transaction or a linked authentication transaction. In operation 608, Node B evaluates whether it is the original authentication transaction. The original authentication transaction contains the OP_RETURN output, which contains the PK. A The certificate, and the linked authentication transaction contains two or more signed inputs that reference earlier transaction outputs, one of which is a previous authentication transaction, and another may be an input resource for the linked authentication transaction. If node B determines that the retrieved transaction is a linked authentication transaction rather than the original authentication transaction, then in operation 610, node B determines whether the referenced output is validly constructed. For example, it can evaluate whether the output includes a binary multi-signature operation that includes the referenced authentication public key (e.g., ...). or ), and the public key of the certification authority (e.g., PK). CA If the retrieved transaction does not have a correctly constructed outgoing reference, node B may reject the transaction because it cannot verify node A's public key. However, if the outgoing reference is correctly constructed, method 600 returns to operation 606 to obtain previous transactions in the linked series based on the input in the retrieved transaction. Method 600 continues to trace back through the linked transactions, confirming at each step that the outgoing reference is correctly formatted to initiate the authority revocation, until the original certified transaction is identified in operation 608.

[0125] Once the original authentication transaction is identified, in operation 612, Node B verifies that the authentication transaction was signed by a Certification Authority using its key. It also verifies Node A's public key PK. A This appears in the OP_RETURN output field of the authentication transaction, thus confirming that the authentication authority has authenticated the authenticity of node A's public key. It can also verify that the authentication transaction output is for the authentication transaction public key. PK with public keys of certification authorities CA The two-choice multi-signature output.

[0126] If node B is convinced that the original authentication transaction is valid, then in operation 614, it adds input to the transaction template to supply the resources being transferred to node A's public key PK. A Then, in operation 614, the completed transaction template is submitted to the blockchain network, and as shown in operation 616, if the latest certified transaction in this series is sent to the certified transaction public key... If the certified transaction output remains valid (i.e., it is still an unspent output in the UXTO central repository), then the transaction is processed in operation 618. Otherwise, in operation 620, the transaction is rejected as invalid by the blockchain network.

[0127] In one implementation, the value of each certified transaction output transferred to a series of certified transaction outputs can be a fixed value x that the validating node confirms when evaluating the form and content of each transaction in the series. In another implementation, to set an upper limit on the number of times a certificate can be reused, this value can start with a fixed number from the original certified transactions and can decrease by a certain amount with each use, such that at some point further updates (renewals) may not occur. In some implementations, the amount of reduction can match the transaction fee amount.

[0128] It should be understood that a certificate authority can revoke a certificate by identifying the latest transaction in a series of authentication transactions and spending a choice of two multi-signature outputs using the certificate authority's key.

[0129] Now for reference Figure 7 The simplified computing device 700 according to an example of this application is shown in block diagram form. This computing device 700 can perform one or more of the functions described above. In this sense, in some implementations, it can be used as a first computing device 102 ( Figure 1 ), second computing device 104 ( Figure 1 ) or server 106 ( Figure 1 ).

[0130] The computing device 700 includes a processor 702, which may include one or more microprocessors, application-specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The computing device 700 may also include a memory 704 and a network interface 706. The memory 704 may include persistent and non-persistent memory to store values, variables, and in some cases, processor-executable program instructions.

[0131] The computing device 700 may include a processor-executable application program 708, which contains processor-executable instructions that, when executed, cause the processor 702 to perform one or more functions or operations described herein.

[0132] The various embodiments presented above are merely examples and are in no way intended to limit the scope of this application. The innovative variations described herein will be readily apparent to those skilled in the art, and such variations are within the scope of this application. In particular, alternative example embodiments may be created by selecting one or more features from the above example embodiments, including sub-combinations of features that may not be explicitly described above. Furthermore, features may be selected from one or more of the above example embodiments and combined to create alternative example embodiments, including combinations of features that may not be explicitly described above. Those skilled in the art will readily understand, upon reviewing this application as a whole, the features suitable for such combinations and sub-combinations. The subject matter described herein and in the cited claims is intended to cover and encompass all suitable technical variations.

Claims

1. A computer-implemented method for verifying a first public key associated with a first node, the method comprising: Receive a transaction template from the first node, the transaction template containing a first input that references the current key to register the transaction output; The last transaction in a series of linked transactions is identified based on the last transaction that includes the output of the current key registration transaction; The key registration transaction is traced through the series of linked transactions to identify and obtain the key registration transaction, which includes a first public key associated with the first node, and the key registration transaction is verified to be signed with a third-party key. as well as The transaction template is propagated on the blockchain network, wherein the propagated transaction template includes a second input that transfers resources to the output address. Therefore, if the current key registration transaction output is included in the set of unspent transaction outputs, the transaction template will be verified by nodes on the blockchain network.

2. The method according to claim 1, wherein, The transaction template includes input from the first public key associated with the first node.

3. The method according to claim 2, wherein, The propagation includes adding an output to the transaction template containing the second public key associated with the second node before propagation.

4. The method according to claim 1, wherein, The transaction template includes the output to the first public key associated with the first node.

5. The method according to claim 4, wherein, The propagation includes adding input from a second public key associated with the second node to the transaction template prior to propagation.

6. The method according to any one of claims 1 to 5, wherein, The key registration transaction output includes the payment to public key output in the last transaction.

7. The method according to claim 6, wherein, The key registration transaction output is one of a plurality of pay-to-public-key outputs in the final transaction, wherein each pay-to-public-key output in the final transaction involves a different corresponding public key.

8. The method according to any one of claims 1 to 7, wherein, The acquisition also includes: verifying that the key registration transaction output is a multi-signature output, and that the allowed signer of the multi-signature output includes the third-party key.

9. The method according to any one of claims 1 to 8, wherein, The unspent transaction output set includes all transaction outputs that have not yet been used as inputs for other transactions, and wherein the unspent transaction output set is maintained by the blockchain network.

10. The method according to any one of claims 1 to 9, wherein, The process of obtaining the key registration transaction includes sending a request for the key registration transaction to a node in the blockchain network and receiving a response containing the key registration transaction.

11. The method according to any one of claims 1 to 9, wherein, The acquisition includes receiving a copy of the last transaction and the Merkel path associated with the last transaction from the first node, and wherein the method further includes verifying that the last transaction is recorded in the blockchain based on a set of the copy of the last transaction, the Merkel path, and the block headers of the blockchain.

12. A computing device for verifying a first public key associated with a first node, the computing device comprising: One or more processors; Memory; Computer-executable instructions stored in the memory, when executed by the one or more processors, cause the processors to perform the method according to any one of claims 1 to 11.

13. A computer-readable medium storing processor-executable instructions for verifying a first public key associated with a first node, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 11.

Images