Topic: Core needs to prepare a GPU only PoW - Spondoolies CEO Guy Corem - page 3. (Read 3446 times)

wonderful changes ,looking forward for that, i liked to concept of GPU mining ,which everyone can participate rather than big mongers who owns huge number of ASICS 

Seems to me that GPU mining is centralisation in one form. Ideally, you want a branching-hard PoW which cannot easily be ported to GPU (or baked into an ASIC) with any performance increase over plain CPU.

https://medium.com/@vcorem/lesson-learned-from-the-classic-coup-attempt-or-why-core-needs-to-prepare-a-gpu-only-pow-6a9afe18e4b0

So, as I write these words, it seems that Classic has a good chance of meeting its activation Threshold. Jonathan is aiming for Classic to be activated when 75% of the last 2,016 (currently coded 1,000 but he said in the interview that he might increase to 2,016) mined blocks indicate support of the Classic fork, meaning the miners that mined them are ready to do a 2MB Hard Fork and leave behind everyone on Core.
What will happen to Core chain if Classic will be activated?

Will Classic activation mean the end to the Core chain ?
Not necessarily; Careful planning on behalf of Core will allow it survive.

I believe that Core developers will split into three camps: Some will join Classic Chain (and fork), some will quit Bitcoin altogether, and some will continue development on Core Chain (and fork).

I tend to believe that most Core developers will remain and implement the Core scalability road-map as planned. I simply don’t see Core following Classic’s governance model in which the users vote on issues.

Mainly, Core needs to replace its PoW function, preferably to a function which make any effort to create ASIC for it economically nonviable. I’ll discuss such a proposal below.
The other thing Core needs to do is to change the Transaction ID, in order to create a complete split of coins.

By implementing the above, upon Classic activation, each Bitcoin will be split to ClassicCoin and CoreCoin. Each coin will be transact-able separately and will have a different market value. Most of the exchanges will probably support both Chains, hence each Coin will have different market value based on supply and demand.

From the user perspective, she will needs to install both wallets (Core and Classic) and import the old private key into both wallets. It makes sense that multi chains wallets will be created, so the user will be able to transact easily with wallets on both Coins. These wallets may even present the following arithmetic: 1 CoreCoin + 1 ClassicCoin = 1 BTC, so if you have 80 CoreCoins and 73 ClassicCoins it would show up as 73 BTC + 7 CoreCoins. It might be able to transact in that way as well, sending CoreCoins and ClassicCoins with one wallet “Send” action to the receiver.

....


Suggestion for GPU only PoW change for Core

In order to survive, Core needs to change its PoW or else Core miners won’t be able to mine at all or Core chain will be susceptible to 51% attacks from Classic miners. I purpose the following, in order to prevent mining centralization, and prevent the possibility of such a governance coup in the future:

    Core will prepare a large set of cryptographic hash functions, at least 100 or more initially. Any simple (not memory hard) function will do

    Every 3 months (12,096 blocks), the PoW change automatically, by random data hashed from the last block before the change

    A selection of 10 or more functions is made from the large set, selected deterministically from last block data

    If the functions have tunable parameters and or constants then those are also selected deterministically from the last block data

    Those 10 or more functions are constructed in a stack (e.g. X11)

    The Stack of functions with their new constants and parameters (all selected deterministically by hashing last block data) is the NewPoW

    In order to prevent Hash-Rate oscillation (very bad…), The OldPoW and the NewPoW coexist for one month (4,032 blocks)

    Each PoW function actually serves for 5 months:

    - One month of Phase In period in which it co-exists with it’s predecessor

    - Three months in which it serves alone as the only PoW

    - One month of Phase Out period in which it co-exists with it’s successor

    During the Phase In period, the NewPoW difficulty is set initially to a very low value, to incentivize miners to mine it.

    However, During the first 252 blocks (1/16 of the phase in period), only one block with the NewPoW is allowed every 16 blocks. If more then one block with the NewPoW is mined during this period, the rest will be discarded.

    There will be a lot of miners trying to mine the new PoW since its difficulty was set to a low value, there will be a lot of soft forks. To avoid it, the block with NewPoW with minimum BlockHash is accepted as the winner, all the rest are discarded.

    In the next 252 blocks (second 1/16 of the phase in period), only two blocks with the NewPoW are allowed every 16 blocks.

    Every subsequent 252 blocks of the phase-in period, one more block with NewPoW will be allowed.

    After each 252 blocks of the phase-in period, the difficulty of the NewPoW will be adjusted based on the time it took to create blocks with NewPoW from the beginning of each 16 blocks period.

    By the end of the phase-in period, the OldPoW will be retired and the only acceptable blocks will be blocks with the NewPoW


This proposal if implemented correctly, will bring a never ending GPU mining on Core chain. It will also reduce the hash-rate oscillation between each PoW change. In order to make sure an ASIC effort will be uneconomic, the initial set of functions needs to be large enough. In addition, on every future Hard Fork of Core Chain, additional hash functions need to be added to this set (assuming CoreCoin price increase).

....

Thanks goes to:

    Adlai Chandrasekhar for suggesting the automatic method of replacing PoW parameters using Blockchain data
    Benny Gorlick for suggesting to select the next PoW from a large set of predefined functions
    Emin Gün Sirer for suggesting the mechanism to prevent hash-rate oscillation after each PoW change
    James Hilliard for creating a tool that generates a transcript from the WeChat group “MinerInWorld”
    Vitalik Buterin for reviewing the proposal
    Luke-Jr for reviewing the proposal