Sending hash values

Abstract

1. A computer-implemented method for feeding hash values ​​from a hash device to a hash pool, the method comprising: obtaining a candidate block header for a candidate block of a blockchain; performing a plurality of hash operations on the candidate block header to generate a plurality of candidate Proof-of-Work (PoW) solutions; encrypting each of the candidate PoW solutions with an encryption key; and sending the encrypted candidate PoW solutions to a hash pool, wherein the hash pool is configured to decrypt the encrypted candidate PoW solutions.

Description

[Technical Field]

[0001] The present disclosure relates to a method and apparatus for providing hash values ​​from a hash device to a hash pool. [Background technology]

[0002] A hash pool (also known as a mining pool) is a node in a blockchain network that is responsible for collecting blockchain transactions, constructing a block template, and then sending this block template to hash producers (i.e., hash devices) to find a hash solution. Hash producers repeatedly apply a hash function to the block template to create candidate proof-of-work solutions. The candidate proof-of-work solutions are sent back to the hash pool. If a candidate proof-of-work solution meets certain criteria, it can be used as a valid proof-of-work solution for a new valid block in the blockchain. Hash pools typically compensate hash producers for their work by paying them a portion of the block reward earned by creating valid blocks. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] WO2017 / 145016 Summary of the Invention [Means for solving the problem]

[0004] Hash producers cannot enforce the submission of candidate Proof-of-Work (PoW) solutions to hash pools; that is, hash producers may intentionally "hide" their candidate PoW solutions. This is particularly problematic if a hash producer finds a valid PoW solution that allows a hash pool to publish a new block and claim the associated block reward. To make matters worse, hash pools currently cannot force hash producers to send candidate PoW solutions to that specific hash pool rather than to other hash pools.

[0005] It is therefore desirable to solve one or both of these problems: ensuring that candidate PoW solutions created by hash producers are only available to one specific hash pool, and discouraging hash producers from hiding candidate PoW solutions.

[0006] According to one aspect disclosed herein, there is provided a computer-implemented method for feeding hash values ​​from a hash device to a hash pool, the method including the steps of obtaining a candidate block header for a candidate block of a blockchain; performing a plurality of hash operations on the candidate block header to generate a plurality of candidate Proof-of-Work (PoW) solutions; encrypting each of the candidate PoW solutions with an encryption key; and sending the encrypted candidate PoW solutions to a hash pool, wherein the hash pool is configured to decrypt the encrypted candidate PoW solutions.

[0007] According to another aspect disclosed herein, there is provided a hashing device comprising: an input interface configured to obtain candidate block headers for candidate blocks of a blockchain; a hashing component configured to apply a hash function to at least the candidate block headers one or more times, wherein each application of the hash function to at least the candidate block header generates a respective candidate PoW solution; an encryption component configured to encrypt each of the candidate PoW solutions; and an output interface configured to output the candidate PoW solutions to a hash pool.

[0008] The hashing device takes the candidate block header and performs a hashing operation on the candidate block header to generate a candidate PoW solution. Each different example of the hashing operation involves applying a hash function (e.g., a double hash) to the candidate block header and a different value (sometimes called a nonce) to generate a different candidate PoW solution. Each candidate PoW solution is encrypted and sent to a hash pool. Only the hash pool can decrypt the encrypted solution. Therefore, only the specific hash pool can use the candidate PoW solution; no other hash pool can use the candidate PoW solution. If the candidate PoW solution is a valid (i.e., winning) PoW solution for the candidate block, this valid PoW solution can be used to publish a new block on the blockchain. The newly published block and its winning PoW solution are validated by other entities on the blockchain network.

[0009] According to another aspect disclosed herein, there is provided a computer-implemented method for obtaining hash values ​​from a hashing device, the method including: receiving a plurality of candidate PoW solutions from the hashing device; counting the number of candidate PoW solutions received from the hashing device over a predetermined period of time; and determining whether a contract has been fulfilled based on whether the number of candidate PoW solutions meets an expected number of candidate PoW solutions.

[0010] The hash pool receives multiple candidate PoW solutions from the hash device. The hash pool can then determine whether the conditions of the contract between the hash pool and the hash device are satisfied based on whether an expected number of candidate PoW solutions have been received over a predetermined period of time, e.g., minutes, hours, or days. This allows the hash device to fulfill the contract by sending the candidate PoW solutions to the hash pool and, in some examples, receive a reward for the candidate PoW solutions. In some examples, the candidate PoW solutions are encrypted before being sent to the hash pool.

[0011] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings in which: [Brief explanation of the drawings]

[0012] [Figure 1A] FIG. 1 illustrates a schematic diagram of an exemplary method for mining new blocks into a blockchain. [Figure 1B] FIG. 1 is a schematic diagram illustrating a pair of blockchain transactions. [Figure 2] 1 is a schematic block diagram of a system for delivering hash values ​​from a hash device to a hash pool. [Figure 3] FIG. 2 is a schematic block diagram of a hash device. [Figure 4] 1A-1C are diagrams illustrating an exemplary method according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0013] 1A schematically illustrates an exemplary method for mining new blocks 101n on a blockchain 102. The blockchain 102 is a form of distributed database (or ledger) that serves as a record of all valid transactions 103 submitted to the blockchain network.

[0014] Valid transactions 103 broadcast on the blockchain network are recorded in blocks on the blockchain 102 by miners (also called mining nodes). Blockchain transactions 103 are used to transfer stored digital tokens of a certain value. A pair of transactions 103 is shown in FIG. 1B. As shown, each transaction 103 includes, among other things, at least one input and at least one output. The input is a reference to an unspent transaction output (UTXO) from a previous transaction. For example, in FIG. 1B, T x1 is T x0 A transaction 103 uses an unspent transaction output (UTXO) as input and scatters its value into new outputs. The output typically includes a locking condition that locks the value of that output and requires specific data (e.g., a key or other set of information) to be present in the input of the new transaction 103 to unlock it. Outputs can also be used to inscribe data on the ledger. The input of a transaction 103 typically includes a digital signature written on the transaction 103. Thus, the chain of transactions 103 includes a chain of digital signatures that maps the entire history of validating exchanges of digital tokens back to the creation of the tokens.

[0015] Now, referring back to Figure 1A, the blockchain 102 starts with a "genesis block" 101g, which is the first created block 101. Each block on the blockchain 102 references the previous block, up to the genesis block: the nth block 101 references the n-1th block 101, the n-1th block references the n-2th block, and so on, ultimately referencing the genesis block 101g.

[0016] A block 101 includes an ordered list of blockchain transactions 103 and a block header 104. The block header 104 includes a Merkle root 105 generated by hashing the ordered list of blockchain transactions 103 into a Merkle tree, a timestamp, a reference 106 to the previous block 101 on which the current block 101 is based, and a means for other miners to verify the "proof of work" required to accept the block 101 as a valid block. The means of verification is the answer to a hash puzzle that is unique to each block 101. The blockchain protocol executed by nodes in the blockchain network uses a hashing algorithm that requires miners to reconstruct the miner's candidate block 101c before attempting to solve the puzzle. A new block 101n cannot be submitted to the network without the correct answer, and the "mining" process is essentially a race to find the next answer that "solves" the current block 101. While the hash puzzle in each block 101 is difficult to solve, once a valid solution is found, it is very easy for the rest of the network to verify that the solution is correct. There are multiple valid solutions for a given block 101, and solving the block 101 only requires finding one of the solutions.

[0017] The following outlines the process of attempting to mine a new block 101n into the blockchain 102. When a blockchain transaction 103 is sent to a mining node, it is first validated according to the blockchain network's consensus rules. If the transaction 103 is valid, it is added to a pool 107 of unconfirmed transactions 103. The pool 107 is sometimes referred to as a "memory pool." The memory pool 107 serves as a temporary store for transactions 103 to be mined into the next block 101n. Each mining node has its own memory pool 107, and if any given transaction 103 is broadcast to more than one mining node, that transaction 103 may be included in more than one memory pool 107.

[0018] A hash function is a function that converts a string of data of any length into a fixed-length value called a hash value or hash digest. Hashing is a one-way function, meaning it is impossible to determine what the input data is by looking at the hash value created from it. On the other hand, it is easy to reproduce the same hash by running the same hash function on the same input data. Some blockchain protocols use the SHA-256 hashing algorithm, and some protocols use the SHA-256 hashing algorithm twice, meaning that candidate block headers are subjected to the same hashing algorithm twice.

[0019] A Merkle tree is a data structure in the form of a tree of hash values. In the context of a blockchain 102, transactions 103 are hashed to form leaf nodes of the tree. As shown in FIG. 1A, transaction Tx1 is hashed to form leaf node D1, transaction Tx2 is hashed to form leaf node D2, and so on. Pairs of leaf nodes are concatenated and then hashed to form nodes at higher layers of the tree. For example, leaf nodes D1 and D2 are concatenated and hashed to result in nodes at higher layers. Pairs of nodes at that layer are then concatenated and hashed to form nodes at even higher layers of the tree. This process is repeated until only a single node remains, called the root node, or Merkle root 105.

[0020] Miners take the transactions 103 that they intend to include in the next block, hash them into a Merkle tree structure, and include the resulting Merkle root 105 in a candidate block header 104. Miners then hash this candidate block header 104 and attempt to find a valid proof-of-work.

[0021] A valid proof of work is found by hashing the candidate block header 104 (in combination with other data, as described below) until the result is less than another value, called the target value, which is automatically adjusted by the blockchain protocol so that it takes the blockchain network, on average, 10 minutes to find a valid proof of work.

[0022] To change the hash value, a mining node must add additional information to the candidate block header 104. Mining nodes typically use two "nonce fields" to change the value being hashed, and therefore the resulting hash value. A first nonce field 108 is included in the block header itself, and a second nonce field is included in the "coinbase transaction." The coinbase transaction is a transaction created by a mining node and included in a candidate block. Each field includes a counter parameter that can be incremented. The hash function cycles through all values ​​in the first nonce field 108, then increments (or otherwise modifies) the second nonce field, and then cycles through all modified values ​​in the first nonce field 108 again. Incrementing the second nonce field involves recalculating the Merkle root 105 as it modifies the hash of the coinbase transaction included in the Merkle tree.

[0023] When a mining node finds a valid proof-of-work hash for a block 101 (i.e., a candidate block header 104 that hashes to a value less than a target value), it broadcasts the new block 101n to the rest of the blockchain network. Other nodes on the network will only accept this new block 101n if all transactions 103 within it are valid and have not already been included in a block. Every block 101 is timestamped and references the hash of the block 101 that preceded it, thus resulting in a chain of blocks (i.e., a blockchain 102).

[0024] An "output-based" transaction model was discussed above. An alternative type of transaction model is the "account-based" model. In this model, each transaction 103 does not define the amount of digital tokens transferred by referencing back unspent transaction outputs, but instead references absolute account balances. The current state of every account is stored and constantly updated by miners independent of the blockchain 102. In such a system, transactions 103 are ordered using the account's running transaction tally (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation.

[0025] FIG. 2 schematically illustrates an exemplary system 200 for feeding hash values ​​from a set of hash devices 201a, 201b to a hash pool 202. In this exemplary system 200, there are two hash devices 201a, 201b, although the system 200 may generally include any number of hash devices 201. The system also includes a set of blockchain client applications 203a, 203b, 203c. While only three client applications 203a, 203b, 203c are shown, the system may include any number of client applications 203. Generally, the client applications 203 are configured to send blockchain transactions to the hash pool 202. The hash pool is configured to construct a block template 101c and send the block template 101c (or at least the candidate block header 104 for the block template 101c) to the hash devices 201a, 201b. Each hash device 201 is configured to generate a candidate PoW solution based on the candidate block header 104. The system further comprises a blockchain network 204 comprising a plurality of blockchain nodes.

