Method and apparatus for automatic digital certificate validation

Abstract

The public key can be recorded on the blockchain by the certificate authority in such a way that any third party can quickly and easily verify that the public key is certified by the certificate authority and that the certification has not been revoked. The certificate authority can revoke a certification almost instantaneously, and / or can certify a new key for the same entity at the same time as revoking the old key. The verification can be incorporated into a new transaction so that there is no gap between reliance on the certificate and verification of its validity. In some cases, each transaction in which a certificate is used can also serve as a certification transaction that links to update the certificate to enable subsequent use.

Description

TECHNICAL FIELD

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

[0002] 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.

[0003] 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 invalidated 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 available for use by an entity intending to rely on the digital certificate. BRIEF DESCRIPTION OF DRAWINGS

[0004] Reference will now be made, by way of example, to the accompanying drawings, which show example embodiments of the present application and wherein:

[0005] Figure 1 An example system for managing a public key infrastructure is schematically illustrated;

[0006] Figure 2 An example method for registering a public key with a certification authority is illustrated in the form of a flow diagram;

[0007] Figure 3 An example method for verifying a public key is illustrated in the form of a flow diagram;

[0008] Figure 4 An example method for verifying a digital certificate is illustrated in the form of a flow diagram;

[0009] Figure 5 Another example method for verifying a digital certificate is illustrated in the form of a flow diagram;

[0010] Figure 6 Another example method for verifying a digital certificate using a linked certification transaction is illustrated in the form of a flow diagram; and

[0011] Figure 7 A simplified example of a node that can implement at least a portion of one of the described methods is shown in block diagram form.

[0012] The same reference numbers are used in the drawings and the description to represent the same elements and features. DETAILED DESCRIPTION

[0013] In one 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.

[0014] 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.

[0015] In some implementations, the method can further include validating the digital certificate. Validating 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 an unspent transaction output pool of the blockchain network. In some such implementations, the input of the attestation transaction can further include a certificate authority public key, and wherein validating the digital certificate can further include determining that the attestation transaction is signed by the certificate authority based on the certificate authority public key.

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

[0017] In some implementations, the method can further include replacing the digital certificate with a new digital certificate of the new public key. The replacing can include creating a new authentication transaction, where the new authentication transaction includes the first output of the authentication transaction as an input, a first new output to a new address based on the third public key, and a second new output with an information field, where the information field contains 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 can include the new public key and the new authentication transaction identifier.

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

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

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

[0021] In another aspect, the application describes a computer-implemented method of verifying a digital certificate using a blockchain network. The digital certificate includes a first public key and an authentication transaction identifier. The method can include receiving the digital certificate from a first entity and obtaining a copy of an authentication transaction from a blockchain based on the authentication transaction identifier in the digital certificate, where 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 with an information field. The method can further include determining that the information field contains a public key matching the first public key in the digital certificate; querying an unspent transaction output pool to determine that the first output in the authentication transaction has not been used for any subsequent transaction; and based on these determinations, verifying that the first public key is certified to be valid.

[0022] In yet another aspect, the application describes a computer-implemented method of validating a certificate associated with a first node. The method can include receiving a transaction template from the first node, the transaction template containing a first input referencing an attestation transaction output and signed by an attestation transaction key; obtaining a copy of the attestation transaction and determining that the attestation transaction includes the certificate associated with the first node and that the attestation transaction is signed by an attestation authority 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. The transaction template is to be validated by nodes on the blockchain network if the attestation transaction output is included in a set of unspent transaction outputs.

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

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

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

[0026] In some implementations, the obtaining includes identifying a last transaction in a series of linked transactions based on a last transaction containing the attestation transaction output, and tracing through the series of linked transactions to identify the attestation transaction. In some cases, the obtaining further includes verifying that the attestation transaction output is a multi-signature output, the allowed signers of which include the attestation authority key.

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

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

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

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

[0031] In another aspect, a computing device implementing a node in a network can be provided. The computing device can include a 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.

[0032] In yet another aspect, a computer-readable medium storing processor-executable instructions for operating a node in a network can be provided, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the processors to perform at least one of the methods described herein.

[0033] Other example embodiments of the present disclosure will be apparent to those of ordinary skill in the art in view of the following detailed description in conjunction with the attached drawings.

[0034] In this application, the term "and / or" is intended to encompass all possible combinations of the elements it connects, including any one of the listed elements, any subcombination thereof, or all of the elements, and not necessarily excluding additional elements.

[0035] In this application, the phrase "at least one of... or... " is intended to cover any one or more of the listed elements, including any one of the listed elements, any subcombination thereof, or all of the elements, and not necessarily excluding additional elements.

[0036] This application will refer to hash processing or hash functions, which are intended to include any of a number of cryptographic hash functions that deterministically produce a unique, fixed-length alphanumeric string when applied to an arbitrary set of data or "message". The result of a hash function can be referred to as a hash value, a fingerprint, a hash result, or equivalent. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0037] In this document, the term“blockchain” is understood to encompass all forms of electronic, computer-based, distributed ledger. These include consensus-based blockchain and transaction chain technologies, permissioned and un-permissioned ledgers, shared ledgers and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While references can be made herein to Bitcoin for the purposes of convenience and illustration, for example as exemplified by the Bitcoin SV protocol, it should be noted that the present application is not limited to use with the Bitcoin blockchain and alternative blockchain implementations and protocols fall within the scope of the present application.

