Reuse of message scheduling computations for bitcoin mining

Abstract

Cryptographic hashing is performed in respect of a group of plural different input messages (104). A message scheduling engine (116) pre-calculates a message schedule array (118) comprising plural different sets of input values for a cryptographic compression function. Each set of input values in the message schedule array (118) corresponds to a respective input message of the group of plural different input messages (104). After the message schedule array (118) has been pre-calculated by the message scheduling engine (116), a cryptographic compressor (112) performs the cryptographic compression function in respect of each input message of the group of plural different input messages (104). Performing the cryptographic compression function in respect of each input message comprises using the set of input values in the message schedule array (118) corresponding to that input message so as to generate a message digest (108) for that input message.

Description

REUSE OF MESSAGE SCHEDULING COMPUTATIONS FOR BITCOIN MININGFIELDThe present invention relates to message scheduling when performing cryptographic hashing in respect of a group of plural different input messages to be hashed. The present invention relates particularly, although not exclusively, to cryptographic hashing when mining for cryptocurrency, such as Bitcoin.BACKGROUNDBitcoin mining comprises applying three instances of a SHA256 cryptographic hashing function (referred to herein respectively as “SHA256o,” “SHA256-i” and “SHA2562”) to input messages, which are derived from a Bitcoin Block Header. SHA256o uses a standard initialisation vector IV and is applied to a first portion of the Bitcoin Block Header. SHA256i then uses the message digest Ho of SHA256o as an initialisation vector and is applied to a second portion of the Bitcoin Block Header plus some padding. Finally, SHA2562 again uses the standard initialisation vector IV and is applied to the message digest of SHA256i plus some padding.The ultimate aim of Bitcoin mining is to find a SHA2562 message digest or “hash” that is lower than or equal to the current Target. If the Target condition is met, then the Bitcoin Block Header in question is accepted by the Bitcoin Network and the Bitcoin miner receives a mining award. On the other hand, if the Target condition is not met, the Bitcoin miner will need to perform cryptographic hashingin respect of one or more different Bitcoin Block Headers until the specified Target condition is met.The different Bitcoin Block Headers are typically generated by incrementing a Nonce field in the second portion of the Bitcoin Block Header. In this case, since the first portion of the Bitcoin Block Header remains unchanged, the output of SHA256o is unchanged and there is no need to re-perform SHA256o for each new Nonce. Once all values for the Nonce have been exhausted, then a Bitcoin Block Header that references different transactions, by way of a different HashMerkleRoot, might be considered. Since the HashMerkleRoot spans both parts of the Bitcoin Block Header, SHA256o then needs to be re-performed to generate a new message digest Ho, and SHA256i then needs to be re-applied to the second portion of the Bitcoin Block Header using that new message digest Ho as the initialisation vector. Further different Bitcoin Block Headers can again be generated by incrementing the Nonce field in the second portion of the Bitcoin Block Header.Bitcoin mining can be extremely computationally expensive and various optimisations have therefore been proposed. For example, Rahul P. Naik, “Optimising the SHA256 Hashing Algorithm for Faster and More Efficient Bitcoin Mining”, MSc Information Security Department of Computer Science UCL, 2013, describes various optimisations which make use of the fact that certain portions of the Bitcoin Block Header remain unchanged, or are slow to change, or are merely incremented, across plural different input messages. US 2018 / 0006808 A1 describes further optimisations which use hardwired values for the portions of input messages that always remain the same.The above optimisations go some way to reducing the computational burden but further optimisations, particularly relating to message scheduling, are possible. In this regard, when performing the cryptographic hashing, a message scheduler is used to calculate, from distinct portions of the input message, a set of input values for compression by the cryptographic compression function. This process of calculating the input values can contribute significantly to the computational effort required to perform the cryptographic hashing.EP 3 095 044 A1 describes a message scheduling optimisation commonly known as “ASICBoost” in which different input messages are used for SHA256o but in which the last 32 bits of the HashMerkleRoot in the Bitcoin Block Header, which are used to derive the input message for SHA256i, are kept the same. This is achieved either by identifying multiple instances of HashMerkleRoot that collide in the last 32 bits (commonly known as “Covert ASICBoost”) or by incrementing the Version in the Bitcoin Block Header (commonly known as “Overt ASICBoost”). The same message schedule for SHA256i can then be reused for multiple outputs of SHA256o. Pham et al, “Double SHA-256 Hardware Architecture With Compact Message Expander for Bitcoin Mining", IEEE Access, Volume 8, 2020, pp.139634-139646, also describes avoiding certain message scheduler calculations for SHA256i and SHA2562 where the input values will always have the value 0x00000000. GB 2 611 321 A1 describes ways in which to further reduce the number of message scheduling calculations that are needed by calculating a set of partially-calculated input values once using initial input message portions which will be invariable across plural different input messages and then, for each subsequent input message of the plural different inputmessages, calculating a set of fully calculated input values using the precalculated set of partially-calculated input values and the variable portions of the subsequent input message.It is desired to provide further improvements relating to message scheduling for cryptographic hashing.SUMMARYAccording to an aspect of the present invention there is provided a method of performing cryptographic hashing in respect of a group of plural different input messages, the method comprising: causing a message scheduling engine to: pre-calculate a message schedule array comprising plural different sets of input values for a cryptographic compression function, wherein each set of input values in the message schedule array corresponds to a respective input message of the group of plural different input messages; and causing a cryptographic compressor to: after the message schedule array has been pre-calculated by the message scheduling engine, perform the cryptographic compression function in respect of each input message of the group of plural different input messages, wherein performing the cryptographic compression function in respect of each input message comprises using the set of input values in the message schedule array corresponding to that input message so as to generate a message digest for that input message.According to another aspect of the present invention there is provided an apparatus for performing cryptographic hashing in respect of a group of plural different input messages, the apparatus comprising: a message scheduling engine having processing circuitry configured to: pre-calculate a message schedule array comprising plural different sets of input values for a cryptographic compression function, wherein each set of input values in the message schedule array corresponds to a respective input message of the group of plural different input messages; and a cryptographic compressor having processing circuitry configured to: after the message schedule array has been pre-calculated by the message scheduling engine, perform the cryptographic compression function in respect of each input message of the group of plural different input messages, wherein performing the cryptographic compression function in respect of each input message comprises using the set of input values in the message schedule array corresponding to that input message so as to generate a message digest for that input message.As will be appreciated, the present invention can greatly increase speed and efficiency when performing cryptographic hashing in respect of groups of plural different input messages. In particular, the Applicant has uniquely recognised that a message schedule array which comprises plural sets of input values can be pre-calculated in advance, i.e. asynchronously, for the plural different input messages and then later re-used many times over whenperforming cryptographic hashing in respect of the plural different input messages. Surprisingly, the Applicant has recognised that it is worthwhile doing this even though the message schedule array may be very large. For example, the message schedule array can also be re-used for further input messages having the same content as the group of plural different input messages but being derived from different overall block headers. This can significantly reduce the number of calculations which need to be performed synchronously during the cryptographic hashing process. This in turn can significantly increase the processing speed and / or can significantly reduce the processing burden placed on the apparatus used to perform the cryptographic hashing. This is in contrast to the known techniques in which the set of input values for each given input message is typically calculated synchronously by a message scheduler just prior to that input message being hashed by the cryptographic compressor.In embodiments, the cryptographic hashing may be performed when mining for cryptocurrency, such as (but not limited to) Bitcoin. The present invention is particularly beneficial in this context. However, the techniques disclosed herein may equally be applied in other cryptographic hashing contexts in which a group of plural different input messages are to be hashed.In embodiments, the cryptographic compression function may be a SHA256 cryptographic compression function. Overall, the cryptographic hashing may comprise performing plural (e.g. three) instances of the cryptographic compression function. For example, the cryptographic hashing may comprise performing a first instance cryptographic compression function (referred to herein as “SHA256o“), a second instance cryptographic compression function (referredto herein as “SHA256-T), and a third instance cryptographic compression function (referred to herein as “SHA2562"). The message digest from one instance of the cryptographic compression function may be passed to a subsequent instance of the cryptographic compression function (in the case of the first instance (SHA256o) and second instance (SHA256i)) or may be compared to a Target (in the case of the third instance (SHA2562)). An instance of the cryptographic compression function may use a standard initialisation vector as its initialisation vector (in the case of the first instance (SHA256o) and third instance (SHA2562)) or may use a message digest from the previous instance of the cryptographic compression function as its initialisation vector (in the case of the second instance (SHA256i)). The message scheduling for at least one instance of the cryptographic compression function may be performed in the manner of the present invention. For example, the message scheduling for the second instance cryptographic compression function (SHA256i) may be performed in the manner of the present invention. Thus, the cryptographic compression function may be a second instance cryptographic compression function (SHA256-i) of three instances of the cryptographic compression function (SHA256o, SHA256i, SHA2562) performed in the cryptographic hashing.In embodiments, the input messages of the group of plural different input messages may each be derived from a different block header. For example, the input messages of the group of plural different input messages may each be derived from a different Bitcoin Block Header. Each block header may comprise plural fields. For example, each block header may comprise a Version field, a HashPrevBlock field, a HashMerkleRoot field, a Timestamp field, a Target field,and / or a Nonce field. The block header may be padded, e.g. with a Padding + Length field, for the purposes of the cryptographic hashing. In embodiments, one or more of the plural fields or parts thereof (e.g. a (second or last) part of the HashMerkleRoot field, the Timestamp field, the Target field and / or the Padding + Length field) may have the same value across (each and every one of) the headers corresponding to the input messages of the group of plural different input messages. One or more of the plural fields or parts thereof (e.g. the Version field, the HashPrevBlock field, a (first or initial) part of the HashMerkleRoot field, the Timestamp field and / or the Nonce field) may not have the same value across (each and every one of) the block headers corresponding to the input messages of the group of plural different input messages. For example, one or more of the fields or parts thereof (e.g. the Version field and / or the Nonce field) may be incremented across the block headers corresponding to the input messages of the group of plural different input messages, e.g. in an attempt to find a SHA2562 message digest or “hash” that is lower than or equal to the Target. For another example, one or more of the fields or parts thereof (e.g. the HashPrevBlock field and / or a (first or initial) part of the HashMerkleRoot field) may change across the block headers corresponding to the input messages of the group of plural different input messages, e.g. in order to account for changes in the Bitcoin Network.In embodiments, each block header may comprise a first portion and a second portion, wherein the input messages of the group of plural different input messages each include the second portion of the block header. Thus, the input messages of the group of plural different input messages may each comprise plural fields or parts thereof. For example, the input messages of the group ofplural different input messages may each comprise a (second or last) part of a HashMerkleRoot field, a Timestamp field, a Target field, a Nonce field, and / or a Padding + Length field. As indicated above, one or more of the plural fields or parts thereof (e.g. a (second or last) part of the HashMerkleRoot field, the Timestamp field, the Target field, and / or the Padding + Length field) may have the same value across (each and every one of) the input messages of the group of plural different input messages. As also indicated above, one or more of the plural fields or parts thereof (e.g. the Timestamp field and / or the Nonce field) may have a different value across (each and every one of) the input messages of the group of plural different input messages. For example, one or more of the plural fields or parts thereof (e.g. the Nonce field) may be incremented across the input messages of the group of plural different input messages.In embodiments, each set of input values in the message schedule array may be calculated using a different field value of a set of field values that a particular (e.g. incremented) field (e.g. the Nonce field) of the input message can take. For example, where the particular field is an n-bit field having 2npossible field values, each set of input values in the message schedule array may be calculated using a different field value of a set of the 2npossible field values that the particular field of the input message can take. The set of field values may be a subset of, or the entire set of, possible values that the particular field of the input message can take. For example, when the set of field values is the entire set of possible values that the particular n-bit field of the input message can take, the message schedule array may comprise 2nsets of input values, each set of input values corresponding to a different one of 2ndifferent input messages andcalculated using a respective one of the 2nfield values. The value of n may, for example, be 32. Thus, the message schedule array may comprise some of, or all of, 232sets of input values corresponding respectively to some of, or all of, 232different input messages having 232different (e.g. Nonce) field values. Alternatively, the message schedule array may comprise more than 232sets of input values corresponding respectively to different input messages having more than 232different combinations of (e.g. Nonce and / or Timestamp) field values.In embodiments, each input message may be a 512-bit input message. Each set of input values in the message schedule array may comprise a set of 64 input values. Each input value of each set of input values may be a 32-bit input value. Thus, the message scheduling engine may expand each input message to a set of 64 32-bit input values totalling 2048 bits (64 x 32).It will be appreciated that, in embodiments, a first portion of the block headers corresponding to the input messages (e.g. the Version field, the HashPrevBlock field and / or a (first or initial) part of the HashMerkleRoot field) may change freely between the block headers without affecting the validity of the message schedule array. For example, the Version field may be incremented without affecting the validity of the message schedule array. Furthermore, the HashPrevBlock field may be updated when there is a new previous block, without affecting the validity of the message schedule array. Furthermore, a (first or initial) part of the HashMerkleRoot field may be changed whilst a (second or last) part of the HashMerkleRoot field may be left unchanged, e.g. by selecting appropriate transactions, without affecting the validity of the message schedule array.Thus, embodiments may comprise the cryptographic compressor using the message schedule array to perform the cryptographic compression function in respect of each input message of a first group of plural different input messages and then re-using the message schedule array to perform the cryptographic compression function in respect of each input message of a second group of plural different input messages, wherein the first and second groups of plural different input messages are identical but are derived from different first and second groups of block headers (e.g. having a different Version field, a different HashPrevBlock field and / or a different (first or initial) part of the HashMerkleRoot field).In embodiments, the message scheduling engine may be configured to (and caused to) select appropriate transactions for the headers of the first and / or second group of plural different input messages such that a (first or initial) part of the HashMerkleRoot field of the second group is different from that of the first group whilst a (second or last) part of the HashMerkleRoot field of the second group is the same as that of the first group. For example, a predetermined (second or last) part of the HashMerkleRoot field may be selected, e.g. in advance of and / or non-asynchronously with performing cryptographic hashing in respect of the first and second groups of plural different input messages. The message scheduling engine may, for example, be configured to (and caused to) select appropriate transactions which provide the predetermined (second or last) part of the HashMerkleRoot field to allow the same message schedule array to be used for both the first and second group of plural different input messages. Alternatively, the message scheduling engine may be configured to (and causedto) store a (second or last) part of the HashMerkleRoot field for a first group of plural different input messages and then to select appropriate transactions which provide that same (second or last) part of the HashMerkleRoot field to allow the same message schedule array to be re-used for a second group of plural different input messages. The selection of appropriate transactions may be implemented in any desired and suitable way, for example the message scheduling engine may implement artificial intelligence which is trained to select the appropriate transactions.It is also desirable to keep a message schedule array valid for as long as possible to reduce the need to pre-calculate a further message schedule array. Thus, the message scheduling engine may be configured to (and caused to) attempt to increase the amount of time between any changes to one or more of the fields or parts thereof (e.g. the HashMerkleRoot field). The message scheduling engine may, for example, be configured to (and caused to) select appropriate sets of transactions which are more likely to remain relevant for longer and / or for more blocks. Thus, the message scheduling engine may be configured preferentially to select transactions for forming block headers that are used to derive the group of plural different input messages which are more likely to remain relevant for a longer period of time and / or for more blocks when compared with other transactions. The selection may again be implemented by the message scheduling engine in any desired and suitable way, for example the message scheduling engine may implement artificial intelligence which is trained to select the appropriate transactions or may use a heuristic approach to select the appropriate transactions.It will, however, be appreciated that the fields or parts thereof (e.g. a (second or last) part of the HashMerkleRoot field, the Timestamp field, and / or the Target field) which are the same for the group of plural different input messages for which the message schedule array was pre-calculated may not be the same for other groups of plural different input messages. These other groups of plural different input messages may make use of a different message schedule array which has been pre-calculated in the manner of the present invention.Thus, in embodiments, the message scheduling engine may be configured to (and caused to), e.g. asynchronously, pre-calculate a further message schedule array for a further (e.g. subsequent) group of plural different input messages to be hashed. For example, the message scheduling engine may be configured to (and caused to) pre-calculate a further message schedule array if there is a change to one or more of the fields or parts thereof (e.g. a (second or last) part of the HashMerkleRoot field, the Timestamp field and / or the Target field) which were the same for the group of plural different input messages for which the (e.g. current) message schedule array was pre-calculated.The further message schedule array may then be used by the message compressor when hashing the further group of plural different input messages in the manner of the present invention. Thus, the message compressor may be configured to (and caused to), after a further message schedule array has been pre-calculated, perform the cryptographic compression function in respect of each input message of the further group of plural different input messages, wherein performing the cryptographic compression function in respect of each input message of the further group of plural different input messages comprisesusing the set of input values in the further message schedule array corresponding to that input message so as to generate a message digest for that input message.In embodiments, for each different input message to be hashed, the precalculation of the set of input values may comprise performing one or more or all of the operations in a (e.g. SHA256) message scheduling calculation. For example, for t rounds of compression, the message scheduling calculation for an input value W[t] of a set of input values W, which is derived from a (e.g. distinct) input message portion M[t] of an input message M, may comprise performing:For 0 < t < 15, W[t] = M[t]For 16 < t < 63, W[t] = m (W[t-2]) + W[t-7] + a0(W[t-15]) + W[t-16] where: ff (x) = ROTRI (X) © ROTRis(x) © SHRio(x) ffo(x) = ROTR (X) © ROTRI8(X) © SHR3(X)ROTRi is a bitwise rotate right for i bitsSHRi is a bitwise shift right for i bits; and© is a bitwise exclusive ORThus, for each different input message to be hashed, the pre-calculation of the set of input values may comprise performing one or more or all of: an add operation; a bitwise rotate right (ROTR) operation; a bitwise shift right (SHR) operation; and a bitwise exclusive OR ©) operation.In embodiments, for each different input message to be hashed, the precalculation of the set of input values may also comprise adding a round-specific constant to each of the input values of the set of input values. Adding a roundspecific constant may be performed by the message scheduling engine. Thus,for each different input message to be hashed, the pre-calculation of the set of input values may also comprise the message scheduling engine adding a roundspecific constant to each of the input values of the set of input values to generate a set of constant-modified input values. It may then be these constant-modified input values which form the message schedule array. Alternatively, adding a round-specific constant to each of the input values of the set may be performed by the message scheduling engine, a message scheduler or the message compressor after the message schedule array has been pre-calculated and / or, e.g. synchronously, prior to performing the cryptographic compression function in respect of the input message in question.In embodiments, the message scheduling engine may be configured to (and caused to) store the message schedule array (e.g. in electronic storage of or for the apparatus, such as (but not limited to) registers and / or memory). The apparatus may comprise retrieval circuitry (e.g. of the message scheduling engine or a message scheduler) which is configured to (and caused to) retrieve, for a given input message, the corresponding set of input values for the input message in the message schedule array (e.g. from the electronic storage) and to provide that set of input values to the message compressor to be used when performing the cryptographic compression function in respect of that input message. Alternatively, the message compressor itself may comprise retrieval circuitry configured to (and caused to) retrieve, for a given input message, the corresponding set of input values for the input message in the message schedule array (e.g. from the electronic storage) prior to using that set of input values whenperforming the cryptographic compression function in respect of that input message.Embodiments can be implemented in any desired and suitable data processing apparatus, such as any suitably configured computer-based, processor-based, and / or circuitry-based, system. Similarly, the various functions of the apparatus described herein can be carried out in any desired and suitable manner. For example, the functions of the apparatus described herein may be implemented in hardware and / or software as desired. Thus, unless otherwise indicated, the various functional elements described herein may, for example, comprise a suitable processor or processors, controller or controllers, functional unit or units, circuitry, processing logic, microprocessor arrangements, etc., that are operable to perform the various functions, etc., such as appropriately dedicated hardware elements (processing circuitry) and / or programmable hardware elements (processing circuitry) that are configured to (and caused to) operate in the desired manner. In embodiments, the apparatus may comprise one or more integrated circuits, such as one or more ASICs (Application-Specific Integrated Circuits) and / or FPGAs (Field-Programmable Gate Arrays). In embodiments, the apparatus may comprise, and / or may be in communication with, one or more electronic storage devices that store the data (e.g. transaction data, header data, input message data, message schedule array data, roundspecific constant data, initialisation vector data, message digest data, etc.) as described herein.BRIEF DESCRIPTION OF DRAWINGSBy way of example only, embodiments of the present invention will now be described in detail with reference being made to the accompanying drawings in which:Figure 1 illustrates an apparatus for performing cryptographic hashing according to an embodiment of the present invention;Figure 2 illustrates a message scheduling operation as performed by the apparatus of Figure 1 ;Figure 3 illustrates cryptographic hashing of a Bitcoin Block Header as performed by the apparatus of Figure 1 ;Figure 4 illustrates generation of a hashMerkleRoot according to an embodiment of the present invention; andFigure 5 illustrates cryptographic compression as performed by the apparatus of Figure 1 .DETAILED DESCRIPTIONFigure 1 shows an apparatus 100 comprising processing circuitry for performing cryptographic hashing. The apparatus 100 may, for example, be implemented using one or more ASICs. The apparatus 100 comprises one or more cryptographic hashing modules 102 (only one shown in Figure 1 ).In this embodiment, the cryptographic hashing module 102 is configured to perform SHA256 to compress a 512-bit input message 104 based on a 256-bit initialisation vector 106 in order to produce a 256-bit message digest or hash 108. The cryptographic hashing module 102 comprises a message scheduler 110which is configured to divide the input message 104 into distinct portions and use those distinct portions to derive a set of input values for t rounds of message compression performed by message compressor 112.In SHA256, the message scheduler 110 divides the input message 104 into 16 x 32-bit words M[0]-M

