SHA-256 CNF conversion and bitcoin mining

Question

When the tool cgen converts SHA-256 into CNF, which literals represent the input bits?

For example, if we input 640 bits into the SHA-256 algorithm, then which bits will represent the nonce?

Answer 1

When the tool cgen converts SHA-256 into CNF, which literals represent the input bits?

Based mostly on the doc and a few experiments: on input like ./cgen encode SHA256, the output sha256r64.cnf has comments near the beginning (lines starting with a c) that describe the assignment of the variables. For the message input the comment is

c var M = {1/32/1}/16/32

which means that the input message block consists of variables 1 thru 512. That's because 1/32/1 means start from 1, 32 variables, incrementing by 1 for each variable; and {}/16/32 means repeat such group 16 times, incrementing the initial number by 32 for each group of variables.

Similarly the following comment describes the assignment of the hash output:

c var H = {{47733/31/-2, -47610}, {-47794, 47792/30/-2, -47052}, {47853/30/-2, -46494, 46492}, {-47912, 47910/29/-2, -45936, 45934}, {47973/31/-2, -47547}, {-48030, 48028/28/-2, -46993, 46991, 46989}, {48091/31/-2, -46429}, {48152/31/-2, -45871}}

And that tells the output is formed of 8 groups of 32 variables, the first group being the variables
47733, 47731, 47729, (26 numbers omitted), 47675, 47673, -47610;
the second group being the variables
-47794, 47792, 47790, (26 numbers omitted), 47736, 47734, -47052;
and so on.

Reading order in the comment coincides with reading order in message and hash when data is in big-endian binary. A minus indicates the variable is complemented.

---

if we input 640 bits into the SHA-256 algorithm…

The command discussed previously is for a single compression function for a single 512-bit message block. If we add the padding manually, that allows messages of 0 to 447 bits.

For 640 bits, that is 80 bytes, I think the command would be

./cgen encode SHA256 -vM string:01234567890123456789012345678901234567890123456789012345678901234567890123456789 pad:sha256 except:1..640

with the input bits 1…640. Since there are two chained compressions, there are about twice as many equations.

For SHA256d used in bitcoin (which re-hashes the hash), I can't find direct support in the tool. We need one more compression function, for a total of three. Note that in mining, the first compression is essentially constant and handled outside the mining ASICs.

---

From thought experiment: the best SAT solvers will actually do when submitted problems about SHA-256 with full 64 rounds per compression is: compute SHA-256 in the forward direction for given inputs, or/and find a few bits of missing input (when there is a solution). The running time grows at best as $2^b$ where $b$ is the total number of missing input bits, and the whole thing does not help at all in bitcoin mining.