[0026] According to some embodiments of the present invention, the hash device 201a is configured to obtain a candidate block header 104. For example, the candidate block header may be sent to the hash device 201a by a hash pool separately or as part of the block template 101c. That is, the hash device does not need access to the transactions in the block template 101c. The hash device is then configured to generate multiple hash values ​​based on the block header 104. These hash values ​​are also referred to as candidate PoW solutions. The candidate PoW solutions are not necessarily valid block solutions. That is, some or all of the candidate PoW solutions may not solve the PoW puzzle required to publish a new valid block on the blockchain. In fact, due to the probabilistic nature of hashing, most of the candidate PoW solutions produced by a given hash device 201 are not valid block solutions. As described above with reference to FIG. 1, the nonce value 108 of the candidate block header 104 is changed each time a hash function is applied (i.e., with each instance of the hashing operation), resulting in a different hash value.

[0027] In some embodiments, the hash device 201a encrypts each of the candidate PoW solutions. That is, each candidate PoW solution is encrypted separately. In general, any encryption technique may be used. Some exemplary encryption techniques are listed below.

[0028] In these embodiments, hash device 201a sends the encrypted candidate PoW solutions to hash pool 202. Hash pool 202 is configured to decrypt the encrypted candidate PoW solutions to reveal the candidate PoW solutions. If one of the candidate PoW solutions is a valid block solution, the hash pool may publish a block to the blockchain that includes the valid block solution, the candidate block header 104, and the transactions on which the candidate block header 104 is based.

[0029] 2, the hash pool 202 may send the candidate block header 104 (e.g., as part of the block template 101c) to two or more hash devices 201. This improves the chances of finding a valid block solution. Each hash device 201 performs similar operations on the created candidate PoW solutions, encrypts them, and sends the encrypted versions to the hash pool 202.

[0030] The hash device 201a encrypts the candidate PoW solution using an encryption key, which may be a symmetric key, an asymmetric key, or a different type of encryption key.

[0031] For example, the hash device 201a may encrypt a candidate PoW solution using a one-time pad (OTP). The one-time pad is a pre-shared key that is the same size as or longer than the message to be encrypted. In this case, the message is the candidate PoW solution. Each bit of the candidate PoW solution is encrypted by combining that bit with a corresponding bit of the one-time pad. Here, if a bit of the OTP and a bit of the candidate PoW solution are in the same position, the bit of the OTP corresponds to a bit of the candidate PoW solution; for example, the first bit of the candidate PoW solution is combined with the first bit of the OTP, the second bit of the candidate PoW solution is combined with the second bit of the OTP, and so on. These bits may be combined using modular addition or a different type of modular arithmetic. The encrypted message (i.e., the encrypted candidate PoW solution) cannot be decrypted without knowledge of the OTP. The hash pool 202 has knowledge of the OTP and can therefore decrypt the encrypted candidate PoW solution. For example, when the hash pool 202 receives an encrypted PoW solution, it uses the OTP to "separate" (i.e., exclude) the OTP from the encrypted PoW solution. In other words, an inverse operation may be used to reveal the underlying bits of a candidate PoW solution. For example, if bits of a candidate PoW solution and the OTP are combined using modular addition, then modular subtraction may be used to reveal the bits of the candidate PoW solution. Encryption using modular addition may also be used with encryption keys other than the OTP.

[0032] In some examples, the OTP may be used to encrypt the candidate PoW shares using XOR encryption, i.e., using an exclusive-or (XOR) operator. As is well known to those skilled in the art, the XOR operator outputs a 0 whenever the inputs match and a 1 whenever the inputs do not match. Note that XOR encryption may be used with encryption keys other than the OTP.

[0033] In some examples, the hash pool may send an encryption key (e.g., an OTP) to hash device 201a. The hash pool may send each different encryption key to each different hash device 201b. Conversely, the hash device may send an encryption key to hash pool 202.

[0034] One option for sharing the encryption key is to establish a shared key between the hash device 201a and the hash pool 202. The shared secret is data known only to (or derivable only by) the hash device 201a and the hash pool 202. The shared secret is used to encrypt the encryption key; that is, the encryption key itself is encrypted, thus improving the security of the encryption key when it is shared between the hash device 201a and the hash pool 202.

[0035] In general, the shared secret may be any secret data. As a specific example, the shared secret may be derived based on the private key of hash device 201a (e.g., installed on the device) and the public key of hash pool 202. Due to the properties of the private-public key pair, the same shared secret may be derived based on the private key of hash pool 202 corresponding to the public key used by hash device 201a and the public key of hash device 201a corresponding to the private key used by hash device 201a. The public key may be publicly accessible or may be shared in some other way between hash pool 202 and hash device 201a.

[0036] In some examples, the public-private key pair used to generate the shared secret may itself be based on a common value (not necessarily a secret). This common value, typically referred to as a deterministic key, may be the result of applying a hash function to the message. That is, the hash device 201a may generate a second private key based on the first private key and the deterministic key. The hash device may generate a second public key for the hash pool 202 based on the first public key for the hash pool 202 and a public key corresponding to the deterministic key. The shared secret is then generated based on the second private key for the hash device 201a and the second public key for the hash pool 202. The hash pool 202 may perform an equality operation to generate the same shared secret. See WO2017 / 145016 for a specific example of establishing a shared secret.

[0037] The firmware installed on the hash device 201a may have a fingerprint, or a public key fingerprint. The public key fingerprint may be just the public key itself or may be based on the public key, for example. In some examples, the private key of the hash device 201a may be based on the fingerprint, for example, a hash or checksum of the fingerprint.

[0038] In addition to using a single encryption key, the encryption key may be updated. For example, the encryption key may be updated periodically, e.g., every time a predetermined amount of time has elapsed since the last update. For example, the encryption key may be updated hourly, daily, etc. In some examples, the encryption key may be updated in response to receiving a new candidate block header 104. That is, each time the hashing device 201a receives a new candidate block header 104 on which to base candidate PoW solutions, the hashing device 201a may encrypt those solutions using a new encryption key. In some examples, the encryption key may be based on the candidate block header 104. As another example, the encryption key may be updated in response to a reset or reboot of the hashing device 201a, e.g., in response to the hashing device 201a going temporarily offline.

[0039] The hashing device 201a may be configured to encrypt a candidate PoW solution each time one is created, and the encrypted solution may then be output from the hashing device 201a, for example, to the hashing pool 202. This prevents other hashing pools from using the solution.

[0040] In some examples, the hash device only needs to encrypt candidate PoW solutions that meet a predetermined hard condition, i.e., solutions that contain a predetermined number of leading zeros (e.g., 10 zeros). In these examples, only these encrypted solutions are sent to the hash pool 202. This reduces the amount of data sent from the hash device 201a to the hash pool 202.

[0041] Although the above has been described primarily with respect to hash device 201a sending the encrypted PoW solution to hash pool 202, the encrypted PoW solution may also be sent to hash pool 202 indirectly, for example, via an intermediary device configured to forward the encrypted PoW solution to hash pool 202.

[0042] 3 shows a schematic diagram of a hashing device 201 according to an embodiment of the present invention. The hashing device 201 comprises an input interface 301, a hashing component 302, an encryption component 303, and an output interface 304.

[0043] The input interface 201 is configured to obtain a candidate block header. The candidate block header 104 was described with reference to FIG. 1. The candidate block header 104 comprises a representation of a set of blockchain transactions, e.g., a Merkle root 105. The candidate block header 104 may include a reference to a previous block 106, a timestamp, and / or a nonce value 108. In some examples, the input interface 301 may obtain a set of transactions 103. In those examples, the input interface 201 may be configured to obtain the candidate block header 104 by generating the candidate block header 104 based on the set of transactions 103. That is, the input interface 301 may comprise components for constructing a Merkle tree to generate a Merkle root 105 for the set of transactions 103. The input interface 301 may also be configured to obtain any other information necessary to construct the candidate block header 104. For example, the input interface 301 may be configured to receive a reference to a previous block 101 in the blockchain 102, i.e., the block header of the previous block 101. The input interface 301 may be configured to retrieve a candidate block template 101c comprising a candidate block header 104 and a set of transactions 103. Any instance of "retrieving" a data item (e.g., a candidate block header 104 or a candidate block template 101c) may be considered to mean receiving that data item unless the context requires otherwise.

[0044] In some examples, the input interface 301 may be connected to mining software. For example, the mining software may be configured to provide the hashing device 201 with a set of transactions 103 and / or a candidate block header 104, e.g., via the input interface 301. The mining software may be configured to provide the hashing device 201 with additional information, e.g., a reference 106 to a previous block 101 in the blockchain 102. The mining software may include or otherwise have access to a pool 107 of unconfirmed transactions from which the set of transactions 103 is provided to the hashing device 201. The mining software may be operated by the hash pool 202 in some examples and thus may be independent of the hashing device 201.

[0045] The hash component 302 is configured to apply a hash function to at least the candidate block header 104. In some examples, the hash component 302 is configured to apply the hash function to the candidate block template 101c, where the candidate block template 101c includes the candidate block header 104. The hash component 302 is configured to generate one or more hash digests (or hash values) based on input received from the input interface 301, e.g., the candidate block header 104. The hash component 302 may generate multiple hash digests. For example, the hash component 302 may include a single hash function that hashes the candidate block header 104 multiple times. Additionally or alternatively, the hash component 302 may include multiple hash functions, each configured to hash the candidate block header 104 one or more times. Each hash function may apply the same hash function (e.g., SHA-256). Alternatively, one or more hash functions may apply different hash functions (e.g., SHA-512). Applying a hash function may include applying a sequence of hash functions (e.g., applying SHA-256 twice) to produce a single hash digest. Note that references to hashing a candidate block header 104 should be considered to mean hashing at least the candidate block header 104 unless the context requires otherwise. Also, note that a hash digest is synonymous with a candidate PoW solution.

[0046] The hashing component 302 is configured to provide the hash digest to the encryption component 303. The encryption component 303 is configured to encrypt the hash digest received from the hashing component 302. In general, any encryption technique may be used. In some examples, the encryption component 303 may be configured to receive an encryption key from the input interface 301, and the hash pool 202 may send the encryption key to the hashing device 201. In some examples, the encryption component 303 may be configured to generate the encryption key based on data provided from the input interface 301, for example. The encryption component 303 is configured to provide the encrypted PoW solution to the output interface 304.

[0047] The hash device 201, or more specifically the output interface 304, may have a local area network (LAN) connection for LAN access, whereby the encrypted PoW solution is output for consumption locally by the hash pool 202 in the local area network where the hash device 201 is located. Additionally or alternatively, the output interface 304 may have a wide area network (WAN) connection for WAN access, whereby the encrypted PoW solution is transported from the network where the hash device 201 is located to the hash pool 202 via a WAN (e.g., the Internet).

[0048] One or more of the components of hash device 201 may be implemented in software. That is, hash device 201 may comprise a processing unit comprising one or more processors, e.g., one or more central processing units (CPUs), accelerator processors (GPUs), application-specific processors, and / or field-programmable gate arrays (FPGAs). The device may comprise memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or EEPROM, and / or optical media such as optical disk drives. Hash device 201 may comprise at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. Alternatively or additionally, hash device 201 may comprise one or more other networked resources, such as cloud computing resources (cloud computing resources including resources of one or more physical server devices implemented at one or more sites) accessed via the user terminal.

