Method and apparatus for registering and authenticating miner identities in a blockchain network

Abstract

A method and system for registering the identity of a mining node to a blockchain within a blockchain network may include generating a validity check transaction having a first output controlled by the mining node and including a minor identifier, and propagating the validity check transaction on the blockchain network. The method may further include mining, by the mining node, a new block including the creation transaction, wherein the creation transaction includes an information field including the minor identifier and a reference to the validity check transaction. Another node may verify the identity by: receiving the minor identifier and the reference to the validity check transaction; reading the validity check transaction to verify that it includes the minor identifier; and determining that the first output is a unspent transaction output.

Description

[Technical field]

[0001] The present disclosure relates to blockchain networks, and more particularly to registration and authentication of minor identifiers in blockchain networks. [Background technology]

[0002] Mining nodes (or "miners") are the main elements of a blockchain network. In a "proof-of-work" blockchain network, mining nodes compete to achieve proof-of-work to "win" the race to mine a block, thereby collecting transaction fees and newly minted tokens that are reflected in the coinbase transaction in the new block. In this way, miners secure the network and ensure that transactions are valid and that all participating nodes follow the general blockchain protocol. However, most blockchains operate as permissionless protocols, so any node may join and leave the network, and any node can operate as a mining node without securing prior approval from any other node. As blockchains grow in usage and transaction volume, the correct registration and verification of mining node identities (or pools of mining nodes) also becomes more important.

[0003] For example, when changes occur to a blockchain protocol, arbitrary or "top-down" code changes can undermine confidence in the stability and reliability of the system, exposing the blockchain network to attacks or potential fraud or theft. As in any consensus-based system, changes to the underlying code of a blockchain network need to be agreed upon by the entities that make up the system. In practice, this means that mining nodes must agree to changes, as they are the entities that validate transactions, assemble candidate blocks, and perform the costly mining work of new blocks. It can be advantageous to be able to track and verify the identity of mining nodes (or mining pools).

[0004] One mechanism for registering and verifying identities in a computer network is through the use of a public key cryptography infrastructure. The public key of a key pair may represent the node identifier. In such a system, a node obtains a public key pair and then requests registration of its public key with a third-party certification authority. The certification authority performs some level of online or offline authentication of the node and issues a digital certificate for the public key to verify that the public key is associated with the node. The digital certificate may be signed by the certification authority. Different nodes wishing to verify the identity of a node rely on trust in the certification authority to buttress the proof of the node's identity, represented by the digital certificate.

[0005] A fundamental aim of many blockchain systems is to provide electronic transfers and communications that do not rely on trust in a third-party intermediary, and therefore it would be advantageous to provide a system that does not rely on certificate authorities to verify node identifiers. Summary of the Invention

[0006] In one aspect, a computer-implemented method for registering an identity of a mining node in a blockchain within a blockchain network may be provided, the method comprising: generating a validity check transaction having a first output controlled by the mining node and including a miner identifier; propagating the validity check transaction on the blockchain network; mining, by the mining node, a new block including a creation transaction, the creation transaction including an information field including the miner identifier and a reference to the validity check transaction; may include:

[0007] In some implementations, the miner identifier includes a first public key for which the mining node holds a corresponding private key. In some such implementations, the validity check transaction may include a second output providing a second information field, the first public key being within the information field. The second output may use an OP_RETURN code.

[0008] In some implementations, the create transaction may include an OP_RETURN output that provides the information field. In some implementations, the reference to the validity check transaction includes a transaction identifier.

[0009] In some implementations, the information field may further include one or more of an action identifier or a digital signature, the digital signature being generated using a private key corresponding to the minor identifier.

[0010] In some implementations, the method may further include verifying, by the second node, the validity of the minor identifier. receiving the minor identifier; retrieving a copy of the creation transaction from the blockchain; retrieving a copy of the validity check transaction from the blockchain based on a reference included in the creation transaction; verifying that the received minor identifier matches the minor identifier in the create transaction and the minor identifier in the validity check transaction; determining that the first output is within a set of unspent transaction outputs of the blockchain network; In some such implementations, the verifying step may further include verifying that an action identifier in the generation transaction indicates registration. In some such implementations, the verifying step may further include verifying a digital signature in the generation transaction based on the minor identifier.

[0011] In some implementations, the method may further include revoking the minor identifier. In some examples, the revoking step comprises: generating a revoke transaction having as an input the first output of the validity check transaction; digitally signing the revocation transaction; propagating the revocation transaction on the blockchain network; The method may further include revoking the minor identifier by

[0012] In some implementations, the method may further include updating the minor identifier and registering a new minor identifier. generating a new validity check transaction having a new first output controlled by the mining node and including a new miner identifier; propagating the new validity check transaction on the blockchain network; mining, by the mining node, a new block including a new generated transaction, the new generated transaction including another information field including the minor identifier, the new minor identifier, a new reference to the new validity check transaction, a first digital signature based on the minor identifier, and a second digital signature based on the new minor identifier; In some examples, the updating step may further include revoking the minor identifier by generating and propagating a transaction that includes the first output of the validity check transaction as an input.

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

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

[0015] 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. [Brief description of the drawings]

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

[0017] [Figure 1] One simple exemplary method for registering a miner identity on the blockchain is illustrated in the form of a flowchart.

[0018] [Diagram 2] 1 illustrates, in flow chart form, an exemplary method for setting a fast revocation option for registering a minor identity.

[0019] [Diagram 3] One exemplary method for recording miner identities on a blockchain is illustrated in the form of a flowchart.

[0020] [Figure 4] 1 illustrates an exemplary method for verifying a minor identity in the form of a flow chart.

[0021] [Diagram 5] We present one exemplary method for recording work history on a blockchain.

[0022] [Figure 6] 1 illustrates an exemplary method for verifying work history using a blockchain.

[0023] [Figure 7] 1 illustrates an exemplary method for determining a reputation score for a mining node based on a recorded operation history.

[0024] [Figure 8] 1 illustrates, in block diagram form, a simplified example of a computing node, such as a mining node.

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

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

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

[0028] This application refers to hashing or 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 produces 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.

[0029] 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. Although 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, although it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0030] A blockchain is a peer-to-peer electronic ledger implemented using a computer-based decentralized distributed 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 become strung together to create a permanent, immutable record of all transactions written to the blockchain since inception. Transactions contain small programs, known as scripts, that 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 scripting language based on the stack.

[0031] A blockchain is implemented by a network of nodes. Each node has a network connection and an applicable blockchain. protocolA mining node is a computing device having a network that has executable software to run a mining program. 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 succeed in solving their respective block's proof-of-work. In the Bitcoin example, the POW involves hashing a block header that contains 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 that another miner has succeeded in. Variations in the mining process are well known to those skilled in the art.

[0032] 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 inputs reference an unspent transaction output (UTXO) from a previous transaction. Some nodes may maintain a running list or set of UTXOs to allow for fast determination of whether a referenced transaction output is in the UTXO set. 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 thus a unique transaction "outpoint" may 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 (e.g., an outpoint) is in the UTXO set, the transaction output is "unspent" and can serve as an input.

[0033] The unlock 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 unlock script often requires a public key and a digital signature generated with 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 contains a digital signature, and thus the entity associated with that particular public key is effectively signing or attesting to the contents of the transaction.

[0034] Public key cryptography appears ubiquitously in online communications. In many instances, processes and policies are required to provide certainty that a public key is owned in association with a particular entity. The most common approach to ensure that a public key is authentic and has not been compromised is the public key infrastructure (PKI). PKI relies on trusted third parties that "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 certificate.

[0035] As mentioned above, mining nodes are key to securing the blockchain network. Mining nodes are compensated for their work when they win the race to find a valid new block. Compensation comes through transaction fees from individual transactions and from "coinbase" transactions included in the new block. Coinbase transactions have no input and output a predefined amount of tokens (e.g., coins) to miners, effectively generating new tokens. Coinbase transactions may also be called "generation transactions" and the terms may be used interchangeably herein. Coinbase or generation transactions have certain properties that distinguish them from regular transactions. For example, each valid block contains only one generation transaction. Each generation transaction has no input and generates an output of an amount of tokens set by the next-prevailing block reward attributed to a successful miner according to the governing blockchain protocol. Generation transactions are "proof-of-work transactions" because they can only be generated by mining nodes that have successfully mined a block, i.e., achieved proof-of-work.

[0036] In many blockchain systems, a single entity may own, control, or direct a large number of individual computers that operate as mining nodes. In some examples, the resources of multiple mining nodes may be pooled together into a mining pool that harnesses the computing power of a large number of individual processors. Many of the examples below may refer to "miners," "mining nodes," or public-private key pairs held or controlled by a miner / mining node. As understood from the context, these references may include individual computers that implement mining nodes and / or a collection or pool of computers / processors that implement a mining pool owned or controlled by a mining entity.

[0037] Given the importance of mining nodes, it may be advantageous to be able to verify the authenticity and identity of a mining node and / or its purported public key, particularly without relying on trust in a third-party certificate authority.

[0038] Establishing a verifiable minor identity According to one aspect of the present application, a miner may establish a miner identity by mining a block that includes a declaration of the miner identity in a coinbase transaction. The validity of the newly mined block and all transactions therein are verified by the blockchain network. The inclusion of a mining node's own miner identity in a coinbase transaction is a declaration of identity backed by proof-of-work. The miner identity in the following example is a public key. A third-party CA does not need to verify the association between a mining node and its declared public key because the association is backed by the blockchain network and the proof-of-work.

[0039] To realize possible revocation of a miner identity, for example if the corresponding private key is compromised, the miner first generates a validity check transaction in which the miner identity is declared and for which there are outputs controlled by the miner. The coinbase transaction may contain a reference to this validity check transaction. Part of the identity verification operation performed by another node may be to verify that the validity check transaction has not been "revoked" through the transfer of outputs controlled by the miner. That is, the miner may invalidate its own miner identity by "spending" the output of the validity check transaction, thereby removing it from the unspent transaction (UXTO) set. This provides a fast revocation mechanism that does not rely on mining new blocks to revoke the miner identity.

[0040] Referring to FIG. 1, one exemplary method 100 of establishing a miner identity in a blockchain network is illustrated in the form of a flow chart. The method 100 includes a configuration operation 102 and a registration operation 104. The configuration operation 102 includes generating and propagating a validity-check transaction (VCT). The VCT includes an arbitrary input and two outputs. One output is an output controlled by the miner that assigns arbitrary tokens to addresses controlled by the miner. The second output of the VCT is a public key PK, chosen by the miner in this example. ID The miner then has to provide the corresponding private key, sk ID The information field may be the OP_RETURN field in a Bitcoin-based implementation. The miner identity (e.g., miner ID) is, in this example, the public key PK ID It is.

