Topic: [ANN] [MARKS] Incentivize Content Creators & Build a Reputation Value Framework - page 17. (Read 32570 times)

What those graphs above show is that there were many periods of time where the emission rate was higher than it is today; only in Fall 2014 to Fall 2016 was it low because there was not much interest in Bitmark at that time and it took a long time for the difficulty adjustment algorithm to catch up. Additionally, statistics like this are not justifications for changing the target emission rate.

If you want to see more interesting statistics, see the wallet rich list: https://chainz.cryptoid.info/btm/#!wallets.
There is one wallet with 2.4 million marks (8.6 % of the total eventual 28 million Bitmarks) and one wallet with 1.5 million marks (5.4%).
You can also see here https://chainz.cryptoid.info/btm/#!rich that there is a single address with 1.6 million marks.
These large wallets are likely individual miners who were mining Bitmark when hashrate was low (uncompetitive), due to the native only mining for a cryptocurrency that has a small number of users. With merge mining this wouldn't happen as mining would be much more competitive and no individual miner can get such a large share of the mining rewards. As an investor I would actually be more worried about those big wallets dumping coins instead of merge miners that can only take little bites at a time.

Anyone looking at those statistics (rich list) will immediately think, whoa that's some really centralized distribution, almost as if the coins were premined. Seeing that makes me rethink whether it is even worth trying to save Bitmark. The only way I see for Bitmark to reedem itself against this is to continue mining now with FULL merge miner rewards. And the question of whether or not to modify the supply schedule is a no brainer as I explained before.

This is what the same data look like in relation to the total emission limit of  about 27.6 million coins .
(27,579,894.73108000 to be exact).    

Thank you @coinzy4
Official repo has 0.9.8.0 branch with the changes described, and is undergoing testing.   Aiming for mid-August release. (In about a week to 10 days)

@dbkeys When can we expect new hard fork? I can't find that information anywhere.
Changes you described are more than welcome at this point.

The more work happening on a chain, the harder for a single actor to make a big effect, thus of course that helps to prevent double spending, which is why merge mining is good, since it adds more hashpower to the chain. But the reward is also important, since without a significant and stable reward, the miners can collude and create a double spend since it is more profitable than taking the honest reward. Doesn't have to be collusion, can be a short burst attack by one actor too.

I didn't say that. Miners will look at profitability, which depends on the dollar value of the reward and inversely with the difficulty. Merge mining has a multiple chains with various rewards depending on the market value of the chains together with the reward for Bitmark, and you combine all the difficulties together with that to determine profitability. Native mining only includes the Bitmark reward thus is less profitable, but how much less depends on the market values of the other chains. You can't just pull a number from nowhere like 5 and say that native mining should get 5 times more reward than merge mining. Unless Bitmark has a much larger market cap than the other chains, it will still likely be more profitable to merge mine even with 5x less reward. The problem is now the merge miners are more likely to double spend on Bitmark since they are not gaining that much from Bitmark anyway, and they see that the rewards can easily be lowered by developers so they have even less trust in the value of mining honestly with Bitmark. Some of these are very unlikely attacks, and probably you will be fine without these protections. But why do you want to add security holes to the protocol just in order to give a favorable price to investors?

My intention is not to annoy or make problems. I just want to inform the Bitmark community of users (if they still exist) that the Bitmark development team is compromised (I heard even Melvin Carvalho caved in to the demands), and if they want to stop that, now is the time. I would do the same thing if Bitcoin Core developers proposed some wacky fork that damages security for users. I am ringing the alarm with the hope of waking some people up. I think this is the responsible thing to do. If enough people join me, we can revolt and stick with the current honest protocol. It will all be clear soon enough...If this fork passes and not enough people join me, then whatever, I will move on. I can create a new currency with similar features.

I think @onelineproof is confused about what serves to prevent double spending. It is not the reward per se, it is the work that goes into the hash computations, the Proof-of-Work.  
There is some logic to saying that the larger the reward the likelier more work will go toward mining a block, but it is not a direct correlation: it is strictly the actual computational work that goes into finding the block versus the difficulty of surpassing that same work, (compounded as it becomes a string, more than one block),  which is the actual security.   Not the reward the blocks carry.

He is making an assumption that the higher the reward the more work will go into finding the block. This is a reasonable assumption to make in general, but I believe its flawed logic in the case of merge-mining, for the reasons already given. To quote an old proverb, you "Don't look a gift horse in the mouth."   ie, It's basically a "freebie", so you shouldn't complain that it's not as big as the reward someone gets when they work harder for it. It's falling on your lap; you're getting it for almost no effort.