[0038] A blockchain is a peer-to-peer, electronic ledger implemented using a computer- based, decentralised, distributed system. The blockchain is made up of blocks, which in turn are made up of transactions. Each transaction is a data structure encoding among other possible information, a transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. Each block header contains a summary of the contents of the block, for example in the form of a Merkle root, and each block header contains the hash of the previous block header, so that blocks are linked together to create a permanent, unalterable record of all transactions that have been written into the blockchain since its inception. Transactions contain small programs, known as scripts, embedded into their inputs and outputs that specify how and by whom the outputs of the transactions can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0039] The 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 validate transactions and propagate them to other nodes in the network. Specialised network nodes, known as“mining nodes” or“miners”, collect a set of unconfirmed transactions (i.e. pending transactions) into a block and attempt to“mine” the block. Mining, in these examples, refers to solving a proof of work (POW) before any other miner in the network successfully solves a POW for their respective block. In the Bitcoin example, the POW involves hashing the block header including a random number (nonce) until the result is less than a threshold set by a difficulty parameter. The nonce is repeatedly incremented and the hashing repeated until the result is less than the threshold or until the miner receives a notification that another miner has succeeded. Variations on the mining process will be familiar to those of ordinary skill in the art.

[0040] Among the various things that are checked when validating a transaction, the node determines whether the inputs of the transaction are valid. In particular, the node evaluates whether the unlocking script evaluates to true and determines whether the inputs reference an "unspent transaction output" (UTXO) from an earlier transaction. Some nodes can maintain a running list or pool of UTXOs so as to be able to quickly determine whether a referenced transaction output is in the UTXO. The list or pool of UTXOs can be referred to as the "unspent transaction output set." The blockchain network is configured to update and maintain the unspent transaction output set to prevent double-spend attacks. Transactions can be identified by their unique transaction identifier, TxID, which in some implementations is the hash of the transaction. Some transactions can have more than one output, so a unique transaction output (i.e., an outpoint) can be identified by the TxID and an index, where the index points to one of the outputs in the ordered set of outputs from the transaction. If a transaction output exists in the UTXO pool or set, the output of the transaction is "unspent" and available to be used as an input.

[0041] The unlocking script of a transaction outpoint defines how to prove "control" over the output in order to be spent. In many cases, the address associated with a transaction output is a hash of a 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, a node that controls the private key is able to control when and how the transaction output is used in any subsequent input. As will be discussed further below, this has the corollary that when a transaction input corresponding to a particular public key includes a digital signature generated using the corresponding private key, then the entity associated with that particular public key effectively signs or authenticates the contents of the transaction.

[0042] Public key cryptography has become ubiquitous in online communications. In many cases, processes and policies are needed to provide certainty that a public key is possessed by the entity to which it is associated. The most common method to ensure that a public key is authentic and not compromised is a Public Key Infrastructure (PKI). A PKI relies on trusted third parties to "certify" that a public key is valid. 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 particular party. The holder of a public key provides another entity with its public key and its digital certificate. 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.

[0043] One of the problems with existing PKI is that sometimes a public key will be compromised, for example if the private key is lost or made public before the certificate's specified expiration date. For this reason, a CA can maintain a certificate revocation list. Any entity wishing to rely on a certificate associated with a public key must also find and review the associated certificate revocation list to confirm that the certificate has not been revoked by the CA. This impairs the ability to offline authenticate keys and creates a risk due to the delay between revocation and issuance of a new certificate revocation list, typically 24 hours or more.

[0044] According to one aspect of the application, a blockchain network can be used to improve public key infrastructure by providing fast and secure verification, revocation, and updating 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 a public key is certified by the certificate authority and that the certification has not been revoked. By recording public keys in this way, a certificate authority can revoke a certification almost immediately, or can certify a new key for the same entity at the same time as revoking an old key. In some cases, the ability to revoke a certification can be granted to all parties to a public key, or in some cases to one or even a group of other entities.

[0045] Reference will now be made to Figure 1 The figure schematically illustrates an example system 100 for managing a public key infrastructure. The system 100 in this example 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 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. Although the CA is depicted as being implemented by the server 106, it will be appreciated that the CA functionality can be implemented by one or more servers or other computing devices.

[0046] The system 100 also includes a blockchain network 108. The blockchain network 108 includes 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 can also be nodes in the blockchain network 108, although in this example they are depicted as separate nodes from the blockchain network 108 for ease of explanation.

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

[0048] Once the CA determines that the public key PK A is authenticated, it generates a blockchain transaction, a "certification transaction" (CTX), that includes the public key PK A and is signed by the CA. This certification transaction also includes an output controlled by the CA. As shown in operation 112, this transaction is submitted to the blockchain network 108. The CA then provides the certification transaction identifier TxID CTX_PKA to Alice in operation 114. In some implementations, Alice can obtain a copy of the certification transaction from the blockchain network 108 based on the transaction identifier to confirm that it is as expected and contains the public key PK A .

[0049] The transaction identifier TxID CTX_PKA , together with the public key PK A , effectively forms a digital certificate for Alice. In connection with certain communications with a second computing 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 and verify that the certification has not been revoked based on the blockchain maintained by the blockchain network 108.