[0015] and expands those 16 x 32-bit words to derive a set of 64 x 32-bit input values W[0]-W

[0063] for the message compressor 112 in accordance with the following:The 8 elements HA-HH of an initialisation vector 106 are also stored as working variables A-H in electronic storage 114 as follows:The message compressor 112 then performs the 64 rounds of a SHA256 message compression function using the set of input values W[0]-W

[0063] provided by the message scheduler 110, together with the working variables A-H stored in electronic storage 114 and a set of 64 x 32-bit round-specific constants K[0]-K

[0063] in accordance with the following:After the 64 rounds the following calculations are performed:In SHA256, the standard initialisation vector IV is:and the round-specific constants K[0]-K

[0063] are:Figure 2 shows details of the message scheduling operation, for example as performed by the message scheduler 110. In this embodiment, the message scheduling comprises causing a multiplexor 202 to progressively select, in 5 respect of each input message, the input value W[t] either to be i) M[t] for 0 < t < 15; or ii) <n(W[t-2]) + W[t-7] + a0(W[t-15]) + W[t-16] for 16 < t < 63. The selected input value W[t] is then progressively passed to circuitry 204 for addition with K[t] to produce the constant-modified input value W[t], Thus, in this embodiment, the message scheduling operation also involves performing the step of adding the0 set of round-specific constants K[0]-K