I can't believe I am still arguing about this. Here we have early Bitmark investors (dbkeys and 82ndabnmedic) using their smooth-talking skills to justify the manipulation of the supply of the currency solely for the purpose of benefiting investors (just like a central bank would do). And in the same time the main website of Bitmark describes itself as a "decentralized reputation platform". If Bitcoin developers wanted to release a forking change that decreases the subsidy paid to miners, do you think that would pass? No way in hell.

You can argue about the advantages and disadvantages of merge mining. I personally believe that merge mining is better for both decentralization and security compared with native mining. though I can see some advantages of native mining in some proportion, thus as a compromise, I proposed to let users vote on whether they support merge mining, weighted by transaction fees, and that would dynamically affect the merged to native ratio.

But cutting out the reward from merged miners will drastically reduce the average reward per block which reduces security for users. The reward is what serves to prevent double spending. It is not the cost that matters. I can be mining and heating my house in the same time, or I can be mining with free excess electricity. Everyone has a different cost. If you want to frame it in terms of cost, then you can say it is the opportunity cost that matters. In Economics, opportunity cost of option A is what you would gain by choosing the next best option. So for a miner (merge miner or not), the opportunity cost of mining honestly is what he would gain by double spending. The opportunity cost of double spending is what he would gain by mining fairly. As the amount gained (subsidy) of mining fairly goes down, the opportunity cost of double spending goes down, thus the chance of double spending goes up.

Thus I would say that merge miners may actually deserve a larger subsidy than native miners, because they are gaining from other coins, so they would not be much affected if they lose our rewards if they are so small compared to other coins. But I think it is simple to keep it the same. Whatever you choose (less or more reward), you need to appropriately balance it for native miners, so that the average reward per block remains the same. If not, then you are decreasing security. With this fork, the merged blocks will receive a much smaller reward, and most blocks will still likely continue to be merge mined, thus the average reward per block will drastically decrease, and result in a decrease in security for users. And for what? To give a boost to early investors so that they can make a timely and profitable exit?

As for decentralization of merged vs native mining. As you see with Bitcoin, native mining also leads to large mining pools. This is inevitable, but individual miners can always pull out of a mining pool that causes harm. Also with 8 algos, we are very decentralized in terms of mining. Since mining is very competitive (especially with merge mining) each miner I believe has it in their best interest to specialize in 1 algo, thus it would be hard for one entity to control multiple algos.

I will try to expose this scam as best as I can, but it is hard to do it alone. So if other people want to help concretely, then you can contact exchanges that trade in Bitmark or mining pools. Merge miners and mining pools actually have it in there best interest to reject this proposed fork as it decreases their reward. If we are successful at stopping this fork then we can continue with the current protocol and replace the current development team with one that is more serious about building a real decentralized reputation platform. I fully support free speech, so even if it's a scam, I don't think it should be illegal, just I want it exposed and people to follow a chain the puts users first, not investors.

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.)

First, I want to clear up the issue of "merge miners create coins at almost 0 cost thus should be rewarded less". What matters for security is the amount rewarded to the miner. The miner has 2 basic choices (whether merge miner or not). The miner can keep mining honestly and receive the quite predictable subsidy each block, or he can mine a side chain to reverse transactions and cause a double spend. If the value of the double spend is much higher than the value of mining honestly, the miner (or group of colluding miners) will be more likely to cause a double spend. This also why, as I mentioned in the github thread that the number of confirmations you wait to be sure that your received coins are safe should be proportional to the size of the transaction, because the bigger the size the more tempting is a double spend, but more confirmations means the miner can just mine honestly and attain the same amount honestly. Also, if he does a double spend it reduces the value of his coins, meaning only the value of the double spend is certain, while the value of the coins he generates during the double spend can depreciate a lot during the 720 blocks for maturity. Thus I would say you should wait the amount received divided by the block subsidy to determine the rough number of confirmations for your received coins to be safe. You also have to factor in value to the miner of having a long term supply of well paid subsidies as a deterrent to double spending. This would actually get worse to a sudden change in the maximum reward for merge miners. It sets a precendent that their reward can easily get lower. Makes sense or am I retarded like jarr0s says in the thread?

Now if you look at the original announcement thread of Bitmark https://bitcointalksearch.org/topic/bitmark-660544 you can see that it says:
Similarly on the webpage bitmark.io it says
One of the main PR guys (82ndabnmedic) says
https://bitcointalksearch.org/topic/m.40969748

