New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Corrected the PoW adjustment parameters. #151

Merged
merged 2 commits into from Nov 8, 2017

Conversation

Projects
None yet
4 participants
@martin-key
Contributor

martin-key commented Nov 7, 2017

With the current parameters the Diff adjustment will be more dynamic. I have made the percentage of lowering the difficulty twice higher, because if some of the major pools stops this could lead to really slow block time, that way it will be reduced at a good speed.

@h4x3rotab

This comment has been minimized.

Show comment
Hide comment
@h4x3rotab

h4x3rotab Nov 8, 2017

Contributor

This change is based on #78. We switched back to +16% -32% cap but keep the N=30 for testnet as the hash power can be far less than the mainnet and can be fluctuate. We didn't applied the 1.0088 fix because of the same reason.

Contributor

h4x3rotab commented Nov 8, 2017

This change is based on #78. We switched back to +16% -32% cap but keep the N=30 for testnet as the hash power can be far less than the mainnet and can be fluctuate. We didn't applied the 1.0088 fix because of the same reason.

@h4x3rotab h4x3rotab merged commit 6827afe into BTCGPU:master Nov 8, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@zawy12

This comment has been minimized.

Show comment
Hide comment
@zawy12

zawy12 Nov 8, 2017

If you go with N=30 instead of N=40, the correction factor will be about 1.02.

The following shows how it will vary on a daily basis, and how it will very likely vary when it goes live due to hash attacks. The peaks after the red bars (hash attacks) are the price your constant miners have to pay as big miners come on briefly to get cheap blocks.

n30
n30_attacks

If you want to write your own difficulty algorithm, currently the best one available is shown below. Jacob Eliosoff came up with this a few days ago, using his stock analysis knowledge. It needs protection against "negative" solvetimes. You could stick with Zcash's MTP but you'll be 5 blocks slow. A better method is to use Tom Harold's limit on timestamps when getting your solvetimes. I threw in a 10 because I do not want a solvetime near zero. The algo is in the chart. You do not even need to go through a loop. You just look at previous D and previous SolveTime.

solvetime = max(10+previous_timestamp, current_timestamp) - previous_timestamp
previous_timestamp=current_timestamp

jacob_ema

You can see the hash attacks can't be as long as in N=30 before the algorithm responds and the post-attack delays are not as bad.

jacob_ema_attacks

For comparison, here's the unmodified Zcash code.

zcash_attacks2

zawy12 commented Nov 8, 2017

If you go with N=30 instead of N=40, the correction factor will be about 1.02.

The following shows how it will vary on a daily basis, and how it will very likely vary when it goes live due to hash attacks. The peaks after the red bars (hash attacks) are the price your constant miners have to pay as big miners come on briefly to get cheap blocks.

n30
n30_attacks

If you want to write your own difficulty algorithm, currently the best one available is shown below. Jacob Eliosoff came up with this a few days ago, using his stock analysis knowledge. It needs protection against "negative" solvetimes. You could stick with Zcash's MTP but you'll be 5 blocks slow. A better method is to use Tom Harold's limit on timestamps when getting your solvetimes. I threw in a 10 because I do not want a solvetime near zero. The algo is in the chart. You do not even need to go through a loop. You just look at previous D and previous SolveTime.

solvetime = max(10+previous_timestamp, current_timestamp) - previous_timestamp
previous_timestamp=current_timestamp

jacob_ema

You can see the hash attacks can't be as long as in N=30 before the algorithm responds and the post-attack delays are not as bad.

jacob_ema_attacks

For comparison, here's the unmodified Zcash code.

zcash_attacks2

@martin-key

This comment has been minimized.

Show comment
Hide comment
@martin-key

martin-key Nov 8, 2017

Contributor

@zawy12 you are awesome man!
I don't know how to express my appreciation.
Thanks!

Contributor

martin-key commented Nov 8, 2017

@zawy12 you are awesome man!
I don't know how to express my appreciation.
Thanks!

@mardarfar

This comment has been minimized.

Show comment
Hide comment
@mardarfar

mardarfar Nov 17, 2017

Worst diff adjustment ever. Varying from 4 to 8 blocks an hour on mainnet.

mardarfar commented Nov 17, 2017

Worst diff adjustment ever. Varying from 4 to 8 blocks an hour on mainnet.

@zawy12

This comment has been minimized.

Show comment
Hide comment
@zawy12

zawy12 Nov 17, 2017

@mardarfar What are you talking about? 6 blocks per hour +/- 2 is as good as it gets. You want 1 to 20 blocks per hour like the new bitcoin cash difficulty?

zawy12 commented Nov 17, 2017

@mardarfar What are you talking about? 6 blocks per hour +/- 2 is as good as it gets. You want 1 to 20 blocks per hour like the new bitcoin cash difficulty?

@zawy12

This comment has been minimized.

Show comment
Hide comment
@zawy12

zawy12 Nov 17, 2017

@StarbuckBG It's using N=30 without the 1.02 correction? (next_D would be a little more accurate if it's 0.98 of the calculation.) Not doing this will mean 2% longer average solvetime, so expect avg to be 612 instead of 600 seconds. Also, if you see distinct oscillations in the difficulty, it is very probably caused by using MTP for nLastBlockTime (end of the averaging window).

Where can I get a CSV list of height, difficulty, and timestamp? I'm really interested in seeing any effects the 32/16 and MTP work out OK with N=30. Judging by bitcoin cash, the N=30 is a really good choice. They used N=144. oops.

zawy12 commented Nov 17, 2017

@StarbuckBG It's using N=30 without the 1.02 correction? (next_D would be a little more accurate if it's 0.98 of the calculation.) Not doing this will mean 2% longer average solvetime, so expect avg to be 612 instead of 600 seconds. Also, if you see distinct oscillations in the difficulty, it is very probably caused by using MTP for nLastBlockTime (end of the averaging window).

Where can I get a CSV list of height, difficulty, and timestamp? I'm really interested in seeing any effects the 32/16 and MTP work out OK with N=30. Judging by bitcoin cash, the N=30 is a really good choice. They used N=144. oops.

@zawy12

This comment has been minimized.

Show comment
Hide comment
@zawy12

zawy12 Dec 3, 2017

For those coming across this thread, here's a newer thread that's corrected some things. Also, here's my blog article where I'll keep the newest algorithm.

zawy12 commented Dec 3, 2017

For those coming across this thread, here's a newer thread that's corrected some things. Also, here's my blog article where I'll keep the newest algorithm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment