Skip to content
dbkeys edited this page May 27, 2017 · 59 revisions

Introduction

The bar for a hard fork in crypto currency is extremely high. The reason being is that a hard fork runs the risk of creating two chains and potentially destroying the currency. Both ethereum and bitcoin have had failed hard forks, despite their large communities. Therefore, to ensure that stakeholders do not lose their assets, any hard fork for bitmark should have the best possible planning. I set out the following 5 Criteria.

1. The problems

This should be ideally understandable to a wide audience.

i) Hash rate Swings.

Hash rate swings (which have been observed to go from a few MH/s to over 100 GH/s) result in a difficulty factor either much too high (which results in no blocks being found and thus no transactions processed, sometimes for as long as several days !) or too low (blocks being too quickly, within seconds of each other). This is the direct result of a difficulty adjustment algorithm, which only takes action every 720 found blocks. This is much too unresponsive. Users of the coin have a reasonable expectation that their transactions will be processed and validated quickly. The advertised inter-block time for bitmark is 2 minutes.

ii) Coin Emission exceeding Demand.

When a healthy block chain generates more coins than the market's ability to absorb these coins, the price per coin will naturally go down (whether denominated in bitcoins, dollars, pounds, yuan or another alt-coin). This is not desirable for stakeholders and supporters of the coin. While the continuous difficulty-adjustment algorithms fix the problem of transactions not being processed expediently, they bring an unwanted side effect: too many coins being generated.

iii) ≥ 51% Hash Rate Attacks.

  • Excessive number of Orphaned Blocks.
  • Blockchain Anomalies.
  • Suspension of Withdrawals and Deposits on Crypto Currency Exchanges.

Many longtime miners have abandoned mining Bitmark (BTM) because a some mining syndicate, commanding enough SCrypt hash power, has been able to privately build on the Bitmark blockchain, and strategically and "selfishly" publish to the rest of the Bitmark network 'their' chain, which is necessarily longer than any competing chain, only when it suits them, thus orphaning and wasting all the work of all the other miners. This problem has to do with the 720 block maturity requirement for generated coins to be used. Miners have to wait 720 blocks before they can spend the coins in a block they have mined. This 'selfish' syndicate is able to act this way because it must have an overwhelming computational advantage in SCrypt hash power. The kind of manipulation, which the bitmark chain has experienced lately, is in fact a type of 51% attack.
There have been reports on BitcoinTalk.org of double-spends related to forked chains. These excessively long chain forks and the abuses they enable are most likely behind the suspension of Bitmark deposits and withdrawals both on Nova and the Poloniex crypto currency exchanges.

iv) Marking Facilities.

Making Bitmark the premiere choice for marking applications.

It has often been asked what distinguishes Bitmark from other blockchain technologies, what advantage it has in regards to the many use cases of marking and related digital notarization applications.


2. The Proposed Solutions

Again this should be widely understood. There should also be a section explaining the risks.

The solutions:

i) Responsive Mining Difficulty Adjustment: Dark Gravity Wave, version 3 (DGWv3)

Difficulty adjustment algorithms, which re-set difficult upon each new block, were pioneered by Megacoin (Kimoto's Gravity Well), perfected by Dash (Dark Gravity Wave v3) and are now well established and standard in the alt-coin space. Bitcoin itself has not adopted any of these continuously difficulty-adjusting algorithms simply because bitcoin has never suffered from the wild network hash rate swings that alt-coins experience. In general terms, the hash rate on the bitcoin network has only every grown and increased.

ii) Demand Sensitive Coin Emission Modulation: (CEMv0.1)

By keeping track of the highest hash rate experienced recently (we choose 1 year as a look-back time frame) and equating this high hash rate with a demand level for the coin which warrants the epoch's highest possible level of coin generation, we hope to let coin generation match demand, and so maintain a more stable market value for the coin.
Most coins, including bitmark, were launched with a schedule of coin generation, which reduces the block reward at certain pre-set fixed number of blocks. These schedules define epochs where block rewards are at certain amounts. This rewards the early miners and first adopters with larger block rewards.
(Bitmark uses a quartering system, so, for bitmark, the first few block reward epochs are the 20 BTM, 15 BTM, 10 BTM, 7.5 BTM and 5 BTM epochs - Bitmark is currently in the first, or 20 BTM epoch; for bitcoin which uses a halving system, the epochs are 50 BTC, 25 BTC, 12.5 BTC, 6.25 BTC and 3.125 BTC - Bitcoin is currently in the 12.5 BTC epoch)
We maintain this basic epoch emission scheme, but refine it further, by allowing the current hash rate to affect coin generation, (instead of just the reaching of fixed block height milestones) Block reward is reduced from the epoch's full value if the current hash rate is lower than the highest hash rate seen within the last year. Block rewards are set for 1 day periods by comparing the current hash rate [] to the highest hash rate observed within one prior year and setting the reward proportionately. We thus decouple coin emission from block production, allowing for timely and expedient transaction processing without flooding the market with coins it is unable to absorb.
Now, the need to process transactions quickly does not mean that too many coins will be generated, because coin generation is informed and guided by demand, as expressed by hash rate. Care is taken to track total coins emitted (the money supply) because the original epoch reductions will be reached as a function of coins emitted, and not simply as a function of fixed block height milestones.

iii) Multiple Proof-of-Work Algorithms: (mPOW)

The single thing which allows a particular group to selfishly orphan blocks is overwhelming computational advantage in Bitmark's originally-chosen Proof-of-Work algorithm, SCrypt. By adopting additional Proof-of-Work algorithms, or a single composite (composed of several sequential PoW algos) algorithm [such as X11, X17 or Lyra2REv2] the 51% exploiters are denied the ability to abuse their computational advantage. Further, by implementing new PoW algorithms which have not been implemented in hardware ASICs, such as Argon2, the mining field is leveled and extended to miners with popular and common GPU or CPU equipment.

In our case, we propose to add 4 additional Proof-of-Work algorithms, which may contribute and add blocks to the Bitmark blockchain, for a total of 5 Proof-of-Work algorithms. One additional single PoW algo is the well-established SHA256D algorithm employed by Bitcoin. The reason to add this algo is to broaden Bitmark's appeal to the huge installed base of miners, which have SHA256D specific hardware. Another single PoW algo is the cutting-edge Argon2 algorithm, chosen because it is a winner in the 2015 Password Hashing Competition and because as of yet, there are no known ASIC implementations of it. One chained composite PoW algo chosen is Lyra2REv2, used by Vertcoin. Vertcoin has a demonstrated track record and commitment to de-centralized mining. We choose to bank on this proven and successful algorithm. Lastly, another composite chained PoW algo, X17, extends the idea pioneered by Dash, which itself uses the X11 composite chained PoW algorithm, by adding an additional 6 components to X11

iv) Blockchain Anchored Data.

Anchoring data trees on transactions on the bitmark block chain using the chainpoint technology inexpensively provides irrefutable proof that the anchored data existed at that point in time. The interested parties must maintain the actual data, but hash functions provide the means to easily prove that the digital data existed as presented at that time.


3. There should be unanimous consent

All concerns should be heard. This could happen on slack.


4. There should be a test plan

Ideally there should be evidence of testing. For example a test suite. Testing in the testnet. Code review.


5. There should be a roll out plan

All major stakeholders should be identified and contacted. e.g. miners, exchanges, block explorers. There should be a rough proposed timeline and ideally contingency planning.

Conclusion

I suggest using this wiki to document the criteria above. A hard fork should occur if it's a no brainer or if some criteria such as repeated double spends, threat of exchange delisting or otherwise poses an existential threat to the coin.

Clone this wiki locally