But in the same time the protocol is decided for the best interests of investors? (you can even see dbkeys say how important investors are in the github thread). And it is important to differentiate investors from users. Users are people who make Bitmark transactions (including the embedding of data and reputation ranking). Investors are people who just buy in and then exit with a profit. For ICOs investors are the main group to satisfy. You have a promise to build something cool and then pay back investors when that's built. But as you saw in the original announcement thread "no IPO" and IPO is the traditional way of saying ICO. There's also other evidence scattered around that supports the idea that Bitmark's goal is not to serve investors but to serve users. Users pay miners and in turn get strong consensus security. Any discussion about price is about investors and that is totally irrelevant to the needs of users. Users will suffer from less security by paying less to miners.

If you are going to advertise Bitmark as a decentralized reputation platform, and then it turns out to be the equivalent of an ICO (promising to build something cool in the future and giving investors a return on their investment) then you are commiting fraud, i.e. that is a scam. Do you think I am just calling it a scam to attract attention? The lowered rate of money supply increase causes the price to temporarily go up, benefiting the centralized group of early investors, and then they can make a quicker profitable exit. I think some of the guys who I worked with in the Project Bitmark Team are fine to hang out with and talk about life and stuff, but now I can clearly see their bad side. Is it intentional? I cannot know for sure. It could be a misunderstanding on their part of how decentralized protocols work or someone could be pointing a gun at them, pressuring them to do what they don't want, who knows. But there are only 2 people with write permissions to the Bitmark github and one of them clearly supports my position, but it seems he doesn't want to be the one to make the decision for the community. Anyway, it's a pretty small group. I only know 3 people for sure who support this price manipulating fork: dbkeys, 82ndabnmedic, and the random guy jarr0s who started the discussion thread. jarr0s could easily be someone who works for another cryptocurrency and wants to harm Bitmark, but either way it doesn't change the argument.

I think Bitmark, as an honest protocol has the potential to become just as big as Bitcoin. So investors who have 10000 Bitmarks for example would be very rich if this would reach full potential. But it won't reach full potential if it is permanently damaged by such a protocol change. Who wants to use a reputation platform that has a bad reputation? In case someone is interested, I wrote a sketch of how a meaningful web of trust can be created on the Bitmark blockchain, and it would be well incentivized in order to create a large amount of demand for Bitmarks: https://github.com/project-bitmark/bitmark/wiki/Marking-Protocol. It's a very rough sketch so still subject to a lot of change.

So if someone wants to help please contact me. I am moving to a new house soon and the next week will be very hectic. I will just add an important announcement to miners and mining pools:

To Mining Pools and Solo Merge Miners: You can stop this fork by not upgrading your node and continue mining with the current version. It is in your interest as the current version gives you a higher subsidy as needed by users who appreciate the security you provide. With a higher proof of work, recognized by all current nodes, exchanges will have to reject the proposed fork since it is very controversial due to its price manipulating purpose

I will post more links soon to the correct versions you need to be using

I must say I do stongly object to using the term "scam" in rererence to the proposal to reward merge-mined blocks less than native-mined blocks.

A scam is an" intent to defraud", usually pulled by con artists who are disguising their intentions. It's wholly inappropriate here, and I find it frankly somewhat offensive....   needlessly so.

  First because nothing proposed is being disguised or hidden. It's entirely transparent and open for discussion.  

Fact #1: Merge-mined blocks cost much, much less to produce than native blocks. By definition, their cost of production is marginal compared to native-mined blocks. The miner's fixed cost are exactly the same whether they mine just the parent chain, or the parent chain plus some number of AuxPoW (merge-mineable) chains along with it.

Fact #2: Higher hashrate means a more secure blockchain, more secure against 51% attacks and other such shenanigans.  That is why we opened up Bitmarks 8 mPoW algos for merge-mining in the first place.  