[0050] In particular, in operations 118 and 120, Bob can request and receive a copy of the certification transaction. From this certification transaction, Bob can verify that it contains the public key PK A that Alice claims, and that it has been signed by a trusted certification authority. Bob is also able to 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 the blockchain network 108, as shown in operations 122 and 124. The UTXO pool 130 is a pool of "unspent" transaction output points maintained by any of the plurality of nodes of the blockchain network 108.

[0051] Reference will now be made to the drawings Figure 2 FIG. 2, in flowchart form, illustrates an example method 200 for registering a public key with a certificate authority. The example method 200 is implemented by an authorized certificate authority, and can be implemented by one or more servers that are suitably programmed to perform the described functions.

[0052] In operation 202, the certificate authority receives a request from Alice to authenticate a public key PK A . The certificate authority can perform an authentication or authorization protocol according to its applicable policies. These protocols can include automated computer-implemented operations and / or administrator-facilitated operations. Regardless of the specific authentication operations, in operation 204 it is determined whether to authenticate the public key for Alice. If the public key is not authenticated for Alice, the method 200 ends. If authentication is to be granted, in operation 206 the certificate authority creates an authentication transaction. As described above, the authentication transaction includes an input that includes a public key of the certificate authority and a digital signature from the certificate authority, an output controlled by the certificate authority, and the public key PK A . As one specific example, the input can be a UTXO of some nominal or arbitrary value for which the certificate authority has a private key to generate a signature in a valid unlocking script. The UTXO can be associated with a sufficient digital value to offset any transaction fees that should be paid for mining the authentication transaction.

[0053] The authentication transaction can include two outputs: a first output based on a CA public key PK CTX_PKA selected and controlled by the certificate authority, and a second output that includes the public key PK A in, for example, a non-operational information field. An example of the second output is the OP_RETURN function in Bitcoin. OP_RETURN is effectively an output that can be placed into the transaction to record arbitrary data on the blockchain once the transaction is mined.

[0054] For example, the first output can be a P2PKH (pay-to-public-key-hash) operation that specifies a transfer to a public key hash (e.g., a Bitcoin address) selected and controlled by the certificate authority.

[0055] The certificate authority, through its digital signature in the transaction, both authorizes the UTXO input into the transaction to satisfy the unlocking script, and provides verifiable evidence that the certificate authority has authenticated the public key PK A that appears in the OP_RETURN output. Note that in some implementations additional information (e.g., a digital signature from Alice or other such data) can appear in the OP_RETURN output field.

[0056] Once the certification transaction has been created, the certification authority hashes the transaction in operation 208 to find the transaction identifier TxID CTX_PKA and propagates the transaction across the blockchain network as shown in operation 210. It will be appreciated that "propagating" the transaction comprises submitting it to a node of the blockchain network, at which node the transaction is validated and then transmitted to all other nodes, which in turn validate and retransmit the transaction until it has reached almost all nodes in the network. In some embodiments, the certification authority is itself one of the nodes in the blockchain network.

[0057] In operation 212, the certification authority waits for a block containing the certification transaction to be mined, i.e. for the "confirmation" of the transaction, and then in operation 214, sends the transaction identifier TxID CTX_PKA to Alice. In some implementations, the certification authority can provide the transaction identifier to Alice before the transaction is mined.

[0058] Alice is then able to provide any third party with a digital certificate comprising Alice's public key PK A and the certification transaction identifier TxID CTX_PKA . Thereby, the third party can verify that Alice's public key is certified by the CA.

[0059] A simplified example of a certification transaction is shown below:

[0060]

[0061] It will be noted that the input unlocking script comprises the public key of the certification authority and a signature generated by the certification authority. Alice's public key PK A appears as the second output in the OP_RETURN field. The first output is any public key hash controlled by the certification authority.

[0062] Reference is now made to Figure 3 which shows an example method 300 of verifying a public key. The operations described in the example method 300 can be performed by a computing device attempting to verify a public key which claims to be certified using the processes illustrated in the examples in Figure 2 . The example computing device comprises any network-enabled computing device.

[0063] The method 300 comprises, in operation 302, receiving a digital certificate of another entity (e.g. a first computing device 102 Figure 1 labelled "Alice"). The digital certificate comprises at least a public key PK A and a certification transaction identifier TxID CTX_PKAIn operation 304, the authentication transaction is obtained from the blockchain network using the authentication transaction identifier. It will be appreciated that the authentication transaction can be obtained from a copy of the blockchain, whether that copy is local to the computing device or whether it is maintained by a node in the blockchain network. In the unlikely event that the transaction has not yet been confirmed (i.e. has not been in a mined block), the transaction can exist in a pool of unconfirmed transactions; however, in many implementations, the authentication authority can only provide the authentication transaction identifier to Alice once the authentication transaction has been mined.

[0064] The computing device can verify certain things from the authentication transaction. In particular, in operation 306, the computing device can verify that the authentication transaction is signed by the authentication authority. The computing device can have or have access to a list of recognised or accredited authentication authorities and their respective public keys, which can enable the computing device to verify the digital signature. As described, the digital signature can form part of the input to the authentication transaction. By confirming that the authentication transaction is signed by a trusted or recognised authentication authority, the computing device is able to confirm that the authentication is legitimate. Note that if the transaction is on the blockchain, the computing device does not necessarily need to verify the digital signature in the input, as the transaction has already been confirmed and verified by a miner. Instead, the computing device can simply verify that the public key identified in the input is associated with the authentication authority.

