Can a proof-of-work estimate the mixing time of a Rubik's cube?

Can a proof-of-work estimate the mixing time of a Rubik's cube?

Forgive the flight-of-fancy; if this is too far-fetched I will delete.

To start off, as of now (1d6e05de09721d4d56107ffbcf54dc557b881e7c83ae36) the number of hashes performed every ten minutes, about 2^71 or so, is not that far off from the order of the Rubik's cube group, about 2^68 or so. That is, presently Bitcoin miners perform slightly more hashes every 10 minutes than the number of positions on a 3x3x3 Rubik's cube.

Elements of the Rubik's cube group are usually written as a combination of moves on the 6 faces (front, back, down, etc.) A move is often called an "algorithm" in cube terminology, or a "word" in discussions about group theory. Thus, each algorithm can be written as a string of moves, e.g. FUDF^2B^-1, etc.

The "mixing time" tau of the Rubik's cube group is the estimated number of scrambles that are needed to go from the solved position to a "random" position, i.e. one of these 2^68 permutations would be achieved after tau moves, with equal probability for each position. Thus, the mixing time is the minimum length of the word/algorithm needed to properly mix the cube.

AFAIK the mixing time of the Rubik's cube group is unknown, but I think there's a consensus that for the 3x3x3 Rubik's cube under the half-turn metric it is less than 40 or so.

Accordingly, I think of the following "proof-of-work:"

• Miners interpret their header/nonce string as a Rubik's cube word/algorithm; with 6 faces and an estimated 40-generator string, the size of such a word would easily be achieved I think
• Miners scramble a Rubik's cube that is in a solved state per the Rubik's cube word above, to generate a permuted cube
• Miners hash the resulting permuted cube, using, say, SHA256
• If the resulting hash is below the target, they win the reward

That is, miners explore every possible state of the Rubik's cube group, as long as the length of the "block/nonce" string, when interpreted as a Rubik's-cube algorithm, is greater than the mixing time tau. Accordingly, one of the Rubik's positions that a miner finds would hash onto a very small number, e.g. around 2^-68 or so.

Would the above approach help to upper-bound the mixing time of the Rubik's cube group?

Clearly this is not meant to be for a practical blockchain/altcoin; this is just for fun thinking about the ridiculous number of hashes being performed every 10 minutes.

https://ift.tt/2yXhtUF