Unfortunately, enabling AuxPoW on all 8 of the algos has had the unitendended consequence of decimating native mining.  Most other mPoW coins, if they allow merge-mining, allow it on only a few of their PoW algos.  My initial thought of a solution was to create native & merge-mine-enabled variants of each of the PoW algos, resulting in 16 "virtual" algos;  each with its own block target time and DGWv3-governed difficulty. In this scenario, we could set any ratio desired of native to merge-mined algos by setting the block time target that DGWv3 seeks.
However, separating merge-mined blocks from native blocks would create a scenario where the merge-miners or the native miners of an algo could manipulate the other group's reward by peaking their hashrate during a day so that the denominator (peak_hashrate) in the subsidy scale factor (SSF = current_hashrate / peak_hasrhate) in CEM would shrink, reducing the other group's reward for as long as the CEM look-back period remembers that peak hashrate.    
So instead, by keeping native and AuxPoW blocks in the same CEM group, this problem is avoided.  And we don't have to choose an arbitrary ratio of native:merged blocks. We simply set the reward for native blocks to to be aproximately 5x greater than merged blocks, and let the economics sort it out.

This way, we account for the fact that merged blocks are cheaper to produce (fact #1) while we  acknowlege that (although they are of near-zero cost to the miner),  they have greater than zero cost value to our blockchain (fact #2).   Setting this differential is somewhat arbitrary, but it's certainly "in the ballpark" of what's fair.  If it strictly represented the cost of mining differential, it would be much larger (maybe 100X greater reward for native), but we _do_want some merge-mining, it is valuable to our chain, therefore a middle ground, with a less pronounced differential seems appropriate.    

I think it's also appropriate to put in a word about the emission rate and the total emission in general.  Since inception, Bitmark has a total cap on emission of below 28,000,000 coins  (27,579,894.73108000 to be exact). (This is on the very first page of our GitHub wiki: Bitmark: Block Reward & Currency Supply.   Everything we have done respects this total cap on emission.
By its nature CEM has the potential (because it can lower a block reward down from the epoch's maximum) to push completion of the total emission further into the future. Likewise, rewarding merge-mined blocks less than native-mined blocks defers completion of the total emission into the future by its own measure.   I believe that a careful reading of the philosophy expressed in the Wiki justifies this. Particularly this passage:


By deferring issuing coins when CEM reductions are in effect, and as well when blocks are mined by merge-miners, it ensures that mining will be sustainable for much longer before mining has to be incentivized only by transaction fees,  But more importantly, it means that there are even less of the "early bird" incentives pointed out in the original paper. The emission algorithms, keeps coins in reserve for a future that may have more demand for them. As always, no more than the 27,579,894.73108000 MARKS will ever be issued.

And last but not least, these measures, although they will not reduce emission as low as it had been for some stretches of time in the past, will move the emission rate closer to what have been Bitmark's real, historical emission averages.

 In summary, their are 5 benefits I see with the approach we are working on now:

1) We get the security of merge mining,    
2) The emission is more dynamic,  and emission is more in line with Bitmark's real historical averages,  
3) We have an incentive for merge-miners to adopt Bitmark as the parent chain,    
4) We don't have to revoke merge-mining on any algo, and  
5) No issues with merge-miners or natives sabotaging each other's CEM reward with 1-day high-hashrate attacks just to affect the other guy's SSF

As always I welcome thoughtful input and suggestions.


PS .. We're working on a graph that will illustrate our emission rates. Should be interesting.

 It's interesting to me, how CEM is attractive to @onlineproof for the  reason he expresses, which is one of the effects of CEM, but I thought of Coin Emission Modulation (CEM) primarily as a way to decouple emission from the number of blocks produced.  From the start, it was absolutely thought of as a way to meet demand adequately, (because hashrate is the only intrinsic demand-linked metric available in the blockchain dynamics themselves) while still finding blocks quickly enough so that transactions (the main concern of users) are processed expediently. We intend to build on it by letting CEM v0.2 act on a larger percentage of the base epoch reward.

@onlineproof
I've read the whole discussion - https://github.com/project-bitmark/bitmark/issues/68
I don't see why you oppose that proposal.
Developers just want to reduce reward for merged mined blocks because cost of creating those blocks is much lower then block created with direct Bitmark mining. It makes sense to me. This would probably have very positive impact on the price. And for some reason you don't like that.
It is very hard to understand you ideas in a discussion. Sometimes they are even laughable.
What is your agenda here? Do you get a cut from merged miners?

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

I was the main developer for Bitmark since early 2017. I developed the multi-algo, merge mining and difficulty adjustments in the recently launched fork. As you can see on the merge mining discussion thread https://github.com/project-bitmark/bitmark/issues/68 , I (user piratelinux) am opposed to the new change that is planned to be released by the people who control the project-bitmark gitub. It is obviously a scam (reduces the rate of money supply in order to pump the price). Bitmark was never pre-mined, never had an ICO, was a completely honest user-focused protocol. But this change will change will break that reputation. So if anyone is with me please contact me (here as a private message) and we can try to continue with the current protocol as it is, uncorrupted.

