More Info About How @supercomputing Was Dominating The Mining Queue

@arhag wrote a post described how @supercomputing was able to dominate the mining queue before hard fork 13.

Here is the old algorithm described in @arhag's post:

1) hash1     = SHA256(latest_block_id)

2) hash2     = hash1 except for the first 64-bits replaced by some nonce (basically some random number selected to try to make the final work value have a sufficient number of leading 0 bits)

3) input     = SHA256(hash2)

4) sig       = ECDSA signature (in 65-byte format) of input using d (the active private key) and k (which is just another nonce used for signing)

5) sig_hash  = SHA256(sig)

6) pubkey    = Recover public key (33-byte format) corresponding to the private key that would have signed sig_hash with signature sig

7) work      = SHA256(pubkey)

work must have sufficient number of leading 0 bits matching the current mining difficulty target

In the post @arhag described:

... quickly (within a millisecond) calculate the corresponding private key necessary to make the new PoW valid according to the mining algorithm ... With the appropriate active private key d computed, the attacker can then change their account's active public key to the one corresponding to the private key ...

But there is a hole in the description, because the private key of a given signature shouldn't be so quickly to be resolved -- it's the nature of ECC algo.

Actually, with the old algorithm, to submit a PoW, an attacker doesn't need to know the private key.

When an attacker got an input with latest head_block_id and whatever nounce in step 3), and if she already have a known will-work sig in step 4), she can simply recover the public key (which is needed to put into the PoW operation) with the same method used in step 6). In addition, because a transaction contains only a PoW operation requires no signature (which is another hole in the old algo which got fixed in new algo), the PoW will be accepted by other nodes.