[0041] The VCT propagates across the blockchain network and is eventually finalized through inclusion in a mined block, thereby making the VCT on-chain.

[0042] The registration operation 104 includes the mining node successfully mining a new block. Mining the block includes assembling a candidate block that includes multiple transactions selected from a memory pool of unconfirmed transactions. The mining node also inserts the coinbase transaction into its candidate block. The mining node then attempts to mine the block by repeatedly incrementing the nonce in the header and hashing the block header to find a hash that is lower than the mining difficulty setting. If another mining node is successful, the miner verifies that the other mining node's new block is valid, then generates a new candidate block and tries again.

[0043] In operation 104, the mining node successfully mines a new block, and the new block includes a coinbase transaction. The coinbase transaction itself contains a miner identity, e.g., PK ID and a reference to the VCT. The reference is a transaction identifier in the VCT, e.g., TxID VCT It may be.

[0044] When a mining node successfully mines a block containing a coinbase transaction that declares its miner identity, it has successfully established its own miner identity. The identity is verifiable and can be revoked or updated by the mining node, if necessary, in a provable and traceable manner. Furthermore, the identity and its association with the mining node are backed by proof-of-work and secured by the network, making it possible for a third party to verify the miner's identity (e.g., its public key, PK), without requiring trust in a certification authority.ID ), which allows for reliance on the miner identity. The miner identity may then be used for a number of purposes, including, among others, tracking miner activity, proving miner identity or status, establishing or engaging in secure encrypted communications with miners, and ranking miners for various purposes.

[0045] 2, there is shown one exemplary configuration method 200 that may be used in the method 100 for establishing a miner identity. The method is, in this example, performed by a mining node.

[0046] In operations 202 and 304, the mining node generates a private key ssk ID Select the corresponding public key PK ID Find the public key PK ID is the minor identifier.

[0047] In operation 206, the mining node then generates a validity check transaction that includes an arbitrary input and two outputs. The input may be any UTXO for which the mining node holds the corresponding private key; that is, any UTXO is controlled by the miner. In many implementations, the input may be a coin or token amount sufficient to offset the transaction cost associated with the VCT to ensure that the VCT is included in a block. In some implementations, the minimum token amount may be established by policy.

[0048] One of the outputs is to an address controlled by the mining node, i.e., the output is to an address for which the mining node holds the corresponding private key that allows the mining node to unlock the associated locking script. In some instances, the output address is VCT may be labeled as PK VCT is an arbitrary public key chosen by the mining node, and PK VCTFor each bitcoin, the mining node holds the corresponding private key. The output may be, for example, a pay to public key hash (P2PKH) operation specifying a transfer to a public key hash (e.g., a Bitcoin address) selected and controlled by the mining node.

[0049] Other outputs include a non-operational information field into which information may be inserted. In particular, the field includes a minor identifier. In Bitcoin-based implementations, outputs may provide the information field using the OP_RETURN opcode.

[0050] Non-operational information fields may be included in transactions for the purpose of disclosing information within the transaction that is not necessarily implemented as an "output" of the transaction, as that term is understood. protocol However, the term "output" in these examples referring to information fields is intended to include such possible implementations in alternative blockchain protocols.

[0051] Once the VCT is generated in operation 206, the mining node then propagates the VCT across the blockchain network in operation 208. Those skilled in the art will appreciate that propagation of the VCT may involve each node in the network validating the transaction and then sending it to all other nodes to which the VCT is connected, resulting in the transaction being rapidly propagated throughout the entire blockchain network. As an unconfirmed transaction, it is inserted into a memory pool. From the memory pool, individual mining nodes select the transaction for inclusion in a candidate block. Thus, it is finally "confirmed" by inclusion in a mined block. In operation 210, the mining node evaluates whether the VCT is confirmed by inclusion in a mined block. Once confirmed, in operation 212, the mining node sends the transaction identifier TxID to the mined block. VCTIt is understood that in some implementations, the mining node may record the transaction identifier before the VCT is mined.

[0052] The VCT portion of the blockchain allows PK VCT That first output to forms part of the UXTO set of "unspent" outputs until a mining node chooses to move / transfer the tokens associated with that output. This UXTO acts as a validity check transaction. As long as it is part of the UTXO set, the miner identifier in the VCT remains valid and cannot be revoked. As soon as it is no longer present in the UTXO set, the miner identifier in the VCT is no longer valid.

[0053] 3, there is shown an exemplary registration method 300 that may be used in the method 100 for establishing a minor identity. The method is performed by a mining node in this example. The method 300 assumes that a setup operation has already occurred that generates a validity check transaction associated with the minor identifier.

[0054] In operation 302, the mining node generates a candidate block. The candidate block includes a number of transactions selected from a memory pool of unconfirmed transactions. As reflected by operation 304, the mining node then inserts a coinbase transaction into the candidate block. In addition to mining a predetermined number of new tokens or coins for the mining node, the coinbase transaction also includes a miner identifier PK ID and an information field containing a reference to the VCT. The reference is a transaction identifier TxID VCT The information field may be provided, for example, using an OP_RETURN code or an expression.