Also just so people understand, CEM (coin emission modulation), was a change that went into the large multi algo fork we recently completed, and the point is to ensure that miners are working at their peak potential by punishing them if they are not at the peak hashrate of the past 365 days. This is good because it enhances hashpower security for users. It has nothing to do with pumping the price or as dbkeys would say "ensuring supply appropriately meets demand".

I am not doing this for any profit. I just want to see and honest and reputable protocol for decentralized reputation. Also, if you currently are a Bitmark merge miner, you will get a much smaller reward with the change they are trying to push now, so contact me if you want to get involved. Just because merge mining is easier for miners because they are already mining other chains in the same time, they still need to be rewarded the same as any other miner, as the amount of reward is correlated with the likelihood of carrying out a double spend attack (I can explain this more if someone wants). There is no such thing as and "official team" in a P2P protocol and even one of the official owners of project-bitmark is opposed to the change as you can see in the thread I linked (his username is melvincarvalho), but has stopped speaking recently.

I rely that the idea will carry out all that has been target!  Good luck DEVs!

new team for bitmark？

Sorry I meant to post that under my personal account:


Afert a resonanable period of discourse our previoud developere could not see the real picture which was blatantly obvious (and which I will not go over as @DBKEYS has already laid out just reasoning for our decision).

We SHALL take action NOW!

Afert a resonanable period of discourse our previoud developere could not see the real picture which was blatantly obvious (and which I will not go over as @DBKEYS has already laid out just reasoning for our decision).

We SHALL take action NOW!

The answer IMO goes back to economics... supply & demand.    Once the Bitmark blockchain started flowing steadily with v0.9.7.0, after many years of producing  very few blocks per day,  many more coins are being produced than the market demand to absorb them at 10k sat. was used to.
 Also, particularly because a majority of blocks are being merge-mined, perhaps they are seen as "freebies" or extras by the merge miners, to be liquidated ASAP on exchanges.

While the project does not specifically target any price for the coin, one purpose of the Coin Emission Modulation (CEM) algo is to buffer, to some degree from these types of market pressures, by issuing coins according to demand, as sensed by network hashrate. Algorithmically, the implementation has worked well, but the limited action range of 50% epoch block reward has not proven to be strong enough. The current 50% CEM v0.1 action range will be expanded to at least 80%  in CEM v0.2.

Additionally, an intense debate has been had on the Bitcoin GitHub regarding the pros / cons of rewarding merge-mined blocks the same as native-mined blocks.    ( Merge Mining Debate )    The discussion ensued after it was raised as an Issue by GitHub user Jarr0s.

Merge-mined blocks are of near-zero marginal cost for merge miners to produce, because their fixed equipment costs do not change at all when they merge-mine MARKS. They are already in operation, mining another chain that shares one of Bitmark's 8 algos.  They just have to set up a Bitmark node on their existing hardware, and dedicate a some extra processor cycles to submit work for Bitmark.

I am of the opinion that it is appropriate to reward them at a fraction of native-mined blocks, because they are of much lower cost to produce than native blocks. Is it simply a principled question of Equity.

The project appreciates merge-miners. The blocks they mine, linked to higher hashrate parent chains, provide addtional security to the Bitmark blockchain, and have value for Bitmark and will be rewarded - just not at the same rate as native blocks.
If merge miners wish to get the higher native rate, they may mine MARKS natively, as the parent chain.

These measures are likely to result in  a coin emission rate more in line with the historical averages, and may restore the market conditions when the Bitmark price was in trading band an order of magnitude higher than it is now, but Disclaimer: this is just speculation on my part.      Market forces are always outside of the control of any one group or individual.

Our purpose and vision from the start has been to be a solid, secure and reliable blockchain on which to implement the myriad possibilites of Marking.      Bitmark v0.9.7 is a solid step in that direcition, because it definitely restored prompt transactions processing, with block production fairly steady at the target 2 minutes.  The idea of decoupling coin emission directly from block production proved feasible and succesful with CEM v0.1, and wil be built upon and strengthened in the next iteration.

Bitmark version 0.9.8 is being coded and will then enter testing. Once it is final, we will publish the exact specifications of CEM v0.2 and the policies regarding native and merged mined blocks.

I am eager to move past the blockchain dynamics and start focusing on the Marking, which is what will bring the best value to Bitmark.