[0049] Additionally or alternatively, one or more of hashing devices 201 may take the form of dedicated hardware. For example, hashing component 302 may comprise one or more hashing devices specifically configured to implement a hashing algorithm. For example, hashing component 302 may comprise one or more application-specific integrated circuit (ASIC) mining devices configured to implement, for example, the SHA-256 hashing algorithm. In general, any hashing algorithm may be used to create a hash digest.

[0050] In some examples, hash device 201 may be operated by a hash farm. The hash farm may include multiple hash devices. Hash device 201 may be connected to the hash farm, for example, via input interface 301. In some examples, candidate block header 104 may be sent to the hash farm (e.g., from hash pool 202), which then provides the candidate block header 104 to hash device 201. Similarly, hash device 201 provides an encrypted PoW solution to the hash farm, which then provides the encrypted PoW solution to hash pool 202.

[0051] As described above, the hash pool 202 is configured to receive and decrypt the encrypted PoW solution from the hash device 201a, thus obtaining a candidate PoW solution. The hash pool 202 uses a decryption key corresponding to the encryption key used by the hash device 201a, and in some examples, the decryption key is the same as the encryption key. If the candidate PoW solution satisfies a predetermined difficulty setting set by the blockchain network, the hash pool 202 may use the PoW solution as a block solution. A block including the block solution may then be sent to the blockchain network 204.

[0052] According to some embodiments, the hash pool 202 counts the number of candidate PoW solutions received from the hashing device 201a to check whether the contract is fulfilled. The contract may specify the number of PoW solutions to be sent by the hashing device 201a to the hash pool 202. The contract may specify that a certain number of candidate PoW solutions must be received over a predetermined period of time, e.g., one hour, one day, one week, etc. In these embodiments, the hash pool 202 may reward the hashing device 201a (or the operator of the hashing device 201a, e.g., a hash farm) only if the contract is fulfilled. Furthermore, a reward may be provided only if a valid block solution is provided.

[0053] Note that in most common embodiments, the hash pool 202 need not count encrypted PoW solutions to determine whether a contract has been fulfilled, but in at least some instances, only encrypted PoW solutions are counted.

[0054] The hash pool 202 may comprise one or more processors, e.g., processing units comprising one or more central processing units (CPUs), accelerator processors (GPUs), application-specific processors, and / or field-programmable gate arrays (FPGAs). The hash pool 202 may comprise memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory or EEPROM, and / or optical media such as optical disk drives. The hash pool 202 may comprise at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. Alternatively or additionally, the hash pool 202 may comprise one or more other networked resources, such as cloud computing resources (cloud computing resources including resources of one or more physical server devices implemented at one or more sites) accessed via the user terminal.

[0055] 4 illustrates an exemplary method 400. It will be appreciated that some of the steps of this method 400 are optional and that method 400 may include additional steps. It will also be appreciated that some steps are performed by the hashing device 201a and some are performed by the hash pool 202. In step 401, the hashing device 201a obtains a candidate block header 104, for example, as part of the block template 101c. In step 402, the hashing device 201a generates multiple different candidate PoW solutions based on the candidate block header 104. The candidate PoW solutions are then encrypted in step 403 and then sent to the hash pool 202 in step 404. In step 405, the hash pool 202 decrypts the encrypted PoW solutions and, in step 406, counts the decrypted PoW solutions to determine whether the contract for the set number and / or hash rate has been fulfilled.

[0056] Exemplary Use Cases Currently, over-the-counter (OTC) hash futures exist. This market is very thin and not widely traded, primarily due to the lack of a way to adequately hedge the counterparty risk involved. The hash rate market emerged relatively recently as part of the emergence of cryptocurrency "mining rigs," which are application-specific integrated circuits (ASICs) that run optimized hashing algorithms to support proof-of-work digital asset blockchains. Therefore, it is not entirely clear how a financial derivatives market based on this "commodity" would function properly. Accordingly, participation in currently available OTC hash power futures is primarily limited to speculators and hedge funds who trade these futures as a proxy for holding the underlying asset. Also, because hash rate is not a physical commodity, achieving physical settlement in such futures contracts is difficult. However, there is a direct relationship between hash rate and the digital assets that can be created from this hash rate, and therefore a relationship between the spot price of the asset and these hash rate futures. That is, the more hash shares received in a pool, the greater the likelihood of a PoW block solution being found, and therefore, more digital assets being created. However, there is currently no way to hedge this basis risk.

[0057] It is therefore desirable to accurately settle and account for hashed power futures, allowing them to be settled by using mining pools in much the same way that power futures markets use power pools (or electricity markets, e.g., PJM, Northwest, ISO-NE, etc.) to act as delivery points. By using existing electricity markets as analogs, many of the market peculiarities and issues surrounding the smooth operation of hashrate futures and spot markets can be eliminated, thus allowing a liquid market to develop, and therefore a fair price to be found for the digital assets created from hash production.

[0058] Also desirable is a device and process that reliably generates hashrate from a hash rig and sends it only to the settlement pool and no other pools, solving the common problem of "holding" the hash solution to actually solve the blocks and cheating the pool.

[0059] PPLNS (Pay Per Last N Shares) is a payment algorithm used by hash pools. It is a method of paying only for what is earned, so there is no risk that pool operators will have to pay hash contributors without actually having the block reward to support the payment. While PPLNS sufficiently prevents hashers from withholding winning shares from profit-sharing pools, it does not sufficiently prevent them from not sending their winning hash shares to the pool for physical settlement of hashrate futures. Therefore, an additional method is needed to "ensure" that hashrate is received (or shares will not be sent to the pool).

