Method and device for recording work history and proving reputation in blockchain network

Abstract

To provide methods and system of recording work history of a mining node on a blockchain in a blockchain network.SOLUTION: A method includes: a step of mining a first block containing a registration generation transaction, the registration generation transaction including, within a registration information field, a miner identifier for a mining node; and a step of sequentially mining two or more additional blocks, each additional block containing a generation transaction that includes the miner identifier and a reference to the generation transaction of the preceding additional block in the order, the registration generation transaction being the first block in the order. Work history may be verified by tracing the recorded work history and validating the miner identifier. Recorded work history may serve as the basis for a reputation score for the miner, which reflects contributed work evidenced by proof-of-work secured work history.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to blockchain networks, and in particular to recording work history and proving reputation 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] Blockchain systems are typically permissionless, meaning that any node may join or leave the network and other nodes have no control over whether a node participates in the network. This flexibility is important to ensure that resources are allocated efficiently and to allow for the addition of computing resources when needed and for economically justifiable reasons. However, in some instances and in some situations, for purposes of trust, reliability, and stability, it is advantageous to be able to verify whether a node, such as a mining node, is a "reputable node" within the blockchain network. Summary of the Invention

[0006] In one aspect, a computer-implemented method for recording a mining node's activity history in a blockchain within a blockchain network may be provided, the method may include mining, by the mining node, a first block including a registration generation transaction, the registration generation transaction including a miner identifier of the mining node in a registration information field, and mining, by the mining node, two or more additional blocks in sequence, each additional block including a generation transaction including the minor identifier and a reference to a generation transaction of a preceding additional block in the sequence, the registration generation transaction being a first block in the sequence.

[0007] In some implementations, the miner identifier may be a public key for which the mining node holds a private key.

[0008] In some implementations, the creation transaction in each of the additional blocks may include a registration reference that points to the registration creation transaction and a digital signature.

[0009] In some implementations, the reference to the generating transaction of the preceding additional block in the order may include one of a transaction identifier, a block number, or an outpoint.

[0010] In some implementations, the method may further include verifying, by a computing node, the operation history recorded in the blockchain. In some examples, the verifying step may include identifying the last block in the sequence, retrieving the generation transactions from the blockchain in reverse order based on the references to the generation transactions of the preceding additional blocks included in each of the generation transactions, retrieving the registration generation transaction, and verifying the registration of the miner identifier in the registration generation transaction. The registration generation transaction and the generation transaction provide the operation history of the mining node.

[0011] In some implementations, the method may further include determining a reputation score for the mining node based on an operational history of the mining node. In some examples, the determining step includes calculating the reputation score based on a count of a number of blocks in the sequence. In some examples, the determining step includes calculating the reputation score based on assigning a respective weight to each block in the sequence and calculating a sum of the respective weights. In some such examples, assigning a respective weight to each block includes, for each block: determining a mining difficulty score for the block based on a mining difficulty threshold applied when mining the block; setting the respective weights based on the mining difficulty scores; In some examples, the reputation score may be calculated as follows:

number

[0012] In the above formula, Rep ID is the reputation score, i is an index referring to the i-th block, B is the number of blocks in the sequence, and Ti is the target mining difficulty to be applied when mining block i.

[0013] In some implementations, the method may further include recording, by the mining node, a weighted vote in a secure blockchain-based voting system by mining a voting block, the voting block including a generation transaction including the miner identifier, a reference to the recent generation transaction, and a voting signal. In some examples, the voting block generation transaction further includes a reputation score calculated for the mining node.

[0014] In another aspect, the present application may describe a computer-implemented method for verifying the operation history of a mining node in a blockchain in a blockchain network, the method comprising: Identifying blocks mined by the mining node that have generation transactions, the generation transactions including a miner identifier and a reference to a previous generation transaction in an information field; retrieving, from the blockchain, in reverse order, a number of previous generating transactions, each of the previous generating transactions including the minor identifier and a reference to a respective preceding generating transaction in the reverse order, up to a last generating transaction including an entry for the minor identifier; verifying the registration of the minor identifier in the last generated transaction; The production transaction and the plurality of prior production transactions provide the operating history of the mining node.

[0015] In yet another aspect, the present application may provide a computer-implemented method for determining a reputation score of a mining node in a blockchain network based on a blockchain, the method comprising: tracing a chain of linked generating transactions, each of which includes a miner identifier of the mining node in an information field, each of which, except for a first generating transaction, includes a reference in the information field to a previous one of the linked generating transactions in the chain, each generating transaction being in a respective block mined by the mining node; determining, for each of the generated transactions, a mining difficulty score for its respective block; determining the reputation score of the mining node based on the mining difficulty score of each block associated with the originating transaction in the chain; may include:

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

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