[0065] The computing device can also verify that one of the output points of the authentication transaction is still “unspent”, i.e. 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 described above, in most embodiments, this output point is controlled by the authentication authority (alternatives are described below), which enables the authentication authority to revoke the authentication in the event that the key is compromised, has expired or is otherwise no longer valid. Revocation or cancellation is easily performed by having the authentication authority “spend” this output point, thereby removing the output point from the UTXO pool. Confirmation that the output point exists in the UTXO pool can be performed by, for example, 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 party such as a node of the blockchain network.

[0066] In operation 310, the computing device confirms that the public key PK A received as part of the digital certificate from Alice matches the public key PK A in the second output of the authentication transaction.

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

[0068] By recording the public key certification using a blockchain network, the certification authority is able to quickly and easily revoke the certification by "spending" the output point, causing the verification at operation 308 to fail. Thus, the certification authority can revoke the certification of the public key by generating and propagating a transaction that spends the first output of the certification transaction. As discussed above, the first output can be a P2PKH operation that transfers a nominal digital asset to the public key hash address specified in the first output. In these examples, the unlocking script of this first output can require a digital signature from the certification authority, which in turn requires possession of the CA private key PK CTX_PKA The corresponding private key is controlled.

[0069] In some cases, rather than simply revoking the certification, the certification authority can be required to replace / update the certified public key. For example, if the private key is lost or compromised, all parties (e.g., Alice) can request that the certification authority replace the public key PK A_new with a new public key PK new to revoke the old certification and issue a new certification.

[0070] The new certification transaction is characterized by having outputs of the same type, i.e., a P2PKH operation using the new public key (e.g., PK CTX_new ) chosen by the CA and an OP_RETURN field containing PK A_new . However, the inputs can include the CA-controlled output point from the original certification transaction TxID CTX_PKA . By "spending" this output as an input to the new certification transaction, the revocation is achieved by removing the output point from the UXTO pool. Advantageously, the revocation of the old public key certification and the registration of the new public key certification occur in a single transaction. Furthermore, the certification authority does not need to maintain a separate certificate revocation list that is periodically published nor make it available.

[0071] As noted above, in many cases, the first output point of the certification transaction can be controlled by the certification authority such that only the certification authority is able to revoke the certification of the public key. Revocation is based on "spending" the first output point using the private key corresponding to the output point. However, in some cases, it can be advantageous to construct the certification transaction to allow other entities to revoke the certification.

[0072] For example, in some cases, all parties to a public key (e.g. Alice) can have the right to revoke their own public key. Under this arrangement, the first output point in the authentication transaction is controlled by Alice, i.e. references a public key (public key hash) for which Alice has a private key corresponding thereto. That is, the unlocking script for the first output point requires a digital signature from Alice. This arrangement can be advantageous for certain public key authentication scenarios, e.g. registration with an online service. One example of an online service is a social media account on a social media platform. The platform can use the above mechanism to register a user’s public key for use by the platform, thereby enabling the user to interact with the platform and / or other users of the platform on a trusted basis, as their digital credentials are backed by the authentication transaction. The user can then revoke the authentication without the co-operation of the platform, thereby terminating their account.

[0073] In another scenario, more than one output point can be provided, where any of the output points can be “spent” to terminate the authentication. In this scenario, a third party is configured to test whether both (or all) such output points of the authentication transaction exist as unspent transaction outputs in the UTXO pool.

[0074] Alternatively, if revocation from any of the multiple parties is to be facilitated, 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. To this end, a multi-signature can be used in the output.

[0075] In yet another scenario, the multi-signature can be configured to ensure that at least a threshold number of entities agree to the revocation of the authentication. The multi-signature can be configured to require n of m signatures to unlock the output, where n < m. For example, in the case of an organisation (e.g. a corporation, a partnership or other such collection of individuals), only if all or at least a threshold number of certain entities (e.g. a chief executive officer, a chief operating officer, a chief technology officer or other senior executives or individuals involved in the business) sign off on the revocation can the authenticated public key associated with the organisation be revoked.

[0076] It will be appreciated that some or all of the above operations of the various example methods described above can be performed in a different order to that shown and / or can be performed simultaneously without changing the overall operation of these methods.

[0077] Automated authentication verification

[0078] The above methods provide mechanisms for issuing digital certificates that are vouched for by the blockchain network. These mechanisms enable the quick verification of the validity of digital certificates and enable the ability to revoke digital certificates almost instantaneously. As described above, in order to verify the validity of a digital certificate, a node seeking to perform certificate verification checks to see if the outpoint of the certification transaction is in the UTXO set and if the public key in the digital certificate being verified matches the public key in the OP_RETURN field of the certification transaction.

[0079] One potential drawback of the described methods is that there can 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 can be revoked for some reason. Furthermore, the verification of a digital certificate relies on access to and inspection of the UTXO set, which can be difficult or impossible for certain nodes (e.g. lightweight simplified payment verification (SPV) nodes (e.g. digital wallets)). This can require these nodes to rely on third party nodes to perform the verification for them, which creates security and reliability issues. Furthermore, nodes that verify that an outpoint is in the UTXO set must be online and have active access to the blockchain network, which can not be the case for many nodes (e.g. lightweight SPV) at certain times.

[0080] According to another aspect of the application, the verification of a digital certificate can be incorporated into a transaction, such that the transaction only takes place if the digital certificate is valid. This enables lightweight SPV and similar nodes to generate transactions in collaboration with other nodes that incorporate automatic digital certificate verification. Advantageously, this can eliminate the time interval between the verification of a digital certificate and the reliance on that verification when submitting a transaction.