[0060] definition Hasher (i.e., miner) - The owner of a hash rig (i.e., hashing device) - for example, an ASIC mining unit that produces valid SHA256 (or other) hash solutions for solving blocks on the blockchain.

[0061] Hash Farm Operator - An operator that manages and operates an entire hash rig in one or more locations and charges a fee for its services.

[0062] Hash pool (i.e. mining pool) - An operator of blockchain network nodes responsible for assembling and creating blocks. This is similar to a settlement and clearing house for hashrate futures.

[0063] Market Participants - Buyers and sellers of hashrate futures on registered exchanges. There are three types: hedgers, speculators, and consumers.

[0064] Hashrate Hedgers - Typically hashers, hash farm operators, or hedgers - are aware of the future ramp-up schedule of their hash rigs and wish to sell their hashrate production in the future to lock in the price of their hashrate, hedging against fluctuations in the underlying digital asset price and against volatility in the total network hash distribution. If the hash pool uses FPPD (full pay per share) or PPS (pay per share), they pay their hashrate to the hash pool. However, if the hash pool uses PPLNS (pay per last n shares), the hash pool is much like participating in a pooled lottery system. If the lottery is pooled and the pool wins, the jackpot is distributed proportionally to the pool hash contributors according to the percentage of hashes they contributed to the winning block (n shares leading up to the block).

[0065] A hashrate hedger sells a fixed number of hashes per unit time at some point in the future. For example, a hashrate hedger might sell 100 TH per second for 1d, 3d, 1w, 1m, etc. Note that TH stands for terahash. Therefore, the buyer of the contract needs metering and assurance that the hashrate being dispensed is actually "good." Events like a power outage or hash rig failure occur, so they count up all the hashes dispensed, calculate an average, and ensure that counting is a necessary service for pools that want to act as settlement and clearing houses.

[0066] Hash Rate Speculators - Hedge funds who may want risk exposure to digital assets without actually owning the assets. Anyone who may want risk exposure to changes in total network hash distribution and creation. ASIC manufacturers who may want to increase their profit margins by shorting hash rate futures according to hash rig sales.

[0067] Hashrate Consumers - the natural buyers of hashrate, transaction processors require hashrate to include transactions on the blockchain in blocks. How much hashrate is required is directly proportional to the desired service level agreement (SLA) for the hashrate consumer's transaction processing contract.

[0068] Hash pool - An entity responsible for collecting transactions on a blockchain, constructing a block template, and then sending this block template to a hash creator to find a hash solution by using proof-of-work hashing. The hash pool compensates the hash creator for their work by paying them a share of any block reward earned by creating valid blocks. A hash pool may be a group of mining nodes that combine their computing power to perform the pool's actions.

[0069] Clearing and settlement organizations are used to settle or settle the day's worth of transactions on an exchange.

[0070] Every hash contract has a feeding pool. Each contract must specify a hash pool to which hashing power will be fed. That hash pool is responsible for metering the hashing power and feeding the created coins (e.g., Bitcoin) to the exchange client (the buyer of the contract). When the contract expires, if physically settled, the hash pool expects the hash arriving at the pool to fulfill the contract. The pool may provide feeding instructions to parties requiring a feeding of hashing power. These instructions may include a fingerprint unique to the feeder and feeding location, and a unique factor (e.g., a timestamp concatenated with the contract ID), which may be hashed to create a one-time pre-shared key. This may then be used as a one-time pad to encrypt (e.g., using XOR or modular addition) the hash shares that are sent to the feeding pool and counted for the feeding contract.

[0071] Furthermore, if participants voluntarily run firmware adapted for feeding, hash power can be secured between the hash rig and the feeding pool to ensure that shares are not lost. With this hash power secured, settlement and liquidation fees, as well as the margin required to maintain an account, can be reduced. A fingerprint check of the firmware installed on the hash rig can be performed to ensure that it has not been tampered with. For example, the firmware's checksum (e.g., SHA256 hash) itself may be used as part of the private key (for secret sharing). A hardware call may be used to inspect a binary dump of the firmware. The firmware encrypts shares that are excluded from the hash rig. If the hash is sent elsewhere, the hash is not decryptable. This way, a given hash rig cannot be hijacked to solve alternative blocks not addressed by the feeding pool.

[0072] With the ability to "measure and meter" hashing power entering the pool, a hashing pool effectively resembles a "dispatch location" in the energy derivatives business. A dispatch location is a "metering point" for the kWh dispatched when energy futures are dispatched. Energy futures are contracts to dispatch a specific amount of kWh at a specific time in the future for a specific price. The holder of such a contract can request a cash settlement (hourly) or actually receive the dispatch of energy, depending on the spot price of energy at the time of dispatch. Currently, the hashing power market only has cash settlement, and actual dispatch of hashing power is not possible. This makes the market highly speculative and not very useful as a hedging device for miners who own hashing power. The present patent and method, which use a pool as a metering device for hashing power, allows for the receipt and measurement of physical hashing power, and therefore allows for physical settlement of hashing futures. This is beneficial to the utility and liquidity of this market.

[0073] Here's an example of metric hashing: If a buyer purchases 100 TH per second for a day, they can simply count and run 86,400 * 1 trillion hashes. However, this means that each hash is sent over the network from the hash rig to the hash pool. This is undesirable, as it's too many to send over the Internet. Therefore, a "hard hash target" is set, i.e., a hash value is only sent if it has, say, four leading zeros (through purely random chance). Statistically, the chance that any given hash has four leading zeros is exactly 1 / 16^4 = 1.5 in 10,000 chances. Therefore, a hash device set up like this will statistically only send hash shares once every 10,000 times. Furthermore, the hard target (number of leading zeros) is typically set so that the hash device only emits hash shares once every 10 seconds or so. This means, for example, that for a machine with 10th hashing per second, the goal is set so that the chances of the hash matching the goal are 1 in every 100,000,000,000,000 (10 * 10 trillion) times. As such, a device typically emits shares every 10 seconds. As long as it sends approximately 8640 shares in the previous 24-hour period, it is assumed to be statistically good and the contract is fulfilled. However, the problem is that this is like rolling dice; statistically, no machine behaves perfectly regularly; there are statistical "wobbles," making it difficult to clearly demonstrate that the machine is not simply unlucky. Also, by design, machines behave more or less regularly, making it difficult to demonstrate whether the machine is behaving poorly or whether it has been hijacked. Therefore, the hashes should be encrypted so that these hash values ​​cannot be used elsewhere.

