Method and apparatus for public key management using blockchain

Abstract

Blockchain networks are used to improve the public key infrastructure by providing fast and secure enrollment, revocation, and renewal of digital certificates.SOLUTION: The public key may be recorded in the blockchain by the certificate authority so that a third party can quickly and easily verify that the public key has been certified by the certificate authority and that the certificate has not been revoked. The certificate authority may invoke a certificate almost instantaneously and / or may certify a new key for the same entity while at the same time revoking an old key. In some cases, the ability to revoke a certificate may be given to the owner of the public key, or in some cases to one or a group of other entities.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to blockchain networks, and more particularly to the use of blockchain to implement public key management for public key infrastructures. [Background technology]

[0002] In a public key infrastructure, a computing device may have a public-private key pair to enable secure communications, digital signatures, non-repudiation, and other functions. As part of the public key infrastructure, a computing device may have its public key registered with a certification authority. The certification authority provides the computing device with a digital signature that verifies the ownership and authorization of the public key.

[0003] A problem with using certification authorities is that once they issue a digital signature, it remains valid until its specified end date. However, public keys can be compromised, necessitating the revocation of the certificate. To solve that problem, certification authorities maintain "revocation lists" that detail which digital certificates should be considered revoked, and they periodically update and publish these lists. Entities wishing to verify a public key may rely on a digital certificate, but must therefore obtain and examine the corresponding certificate revocation list to learn whether the digital certificate has been revoked by the certification authority. This system and its inherent delays mean that some digital certificates may be revoked, and the revocation may not yet have been issued or available to entities seeking to rely on the digital certificate. [Brief explanation of the drawings]

[0004] By way of example, reference is made to the following accompanying drawings which illustrate exemplary embodiments of the present application:

[0005] [Figure 1] 1 illustrates an exemplary block structure of a blockchain network.

[0006] [Figure 2] 1 shows a flowchart of an exemplary method for block propagation.

[0007] [Figure 3] One exemplary method for verifying a public key is illustrated in flow chart form.

[0008] [Figure 4] A simple example of a mining node is shown in block diagram form.

[0009] Like reference numbers in the figures are used to denote like elements and features. DETAILED DESCRIPTION OF THE INVENTION

[0010] In one aspect, a computer-implemented method for managing a public key infrastructure using a blockchain may be provided, the method may include generating a digital certificate of a first entity, The first entity comprises: generating a certification transaction, the certification transaction including a digital signature from a certification authority, a first output to an address based on a second public key, and a second output having an information field including the first public key; determining an attestation transaction identifier from a hash of the attestation transaction; The attestation transaction is propagated on the blockchain network to have a first public key, and the digital attestation includes the first public key and the attestation transaction identifier.

[0011] 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 certification authority holds a second private key corresponding to the second public key.

[0012] In some implementations, the method may further include verifying the digital certificate, which includes: obtaining a copy of the attestation transaction from a blockchain based on the attestation transaction identifier in the digital certificate; determining that the first output is an unspent transaction output; determining that the first public key included in the second output in the certification transaction matches a 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 is in a pool of unspent transaction outputs of the blockchain network. In some such implementations, the attestation transaction may further include a certification authority public key, and verifying the digital certificate may further include determining that the attestation transaction is signed by the certification authority based on the certification authority public key.

[0013] Some such implementations may further include revoking the digital attestation by generating a revocation transaction that includes an input and the first output of the attestation transaction and propagating the revocation transaction on the blockchain network.

[0014] In some implementations, the method may further include replacing the digital certificate with a new digital certificate for a new public key. generating a new attestation transaction, the new attestation transaction including as input the first output of the attestation transaction, a first new output to a new address based on a third public key, and a second new output having the information field, the information field including the new public key; determining a new attestation transaction identifier from hashing the new attestation transaction; propagating the new attestation transaction onto the blockchain network; The new digital certificate may include the new public key and the certification transaction identifier.

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

[0016] In some implementations, the attestation transaction includes an input referencing an unused transaction outpoint address obtained from a hash of a certification authority public key, and the attestation transaction includes an unlock script for the unused transaction outpoint address that includes the certification authority public key and the digital signature, the digital signature being generated based on a private key corresponding to the certification authority public key.

[0017] In some implementations, the first output includes a multi-siglock script that allows one of two or more private keys to utilize the first output.