[0063] respectively to the set of input values W[0]-W

[0063] to generate a set of constant-modified input values W[0]-W

[0063] , although in other embodiments the circuitry 204 could be omitted and the addition of the round-specific constants K[0]-K

[0063] could instead be performed by the message compressor 112. To enable the calculation of W[t] for 16 < t < 63, the5 input values W[t] are also progressively moved through a set of 16 x 32-bit registers 206. Circuitry 208 is then used to perform the standard message scheduling calculation: ai(W[t-2]) + W[t-7] + ao(W[t-15]) + W[t-16]. The messagescheduler 110 operates in this conventional manner in respect of SHA256o and SHA2562.Referring again to Figure 1 , the apparatus 100 further comprises a message scheduling engine (MSE) 116 for calculating a message schedule array (MSA) and electronic storage 118 for storing the MSA. The MSA comprises, for each one of plural different input messages derived from a respective block header, a corresponding set of pre-calculated input values W[0]-W

[0063] , which are calculated in the same manner as the message scheduler 110 discussed above. Thus, the MSE 116 also includes the circuitry as shown in Figure 2 in order to calculate the sets of pre-calculated input values W[0]-W

[0063] for each of the input messages. As will be discussed in more detail below, in this embodiment, the MSE 116 only pre-calculates and stores an MSA in respect of SHA256i for later retrieval by the message scheduler 110.Thus, in accordance with embodiments of the present invention, depending on which instance of SHA256 is being performed, the message scheduler 110 either operates in a conventional manner by synchronously calculating the constant-modified input values W[0]-W

