-
Notifications
You must be signed in to change notification settings - Fork 43
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
switch to KangarooTwelve proof of work #108
Conversation
|
Great work guys! I like how this is set up with the future in mind for pow and tx cohesion availability. This just sounds like the best choice for Aeon in regards to a Keccak variant. Nice pick. Informational paper on K12 POW: https://keccak.team/files/KangarooTwelve.pdf From the conclusion:"KangarooTwelve can be seen as a new member of the Keccak family. It inherits all the properties of the family such as suitability in hardware and resistance against side-channel attacks, but grew up with a strong focus on software performance and interoperability." Also from page 17 regarding speed comparisons to other POW in Table 2:"The speedup benefits to both low-end and high-end processors. " Stoffu, let us know when you are able to port any miner for usage of this POW for testing purposes. I have noticed with our current version that the CLI miner does have close to average miners hash rates CPU wise of course. |
@BigslimVdub The built-in miner already supports it and will go live on testnet once the fork happens. Standalone miners will need to be upgraded. As I noted on reddit, I fully expect at least a small arms race and initial miners will likely not remain competitive for long. |
I've removed the testnet fork height and will bring it back once XKCP/XKCP#58 is addressed. |
Brought back the testnet fork height since XKCP/XKCP#58 was self-resolved. |
2639bf2
to
4bb9059
Compare
Testnet fork seemed to go fine. |
Build success Ubuntu 18.04.2. |
@stuffu Nice work making the PRs for xmrig and the stratum proxy. Is something needed for pool code and/or that javascript hashing library that most of the JS pool implementations use? |
I believe it needs to be added to multi-hashing as most pools call upon an algorithm defined in multi-hashing. |
Currently I’m trying to update the pool code but still struggling to get it working: |
Testnet pool working: http://162.210.173.150:8080/ |
Built on osx high sierra and seems to be working ok only basic testing with testnet. |
ef86d6c
to
368be95
Compare
The above fix is for visibility purposes and is meant to be squashed with the previous commit. |
Note that the nonce size change requires wiping the older v8 testnet chain. Please use aeon-blockchain-import from the commit before the nonce size change and roll back to 111000 before running the latest daemon. |
Monero's scaling solution based on the long term block weight (monero-project#5124) has now been taken as well. It includes some misc tweaks I've made along the way pending review/approval (monero-project#5414). |
Approved |
Has a conflict now after #106 was merged. |
Resolved conflicts |
The last commit is pending upstream approval monero-project#5659 |
2d6a850
to
66c7dd9
Compare
18.04.2 builds ok with the latest fetch and checkout of pr-108.
It seems that PR-119 was merged yesterday. |
Build successful now on 18.04.2 and |
Based on Boolberry work by: jahrsg <jahr@jahr.me> cr.zoidberg <crypto.zoidberg@gmail.com>
This curbs runaway growth while still allowing substantial spikes in block weight Original specification from ArticMine: here is the scaling proposal Define: LongTermBlockWeight Before fork: LongTermBlockWeight = BlockWeight At or after fork: LongTermBlockWeight = min(BlockWeight, 1.4*LongTermEffectiveMedianBlockWeight) Note: To avoid possible consensus issues over rounding the LongTermBlockWeight for a given block should be calculated to the nearest byte, and stored as a integer in the block itself. The stored LongTermBlockWeight is then used for future calculations of the LongTermEffectiveMedianBlockWeight and not recalculated each time. Define: LongTermEffectiveMedianBlockWeight LongTermEffectiveMedianBlockWeight = max(300000, MedianOverPrevious100000Blocks(LongTermBlockWeight)) Change Definition of EffectiveMedianBlockWeight From (current definition) EffectiveMedianBlockWeight = max(300000, MedianOverPrevious100Blocks(BlockWeight)) To (proposed definition) EffectiveMedianBlockWeight = min(max(300000, MedianOverPrevious100Blocks(BlockWeight)), 50*LongTermEffectiveMedianBlockWeight) Notes: 1) There are no other changes to the existing penalty formula, median calculation, fees etc. 2) There is the requirement to store the LongTermBlockWeight of a block unencrypted in the block itself. This is to avoid possible consensus issues over rounding and also to prevent the calculations from becoming unwieldy as we move away from the fork. 3) When the EffectiveMedianBlockWeight cap is reached it is still possible to mine blocks up to 2x the EffectiveMedianBlockWeight by paying the corresponding penalty. Note: the long term block weight is stored in the database, but not in the actual block itself, since it requires recalculating anyway for verification. AEON Notes: - The surge factor is reduced from x50 to x20. - The long term growth rate is reduced from 40% to 4%.
This implements my proposal in #103.
After doing some research (including asking the Keccak team for a comment) and discussing with @iamsmooth privately, it now seems that the most preferable choice among all possible Keccak variants for PoW is KangarooTwelve (or K12 for short) with the reasons being:
The testnet fork height is set to
111600112000, so for those who want to try please upgrade your testnet daemon .Included upstream patches: