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

Merged
merged 11 commits into from
Jul 17, 2019
Merged

Conversation

stoffu
Copy link

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

Included upstream patches:

@iamsmooth
Copy link

  • It has a cool name

@BigslimVdub
Copy link

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
Copy link

@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
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
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 aeon-k12 branch 3 times, most recently from 2639bf2 to 4bb9059 Compare March 28, 2019 07:21
@iamsmooth
Copy link

Testnet fork seemed to go fine.

@BigslimVdub
Copy link

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

@iamsmooth
Copy link

@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
Copy link

@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
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
Copy link
Author

stoffu commented Apr 1, 2019

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

@BigslimVdub
Copy link

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 aeon-k12 branch 2 times, most recently from ef86d6c to 368be95 Compare April 8, 2019 10:20
@stoffu
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
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
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).

@BigslimVdub
Copy link

Approved

@iamsmooth
Copy link

Has a conflict now after #106 was merged.

@stoffu
Copy link
Author

stoffu commented Jun 17, 2019

Resolved conflicts

@stoffu
Copy link
Author

stoffu commented Jun 17, 2019

The last commit is pending upstream approval monero-project#5659

@stoffu stoffu force-pushed the aeon-k12 branch 2 times, most recently from 2d6a850 to 66c7dd9 Compare July 3, 2019 02:17
@BigslimVdub
Copy link

18.04.2 builds ok with the latest fetch and checkout of pr-108.
I am getting this error from daemon now running on testnet:

status

2019-07-04 02:36:20.363	    7f90bffff700	ERROR	default	contrib/epee/include/console_handler.h:388	Exception at [console_handler], what=boost::too_few_args: format-string referred to more arguments than were passed
version
Aeon 'Sophia' (v0.12.9.0-master-66c7dd91)

It seems that PR-119 was merged yesterday.

@BigslimVdub
Copy link

18.04.2 builds ok with the latest fetch and checkout of pr-108.
I am getting this error from daemon now running on testnet:

status

2019-07-04 02:36:20.363	    7f90bffff700	ERROR	default	contrib/epee/include/console_handler.h:388	Exception at [console_handler], what=boost::too_few_args: format-string referred to more arguments than were passed
version
Aeon 'Sophia' (v0.12.9.0-master-66c7dd91)

It seems that PR-119 was merged yesterday.

Build successful now on 18.04.2 and status command shows proper response.

moneromooo-monero and others added 11 commits July 15, 2019 22:09
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%.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants