Skip to content
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

Open
wants to merge 9 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@stoffu
Copy link

stoffu commented Mar 28, 2019

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:

  • a semi-standardized design endorsed by the same team who designed SHA-3
    • It feels safer than tweaking the Keccak parameters by ourselves.
  • a bit faster than SHA-3 with the round number reduced to 12 which is still believed to be secure enough
  • potentially useful for hashing all other things in the protocol, especially transactions which are often large, because K12's main strength is its ability to quickly process large chunks of data in parallel
    • If we implement this in the future, we get another benefit that the PoW hash and the block hash become identical (as in Bitcoin), thus saving the current doubled computation of hashes for each block (one for the block ID and the other for PoW).

The testnet fork height is set to 111600 112000, so for those who want to try please upgrade your testnet daemon .

moneromooo-monero and others added some commits Sep 13, 2018

Make difficulty 128 bit instead of 64 bit /monero#5239
Based on Boolberry work by:
  jahrsg <jahr@jahr.me>
  cr.zoidberg <crypto.zoidberg@gmail.com>
@iamsmooth

This comment has been minimized.

Copy link

iamsmooth commented Mar 28, 2019

  • It has a cool name

@stoffu stoffu force-pushed the stoffu:aeon-k12 branch from f8aefc1 to 9b03996 Mar 28, 2019

@BigslimVdub

This comment has been minimized.

Copy link

BigslimVdub commented Mar 28, 2019

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."
and
"KangarooTwelve benefits immediately from the new SHA-3 hardware support recently introduced in the ARMv8.2 instruction set". mobile mobile mobile

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.

@iamsmooth

This comment has been minimized.

Copy link

iamsmooth commented Mar 28, 2019

@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.

@stoffu

This comment has been minimized.

Copy link
Author

stoffu commented Mar 28, 2019

I've removed the testnet fork height and will bring it back once XKCP/XKCP#58 is addressed.

@stoffu stoffu force-pushed the stoffu:aeon-k12 branch from 3a7d767 to e67b87d Mar 28, 2019

@stoffu

This comment has been minimized.

Copy link
Author

stoffu commented Mar 28, 2019

Brought back the testnet fork height since XKCP/XKCP#58 was self-resolved.

@stoffu stoffu force-pushed the stoffu:aeon-k12 branch 2 times, most recently from 639e802 to 2639bf2 Mar 28, 2019

@stoffu stoffu force-pushed the stoffu:aeon-k12 branch from 2639bf2 to 4bb9059 Mar 28, 2019

@iamsmooth

This comment has been minimized.

Copy link

iamsmooth commented Mar 29, 2019

Testnet fork seemed to go fine.

@BigslimVdub

This comment has been minimized.

Copy link

BigslimVdub commented Mar 29, 2019

Build success Ubuntu 18.04.2.
seems to be working ok on testnet and mining at 815kh on 2 threads

@iamsmooth

This comment has been minimized.

Copy link

iamsmooth commented Mar 29, 2019

@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?

@camthegeek

This comment has been minimized.

Copy link

camthegeek commented Mar 30, 2019

@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.

@stoffu

This comment has been minimized.

Copy link
Author

stoffu commented Mar 31, 2019

Currently I’m trying to update the pool code but still struggling to get it working:

@stoffu

This comment has been minimized.

Copy link
Author

stoffu commented Apr 1, 2019

Testnet pool working: http://162.210.173.150:8080/

@BigslimVdub

This comment has been minimized.

Copy link

BigslimVdub commented Apr 8, 2019

Built on osx high sierra and seems to be working ok only basic testing with testnet.
7 threads on i7 cpu xmrig pr1004 getting 4.2Mh.

@stoffu stoffu force-pushed the stoffu:aeon-k12 branch 2 times, most recently from ef86d6c to 368be95 Apr 8, 2019

@stoffu

This comment has been minimized.

Copy link
Author

stoffu commented Apr 8, 2019

The above fix is for visibility purposes and is meant to be squashed with the previous commit.

@stoffu

This comment has been minimized.

Copy link
Author

stoffu commented Apr 8, 2019

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.

stoffu and others added some commits Apr 4, 2019

ArticMine's new block weight algorithm /monero#5124
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%.

@stoffu stoffu force-pushed the stoffu:aeon-k12 branch from 368be95 to 6c2499a Apr 9, 2019

@stoffu

This comment has been minimized.

Copy link
Author

stoffu commented Apr 9, 2019

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.