[0081] In some examples below, a node can have its public key certified by a certification authority node in the form of a certification transaction, which can take the form of the example:

[0082]

[0083] The above example is a certification transaction for the certification of the public key PK A of node A. Note that the OP_RETURN output contains a certificate of the public key PK A . 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 with the public key in the certificate contained in the OP_RETURN output.

[0084] Note also that the input is a transaction outpoint controlled by the certification authority and that its unlocking script is signed by the certification authority. The output is a pay-to-public-key-hash (P2PKH) of the certification transaction public key PK CTXA . The public key PK CTXAhas a corresponding private key. In some cases, the private key can be generated by an authentication authority when creating the authentication transaction. The authentication authority can share the private key with node A. That is, when node A requests to authenticate its public key PKA A , the authentication authority can return the transaction identifier TXID CTX of the authentication transaction - PKAand the private key that enables the authentication transaction to be used.

[0085] This certificate can be invalidated or revoked by using an outpoint in a subsequent transaction, which involves using a signature of the corresponding private key to the authentication transaction public key PK CTXA . In this example, both the authentication authority node and node A possess this key.

[0086] As mentioned above, the authentication transaction can be used to automate the verification of digital certificates. Specifically, the automation is in terms of checking the UTXO set. For example, a new transaction (such as a payment transaction) includes an outpoint of the authentication transaction as a prerequisite to being present in the UTXO set. This ensures that the new transaction is only valid if the certificate is still valid and has not been revoked.

[0087] Typically, a node (e.g. Alice) that has a digital certificate authenticating its public key generates a transaction template that includes an outpoint of the certificate as an input. The input is signed with the 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 (e.g. Bob) that participates in the transaction. The other node (i.e. Bob) obtains the authentication transaction based on the reference to the TXID of the authentication transaction in the input of the transaction template, verifies that the purported public key PK A has indeed been authenticated by the authentication transaction, and adds any inputs / outputs to complete the transaction template. The transaction template can then be propagated on the blockchain network. If the input signed by the authentication transaction key fails because the output has already been used in another transaction (i.e. the output is not in the UTXO set), then the entire transaction fails and will not be propagated or mined. If the input signed by the authentication transaction key is valid because it is in the UTXO set, then the transaction is validated, propagated and enters the mempool, eventually into a mined block.

[0088] In one example, the mechanism can be used to verify the address of the recipient. For example, where Alice is requesting a digital asset or some other transfer from Bob, Bob can wish to verify Alice's identity, for example, that her purported public key is authenticated before committing to such a transaction. In this case, Alice can prepare a transaction template that includes a payment to her public key with an input that references an authentication transaction that authenticates that public key. Upon receipt of the transaction template, Bob can retrieve the authentication transaction from the blockchain, verify that the authentication transaction authenticates Alice's public key, and confirm that the authentication transaction is digitally signed by an authentication authority. Bob can then add an input to the transaction template that transfers the digital asset, and the transaction template can be propagated on the blockchain. If Alice's digital certificate is still valid, i.e. it has not been revoked, then the transaction will proceed. An example of such a transaction is as follows:

[0089]

[0090] In the example transaction above, Bob can rely on the fact that if the referenced outpoint from is not in the set of UXT0s as unspent transaction outputs, then the transaction will be rejected as invalid.

[0091] In another example, the mechanism can be used to verify the address of the sender in order to comply with Know Your Customer (KYC) conditions. For example, Alice can be transferring an asset to Bob, and Bob wishes to verify Alice's identity before accepting the transfer. In this case, Alice prepares a transaction template that includes an input that transfers a digital asset and is associated with Alice's public key PK A . The transaction template also includes, as an input, an authentication transaction that authenticates that public key. Upon receipt of the transaction template, Bob can obtain the authentication transaction, verify that the authentication transaction is signed by an authentication authority, and verify that the authentication transaction authenticates Alice's public key. If so, then Bob completes the transaction template by adding an output to transfer the digital asset to a public key address under Bob's control. Such an example transaction can take the following form:

[0092]

[0093] It will be appreciated that in each of the two detailed examples described above, the digital certificate is invalidated as soon as it is used in a transaction to prove the validity of a public key. That is, the certificate can only be used once and is automatically revoked once it has been used. This can be applied in certain circumstances, for example, where a large asset is being transferred to or from a verified address in a one-off transaction. Such a transaction can be used in the case of a car transfer, a real estate transaction, a stock sale or other device high value transfer. However, for small everyday transactions, it can be cumbersome to return to the certification authority to obtain a new certificate each time the certificate is used. Therefore, a certificate that can be used multiple times can be constructed, as will be described below.

[0094] Reference will first be made to Figure 4 which shows, in the form of a flowchart, an example method 400 of verifying a certificate associated with a first node. The method can be implemented by a computing device such as a mobile phone, tablet, personal computer or the like. The computing device comprises one or more processor units and an associated memory storing computer executable instructions which, when executed by the processor units, cause the processor units to perform the operations described. In some cases, the computer executable instructions can be stored in the form of an application (e.g. a wallet application).