[0074] An alternative to having custom firmware on the hash devices is to have an intermediate device (e.g., formed in an FPGA) that can be placed in front of the network switch and act as a proxy for the pool. The hash unit controls this unit similarly to a pool node. The purpose of this device is to authenticate with the pool server, negotiate a one-time pre-shared key, and encrypt to secure all shares that pass through the intermediate device. It may also be possible to simply track all connected hash units via their IP addresses and track any irregular activity, i.e., disconnect them from the proxy. This alone may be used to ensure that the hash units contribute to the security of the hash.

[0075] In summary, embodiments of the present invention provide a device for securing hash generation. The device encodes every PoW share with an OTP (One-Time-Pad). This OTP is exclusive-ored at the receiving end. Only PoW shares that pass this filter are counted towards the total shares. This allows generated shares to be accepted only at mining pools that act as a feeder point for hashing power.

[0076] Using a measurement device for hashing power, it is possible to enable the hashing power futures market to function very similarly to the electricity futures market. This allows the liquidity and utility of this market to be greatly expanded, meaning that the utility of this market for proof-of-work miners on a blockchain system is significantly improved. By creating an effective settlement and liquidation process for physically settling hashing futures, the hashing futures market can be made similar to the electricity market, and any hashing pool that can guarantee that the hashing power sent to the pool is trustworthy can charge a settlement and liquidation fee for all contracts settled through their platform.

[0077] conclusion It will be appreciated that the above-described embodiments have been described by way of example only.

[0078] More generally, according to one aspect disclosed herein, there is provided a computer-implemented method for feeding hash values ​​from a hash device to a hash pool, the method including obtaining a candidate block header for a candidate block of a blockchain; performing a plurality of hash operations on the candidate block header to generate a plurality of candidate Proof-of-Work (PoW) solutions; encrypting each of the candidate PoW solutions with an encryption key; and sending the encrypted candidate PoW solutions to a hash pool, wherein the hash pool is configured to decrypt the encrypted candidate PoW solutions.

[0079] In an embodiment, the encryption key may be a one-time pad encryption key.

[0080] In an embodiment, each of the candidate PoW solutions may be encrypted using XOR encryption or modular addition.

[0081] In an embodiment, the method may include obtaining an encryption key from a hash pool or sending an encryption key to a hash pool.

[0082] In an embodiment, the method may include establishing a shared secret with a hash pool, and the encryption key is encrypted using the shared secret before being retrieved from and / or sent to the hash pool.

[0083] In an embodiment, the method may include calculating a shared secret based on a private key of the hash device and a public key of the hash pool, and the hash pool may calculate the shared secret based on the private key of the hash pool and the public key of the hash device.

[0084] In an embodiment, the firmware of the hash device may have a fingerprint, and the private key of the hash device may be based on a checksum of the fingerprint.

[0085] In an embodiment, the fingerprint may be an existing public key fingerprint.

[0086] In an embodiment, the method may include updating the encryption key.

[0087] In an embodiment, the encryption key may be updated in response to one of a set of predefined events, the set of predefined events including rebooting the hash device, a predetermined period of time since the last update of the encryption key, and receiving a new candidate block header.

[0088] In an embodiment, the method may include running all candidate PoW solutions submitted to a hash pool to be encrypted.

[0089] In an embodiment, the method may include encrypting only candidate PoW solutions that satisfy a predetermined hard condition.

[0090] In embodiments, the sending step may include sending the encrypted candidate PoW solution to an intermediate device configured to forward the encrypted candidate PoW solution to a hash pool.

[0091] According to another aspect disclosed herein, there is provided a hashing device comprising: an input interface configured to obtain candidate block headers for candidate blocks of a blockchain; a hashing component configured to apply a hash function to at least the candidate block headers one or more times, wherein each application of the hash function to at least the candidate block header generates a respective candidate PoW solution; an encryption component configured to encrypt each of the candidate PoW solutions; and an output interface configured to output the candidate PoW solutions to a hash pool.

[0092] According to another aspect disclosed herein, there is provided a computer-implemented method for obtaining hash values ​​from a hashing device, the method including: receiving a plurality of candidate PoW solutions from the hashing device; counting the number of candidate PoW solutions received from the hashing device over a predetermined period of time; and determining whether a contract has been fulfilled based on whether the number of candidate PoW solutions meets an expected number of candidate PoW solutions.

[0093] In an embodiment, the method may include sending a blockchain block including a candidate PoW solution to a blockchain network, provided that a predetermined difficulty condition is satisfied by one of the candidate PoW solutions.

[0094] In an embodiment, the method may include sending the candidate block header to a hashing device.

[0095] In an embodiment, each of the plurality of candidate PoW solutions received from the hashing device may be encrypted using an encryption key, and the method may include decrypting each of the plurality of encrypted candidate PoW solutions and obtaining the plurality of candidate PoW solutions using a decryption key corresponding to the encryption key.

[0096] In an embodiment, the encryption key may be a one-time pad encryption key.

[0097] In an embodiment, each of the candidate PoW solutions may be encrypted using XOR encryption or modular addition.

[0098] In an embodiment, the method may include obtaining an encryption key from a hashing device or sending an encryption key to a hashing device.

