-
Notifications
You must be signed in to change notification settings - Fork 2
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
Orphanes. 51% problem #1
Comments
Please note that "more work" wins over "more high" blockchain (Introduced on PascalCoin 1.5) How PascalCoin calcs "more work".
Then, note that a node will accept as a valid the first new block received and will discard the other ones (malformeds or legits), so:
The personal conclusion is that to inject a block you need more work, and that cannot be solved if a miner has 51% of the hashrate |
@PascalCoin, thanks for your reply. So, updating code to "more work" logic from PascalCoin 1.5 may help with that crazy orphane rates. |
@PascalCoin,
a bit. |
Updated first post and renamed the issue because this actually not a block's timestamp problem. |
The timestamp issue still can be a problem and exist. When the coin first launched, some "cheaters" hosted a few nodes on their own. They moved the time ahead on those nodes so the average timestamp would be further ahead, then they moved their miner PCs time up to 30-60 seconds or so and no other miners blocks would get accepted because they got the "invalid timestamp error". Nobody does this cheat anymore because the block times are much further apart and moving the clock up 30-60 seconds had little effect but the issue is still present. For the other minor issues such as difficulty retarget they can be easily tighten by changing the factor here
|
Created separate issue #2 for that. |
Seems somebody on the PascalCoin Github opened a similar ticket |
First, to reproduce that your hashrate need to be as tenths of percents of total network hashrate (even with 20-30% you will have good chances to reproduce).
So it is basically the same 51% problem.
I don't think that anyone had produced that situation deliberately. Miners that were able to do that had to have really big hashrate and a bad connection (?) (or some other sync issues) was more than enough.
As for timestamps that are equal to previous block's timestamp. Inspected the code. Forging blocks having the same timestamp as previous block will lead to difficulty increase more roughly. So no profit here at all.
The text was updated successfully, but these errors were encountered: