Quote from: tync on August 02, 2018, 06:53:09 AM

I understand that those who now manage a coin want to stop the coin's depreciation. for this they want to use centralized methods. and the original developer does not agree to a centralized solution. correct if I do not correctly understood the situation

Hmm, not really. First, @onelineproof is not the original developer. But most importantly, the changes the project is contemplating now would have a de-centralizing effect.

I recall it this way:

In years 2015, 2016 and 2017, Bitmark had a very low emission rate and block production rate, beacause it was often stuck with very high difficulty when miners came and went: (the "multipool" problem).
The original diffalgo only adjusted difficulty every 720 blocks. (The "Multipool" problem was solved with DGWv3 diffalgo). @onelineproof was contacted in January of 2017 to help implement changes and improvements that were originally discussed in Slack and were memorialized here: Bitmark Hard Fork (April 2017) and design objectives finalized here: Hard Fork 1 Criteria (May 2017)

(Note: The originator of the project and original developer, @coinsolidation, left the project early on, sometime in 2015, iirc. This is the old ANN thread where @coinsolidation announced Project Bitmark for the first time: Original Bitmark ANN thread )

Hard Fork 1, Bitmark v0.9.7.0, was succesfully deployed on June 6, 2018, solving the issues detailed in the first two links above. Eight Proof-of-Work algorithms, each governed by DGWv3 and each targeted for a 16 minute block time, replaced the single SCrypt PoW algo that had been in service since the start. These graphs detail the performance of the 8 PoW algos and the resulting overall composite inter bock time: Bitmark 8mPoW Performance (updated frequently)
Additionally, novel technology, Coin Emission Modulation, CEM v0.1 was introduced as well. (Coin Emission Modulation has been extensively discussed and detailed elsewhere.)

Hard Fork 1 not only introduced 7 new algos to Bitmark, but it allowed all 8 algos { SCrypt, SHA256d, Yescrypt, Argon2d, X17, Lyra2REv2, EquiHash & CryptoNote} to be merge-mined. This proved succesful in vastly improving the hashrate and thus the security of the chain, but at the expense of eliminating most native mining. Most other multiple Proof-of-Work (mPoW) coins allow merge mining on usually less than half their PoW algos. (For example, Argentum which has 6 PoW algos, has only AuxPoW enabled 2 of them: SCrypt and SHA256d; likewise, Myriadcoin has only enabled merge-mining on 2 of its 5 PoW algos, also SCrypt and SHA256d. )

Merge-mining is a simple and very low cost way for an existing mining operation to mine coins. I have not seen a real-life case analysis of what the fixed costs of a mining operation are and what the extra marginal cost of adding and mining AuxPoW enabled chains is on average; but it is simple to understand that if you already have equipment in operation and are already paying electricity and other recurring costs, simply adding an AuxPoW chain in addtion to the Parent Chain you are already mining on the same hardware and infrastructure would only cost a fraction, truly a very small additional cost in using your existing storage and extra processor cycles.

Therefore the Hard Fork 2 proposed change in question is to reward native-mined blocks a bit more than merge-mined blocks and this way level the playing field. This would have a de-centralizing effect, by incentivizing more miners to mine Bitmark algos directly (natively), making it financially attractive to do so, discouraging centralization from large mining pools.
Even with block rewards that are less than rewards payed to native miners, I believe that it will still be advantageous for the merge-mining operations to continue merge-mining Bitmark algos.

The other changes we propose are evolutionary advancements of CEM, so that instead of acting on only 50% of the epoch reward, it can act on a larger portion, 80% and to make it somewhat more forgiving of hashrate swings by limiting its memory. (Instead of remembering hash rate peaks as far back as a year, CEM v0.2 would only look back 30 days.)