[0018] In a further aspect, the present application describes a computer-implemented method for verifying a digital certificate using a blockchain network, the digital certificate including a first public key and a certificate transaction identifier, the method comprising: receiving the digital certificate from a first entity; obtaining a copy of the attestation transaction from a blockchain based on the attestation transaction identifier in the digital certificate; wherein the certification transaction includes a digital signature from a certification authority, a first output to an address based on a second public key, and a second output having an information field. determining that the information field contains a public key that matches the first public key in the digital certificate; querying a pool of unspent transaction outputs to determine that the first output in the attestation transaction has not been spent in any royal transaction; verifying that the first public key is valid based on the results; Includes:

[0019] In another aspect, a computing device implementing a node in a network may be provided, the computing device may include memory, one or more processors, and computer-executable instructions that, when executed, cause the processors to perform one or more of the methods described herein.

[0020] In yet another aspect, a computer-readable medium may be provided having processor-executable instructions stored thereon for differentiating nodes in a network, the processor-executable instructions, when executed by one or more processors, causing the processors to perform at least one of the methods described herein.

[0021] Other exemplary embodiments of the present disclosure will become apparent to those skilled in the art from a reading of the following detailed description in conjunction with the drawings.

[0022] As used herein, the term "and / or" is intended to cover all possible combinations and subcombinations of the listed elements, including the listed elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements.

[0023] As used herein, the term "at least one of ... or ..." is intended to cover all possible combinations and subcombinations of the listed elements, including the listed elements alone, any subcombination, or all of the elements, and does not necessarily exclude additional elements, and does not necessarily require all elements.

[0024] This application refers to hashing or a hash function, which is intended to include any one of a number of cryptographic hash functions that, when applied to any data set or "message," 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 equivalents thereof. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0025] As used herein, the term "blockchain" is understood to encompass 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. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin, as exemplified by the Bitcoin SV protocol, may be referenced herein for convenience and illustrative purposes; however, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are encompassed within the scope of the present invention.

[0026] A blockchain is a peer-to-peer electronic ledger implemented using a decentralized, distributed, computer-based system. Blockchains are composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes, among other things, the transfer of control of a digital asset between participants in a blockchain system and contains at least one input and at least one output. Each block header contains a summary of the block's contents, such as in the form of a Merkle root, and each block header contains a hash of the previous block header. As a result, blocks are strung together to create a permanent, immutable record of all transactions written to the blockchain since its inception. Transactions contain small programs known as scripts. Scripts embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0027] A blockchain is implemented by a network of nodes. Each node is a computing device with a network connection and running software that implements the applicable blockchain protocol. Nodes validate transactions and propagate them to other nodes in the network. Dedicated network nodes, called "mining nodes" or "miners," collect sets of unconfirmed, or pending, transactions into blocks and attempt to "mine" the blocks. Mining, in these examples, refers to solving a proof-of-work (POW) before other miners in the network successfully solve their respective block's proof-of-work. In the Bitcoin example, POW involves hashing a block header containing a nonce until the result is below a threshold set by a mining difficulty parameter. The nonce is repeatedly incremented, and hashing is repeated until the result is below the threshold or the miner receives a nonce successfully mined by another miner. Variations on the mining process are familiar to those skilled in the art.

[0028] Among other things checked, when validating a transaction, a node determines whether the inputs to the transaction are valid. In particular, the node evaluates whether the unlock script evaluates to true and determines whether the input references an unspent transaction output (UTXO) from a previous transaction. Some nodes may maintain a running list or pool of UTXOs to enable fast determination of whether a referenced transaction output is in a UTXO. A transaction may be identified by its unique transaction identifier, TxID, which in some implementations is a hash of the transaction. Some transactions may have more than one output, and therefore a unique transaction output (i.e., outpoint) may be identified by the TxID and an index, where the index refers to one of the outputs in the ordered set of outputs from the transaction. If a transaction output is in the UTXO pool, the transaction output is "unspent" and can serve as an input.

[0029] The unlocking script of a transaction outpoint defines how to prove "control" over the output in order to be executed. Often, the address associated with a transaction output is a hash of a public key. To prove control over the output, the unlocking script often requires a public key and a digital signature generated using the corresponding private key. In this way, the node that controls the private key can control when and how the transaction output is used in any subsequent input. As discussed further below, this has the inference that a transaction input corresponding to a particular public key includes a digital signature generated using the corresponding private key, and therefore the entity associated with that particular public key has effectively signed or attested to the contents of the transaction.