[0095] The method 400 provides an example of automatic certificate verification for verifying the identity of a recipient. In this example transaction, node A is the recipient and node B is the sender. The nodes can communicate over a wired and / or wireless network. In some cases, the nodes can communicate using near field communication, for example, via a point of sale terminal. The method 400 begins in operation 402 with node A creating a transaction template. The transaction template comprises an input which references an authentication transaction output from an authentication transaction authenticating the identity of node A (e.g. an authentication transaction public key PK A The output in the authentication transaction is a pay-to-public key operation which references the authentication transaction public key PK The corresponding private key can be referred to as the authentication transaction key. The input of the transaction template is signed by the authentication transaction key The transaction template also comprises an output transferring a resource to the public key PK A of node A.

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

[0097] On receipt of the transaction template, in operation 406, node B identifies the authentication transaction based on the reference to the authentication transaction in the input of the transaction template. Because this reference includes the transaction identifier of the authentication transaction, node B is able to retrieve a copy of the authentication transaction. If node B stores a local copy of the blockchain, it can obtain the authentication transaction by looking it up in the local copy. If not, node B can send a query or request to a blockchain node based on the transaction identifier to obtain a copy of the authentication transaction. In some cases, this verification can be done as proof of the existence of the authentication transaction. That is, if node B is provided with a copy of the authentication transaction and a Merkle proof (Merkle path), it can verify from the block headers that the authentication transaction exists in the blockchain. SPV nodes or other lightweight implementations can have copies of the block headers available to them, even offline, which can enable node B to verify the existence and content of the authentication transaction without necessarily needing real-time access to the blockchain network. Thus, node A can provide node B with a copy of the authentication transaction and its Merkle path as well as the transaction template.

[0098] Once node B has a copy of the authentication transaction, in operation 408, it verifies that the authentication transaction is signed by the authentication authority using the authentication authority key. It also verifies that the public key PK A appears in the OP_RETURN output field of the authentication transaction, confirming that the authentication authority has certified the authenticity of the public key of node A. Node B can also verify the structure of the authentication transaction, in particular that it includes a pay-to-public-key output that references the authentication transaction public key and is consistent with the input of the transaction template.

[0099] It will be appreciated that if these checks fail, for example if the public key of node A cannot be verified as certified, or if the authentication transaction is not constructed as expected, then the method 400 will end as node B will not complete the transaction. However, assuming that node B verifies that the authentication transaction is valid, then in operation 410 it modifies the transaction template to add an input from an address under the control of node B. That is, node B adds a 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 propagate it on the blockchain network.

[0100] In either case, one of two things will happen, as shown in operation 412. If the authentication transaction output to is contained in the UTXO set, that is, it is an unspent output, then the transaction will be validated by nodes in the blockchain network, propagated throughout the network, and added to the mempool of unconfirmed transactions to be mined and included in a block, as shown in operation 414. However, if the authentication transaction output to If the authentication transaction output is not in the UTXO set, e.g. because the certificate has already been used or revoked, then the transaction will not be validated, will not be propagated, and will be rejected by the blockchain network, as indicated by operation 416. In this way, the transaction between node A and node B only occurs if the certificate of node A is valid at the time the transaction is submitted to the blockchain network. Thus, there is no time gap between validating the certificate and relying on that validation when entering the transaction.

[0101] Reference will now be made to Figure 5 which shows, in flowchart form, another example method 500 of automatically validating a digital certificate. As with Figure 4 the method 500 shown in Figure 5 may be performed by computing devices implementing a first node (node A) and a second node (node B). In the example of method 500, a transaction is generated to transfer a resource from node A to node B. For example, node B seeks to validate the identity of node A before accepting the transfer of the resource, e.g. as part of a “know your customer” or anti-money laundering record keeping requirement.

[0102] In operation 502, node A creates a transaction template and includes an input that references an authentication transaction output from an authentication transaction of a public key of node A. The input is signed by node A using an authentication transaction key that corresponds to the authentication transaction public key referenced in the authentication transaction output. Node A also adds an input that transfers the resource. In operation 504, node A sends the transaction template to node B. A

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

[0104] In operation 508, node B validates that the authentication transaction is signed by the authentication authority using the authentication authority key. It also validates that the public key PK A of node A appears in the OP_RETURN output field of the authentication transaction, confirming that the authentication authority has certified the authenticity of the public key of node A. Node B can also validate the structure of the authentication transaction, specifically that it includes a pay-to-public-key output that references the authentication transaction public key and is consistent with the input of the transaction template.

[0105] ​It will be appreciated that if these checks fail, for example if the public key of node A cannot be verified as being authenticated, or if the authentication transaction is not built as expected, then the method 500 will end as node B will not complete the transaction. However, assuming that node B verifies that the authentication transaction is valid, then in operation 510 it can modify the transaction template to add an output to an address controlled by node B. In some cases, node A can have already added an output to transfer resources to node B, in which case node B simply verifies in operation 510 that the output is correct. This completes the transaction template, which node B can then propagate onto the blockchain network. Alternatively, node B can send the completed transaction template to node A, which can propagate it onto the blockchain network.

[0106] After sending the transaction to nodes of the blockchain network, one of two things will happen, as shown in operation 512. If the authentication transaction output of is contained in the UTXO set, i.e. it is an unspent output, then the transaction will be validated by nodes in the blockchain network, will be propagated throughout the network, and will be added to the pool of unconfirmed transactions to be mined and included in a block, as shown in operation 514. However, if the authentication transaction output of is not in the UTXO set, for example because the certificate has already been used or revoked, then the transaction will not be validated, will not be propagated, and will be rejected by the blockchain network, as shown in operation 516. In this way, the transaction between node A and node B only occurs if the certificate of node A is valid at the time the transaction is submitted to the blockchain network. Thus, there is no time interval between verifying the certificate and relying on that verification when entering into the transaction.

[0107] Multiple use certificate

[0108] As mentioned previously, in the example discussed above, it was assumed that once a digital certificate is used in a transaction to prove the validity of a public key, then the digital certificate is invalid because the authentication transaction output will be “spent”. That is, the certificate can only be used once and is automatically revoked once it has been used. In some cases, it can be desirable to have a certificate that can be used multiple times without the node having to obtain a new certificate from the authentication authority after each use.

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

[0110]

[0111] public key The same public key, different public keys that are completely independent of each other, or different public keys that are provably linked to each other. When node A uses the authentication transaction in a transaction template, such as the example given above, node A ensures that the authentication transaction output referenced as an outpoint in the transaction template is one of the m outputs that has not yet been used.

[0112] Node A can revoke its own certificate by submitting a transaction that spends all of the remaining unspent transaction outputs of the certificate. The authentication authority can do this as well to revoke a certificate; however, if the authentication authority does not have a trusted way of knowing which outputs of the authentication transaction have already been spent, it will submit a separate transaction for each output to ensure revocation of the certificate.

[0113] The multiple-use certificate of the example above has the advantage that it can be used by node A up to m times; however, after all of the outputs have been used, node A must obtain a new certificate from the authentication authority. In another example, the authentication verification process can be constructed so that each verification also produces a new outpoint linked to the authentication transaction, thereby establishing a chain of transactions that traces back to the original authentication transaction.

[0114] In one example implementation, the certificate in the form described above can be used if the authentication authority does not need the ability to revoke the certificate. Each time node A uses the certificate in a transaction, it will ensure that the transaction produces a new pay-to-public-key output, which is then used as the authentication transaction output in any subsequent transaction that uses its certificate.

[0115] In another example implementation, to ensure that the authentication authority is able to revoke the certificate, the authentication transaction, and each subsequent transaction in the chain, a multi-signature output is used. The multi-signature output allows a 1-of-2 signature to unlock the output, and it includes the public keys of the authentication authority and node A. One illustrative example is shown below:

[0116]

[0117] It will be appreciated that the authentication transaction public key The corresponding authentication transaction key is able to be used in a verification or revocation transaction. This key is held by node A. It will also be appreciated that the authentication authority has the ability to revoke the key because it has the corresponding private key corresponding to the public key PK CA

[0118] To use the certificate, node A creates a transaction template that includes a 1-of-2 multi-signature output that references the authentication authority and a new authentication transaction key In this way, the transaction that uses the authentication transaction becomes the next transaction in a chain of transactions that links back to the authentication transaction.​

[0119] As an example, consider a transaction between node A and node B in which node B transfers a resource to node A, and node A proves the validity of its public key using its digital certificate. This transaction can take the following form:

[0120]

[0121] In the example transaction above, note that one of the inputs is from a public key PK B controlled by node B. This input is added to the transaction template by node B after node B confirms that the structure of the transaction template is valid and that node A’s certificate is verified.

[0122] The transaction is constructed to transfer the resource y BSV to the public key PK A as the first outpoint. The other input references the certification transaction output From this input, node B is able to identify the certification transaction retrieve a copy of it, and confirm that it certifies the public key PK A of node A and is signed by the certification authority. Node B is also able to confirm that the certification transaction and any subsequent transactions in the chain each contain the certification transaction output, which is a one-of-two multi-signature output with the certification authority as one of the possible signers. That is, the certification authority has the ability to revoke the certification.

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

[0124] After the above transaction is submitted to the blockchain network, node A can subsequently prove its identity using the newly linked public key . For example, in a subsequent transaction with node C, node A can provide a transaction template that includes as an input a reference to the certification transaction output via the newly linked public key and a transaction identifier Node C retrieves the linking transaction and confirms that the referenced outpoint is a one-of-two multi-signature operation with the authorized signers being the newly linked public key and the certification authority public key PK CA . Node C then identifies the input’s certification transaction identifier retrieves a copy of the certification transaction, and confirms that it is signed by the certification authority and certifies the public key PK Aand confirming that the authentication transaction output is a multi-signature output operation with an authorizing signature of the authentication transaction public key and the authentication authority public key PK CA .

[0125] Subsequent transactions involving the authentication of node A proceed in the same way, with another node tracing back through a chain of link transactions to ensure that its authentication transaction output is correctly constructed, until the original authentication transaction is reached.

[0126] Reference will now be made to Figure 6 which shows, in flowchart form, part of a method 600 for verifying a digital certificate using link transactions. The 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. The method 600 begins in operation 602 with node A creating a transaction template. In this example, the transaction template includes an input that references an authentication transaction output from the last transaction in a chain of link authentication transactions that trace back to an original authentication transaction that verifies the identity of node A (e.g. authenticates the public key PK A of node A). The output in the last authentication transaction is a pay-to-public-key operation that references the authentication transaction public key The corresponding private key can be referred to as the current authentication transaction key. The input of the transaction template is signed by the current authentication transaction key generating a signature The transaction template also includes an output that transfers a resource to the public key PK A of node A.

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

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

[0129] Once the original certification transaction is identified, then in operation 612, node B verifies that the certification transaction is signed by the certification authority using the certification authority key. It also verifies that node A's public key PK A appears in the OP_RETURN output field of the certification transaction, confirming that the certification authority has certified the authenticity of node A's public key. It can also verify that the certification transaction output is a choice multi-signature output to the certification transaction public key and the certification authority public key PK CA .

[0130] If node B is satisfied that the original certification transaction is valid, then in operation 614, it adds an input to the transaction template to supply the resource being transferred to node A's public key PK A . The completed transaction template is then submitted to the blockchain network in operation 614, and if the certification transaction output to the certification transaction public key is still valid in the latest certification transaction in the series, i.e., still an unspent outpoint in the UTXO set, then the transaction is processed in operation 618. Otherwise, in operation 620, the transaction is rejected as invalid by the blockchain network.

[0131] In one implementation, the value transferred to each of the series of attestation transaction outputs can be a fixed value x that the validating nodes confirm 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, the value can start with a fixed amount in the original attestation transaction and can decrease by an amount with each use, such that at some point further renewals can not occur. In some implementations, the amount decreased can match the transaction fee amount.

[0132] It will be appreciated that the certificate authority can revoke the certificate by identifying the latest transaction in the series of attestation transactions and spending the either-or multi-signature output using the certificate authority’s key.

[0133] Reference is now made to Figure 7 which illustrates, in block diagram form, a simplified computing device 700 according to examples of the present application. The computing device 700 can perform one or more of the functions described above. In this sense, in some implementations it can serve as the first computing device 102 Figure 1 ), the second computing device 104 Figure 1 ), or the server 106 Figure 1 ).

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