[0055] In addition to the miner identifier and a reference to the VCT, the information field may contain additional information. For example, it may contain an action identifier or code indicating what action is implemented by the coinbase transaction. In this example, the action may be "register", indicating that the mining node is publicly registering its miner identifier. It may alternatively contain a signature. For example, the signature may be a signature of the rest of the information field. For example,

number

[0056] Once a candidate block with this coinbase transaction is generated, the mining node attempts to mine the block, as indicated by operation 306. It also evaluates whether the competing node will be successful in mining another block, as indicated by operation 308. If the competing node wins the race to mine the block, the mining node evaluates the other block, adds it to the blockchain, and returns to operation 302 to build a new candidate block and try again.

[0057] If a mining node successfully mines a candidate block, it will receive the transaction identifier TxID of the coinbase transaction. REG Alternatively, note that since it only contains one coinbase transaction, we only need to note the block number, and other nodes can identify it based on the block number.

[0058] When a mining node successfully mines a block with a registration coinbase transaction, it successfully registers its own miner identifier and publishes it on the blockchain. The miner identifier, e.g., the public key PK ID Another node receiving the public key may verify that the public key is valid and associated with the mining node without relying on trust in a separate certification authority.

[0059] 4 illustrates, in flow chart form, one example method 400 that a node may perform to verify a minor identifier, according to an aspect of the present application. ID PK is any node in or outside of the blockchain that should validate the public key PK. Validation can be, for example, to verify or authorize a request from a miner, to establish a communication session with the miner, or to verify the public key PK. ID The verification may occur as part of proving the validity of the sigma-based cryptocurrency and its association with a mining node.