[0030] Public key cryptography is ubiquitous in online communications. In many instances, processes and policies are required to provide certainty that a public key is owned by an association with a particular entity. The most common approach to ensuring that a public key is authentic and not compromised is the public key infrastructure (PKI). PKI relies on trusted third parties to "certify" public keys as valid. These entities are "certificate authorities (CAs)." CAs provide registration and issuance of digital certificates that confirm the binding between a public key and a particular owner. A public key holder provides their public key and their digital certificate to another entity. The other entity may then verify the authenticity of the public key by verifying that a trusted CA has digitally signed the public key as belonging to the holder.

[0031] One of the problems with existing PKIs is that public keys are sometimes compromised if the private key is lost or disclosed before the certificate's specified end date. For that reason, CAs may maintain certificate revocation lists. Any entity that wishes to rely on a certificate associated with a public key must therefore locate and review the associated certificate revocation list to ensure that the certificate has been revoked by the CA. This compromises the ability to authenticate keys offline and creates risks due to the delay, sometimes 24 hours or more, between revocation and the issuance of a new certificate revocation list.

[0032] According to one aspect of the present application, a blockchain network may be used to improve public key infrastructure by providing fast and secure verification, revocation, and renewal of digital certificates. Public keys may be recorded on a blockchain by a certification authority so that a third party can quickly and easily verify that the public key has been certified by the certification authority and that the certificate has not been revoked. By recording the public key in the manner described below, the certification authority can nearly instantaneously recall a certificate or revoke an old key while simultaneously certifying a new key for the same entity. In some cases, the ability to revoke a certificate may be granted to the owner of the public key or, in some cases, to one or a group of other entities.

[0033] Referring to FIG. 1 , an exemplary system 100 for managing a public key infrastructure is illustrated. The 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 may be implemented by any network-enabled computing device, including a server, a personal computer, a tablet, a smartphone, a connected car, an Internet of Things device, 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. While the CA is shown implemented by the server 106, it is understood that the CA functionality may be implemented by one or more servers or other computing devices.

[0034] The system 100 further includes a blockchain network 108. The blockchain network 108 includes a network of nodes that operate according to an applicable blockchain protocol. In some implementations, one or more of the first computing device 102, the second computing device 104, and / or the server 106 may be nodes within the blockchain network 108, but in this example, they are shown as being separate nodes from the blockchain network 108 for ease of explanation.

[0035] In this example system 100, a first computing device 102 is labeled "Alice" and has a public-private key pair for use in asymmetric cryptographic communications. To use the public key in some cryptographic scenarios, Alice may need to have a corresponding digital certificate that authenticates the public key and its association with Alice. Thus, at operation 110, Alice submits her public key, PK , to the CA along with a request for registration. AThe CA may engage in some level of authentication to vouch for Alice's identity as the owner of the public key. In some examples, this authentication may be an automated online operation performed by server 106 based on the data provided in operation 110. In some examples, this authentication may additionally or alternatively include an offline authentication operation. Two-factor authentication and other such techniques may be utilized.

[0036] The CA issues the public key PK A If it decides that a token should be certified, it generates a blockchain transaction called a certification transaction (CTX). This transaction includes the public key PK A and is signed by the CA. The attestation transaction further includes an output controlled by the CA. As indicated by operation 112, the transaction is submitted to the blockchain network 108. At operation 114, the CA then sends Alice the attestation transaction identifier TxID CTX _ PKA In some implementations, Alice obtains a copy of the attestation transaction from the blockchain network 108 based on the transaction identifier and checks whether it meets expectations and provides the public key PK A You can check that it includes.

[0037] Transaction Identifier TxID CTX _ PKA is the public key PK A together, in effect, form a digital certificate for Alice. In connection with some communication with a second computing device 104, labeled "Bob" in this example, Alice may send her digital certificate to Bob in operation 116. Bob then sends the public key PK A and verify that the proof has not been revoked based on the blockchain maintained by the blockchain network 108.

[0038] In particular, in operations 118 and 120, Bob may request and receive a copy of the attestation transaction. From the attestation transaction, Bob may learn that it is Alice's purported public key, PK A and that it is signed by a trusted certification authority. As indicated by operations 122 and 124, Bob can further verify that the proof has not been revoked by querying the blockchain network 108 whether the CA-controlled transaction output remains "unspent," i.e., the transaction output point resides in the UTXO pool 130. The UTXO pool 130 is a pool of "unspent" transaction output points maintained by any of the many nodes of the blockchain network 108.