[0135] The computing device 700 can include a processor-executable application 708 containing processor-executable instructions that, when executed, cause the processor 702 to perform one or more functions or operations described herein.

[0136] The various embodiments presented above are merely examples and are in no way meant to limit the scope of the present application. Variations of the innovations described herein will be apparent to those of ordinary skill in the art and it is intended that the application cover such modifications and variations. In particular, features from one or more of the above-described example embodiments can be selected to create alternative example embodiments including features from some example embodiments that are not explicitly described or claimed above. In addition, features from one or more of the example embodiments described above can be selected and combined to create alternative example embodiments including features from some example embodiments that are not explicitly described or claimed above. Modifications to the example embodiments described in this disclosure will be apparent to those of ordinary skill in the art and the general principles defined herein can be applied to other situations. Thus, the scope of the application is not to be determined by the specific examples presented above but only by the claims below.

Claims

1. A computer-implemented method for implementing a blockchain-based transfer of resources between a first node and a second node, the method comprising: receiving, at the second node, a transaction template from the first node, the transaction template containing a first input referencing an authentication transaction output of an authentication transaction, wherein the first input is signed by the first node using an authentication transaction key, and wherein the transaction template includes a public key associated with the first node; obtaining a copy of the authentication transaction and determining that the authentication transaction authenticates the public key associated with the first node and that the authentication transaction is signed by an authentication authority key; modifying the transaction template to complete a transaction template for the transfer of resources; and propagating the transaction template on a blockchain network, wherein the propagated transaction template includes a second input transferring resources to an output address, whereby the transaction template is to be validated by nodes on the blockchain network if the authentication transaction output is included in a set of unspent transaction outputs.