[0018] 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]

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

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

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

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

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

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

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

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

[0027] [Figure 8] FIG. 1 illustrates, in block diagram form, a simplified example of a computing node, such as a mining node, in which like reference numbers are used to denote like elements and features. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

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

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

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

[0033] A blockchain is implemented by a network of nodes. Each node is a computing device with a network connection and running software that implements the applicable blockchain protocol. The nodes validate transactions and propagate them to other nodes in the network. Dedicated network nodes, called "mining nodes" or "miners," collect a set of unconfirmed or pending transactions into a block and attempt to "mine" the block. 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, including 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0057] 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, e.g.

number

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

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

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

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

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

[0063] 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".

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

[0065] 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 verify the signature of the mining node using σ to verify the signature of the mining node. Operation 414 may include the node verifying the signature in the OP_RETURN field of the coinbase transaction, or, if present, the signature σ for message m. 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

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

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

[0068] 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0089] 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

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

number

number

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

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

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

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

[0095] 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

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

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

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

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

[0100] At operation 702, the chain of coinbase transactions linked to 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.

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

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

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

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

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

[0106] To cast a vote, a mining node must mine a voting block during a voting window. In the voting block, the miner inserts its miner identifier and a reference to the recent coinbase transaction in the 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 value "yes / no" or "for / against", 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 over other contents of information fields in the coinbase transaction.

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

[0108] 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 IDAfter 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.

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

[0110] 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

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

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

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

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

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

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

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

[0118] 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 computer-implemented method for verifying a history of operations of a mining node on a blockchain in a blockchain network, comprising: Identifying a block mined by the mining node and having a generation transaction, the generation transaction including a miner identifier and a reference to a previous generation transaction in an information field; retrieving, from the blockchain, in reverse order, a number of previous generation transactions, each of which includes the minor identifier and a reference to a generation transaction that precedes each of the previous generation transactions in the reverse order, up to a last generation transaction that includes a registration for the minor identifier; verifying the registration of the minor identifier in the last generated transaction; whereby the generating transaction and the plurality of prior generating transactions provide the operating history of the mining node.

2. 2. The method of claim 1, wherein the searching step comprises searching the blockchain for one or more subsequent production transactions in blocks mined by the mining node after the block, each of the one or more subsequent production transactions including the miner identifier and a reference to a preceding one of the respective ones of the blocks in order.

3. The method of claim 1 or 2, further comprising the step of calculating a work contribution by the mining node based on the work history of the mining node.

4. 4. The method of claim 3, wherein the step of calculating the work contribution comprises the steps of assigning a respective weight to each block mined by the mining node and calculating a sum of the respective weights.

5. The step of assigning a respective weight to each block mined by the mining node includes, for each block, determining a mining difficulty score for the block based on a mining difficulty threshold applied when mining the block; setting the respective weights based on the mining difficulty scores; The method of claim 4 , comprising:

6. 1. A computer-implemented method for determining a reputation score for a mining node in a blockchain network based on a blockchain, comprising: tracing a chain of linked generating transactions, each of which includes a miner identifier of the mining node in an information field, each of which, except for a first generating transaction, includes a reference in the information field to a previous one of the linked generating transactions in the chain, each generating transaction being in a respective block mined by the mining node; determining the reputation score of the mining node based at least in part on a number of blocks associated with the generating transaction in the chain; The method includes:

7. 7. The method of claim 6, wherein the step of determining the reputation score further comprises the steps of: assigning a respective weight to each block mined by the mining node; and calculating a sum of the respective weights.

8. The step of assigning a respective weight to each block mined by the mining node includes, for each block, determining a mining difficulty score for the block based on a mining difficulty threshold applied when mining the block; setting the respective weights based on the mining difficulty scores; The method of claim 7, comprising:

9. The method according to any one of claims 6 to 8, further comprising determining a weighted vote to be attributed to the mining node in a secure blockchain based voting system based on the reputation score.

10. 10. The method of claim 9, wherein determining the weighted vote comprises retrieving data from the secure blockchain based voting system from a voting block mined by the mining node, the data including a transaction that includes the miner identifier, a reference to at least one of the generated transactions that includes the miner identifier, and a voting signal.

11. 1. A computing device comprising: 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 10; 2. A computing device comprising:

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

Images