RE: How @supercomputing was able to dominate the mining queue and how the bug was fixed. by letc

View this thread on: hive.blog | peakd.com | ecency.com

Viewing a response to: @arhag/how-supercomputing-was-able-to-dominate-the-mining-queue-and-how-the-bug-was-fixed

steem · @letc · Aug 16 '16

$3.26

It is possible to create a faster ECDSA implementation (GPU or CPU) by compromising on security of the private key (which is OK now as the new algorithm does not use the accounts private key), but will such an implementation be useful for anything other than mining?

I experimented a bit with the EC library before the hard fork (just out of curiosity, do not have the hardware to profit from mining).

First, I ported the changes from [this secp256k1 fork](https://github.com/llamasoft/secp256k1_fast_unsafe). The simple modifications like replacing  constant-time functions with variable-time equivalents gave about 15% increase in hash rate. After adapting their ecmult implementation (ecmult_big) I got 10% more.

I also replaced the RFC 6979 nonce function with a trivial implementation and it gained me 30% more hash rate in addition to the above, but this hack is not relevant any longer.

👍 abit, fydel

`author`	letc
`permlink`	re-arhag-how-supercomputing-was-able-to-dominate-the-mining-queue-and-how-the-bug-was-fixed-20160816t011609794z
`category`	steem
`json_metadata`	{"tags":["steem"],"links":["https://github.com/llamasoft/secp256k1_fast_unsafe"]}
`created`	2016-08-16 01:16:09
`last_update`	2016-08-16 01:16:09
`depth`	1
`children`	2
`last_payout`	2016-09-16 02:57:09
`cashout_time`	1969-12-31 23:59:59
`total_payout_value`	3.260 HBD
`curator_payout_value`	0.000 HBD
`pending_payout_value`	0.000 HBD
`promoted`	0.000 HBD
`body_length`	896
`author_reputation`	4,908,604,636,880
`root_title`	"How @supercomputing was able to dominate the mining queue and how the bug was fixed."
`beneficiaries`	`[]`
`max_accepted_payout`	1,000,000.000 HBD
`percent_hbd`	10,000
`post_id`	827,066
`net_rshares`	5,926,497,906,350
`author_curate_reward`	""

properties (23)vote details (2)

voter	weight	wgt%	rshares	pct	time
abit	0 B		5,926,232,052,156	100%
fydel	0 B		265,854,194	100%

@abit · Aug 17 '16

Thanks for sharing.

properties (22)

`author`	abit
`permlink`	re-letc-re-arhag-how-supercomputing-was-able-to-dominate-the-mining-queue-and-how-the-bug-was-fixed-20160817t192252684z
`category`	steem
`json_metadata`	{"tags":["steem"]}
`created`	2016-08-17 19:22:51
`last_update`	2016-08-17 19:22:51
`depth`	2
`children`	1
`last_payout`	2016-09-16 02:57:09
`cashout_time`	1969-12-31 23:59:59
`total_payout_value`	0.000 HBD
`curator_payout_value`	0.000 HBD
`pending_payout_value`	0.000 HBD
`promoted`	0.000 HBD
`body_length`	19
`author_reputation`	141,171,499,037,785
`root_title`	"How @supercomputing was able to dominate the mining queue and how the bug was fixed."
`beneficiaries`	`[]`
`max_accepted_payout`	1,000,000.000 HBD
`percent_hbd`	10,000
`post_id`	857,753
`net_rshares`	0

@letc · Aug 31 '16

I retried my experiments with the current version — got about 60% increase in hash rate by applying the changes from the fast unsafe secp256k1 fork and enabling GMP. Details and patches are [here](https://steemit.com/mining/@letc/steem-mining-how-to-increase-hash-rate-by-60-patches-included).

properties (22)