2. The method of claim 1, wherein, The transaction template received by the second node includes an input from the public key associated with the first node.

3. The method of claim 2, wherein, The modifying includes adding an output to the transaction template to a second public key associated with the second node prior to propagation.

4. The method of claim 1, wherein, The transaction template received by the second node includes an output to the public key associated with the first node.

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

6. The method of any one of claims 1 to 5, wherein, The authentication transaction output includes a pay-to-public-key output in the authentication transaction.

7. The method of claim 6, wherein, The authentication transaction output is one of a plurality of pay-to-public-key outputs in the authentication transaction, and wherein each pay-to-public-key output in the authentication transaction involves a different respective public key.

8. The method of any one of claims 1 to 5, wherein, The obtaining includes identifying a last transaction in a series of linked transactions based on a last transaction containing the authentication transaction output, and tracing through the series of linked transactions to identify the authentication transaction.

9. The method of claim 8, wherein, The obtaining further includes verifying that the authentication transaction output is a multi-signature output, the allowed signers of the multi-signature output including the authentication authority key.

10. The method of claim 1, wherein, The set of unspent transaction outputs includes all transaction outputs that have not yet been used as an input to a further transaction, and wherein the set of unspent transaction outputs is maintained by the blockchain network.

11. The method of claim 1, wherein, The authentication transaction output is in a transaction having a transaction identifier, and 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 an index.

12. The method of claim 1, wherein, The obtaining includes sending a request for the authentication transaction to a node in the blockchain network and receiving a response containing the authentication transaction.

13. The method of claim 1, wherein, The obtaining includes receiving a copy of the authentication transaction and a Merkle path associated with the authentication transaction from the first node, and wherein the method further includes verifying that the authentication transaction exists in the blockchain based on the copy of the authentication transaction, the Merkle path, and a set of block headers of the blockchain.

14. A computing device for verifying a certificate associated with a first node, the computing device comprising: one or more processors; memory; computer-executable instructions stored in the memory that, when executed by the one or more processors, cause the processors to perform the method of any of claims 1-13.

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

Images