[0099] In an embodiment, the method may include establishing a shared secret with the hashing device, and the encryption key is encrypted using the shared secret before being obtained from or sent to the hashing device.

[0100] According to another aspect disclosed herein, there may be provided a computing device comprising: a memory comprising one or more memory units; and a processing device comprising one or more processing units, the memory storing code configured to be executed on the processing device, the code configured to perform the method of any of the above-described embodiments when executed on the processing device.

[0101] According to another aspect disclosed herein, there may be provided a computer program embodied on a computer readable storage and configured to perform the method according to any of the above-described embodiments when executed on a computing device.

[0102] According to another aspect disclosed herein, a method may be provided that includes actions of a hash device and a hash pool.

[0103] According to another aspect disclosed herein, a system may be provided that includes a hash device and a hash pool.

[0104] Other variations or use cases of the disclosed techniques will be apparent to those skilled in the art after given the disclosure herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims. [Explanation of symbols]

[0105] 101c candidate block 101g Genesis Block 101n Block 102 Blockchain 103 transactions 104 Block Header 105 Merkle Root Reference 106 107 Pool 108 First Noncefield 200 systems 201a, 201b Hash Device 202 Hashpool 203a, 203b, 203c Client Applications 301 Input Interface 302 Hash Components 303 Encryption Component 304 Output Interface 400 ways D1, D2 leaf nodes Tx1 transaction

Claims

1. 1. A computer-implemented method for feeding hash values ​​from a hash device to a hash pool, the method being performed by the hash device and comprising: receiving a candidate block header for a candidate block of a blockchain; performing a plurality of hash operations on the candidate block headers to generate a plurality of candidate proof-of-work (PoW) solutions; encrypting each of the candidate PoW solutions with an encryption key; sending the encrypted candidate PoW solution to the hash pool, wherein the hash pool is configured to decrypt the encrypted candidate PoW solution.

2. The method of claim 1 , wherein the encryption key is a one-time pad encryption key.

3. 3. The method of claim 1 or 2, wherein each of the candidate PoW solutions is encrypted using XOR encryption or modular addition.

4. The method of claim 1 , further comprising obtaining the encryption key from the hash pool or sending the encryption key to the hash pool.

5. 5. The method of claim 4, further comprising establishing a shared secret with the hash pool, wherein the encryption key is encrypted using the shared secret before being obtained from and / or sent to the hash pool.

6. 6. The method of claim 5, further comprising calculating the shared secret based on a private key of the hash device and a public key of the hash pool, wherein the hash pool can calculate the shared secret based on the private key of the hash pool and the public key of the hash device.

7. The method of claim 6 , wherein the firmware of the hashing device has a fingerprint, and the private key of the hashing device is based on a checksum of the fingerprint.

8. The method of claim 7 , wherein the fingerprint is a public key.

9. The method of claim 1 , further comprising updating the encryption key.

10. The encryption key is updated in response to one of a set of predefined events, the set of predefined events being: rebooting the hash device; a predetermined period of time since the last update of the encryption key; and receiving a new candidate block header.

11. 11. The method of claim 1, wherein the method comprises encrypting all candidate PoW solutions sent to a hash pool.

12. 12. The method of claim 1, comprising encrypting only candidate PoW solutions that satisfy a predetermined difficulty condition.

13. 13. The method of claim 1, wherein the sending step comprises sending the encrypted candidate PoW solution to an intermediate device configured to forward the encrypted candidate PoW solution to the hash pool.

14. 13. The method of claim 1, wherein the encrypted candidate PoW solutions are sent directly to the hash pool.

15. A computer device comprising: a memory comprising one or more memory units; a processing device having one or more processing units, the memory storing code configured to be executed on the processing device, the code configured, when executed on the processing device, to perform the method of any one of claims 1 to 14.

16. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 14 when executed on one or more processors.

17. 1. A hash device, comprising: an input interface configured to obtain a candidate block header for a candidate block of the blockchain; a hashing component configured to apply a hash function to at least the candidate block header one or more times, each time applying the hash function to at least the candidate block header to generate a respective candidate PoW solution; an encryption component configured to encrypt each of the candidate PoW solutions to generate an encrypted candidate PoW solution; an output interface configured to output the encrypted candidate PoW solution to a hash pool; A hash device comprising:

18. 1. A computer-implemented method for obtaining a hash value from a hash device, the method being performed by a hash pool; receiving a plurality of encrypted candidate PoW solutions from a hashing device, each of the plurality of candidate PoW solutions received from the hashing device being encrypted using an encryption key; decrypting each of the plurality of encrypted candidate PoW solutions using a decryption key corresponding to the encryption key to obtain a plurality of candidate PoW solutions; Counting the number of candidate PoW solutions received from the hashing devices over a predetermined period of time; and determining whether the contract has been fulfilled based on whether the number of candidate PoW solutions satisfies an expected number of candidate PoW solutions.

19. 20. The method of claim 18, further comprising: sending a blockchain block including a candidate PoW solution to a blockchain network, provided that a predetermined difficulty condition is satisfied by one of the candidate PoW solutions.

20. 20. The method of claim 18 or 19, comprising sending the candidate block header to a hashing device.

21. 20. The method of claim 18, wherein the encryption key is a one-time pad encryption key.

22. 22. The method of claim 18 or 21, wherein each of the candidate PoW solutions is encrypted using XOR encryption or modular addition.

23. 23. The method of any one of claims 18 to 22, comprising obtaining the encryption key from the hashing device or sending the encryption key to the hashing device.

24. 24. The method of claim 23, further comprising establishing a shared secret with the hashing device, wherein the encryption key is encrypted using the shared secret before being obtained from or sent to the hashing device.

25. A computer device comprising: a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured, when executed on the processing device, to perform the method of any one of claims 18 to 24.

26. 25. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 18 to 24 when executed on one or more processors.

Images