[0063] or retrieves the asynchronously pre-calculated constant-modified input values W’[0]-W

[0063] from the MSA in electronic storage 118. In either case, the message scheduler 110 provides those constant-modified input values WlOJ-W^eS] to the message compressor 112 to perform the message compression function. Using the MSA in respect of SHA256i can, for example, reduce the need to re-calculate the input values for SHA256i synchronously multiple times for many different groups of plural different input messages where those input values would remain the same.Other cryptographic hashing modules 102 may also have access to the MSA in electronic storage 118 for parallel compression of the different input messages.Figure 3 illustrates further details of cryptographic hashing of a Bitcoin Block Header 302. The Bitcoin Block Header 302 contains: a 32-bit Version field 304 which provides block version information; a 256-bit HashPrevBlock field 306 which provides the message digest of the previous block accepted by the Bitcoin Network as referenced by the current block; a 256-bit HashMerkleRoot field 308 which provides a message digest of the Merkle Root for the unconfirmed transactions that are selected by the MSA engine 116 to include in the new block; a 32-Bit Timestamp field 310 which provides the current timestamp in seconds since 1970-01-01 00:00 UTC; a 32-bit Target field 312 which provides the current Target to be met for the message digest of the new block (i.e. indicative of a particular minimum number of leading zeros that the message digest must have); and a 32-bit Nonce field 314 which is used to add variation to the block header so as to compute different message digests. A 384-bit Padding + Length field 316 is appended to provide two 512-bit input messages 318 and 320 of suitable size for cryptographic hashing using SHA256.In order to perform the cryptographic hashing, a first input message 318 is provided by the MSE 116 to a first cryptographic hashing module 324 which operates in a conventional manner by synchronously calculating the constant- modified input values W[0]-W