[0039] 2, an exemplary method 200 for registering a public key with a certification authority is illustrated in flow chart form. The exemplary method 200 is performed by a certified certification authority and may be performed by one or more servers suitably programmed to perform the described functions.

[0040] In operation 202, the certification authority obtains the public key PK A The certification authority receives a request from Alice for certification of the public key PK. The certification authority may perform an authentication or authorization protocol in accordance with its applicable policies. These protocols may include automated computer-implemented actions and / or administrator-implemented actions. Regardless of the particular authentication action, in operation 204 a determination is made as to whether to certify the public key for Alice. If not, the method ends. If the certification is approved, in operation 306 the certification authority generates a certification transaction. As described above, the certification transaction involves inputs including the certification authority's public key and a digital signature from the certification authority, outputs controlled by the certification authority, and the public key PK. ATo provide a specific example, the input may be a UTXO of some normalized or arbitrary value for which the attestation authority has the private key to generate the signature in a valid unlock script. The UTXO may be associated with a digital value sufficient to offset any transaction fee for mining the attestation transaction.

[0041] An attestation transaction may contain two outputs: the CA public key PK, which is selected and controlled by the certification authority; CTX_PKA Based on this, the second is to use the public key PK in the non-operational information field, for example. A An example of the latter is the OP_RETURN function in Bitcoin, which is effectively an output where any data may be placed on the blockchain to be recorded once the transaction has been mined.

[0042] The first output may be, for example, a pay to public key hash (P2PKH) operation specifying a transfer to a public key hash (eg, a Bitcoin address) selected and controlled by the certification authority.

[0043] By its digital signature in the transaction, the certificate authority authenticates the UTXO input to the transaction, thereby satisfying the unlock script, and the certificate authority's public key PK, which appears in the OP_RETURN output. A Note that in some implementations, additional information, such as a digital signature from Alice or other such information, may appear in the OP_RETURN output field.

[0044] Once the attestation transaction is generated, in operation 208 the attestation authority hashes the transaction to generate a transaction identifier TxID CTX _ PKAand propagates the transaction across the blockchain network, as shown in operation 210. It is understood that "propagating" a transaction includes submitting the transaction to a node in the blockchain network, where it is validated and sent to all other nodes, and validating and re-sending the transaction until it has reached substantially all nodes in the network. In some embodiments, the certification authority is itself one of the nodes in the blockchain network.

[0045] In operation 212, the attestation authority waits for the mining of a block containing the attestation transaction, i.e., the "confirmation" of the transaction, and then in operation 214, the transaction identifier TxID CTX _ PKA to Alice. In some implementations, the certificate authority may provide Alice with a transaction identifier before the transaction is mined.

[0046] Alice then sends Alice's public key, PK A and the proof transaction identifier TxID CTX _ PKA From this, a third party may verify that Alice's public key is certified by the CA.

[0047] A simple example of a proof transaction is shown below: [Table 1]

[0048] Note that the unlock script for input contains the public key of the signing authority and the signature generated by the certification authority. Alice's public key PK A appears in the OP_RETURN field as the second output. The first output is an arbitrary public key hash controlled by the certificate authority.

[0049] Referring to Figure 3, an exemplary method 300 for verifying a public key is shown. The operations illustrated in exemplary method 300 may be performed by a computing device seeking to verify a public key intended to be certified using the process illustrated in Figure 2. Exemplary computing devices include any network-enabled computing device.

[0050] The method 300 includes receiving a digital certificate for another entity, such as the first computing device 102 (FIG. 1) labeled "Alice," at operation 302. The digital certificate contains at least a public key PK A , and the proof transaction identifier TxID CTX _ PKA At operation 304, the attestation transaction is retrieved from the blockchain network using the attestation transaction identifier. It is understood that the attestation transaction may be retrieved from a copy of the blockchain whether that copy is local to the computing device or maintained by a node in the blockchain network. If the transaction is not confirmed, i.e., not yet in a mined block, the transaction may reside in a mempool of unconfirmed transactions. However, in many implementations, the authentication authority need only provide the attestation transaction identifier to Alice after the attestation transaction has been mined.

