Skip to content

Bitmark Blockchain Hard Fork #1 v0.9.7.0

dbkeys edited this page Jul 25, 2018 · 1 revision

# Bitmark Fork

Motivation - Reasons that make a hard fork neccessary and desirable.

The current difficulty adjustment algorithm employed by Bitmark has proven to be too slow to adapt to changing hash rate circumstance. At present, difficulty is adjusted only every 720 blocks. While this should be roughly once a day, the reality is that because total hashrate has varied from peaks of over 200 Gig Hash/second (20010^9 GH/s) to lows of perhaps 100 MegaHash/second (10010^6 MH/s), a dynamic range over 3 orders of magnitude, sometimes the chain has stalled and only produced a block every few days. This is unacceptable of course to anyone who wishes to have his or her transaction processed quickly. The solution successfully adopted my most coins, is to regulate difficulty with algorithms (like Kimoto's Gravity Well and Dark Gravity Wave) which adjust on every new block found, and are thus much more responsive to changing hashrate. The resulting complication that these algorithms produce is that coin emission is then very high in relation to the real demand for the coin, unless the block reward is also adjusted more frequently. Proceeding on the assumption that hashrate is intimately related to demand for the coin, it is thus reasonable to equate hashrate with demand for the coin, and adjust block reward accordingly, and thus satisfy the true demand for the coin, and not flood the market with coins that it cannot absorb at a stable price. Additionally, to protect the network against the possibility of a single miner or mining syndicate controlling more than 51% of the network hashrate, some coins (Myriadcoin, DigyByte, Verge and Vertcoin among others) have adopted a scheme that allows several different Proof-of-Work algorithms to contribute blocks to the chain. This reduces the probability that a single mining syndicate has enough hardware of the needed types and/or resources to reach an excess of 51% of the network hashrate.

1. Difficulty adjustment: Dark Gravity Wave, v3 (DGWv3)

Much more flexible response to varying hash rate. Rapid adaptation of difficulty factor to match the network hash rate.

2. Block Reward Algorithm: Coin Emission Modulation (CEM) - Rate of Money Supply growth linked to Hashrate

The main idea is that while transactions need to be processed promptly (as advertised, with an average 2 minute blocktime), we don't want to generate more coins than the demand (which we equate to the hashrate on the network) calls for. If hashrate is relatively low, then we assume demand is relatively low and subsidy coin generation should be relatively low as well. We’ve settled on going from 1 coin to the epoch’s maximum coins by mapping the maximum reward to either a] Setting the Threshold_Grant_Max equal to the highest hash rate observed over the previous year or b] an arbitrarily chosen rate such as 160 GH/s as the Threshold_Grant_Max. The block subsidy can range from 5% to 100% of the epoch’s max value, depending on the observed hash rate on the network. Any hash rate from a few Kh/s on up to 500 MH/s will get a 1 BTM reward. When hash rate goes above 500 MH/s, the reward will start climbing, and reach the maximum if it gets to the Threshold_Grant_Max or higher. Care has been taken to track the total coin emission (money supply) in order to respect the total emission limits and transition throught the epochs as the moneysupply grows.

3. multiple Proof-of-Work Algorithms (mPOW)

Instead of only using SCrypt, (which is the main reason some syndicate of miners is orphaning other miner's blocks) Bitmark will use the technique (originally pioneered by MyriadCoin) of using several proof-of-work algorithms instead of just one. These two will definitely be selected as 2 of the 5 POW algorithms:

a. SCrypt: the original algorithm securing the Bitmark chain.

b. sha256d: the algorithm employed by Bitcoin, which is naturally supported by a wide range of ASIC hardware

In addition, these are under consideration:

  1. Argon2: presently, a CPU-friendly algo, as ASIC’s have not been developed for it (yet)

  2. Kekkak: Winner of the SHA-3 competition

  3. Groestl: One of the top 5 SHA-3 contenders

  4. Lyra2REv2: Used by Vertcoin

Each algorithm's difficulty is only affected by its own hash rate, and each POW algo is calibrated to contribute 1/5 of the blocks to the chain (on average), so that the combined block time of the chain is the original 2 minutes.

Comments

1 (melvincarvalho)

My general thoughts are: Firstly, a hard fork is a big risk to any coin (see ethereum). So should only be done if there very big support (almost unanimous) behind it, particularly from miners, who we'd love to hear more from. Secondly, we certainly have observed very inconsistent block rates and orphans (more data on this would be welcome!). So changing how the difficulty rebases in line with other Scrypt coins have successfully used is a good argument. I'm less keen (tho open to ideas) on changing from Scrypt because that was a specific choice by the original dev / community based on existing infrastructure. Finally, I'd like to note that if marking gets to its target of 1 million+ users then it could well overtake LTC and be the top coin in scrypt, at which point mining problems go away ...

2 (melvincarvalho)

Right now, the mpow is an interesting idea but stretching our resources to the extent, that there is a real risk that the coin will become broken. This is a complex change and even the slightest bug would be terminal for bitmark, and we dont have a team that has experience fire fighting such bugs. So Im conservative right now, but open to persuasion.

There needs to be near unanimous support for a hard fork, based on either

  1. we are forced to for example, if poloniex will delist us, or some mining attack happens otherwise OR

  2. its very clear that the community and the miners, are unanimously on board, there is a roll out plan, thorough testing ensures it to be bug free.

Sorry to set a high bar for this, but I feel that's part of my role to protect everyone in the community that has invested in BTC, in a conservative way. I cant go to a user that put faith in us and say, 'hey we tried to make things better but made a mistake ... and now you lost everything'.