[0063] , The first cryptographic hashing module 324 performs a first instance cryptographic hashing SHA256o of the first input message 318 using the standard initialisation vector IV 322. SHA256o produces a first message digest Ho which is stored in electronic storage 326.In accordance with the present invention, a second cryptographic hashing module 328 performs the SHA256 message compression function in respect of a second instance cryptographic hashing SHA256i using the first message digest Ho as the initialisation vector together with a set of input values retrieved from the MSA, as calculated and stored by the MSE 116 in electronic storage 118.As discussed above, in advance of performing SHA256i message compression in respect of plural different input messages 320, the MSE 116 precalculates and stores a respective set of input values W[0]-W

[0063] for each one of those plural different input messages 320. In this embodiment, each input message 302 will have the same last 32 bits of the HashMerkleRoot field 308, the same Timestamp field 310, the same Target field 312 and the same Padding + Length field 316, but an incremented Nonce field 314. Thus, the MSA can comprise up to 232sets of input values, with there potentially being one set of 64 x 32-bit input values for each value that the Nonce can take. Alternatively or additionally, a message scheduling array might be stored in the MSA based on different values for other fields, such as different values of the Timestamp field. In this case, the MSA can comprise fewer or more than 232sets of input values. Thus, the MSA may be up to 1TB in size, but the amount of data stored may be smaller or larger depending on whether or not input values are included corresponding to each and every Nonce value and / or whether or not input values are included corresponding to other fields values, such as different Timestamp field values. Although this can be a large amount of data, since the input values for the plural input messages 302 are already stored in the electronic storage 118, there is no need to wait for the message scheduler 110 to calculate thoseinput values synchronously while performing the SHA256i hashing algorithm, and this can significantly reduce the overall processing time by allowing asynchronous operation.Furthermore, those input values can be reused, and thus do not need to be recalculated, for other Version fields 304, HashPrevBlock fields 306, and first 224-bits of the HashMerkleRoot field 308. For example, multiple instances of the HashMerkleRoot that have the same last 32 bits may be identified and / or the Version may be incremented. In either case, the last 32 bits of the HashMerkleRoot field 308 will remain unchanged and thus, as long as the Timestamp field 312 and Target field 312 also remain unchanged, the same MSA as previously pre-calculated and stored in the electronic storage 116, can be reused.Figure 4 shows the process by which the HashMerkleRoot 412 may be derived. In this embodiment sixteen transactions are shown, although a much greater number of transactions could be used. First, a set 402 of unconfirmed transactions tXA-txp are selected by the MSE 116 from the Bitcoin Mempool 120 (see Figure 1 ). Then, a first set 404 of hash values HA-HP are generated by hashing each transaction id in the set 402 of transactions txA-txp. Next, a second set 406 of hash values HAB-HOP are generated by hashing pairs of hash values in the first set 404 of hash values HA-HP. Next, a third set 408 of hash values HABCD- HMNOP are generated by hashing pairs of hash values in the second set 406 of hash values HAB-HOP. Next, a fourth set 410 of hash values HABCDEFGH-HILKLMNOP are generated by hashing pairs of hash values in the third set 408 of hash valuesHABCD-HMNOP. Finally, the HashMerkleRoot 412 is generated by hashing the pair of hash values in the fourth set 410 of hash values HABCDEFGH-HILKLMNOP.As discussed above, the entire HashMerkleRoot 412 could be kept the same for plural different input messages. Alternatively or additionally, various techniques can be used to identify multiple instances of the HashMerkleRoot 412 that have a desired last 32 bits. For example, the MSE 116 could use artificial intelligence trained to select sets of transactions from the Mempool 120 that are more likely to result in a predetermined last 32 bits. Alternatively, the MSE 116 could store the last 32-bits of an initial HashMerkleRoot 412 for a first set of transactions and then use artificial intelligence trained to select other sets of transactions from the Mempool 120 that are more likely to result in the same last 32 bits. Various techniques can also be used to increase the amount of time that a given MSA, as stored in the electronic storage 118, remains valid. For example, an artificial intelligence or heuristic approach could be used to select sets of transactions which are more likely to remain relevant for more blocks by remaining in the Mempool 120 for a greater amount of time.Referring again to Figure 3, the SHA256i hashing algorithm produces a second message digest Hi 330. The second message digest Hi is combined with a Padding + Length 332 to create a third input message 334 of suitable size for cryptographic hashing using SHA256. The third input message 334 is provided to a third cryptographic hashing module 338, which again operates in a conventional manner by synchronously calculating the constant-modified input values W[0]-W

[0063] , The third cryptographic hashing module 338 performs a third instance cryptographic hashing SHA2562 of the third input message 334 usingthe standard initialisation vector IV 336. SHA2562 produces a third, and final, message digest H2340.If the third message digest H2 meets the Target condition, then the Bitcoin Block Header used to create that message digest H2 can be broadcast to the Bitcoin Network. On the other hand, if the third message digest H2 does not meet the Target condition, then one or more different Bitcoin Block Headers will need to be considered. In this embodiment, this is achieved by the second cryptographic hashing module 328 using the same first message digest Ho together with each subsequent set of input values in the MSA (which corresponds to an incremented Nonce value) until either H2 meets the Target condition or all Nonce values are exhausted. At this point, the Version may be incremented, a new hashPrevBlock may be available and / or a new HashMerkleRoot with the same last 32 bits may be derived, such that the same MSA can be re-used again. It is also possible for the MSE 116 to asynchronously pre-calculate and store plural sets of input values in a new MSA for other groups of plural input messages, e.g. having a different last 32 bits of the HashMerkleRoot field 308, a different Timestamp field 310 and / or a different Target field 312.Figure 5 shows the cryptographic compression in more detail. As is shown, a first message compressor 502 is used to perform the 64 rounds of compression in SHA256o. The first message compressor 502 receives the set of constant- modified input values Wo’[t] calculated synchronously by a message scheduler 110 and the standard initialisation vector IV 322. Also shown is circuitry 504 for adding the outputs of the first message compressor 502 to the elements of the standard initialisation vector IV 322 to produce the first message digest Ho. Alsoshown is a second message compressor 506 for performing the 64 rounds of compression in SHA256i. The second message compressor 506 receives the set of constant-modified input values Wi’[t] retrieved from the MSA for the input message in question from the electronic storage 118 and Ho as an initialisation vector. Also shown is circuitry 508 for adding the outputs of the second message compressor 506 to the elements of Ho to produce the second message digest Hi. Also shown is a third message compressor 510 for performing the 64 rounds of compression in SHA2562. The third message compressor 510 receives the set of constant-modified input values W2’[t] calculated synchronously by a message scheduler 110, which are based on H-i, and the standard initialisation vector IV 336. Also shown is circuitry 512 for adding the outputs of the third message compressor 510 to the elements of the standard initialisation vector IV 336 to produce the third, and final, message digest H2.