[0051] From the attestation transaction, the computing device may verify certain things. In particular, at operation 306, the computing device may verify that the attestation transaction is signed by a certification authority. The computing device may have, or have access to, a list of certified or trusted authorities and their respective public keys. This may allow the computing device to verify the digital signature. The digital signature may form part of the input to the attestation transaction as described. By verifying that the attestation transaction is signed by a trusted or certified certification authority, the computing device can confirm that the attestation is valid. Note that if the transaction is on the blockchain, it has been confirmed and verified by miners, so the computing device does not necessarily need to verify the digital signature in the input. Rather, the computing device may simply verify that the public key identified in the input is associated with a certification authority.

[0052] As indicated by operation 308, the computing device may further verify that one of the output points of the proof transaction remains “unspent,” i.e., the output point can be found in the UTXO pool. This verification operation confirms that the proof remains valid and unrevoked. As mentioned above, in many embodiments (alternatives are described below), this output point is controlled by the proof authority. This allows the proof authority to revoke the proof if the key is compromised, terminated, or no longer valid. Revocation or cancellation is easily accomplished by having the proof authority “spend” the output point, thereby removing it from the UTXO pool. Confirmation that the output point is in the UTXO pool may be performed by querying the UTXO pool, for example, based on the TxID number and output index. In some examples, the computing device may query the UTXO pool through an intermediary, such as a node in a blockchain network.

[0053] At operation 310, the computing device receives the public key PK in the second output of the attestation transaction. A is the public key PK received as part of a digital certificate from Alice A Verify that it matches.

[0054] If operations 306, 308, and 310 are all verified, then in operation 312, the computing device checks the public key PK in the digital certificate received from Alice. A is determined to be valid.

[0055] By using the blockchain network to record the public key certification, the certification authority can quickly and easily revoke the signature by "using" the output point, resulting in a failed verification in operation 308. Thus, the certification authority may revoke the public key certification by generating and propagating a transaction that uses the first output of the attestation transaction. As described above, the first output may be a P2PKH operation that transfers a nominal digital asset to the public key hash address specified in the first output. The unlock script for that first output, in these examples, is the CA public key PK used in the P2PKH operation. CTX_PKA A digital signature may be required from a certification authority claiming control over the private key corresponding to the .

[0056] In some instances, a certification authority may not revoke a certification, but may be asked to replace / update a certified public key. For example, if a private key is lost or compromised, the owner (e.g., Alice) can replace a public key previously certified by the certification authority with a new public key, PK A_new The CA may request that the certificate be renewed or replaced with a new certification transaction CTX. The CA will authenticate the request using the online or offline authentication mechanism in place and, if it determines that a renewal action should occur, will issue a new certification transaction CTX. new to revoke the old certificate and issue a new one.

[0057] The new proof transaction will have the same type of output, i.e., PK CTX_new A new public key and PK selected by the CA such as A_new However, the input is the original proof transaction TxID. CTX _ PKAThe public key certificate may include a CA-controlled output point from the certificate authority. Revocation is performed by removing the output point from the UTXO pool by "using" that output as input to a new certification transaction. Advantageously, the revocation of the old public key certificate and the registration of the new public key certificate occur in a single transaction. Furthermore, a separate, periodically published list of certificate revocations does not need to be maintained and made available to certification authorities.

[0058] As noted above, in many cases, the first output point of the attestation transaction may be controlled by a certification authority, such that only the certification authority can revoke the certification of the public key. Revocation is based on "using" the first output point with the private key corresponding to that output point. In some instances, however, it may be advantageous to configure the attestation transaction to allow other entities to revoke the certification.

[0059] For example, in some situations, the owner of a public key, e.g., Alice, may have the authority to revoke their own public key. In this configuration, the first output point in the attestation transaction is controlled by Alice, i.e., it references a public key (public key hash) for which Alice has the corresponding private key. That is, the unlock script for the first output point requires a digital signature from Alice. This configuration may be advantageous in some public key attestation scenarios, such as registration for an online service. One example of an online service is a social media account on a social media platform. The platform may use the above-described mechanism to register a user's public key for use with the platform, allowing the user to interact with the platform and / or other users of the platform based on trust in their digital certificate, which is backed up via the attestation transaction. The user can then revoke the certificate to terminate their account without the platform's cooperation.