[0060] At operation 402, the node receives the minor ID (PK ID ) and the registration transaction identifier (TxID REG , or in some examples, the block number in which the registered coinbase transaction appears. Operation 402 may further include retrieving or receiving a message that the mining node claims to have signed. The message m and the signature σ m may be provided by a mining node. In some examples, the message and its signature may be part of a digital certificate provided or issued by the mining node as proof of its identity.

[0061] At operation 404, the node registers a transaction identifier TxID REG ., it then verifies or validates certain data in the registered coinbase transaction from the blockchain at operation 406. For example, the node may parse the OP_RETURN field to extract the information in that field from the coinbase transaction. From the parsed information, it may extract the VCT transaction identifier TxID VCT It is obtained by using the same public key PK provided by the mining node in the OP_RETURN field. ID and that the "action" is "register".

[0062] At operation 408, the node may retrieve the VCT from the VCT transaction identifier issued in the registration coinbase transaction. As shown by operation 410, the node may search for a VCT whose OP_RETURN field in the VCT matches the same public key PK ID It may then evaluate whether other outputs in the VCT remain "unspent", i.e., remaining part of the UTXO set of available output points. This may involve querying the UTXO set database, either directly or through intermediate nodes. The query may include the transaction identifier TxID VCT The validation may be based on an outpoint identifier, which may include an index indicating which output. If the output does not appear in the UXTO set, the minor identifier is invalid because it has been cancelled or replaced. Therefore, validation fails.

[0063] However, if the outpoint is within the UXTO set, then at operation 414 the node ID can be treated as the verified public key of the mining node, and PK ID Operation 414 may include the node verifying the signature of the mining node using the signature in the OP_RETURN field of the coinbase transaction, or verifying the signature σ for message m, if present. m Note that the signature check may involve verifying the mining identifier, i.e., the verified registered public key PK, or both. Obviously, if the signature check fails, the intended mining node cannot be verified as the holder of the corresponding private key, and the verification fails. If the signature check succeeds, the mining node will verify the mining identifier, i.e., the verified registered public key PK, ID The mining node associated with the

[0064] As mentioned above, a registered miner ID can be revoked by removing the first output of the VCT from the UXTO set. This is done through "spending" the output by using it as an input to any other transaction. This may include transferring any tokens assigned to the first output to a new address in the revocation transaction. The creation and propagation of the revocation transaction is sufficient to cause any validation of the miner ID to fail, as validating nodes will no longer be able to identify the output in the UXTO set. However, the miner may also register the revocation by including an OP_RETURN field in the coinbase transaction for its next mined block. In one example, the OP_RETURN may include the action "revoked" and the miner ID. In some implementations, it may further include the transaction identifiers and signatures of both the registration transaction and the revocation transaction.

[0065] In many cases, rather than simply revoking a miner ID by compromising its private key, a mining node may wish to "update" or replace its miner ID. This may be due to disclosure or theft of the private key, or may be done periodically as part of risk management to ensure regular updating of key material.

[0066] Old Minor ID PK ID-OLD To update, a mining node first creates a new public key, PK ID-NEW From that process, the mining node generates a new VCT transaction identifier TxID VCT-NEWThe mining node then mines a new block with the new coinbase transaction to register the new miner ID. However, to link it to the old ID and any history of work of the old ID, the miner may use the action "Update ID" or "Update ID" to signal that the coinbase transaction is not the initial registration of the miner ID, but is replacing the previous miner ID. The contents of the OP_RETURN field in the update coinbase transaction may include:

number

[0067] In this example, it is understood that the update operation involves the mining node providing up to three signatures, one associated with the old ID, one associated with the old VCT, and one associated with the new miner ID. In some examples, the old VCT signature may not be included.

[0068] It is also understood that a mining node may invalidate a previous miner ID through the use of the output from the old VCT as an input to some other transaction. In one example, the output may be an input to a new VCT. In another example, a mining node may wait to propagate a separate revocation transaction to invalidate its old miner ID until it has successfully mined a block and registered an updated miner ID.

[0069] The above-described system allows miners to establish and register their provable identifier on the blockchain. By including it in the coinbase transaction of a mined block, the miner proves that they are a bona fide mining node, and the validity of the identifier and associated materials is backed by the proof-of-work. The VCT provides a mechanism for rapid revocation, if necessary. In some exemplary implementations, the VCT may require, by policy, that at least a predefined token or coin value be assigned to the output, thereby backing up the proof-of-work with a proof-of-stake. Advantageously, the above-described system avoids the need for trust in a trust authority, involves no additional work for the mining node, and involves little additional data in the block.

[0070] The above described registration system and method allows miners to prove their identity and provides mining nodes with digital proof that can be verified by other nodes without relying on a trusted authority. Furthermore, as described below, the miner identifier may be used to provably chain together coinbase transactions from blocks mined by the miner. This provides miners with a verifiable history of operations associated with their miner ID. This history of operations may be useful in establishing a number of things including miner status, entitlement to access certain resources, ranking within a hierarchy of miners for some purpose, etc. In the following description, this history of operations may be referred to as a "proof of reputation" system.

[0071] Proof of reputation In one aspect, the present application provides a method and system for recording and verifying miner activity history on a blockchain. As described, in the following example, the activity history is recorded by a chain of linked coinbase transactions in a block mined by a mining node. The activity history may be used in some implementations to determine a reputation score for the mining node. The reputation score may be used in a number of applications, including, by way of example, miner voting behavior.

[0072] In some of the implementations described below, the coinbase documents each include a minor identifier in an information field. The minor identifier may be established and verifiable in some implementations using the methods and systems described above. However, in some implementations, other techniques or systems may be used to establish and verify the minor identifier. Thus, the work history and proof-of-reputation examples described below do not necessarily require the use of the minor identifier registration process described above in all implementations.

[0073] As mentioned above, one mechanism for registering a miner identifier is to include the miner identifier in the coinbase transaction of a block mined by the associated mining node. The miner identifier may appear in an information field, such as an OP_RETURN field, in the coinbase transaction. The information field may further include a signature or other data. As mentioned above, in some implementations, the information field may include a reference to a validity check transaction. This allows for fast revocation and easy verification of the miner identifier by others who have not revoked the miner identifier.

[0074] The coinbase transaction may further be used in conjunction with the registered miner identifier to record the activity of the mining node. FIG. 5 illustrates, in flow chart form, one exemplary method 500 for recording the activity of a miner in a blockchain. The method 500 is performed by a mining node associated with the miner identifier. The miner identifier may be a public key, and the mining node holds the corresponding private key of the public key, i.e., the miner identifier is a PK ID It may be.

[0075] The method 500 includes registering a miner identifier at operation 502. As described above, the registration operation includes publishing the miner identifier in a registration coinbase transaction in a block mined by the mining node.

[0076] At operation 504, the mining node continues to attempt to mine new blocks. In particular, the mining node constructs a new candidate block and inserts a coinbase transaction that includes an information field that includes the miner identifier. The information field of the coinbase transaction further includes a reference to a previous coinbase transaction in a block mined by the same miner. The previous coinbase transaction is a block that was recently mined, and the coinbase transaction includes the miner identifier. When a second block is mined, the reference is to the registered coinbase transaction. Subsequent mined blocks from the mining node include the coinbase transaction in the order they were mined, linked by a reference to the coinbase transaction of the recently mined block. The reference may be, for example, the transaction identifier of the coinbase transaction, such as the TxID. In some examples, the reference may be to a block number that includes the coinbase transaction, based on which the node can identify the coinbase transaction in the block. In some examples, the reference may be an "outpoint" that includes the TxID and an index that points to one of the outputs of the coinbase transaction, specifically the OP_RETURN output.

[0077] In some implementations, the information field includes additional information. For example, the information field may include a reference to the coinbase transaction from the most recently mined block from the mining node, as well as a reference to the registered coinbase transaction in all subsequent blocks mined by the mining node. As another example, the information field may include a digital signature generated based on the miner identifier, i.e., using a private key associated with the miner identifier. The digital signature may be, for example, of a reference included in the information field.

[0078] Once a candidate block with a coinbase transaction is generated in operation 504, the mining node attempts to mine the block in operation 506. In operation 508, the mining node further monitors to receive a notification of a new block from another mining node. If the other node is successful in finding the new block, the mining node verifies that the new block is valid according to the applicable blockchain protocol in operation 510 and adds the new block to the blockchain. If the mining node is successful in mining the candidate block before receiving a notification of the new block from another node, in operation 512, the mining node quickly propagates the successful mining of the candidate block on the blockchain network and adds the new block to the blockchain. Once a new block is found, whether the new block on the blockchain comes from the mining node or another node, the mining node returns to operation 504 and tries again to build a new candidate block.

[0079] Obviously, the above cycle will result in a chain of linked coinbase transactions linking blocks mined by a mining node, if the mining node is ever successful in mining a new block, back to the original registered coinbase transaction from the recent block. Because the OP_RETURN data is visible on the blockchain, the linked set of coinbase transactions, each containing a miner identifier, is immediately identifiable as a public record of the mining node's work history.

[0080] 6, one exemplary method 600 for verifying miner activity history from a blockchain is shown. Method 600 may be performed by any computing node, whether or not it is part of a blockchain network of nodes.

[0081] At operation 602, the computing node identifies the coinbase transaction. This identification may occur in a number of possible ways. For example, a mining node may provide the computing node with its intended identity and a transaction identifier of the coinbase transaction. The transaction identifier may refer to a recently mined coinbase transaction generated by the mining node. In some circumstances, the mining node may provide this information to the computing node in connection with a request to participate, vote, communicate, or as part of an assertion that the mining node has an associated reputation, particularly of its identity and work history. This assertion may be issued by the mining node in the same manner, and the computing node may access and retrieve information from the reputation. Regardless of the context or mechanism, the computing node obtains information that identifies the particular coinbase transaction as part of the particular mining node's intended work history.

[0082] At operation 604, the computing node evaluates whether the coinbase transaction includes a miner identifier in the information field. In many circumstances, the computing node has obtained the intended identifier of the mining node, and operation 604 may include verifying that the same identifier appears in the coinbase transaction. If not, method 600 fails because the coinbase transaction does not verify the work history for the intended miner identity.

[0083] At operation 606, the computing node further determines whether the information field of the coinbase transaction includes a reference to a previous coinbase transaction. The reference may be, for example, a TxID number. In some examples, the reference may be a block number or height that identifies the block where the coinbase transaction should be found, or may be an outpoint of the previous coinbase transaction. If a reference exists and is to a previous (lower block height) mined coinbase transaction, at operation 608, the computing node retrieves a copy of the coinbase transaction from the blockchain and returns to operation 604 to verify that it points to the miner identifier and the previous coinbase transaction. In this manner, the computing device traces back through the linked set of coinbase transactions using a reference in the information field of the coinbase transaction that is linked to the previous one in the mined order.

[0084] At operation 606, if one of the coinbase transactions does not include a reference to a previous coinbase transaction, the computing node evaluates whether it is a registered coinbase transaction, i.e., the first in the chain. They may be verifiable from an information field that may include an indication that it is a registered coinbase transaction, such as "Action:Registration" or an equivalent code or indicator. In some examples, alternatively or additionally, it may be verified based on all other coinbase transactions in the chain identifying it as a registered coinbase transaction. If it is not a registered coinbase transaction, the chain is broken and method 600 fails to verify the working history. If so, the working history is identified and at operation 612 the computing node may proceed to verify the minor identifier. As discussed above, in some embodiments, this may include utilizing a validity check transaction and associated verification process.

[0085] The above process, as an example, allows a third-party computing node to verify that a particular mining node has a particular work history. That is, a computing node can immediately trace the work history of a mining node, which provides a verifiable reputation proof for the mining node. A mining node with a long history of producing valid blocks is considered more trustworthy, important, trustworthy, and delegable or invested in than a mining node with little or no work history. Based on this, the "proof-of-work" not only serves to determine which blocks are valid and which miners are currently being rewarded for their investment in computing power, but also serves to reinforce the foundation of miner reputation to invest in computing power and delegation to build a particular blockchain.

[0086] The mining process involves searching for a block header hash that is lower than a target mining difficulty threshold. The search involves incrementing a nonce value in the header, hashing the block header, evaluating whether the hash result yields a number lower than the mining difficulty threshold, and if not, incrementing the nonce value and trying again. The mining difficulty threshold is set by the protocol and is adjusted periodically based on the blockchain protocol to produce blocks approximately every 10 minutes. The adjustment occurs so that the blockchain network takes into account changes in the overall hash power in the network. As hash power is added, the mining difficulty is changed to ensure that it is not generated too quickly and too easily. In the Bitcoin Core protocol, for example, the mining difficulty is adjusted to 2016 blocks (approximately 14 days). In the Bitcoin Cash or Bitcoin SV protocol, the mining difficulty is adjusted to 144 blocks, for example.

[0087] The block header contains a field, nBits, that specifies the current mining difficulty threshold used for that block. The mining difficulty threshold is expressed in base 256 scientific notation. Thus, if the following is 4 bytes:

number

number

[0088] a 1 The value of is always 2 256 To ensure that it remains smaller, it must be within the following range:

number

number

[0089] In another aspect of the present application, a reputation score may be determined for a mining node based on its verified operating history, which, as described above, may be represented by a chain of linked coinbase documents that attest to an association between the mining node, its miner identifier, and the set of blocks mined by the mining node.

[0090] In one exemplary implementation, a mining node's reputation score is determined based on the number of blocks it has mined, and thus the number of linked coinbase documents. This example provides equal weighting to any block at any point in the blockchain history if it forms part of a chain of mined blocks via a linked coinbase transaction.

[0091] In another example implementation, the reputation score may be determined based on a weighted number of blocks mined. That is, each block may have a weight associated with it. In one example implementation, the weight may be based on the block height. For example, one implementation may be to give a greater weight to older blocks. In another example, an implementation may be to give a greater weight to more recent blocks.

[0092] In another implementation, the weights assigned to blocks may be based on the block mining difficulty, i.e., blocks that have a lower mining difficulty threshold, i.e., require more hash power to mine on average, may be given a greater weight in determining the reputation score. In one example of such an implementation, the reputation score may be determined as a function of the target mining difficulty of each block that includes one of the coinbase documents in the chain of linked coinbase documents.

[0093] For example, if the minor reputation score is Rep ID and the target mining difficulty of block i is T i If B is the number of blocks in the work history, then the miner reputation score may be calculated as follows:

number

[0094] In some examples, the reputation score may be based on the entire work history, or may be based on a window up to a maximum number of recent blocks, i.e., a "rolling" reputation score. In some examples, the window may be based on any block from the work history that falls within the blockchain height, e.g., within X number of blocks of the current blockchain height.

[0095] In some example implementations, the current reputation score may be calculated by a mining node and included in an information field of each coinbase transaction.

[0096] In some examples, the reputation scores may be normalized, e.g., by dividing the reputation score by the maximum reputation score, e.g., the reputation scores resulting from all blocks in a blockchain or window. This ensures that all reputation scores are between 0 and 1.

[0097] 7, an example method 700 for determining a reputation score of a mining node is shown. The example method 700 may be performed by the mining node, by another blockchain node, or by a computing node external to the blockchain network.

[0098] At operation 702, the chain of linked coinbase transactions for a particular mining node is traced, for example as described above with respect to FIG. 6. From tracing the coinbase transactions, the work history of the mining node is identified. At operation 704, the mining difficulty thresholds of each block that contains one of the coinbase transactions are determined. Next, at operation 706, the reputation score of the mining node is determined by applying a function to the set of mining difficulty thresholds. As described above, this may include summing the mining difficulty thresholds (or their inverses). Additionally or alternatively, a weighted function may be applied. The result is the reputation score of the mining node, which is the output of operation 708.

[0099] The reputation score is a quantifiable measure of a mining node's contribution to the blockchain that can be used in many scenarios. Advantageously, all data determining and assessing the miner identity and its associated reputation score are publicly available from the blockchain and are verifiable thanks to the immutable properties of the blockchain backed by proof-of-work. To prevent malicious behavior, the reputation score of a mining node can only be improved through mining blocks, i.e., through positive contributions to the stability of the blockchain network.

[0100] Reputation scores are developed by mining nodes by including their miner identifier and linking it to the previous block in the coinbase document. The contents of the coinbase document are in the control of the mining node, meaning that mining nodes do not need to rely on third-party verification or attestation to build reputations. Furthermore, mining nodes cannot forge or tamper with reputations.

[0101] The ability to verifiably determine the reputation score of a mining node with an associated miner identifier can be used in a number of applications. For example, eligibility to participate in a particular protocol or activity may be based on mining nodes having a minimum threshold reputation score, to allow only miners with a particular background to be involved. Another possible application is voting. In particular, when changes are proposed to the underlying blockchain protocol, miners are tasked with submitting a vote, which may be weighted in some way. One option is to weight the vote based on the reputation score, thereby giving more weight to miners with higher reputation scores based on the miners having done more work to build on the existing blockchain.

[0102] One exemplary voting scheme used in blockchain involves opening a time window during which miners can vote, then counting votes based on blocks mined during the time window. This awards the most votes to miners with the most hash power during the time window, and does not consider contribution history. This can result in "hash wars" and makes the system vulnerable to "rented hashes," where miners interested in skewing the voting results temporarily commit huge amounts of computing power to the blockchain in order to dominate the blockchain's hash power during the window, but do not have the resources or interest to commit such amounts of computing power to the blockchain for the long term. In some instances, "rented hashes" are sustainable in that they are an uneconomical allocation of resources, but they incur costs to the miners to enforce the outcome of the vote. Miners thus obtain voting influence that is out of proportion to the miners' actual involvement and investment in the blockchain.

[0103] In one example, the process by which miners vote is as follows: mining nodes vote by sending their miner identifier, e.g. PK ID and the associated reputation score Rep ID Once a person has registered, they may be allowed to participate. Voting occurs over an agreed upon time window from a start time to an end time (or from a start block height to an end block height). The mechanism for achieving agreement on the window and timing for any vote may be on-chain or off-chain.

[0104] To cast a vote, a mining node must mine a block during the voting window. In the block, the miner must include their miner identifier and mostThe miner may also include a reference to a recent coinbase transaction. The miner may also include its calculated reputation score in some implementations. The mining node may also include a voting signal. Depending on the vote, the signal may be a binary "yes / no" or "for / against" value, or may be a multi-valued signal such as a choice between three or more options, a ranking of three or more options, etc. In some examples, the coinbase transaction may further include a digital signature based on a private key corresponding to the miner identifier. The digital signature may be overridden by other contents of information fields in the coinbase transaction.

[0105] In some implementations, a single miner may be eligible to vote multiple times during the voting window. In some other implementations, a single miner may be eligible to vote multiple times per miner, i.e., the associated miner identifier PK ID Only one vote is allowed per window. In the latter case, if a miner mines more than one block in which they intend to cast a vote, a policy may be applied to determine which one to count. For example, the policy may be to take the earliest (lowest block height) vote. Alternatively, the policy may be to take the latest (highest block height) vote, allowing miners to change their vote during the window.

[0106] Any vote monitor may verify that a vote is valid by verifying the miner identifier as described above, and by verifying the reputation score associated with the miner identifier as described above. If a signature is required as part of the vote coinbase transaction, it prevents another miner from maliciously mining a block and their PK ID After the voting window has ended, all information is recorded and can be verified on the blockchain, so any observer may determine the outcome by adding up the votes weighted by the reputation score for each option.

[0107] By tallying votes using historical block data, rather than current and future block data, votes can be cast over a relatively short period of time during which vote weights are calculated with enough proof-of-work data to accurately reflect the chain. This allows for a relatively short voting period without the risk of vote weights being disrupted by temporary hash bursts.

[0108] However, voting is done by PK to mine a new block. ID Since it requires a block time of 10 minutes, sufficient time must be given for miners to be able to cast their votes. Assuming a 10 minute block time, PK ID If a miner with x has a network hashrate of x%, then the probability of mining at least one block in t time is:

number

[0109] Table 1 below gives P for various x and t. [Table 1]

[0110] From the above table, PK ID Even if a shard has only 1% of the network hashrate, the 72 hour voting period almost guarantees that they will be able to mine a voting block.

[0111] In at least one exemplary model of a possible hash war scenario, the reputation system described above can be shown to reduce the effectiveness of rented hashes, such that even if an attacker controls 75% of the network for 14 days, he or she can only accumulate 23% of the voting power.

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

[0113] Referring to FIG. 8, a simplified computing device 800 is illustrated in block diagram form according to an example of the present application. The computing device 800 may perform one or more of the functions described above. The computing device 800 may be, for example, a mining node. In some implementations, the computing device 800 may be a non-mining node that operates to verify data recorded in the blockchain, such as, for example, a miner identifier, a miner work history, a miner reputation score, or a miner voting block.

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

[0115] Computing device 800 may include processor-executable applications 808 that include processor-executable instructions that, when executed, cause processor 802 to perform one or more of the functions or operations described herein.

[0116] The various embodiments described above are merely examples and are not meant 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 combinations of features not explicitly shown 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 shown above. Features suitable for such combinations and combinations will be readily apparent to those skilled in the art upon review of the present application as a whole. The subject matter described in the present specification and claims covers and encompasses all appropriate technical modifications.

Claims

1. 1. A method of registering an identity of a mining node in a blockchain within a blockchain network, comprising: generating a validity check transaction having a first output controlled by the first mining node and including a miner identifier; propagating the validity check transaction on the blockchain network; mining a new block containing a creation transaction, the creation transaction including an information field containing the miner identifier and a reference to the validity check transaction; The method includes:

2. 2. The method of claim 1, wherein the miner identifier comprises a first public key for which the first mining node holds a corresponding private key.

3. 3. The method of claim 2, wherein the validity check transaction includes a second output providing a second information field, the first public key being within the second information field.

4. The method of claim 3 , wherein the second output uses an OP_RETURN code.

5. The method of any one of claims 1 to 4, wherein the generate transaction includes an OP_RETURN output providing the information field.

6. The method of any preceding claim, wherein the reference to the validity check transaction comprises a transaction identifier.

7. The method of any one of claims 1 to 6, wherein the information field further includes one or more of an action identifier or a digital signature, the digital signature being generated using a private key corresponding to the minor identifier.

8. When the one or more mining nodes include a plurality of mining nodes, a second mining node of the plurality of mining nodes performs the following: receiving the minor identifier; retrieving a copy of the creation transaction from the blockchain; retrieving a copy of the validity check transaction from the blockchain based on a reference included in the creation transaction; verifying that the received minor identifier matches the minor identifier in the create transaction and the minor identifier in the validity check transaction; determining that the first output is within a set of unspent transaction outputs of the blockchain network; The method according to any one of claims 1 to 7, further comprising the step of verifying the validity of the minor identifier by:

9. The method of claim 8 , wherein the step of validating further comprises the step of validating that an action identifier in the create transaction indicates registration.

10. The method of claim 8 or 9, wherein the step of verifying further comprises the step of verifying a digital signature in the generated transaction based on the minor identifier.

11. The first mining node performs the following: generating a revert transaction having as an input the first output of the validity check transaction; digitally signing the revocation transaction; propagating the revocation transaction on the blockchain network; The method according to any one of claims 1 to 7, further comprising the step of revoking the minor identifier by:

12. The first mining node performs the following: generating a new validity check transaction having a new first output controlled by the first mining node and including a new miner identifier; propagating the new validity check transaction on the blockchain network; mining a new block containing a new generation transaction, the new generation transaction containing another information field containing the minor identifier, the new minor identifier, a new reference to the new validity check transaction, a first digital signature based on the minor identifier, and a second digital signature based on the new minor identifier; The method according to any one of claims 1 to 7, further comprising updating the minor identifier and registering the new minor identifier by:

13. The method of claim 12, further comprising the step of revoking the miner identifier by generating and propagating, by the first mining node, a transaction that includes the first output of the validity check transaction as an input.

14. A computing device that manages a public key infrastructure using a blockchain network, the computing device being a mining node, one or more processors; Memory, computer-executable instructions stored in said memory, which, when executed by said one or more processors, cause said processors to perform a method according to any one of claims 1 to 13; 2. A computing device comprising:

15. A computer readable medium storing processor executable instructions for managing a public key infrastructure using a blockchain network, the processor executable instructions, when executed by one or more processors, cause the processors to perform the method of any one of claims 1 to 13.

Images