Claims

CLAIMS1. A method of performing cryptographic hashing in respect of a group of plural different input messages, the method comprising: causing a message scheduling engine to: pre-calculate a message schedule array comprising plural different sets of input values for a cryptographic compression function, wherein each set of input values in the message schedule array corresponds to a respective input message of the group of plural different input messages; and causing a cryptographic compressor to: after the message schedule array has been pre-calculated by the message scheduling engine, perform the cryptographic compression function in respect of each input message of the group of plural different input messages, wherein performing the cryptographic compression function in respect of each input message comprises using the set of input values in the message schedule array corresponding to that input message so as to generate a message digest for that input message.

2. A method as claimed in claim 1 , wherein the cryptographic hashing is performed when mining for Bitcoin.

3. A method as claimed in claim 1 or 2, wherein the cryptographic compression function is a SHA256 cryptographic compression function.

4. A method as claimed in claim 1 , 2 or 3, wherein the cryptographic compression function is a second instance cryptographic compression functionof three instances of the cryptographic compression function performed in the cryptographic hashing.

5. A method as claimed in any one of the preceding claims, wherein the input messages of the group of plural different input messages are each derived from a different block header.

6. A method as claimed in claim 5, wherein each block header comprises a Version field, a HashPrevBlock field, a HashMerkleRoot field, a Timestamp field, a Target field, and a Nonce field.

7. A method as claimed in claim 5 or 6, wherein each block header comprises a first portion and a second portion, and wherein the input messages of the group of plural different input messages each include the second portion of the block header.

8. A method as claimed in any one of the preceding claims, wherein the input messages of the group of plural different input messages each comprise a part of a HashMerkleRoot field, a Timestamp field, a Target field, a Nonce field and a Padding + Length field.

9. A method as claimed in claim 8, wherein the part of the HashMerkleRoot field, the Timestamp field, the Target field and / or the Padding + Length field have the same value across the input messages of the group of plural different input messages.

10. A method as claimed in claim 8 or 9, wherein the Nonce field has a different value across the input messages of the group of plural different input messages.

11. A method as claimed in claim 8, 9 or 10, wherein the Nonce field is incremented across the input messages of the group of plural different input messages.

12. A method as claimed in any one of claims 8-11 , wherein each set of input values in the message schedule array is calculated using a different field value of a set of field values that the Nonce field of the input message can take.

13. A method as claimed in any one of the preceding claims, wherein the cryptographic compressor uses the message schedule array to perform the cryptographic compression function in respect of each input message of a first group of plural different input messages and then re-uses the message schedule array to perform the cryptographic compression function in respect of each input message of a second group of plural different input messages, wherein the first and second groups of plural different input messages are identical but are derived from different first and second groups of block headers.

14. A method as claimed in claim 13, wherein the message scheduling engine selects transactions for the block headers of the second group of plural different input messages such that a first part of a HashMerkleRoot field of the second group is different from that of the first group whilst a second part of the HashMerkleRoot field of the second group is the same as that of the first group.

15. A method as claimed in any one of the preceding claims, wherein the message scheduling engine preferentially selects transactions for forming block headers that are used to derive the group of plural different input messages which are more likely to remain relevant for a longer period of time and / or for more blocks when compared with other transactions.

16. A method as claimed in any one of the preceding claims, wherein the message scheduling engine pre-calculates a further message schedule array for a further group of plural different input messages to be hashed.

17. A method as claimed in claim 16, wherein the message compressor, after the further message schedule array has been pre-calculated, performs the cryptographic compression function in respect of each input message of the further group of plural different input messages, wherein performing the cryptographic compression function in respect of each input message of the further group of plural different input messages comprises using the set of input values in the further message schedule array corresponding to that input message so as to generate a message digest for that input message.

18. A method as claimed in any one of the preceding claims, wherein, for each different input message to be hashed, the pre-calculation of the set of input values comprises performing one or more or all of the operations in a message scheduling calculation.

19. A method as claimed in any one of the preceding claims, wherein, for each different input message to be hashed, the pre-calculation of the set of input values comprises adding a round-specific constant to each of the input values of the set of input values.

20. An apparatus for performing cryptographic hashing in respect of a group of plural different input messages, the apparatus comprising: a message scheduling engine having processing circuitry configured to: pre-calculate a message schedule array comprising plural different sets of input values for a cryptographic compression function, whereineach set of input values in the message schedule array corresponds to a respective input message of the group of plural different input messages; and a cryptographic compressor having processing circuitry configured to: after the message schedule array has been pre-calculated by the message scheduling engine, perform the cryptographic compression function in respect of each input message of the group of plural different input messages, wherein performing the cryptographic compression function in respect of each input message comprises using the set of input values in the message schedule array corresponding to that input message so as to generate a message digest for that input message.

Images