[0060] In another scenario, more than one output point may be provided, one of which may be "used" to complete the proof. In such a scenario, the third party is configured to test both (or all) such output points of the proof transaction for their presence as unspent transaction outputs in the UTXO pool.

[0061] Alternatively, if revocation from any one of multiple parties is to be achieved, the first output may be configured to use multiple signatures, i.e., any of a number of signatures may be used to "spend" the output. For this purpose, multisig may be used in the output.

[0062] In yet another scenario, a multisig may be configured to ensure that at least a threshold number of entities agree to revoke a proof. The multisig may be configured to require n out of m signatures to unlock an output, where n≦m. By way of example, in the case of an organization such as a business, partnership, or other such collection of individuals, a signed public key associated with the organization may be revocable only if all or at least a threshold number of the particular entities, e.g., the CEO, COO, CTO, or other executive or business-related individual, sign the revocation.

[0063] It will be understood that some or all of the above operations of the various above-described exemplary methods may be performed in a different order than that shown and / or may be performed simultaneously without changing the overall operation of the methods.

[0064] 4, a simplified computing device 400 according to an example of the present application is illustrated in block diagram form. Computing device 400 may perform one or more of the functions described above. In this sense, it may function as first computing device 102 (FIG. 1), second computing device 104 (FIG. 1), or server 106 (FIG. 1) in some implementations.

[0065] Computing device 400 includes a processor 402, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. Computing device 400 may further include memory 404, which may include permanent and non-permanent memory for storing values, variables, and, in some examples, processor-executable program instructions, and a network interface 406.

[0066] Computing device 400 may include processor-executable applications 408 that include processor-executable instructions that, when executed, cause processor 402 to perform one or more of the functions or operations described herein.

[0067] The various embodiments described above are merely examples and are not intended to limit the scope of the present application. Various innovations described herein will be apparent to those skilled in the art, as will variations within the intended scope of the present application. In particular, features from one or more of the exemplary embodiments described above may be selected to generate alternative exemplary embodiments, including subcombinations of features not explicitly set forth above. Furthermore, features from one or more of the exemplary embodiments described above may be selected and combined to generate alternative exemplary embodiments, including combinations of features not explicitly set forth above. Features suitable for such combinations and subcombinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter described and claimed herein covers and encompasses all appropriate technical modifications.

Claims

1. 1. A computer-implemented method for public key verification, comprising: In a computing device, receiving a first public key associated with a first entity and an attestation transaction identifier generated from a hash of an attestation transaction, the attestation transaction including a first output to an address based on a second public key and a second output having an information field including the first public key; obtaining a copy of the attestation transaction from a blockchain based on the attestation transaction identifier; determining that the first output is an unspent transaction output; determining that the first public key included in the second output in the attestation transaction matches the received first public key; determining, based on these determinations, that the first public key is a valid public key associated with the first entity; A method comprising:

2. The method of claim 1 , wherein the second output includes an OP_RETURN field that includes at least the first public key.

3. 3. The method of claim 1, wherein the first output comprises a pay-to-public-key-hash (P2PKH) operation that references an address obtained as a hash of the second public key.

4. 4. The method of claim 1, wherein determining that the first output is an unspent transaction output comprises determining that the first output is in a pool of unspent transaction outputs of a blockchain network.

5. 5. The method of claim 4, wherein determining that the first output is present in an unspent transaction output pool of the blockchain network comprises querying the unspent transaction output pool based on the proof transaction identifier and an index of the first output to determine that the first output is present and has not been used in a subsequent transaction.

6. 6. The method of claim 1, wherein the input to the certification transaction further comprises a certification authority public key, and wherein the method further comprises the step of determining that the certification transaction has been signed by a certification authority based on the certification authority public key.

7. The method according to any one of claims 1 to 6, wherein the information field is an OP_RETURN output.

8. 8. The method of claim 1, wherein the first output comprises a multi-siglock script that allows one of two or more private keys to utilize the first output.

9. The method of any one of claims 1 to 8, wherein the receiving step comprises receiving the first public key and the certification transaction identifier from the first entity.

10. 1. A computing device comprising: one or more processors; Memory and computer-executable instructions stored in said memory, which, when executed by said one or more processors, cause said processors to perform the method of any one of claims 1 to 9; and 1. A computing device comprising:

11. A computer readable medium storing processor executable instructions that, when executed by one or more processors, cause the processors to perform the method of any one of claims 1 to 9.

Images