[ANN] [MARKS] Incentivize Content Creators & Build a Reputation Value Framework

[onelineproof]

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.

[dbkeys]

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.

[onelineproof]

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. 

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.

He is making an assumption that the higher the reward the more work will go into finding the block.

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.

[coinzy4]

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

[dbkeys]

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

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]

Bitmark (MARKS) (BTM)
Coin Emission Graph.
The first 4 years

Total coins issued as time goes forward. Graph starts July 2014 and goes until August 10, 2018, basically 4 years.

Almost reaching 10 million Bitmark units. (10,000,000 = 1x10^7 )

Notice how low our rate of emission was the first 2 or or 2.25 years...
 then it shot up and is only now moderating with CEM v0.1
CEM v0.2 will do a better job, and merge-mining changes should help too to get it more in line with an overall average.

[dbkeys]

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

[onelineproof]

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.

[dbkeys]

Those large wallets almost certainly belong to the "selfish miner" which mined from the Fall of 2016 until perhaps early 2018, the exact period with the highest emission rate. You can read about this problem, and how we as a community have dealt with it here:    Hard Fork #1 Criteria and Motivation.   The selfish miner did not attack the chain _per se_, that is, they did not double-spend or anything like that, they merely employed their superior hashing power (probably above 51%) to mine the chain, and they are almost certainly the holders of the large sums as detailed above.

After early 2018, there is a much less pronounced emission rate from a relatively short period of honest, native SCrypt-only mining, and, now, once again, much higher emission from honest, distributed mining on the 8mPoW algos, dominated by merge-mining. Honest merge-mining, yes, but very cheap to produce merge-mining, which is driving the price down.

 I do believe that there must be a reward policy which accounts for the production cost differential of pure native mining from near zero-cost merge-mining. I think it's unwise to foster a complete reliance on foreign chains for our mining.   I do believe the best way to maintain balance, retain dedicated native Bitmark miners and still benefit from the security of a measure of merge-mining is simply to account for that production cost differential in the subsidy.

And yes, certainly that selfish-mining period was centralized mining, and it is for that very reason that we went from a primitive diffalgo with single PoW SCrypt  to  8mPoW with DGWv3 diffalgo.

[coinzy4]

The biggest wallet without any doubt is Poloniex wallet.

[psycodad]

Those large wallets almost certainly belong to the "selfish miner" which mined from the Fall of 2016 until perhaps early 2018, the exact period with the highest emission rate. You can read about this problem, and how we as a community have dealt with it here:    Hard Fork #1 Criteria and Motivation.   The selfish miner did not attack the chain _per se_, that is, they did not double-spend or anything like that, they merely employed their superior hashing power (certainly above 51%) to mine the chain, and they are almost certainly the holders of the large sums as detailed above.

After early 2018, there is a much less pronounced emission rate from a relatively short period of honest, native SCrypt-only mining, and, now, once again, much higher emission from honest, distributed mining on the 8mPoW algos, dominated by merge-mining. Honest merge-mining, yes, but very cheap to produce merge-mining, which is driving the price down.

 I do believe that there must be a reward policy which accounts for the production cost differential of pure native mining from near zero-cost merge-mining. I think it's unwise to foster a complete reliance on foreign chains for our mining.   I do believe the best way to maintain balance, retain dedicated native Bitmark miners and still benefit from the security of a measure of merge-mining is simply to account for that production cost differential in the subsidy.

And yes, certainly that selfish-mining period was centralized mining, and it is for that very reason that we went from a primitive diffalgo with single PoW SCrypt  to  8mPoW with DGWv3 diffalgo.

You don't need 51% for selfish mining at all, roughly 30-40% are sufficient depending on the specific selfish mining technique used by the attacker/selfish miner, even much less if the chain is stalled for weeks like BTM was at that time.

Selfish mining is not to be confused with a 51% attack where the goal is to doublespend inputs. The selfish miner just wants all blocks at lowest possible (hash-)price and to annoy honest miners until they leave by constantly invalidating the blocks the honest miners find.

[dbkeys]

Those large wallets almost certainly belong to the "selfish miner" which mined from the Fall of 2016 until perhaps early 2018, the exact period with the highest emission rate. You can read about this problem, and how we as a community have dealt with it here:    Hard Fork #1 Criteria and Motivation.   The selfish miner did not attack the chain _per se_, that is, they did not double-spend or anything like that, they merely employed their superior hashing power (certainly above 51%) to mine the chain, and they are almost certainly the holders of the large sums as detailed above.

After early 2018, there is a much less pronounced emission rate from a relatively short period of honest, native SCrypt-only mining, and, now, once again, much higher emission from honest, distributed mining on the 8mPoW algos, dominated by merge-mining. Honest merge-mining, yes, but very cheap to produce merge-mining, which is driving the price down.

 I do believe that there must be a reward policy which accounts for the production cost differential of pure native mining from near zero-cost merge-mining. I think it's unwise to foster a complete reliance on foreign chains for our mining.   I do believe the best way to maintain balance, retain dedicated native Bitmark miners and still benefit from the security of a measure of merge-mining is simply to account for that production cost differential in the subsidy.

And yes, certainly that selfish-mining period was centralized mining, and it is for that very reason that we went from a primitive diffalgo with single PoW SCrypt  to  8mPoW with DGWv3 diffalgo.

You don't need 51% for selfish mining at all, roughly 30-40% are sufficient depending on the specific selfish mining technique used by the attacker/selfish miner, even much less if the chain is stalled for weeks like BTM was at that time.

Selfish mining is not to be confused with a 51% attack where the goal is to doublespend inputs. The selfish miner just wants all blocks at lowest possible (hash-)price and to annoy honest miners until they leave by constantly invalidating the blocks the honest miners find.

Thanks for the clarification @psycodad. And this is what was happening. Nobody but Mr./Ms. Selfish mined Bitmark until they left, and shortly thereafter we switched to 8mPoW with DGWv3 anyway.  

 IIUC, this selfish-mining is possible (at least in part) because a larger chain can appear out of the blue and is accepted by all the nodes, because it is the longest, most-work chain, although the "honest" nodes had not seen the selfish node before at all.
Thus, the "selfish" part: The Selfish Miner did not share their work (and thus allow possible competition) until they were sure they hade a stronger chain to show.   Can you shed some more light on this ?

[psycodad]

Those large wallets almost certainly belong to the "selfish miner" which mined from the Fall of 2016 until perhaps early 2018, the exact period with the highest emission rate. You can read about this problem, and how we as a community have dealt with it here:    Hard Fork #1 Criteria and Motivation.   The selfish miner did not attack the chain _per se_, that is, they did not double-spend or anything like that, they merely employed their superior hashing power (certainly above 51%) to mine the chain, and they are almost certainly the holders of the large sums as detailed above.

After early 2018, there is a much less pronounced emission rate from a relatively short period of honest, native SCrypt-only mining, and, now, once again, much higher emission from honest, distributed mining on the 8mPoW algos, dominated by merge-mining. Honest merge-mining, yes, but very cheap to produce merge-mining, which is driving the price down.

 I do believe that there must be a reward policy which accounts for the production cost differential of pure native mining from near zero-cost merge-mining. I think it's unwise to foster a complete reliance on foreign chains for our mining.   I do believe the best way to maintain balance, retain dedicated native Bitmark miners and still benefit from the security of a measure of merge-mining is simply to account for that production cost differential in the subsidy.

And yes, certainly that selfish-mining period was centralized mining, and it is for that very reason that we went from a primitive diffalgo with single PoW SCrypt  to  8mPoW with DGWv3 diffalgo.

You don't need 51% for selfish mining at all, roughly 30-40% are sufficient depending on the specific selfish mining technique used by the attacker/selfish miner, even much less if the chain is stalled for weeks like BTM was at that time.

Selfish mining is not to be confused with a 51% attack where the goal is to doublespend inputs. The selfish miner just wants all blocks at lowest possible (hash-)price and to annoy honest miners until they leave by constantly invalidating the blocks the honest miners find.

Thanks for the clarification @psycodad. And this is what was happening. Nobody but Mr./Ms. Selfish mined Bitmark until they left, and shortly thereafter we switched to 8mPoW with DGWv3 anyway.  

 IIUC, this selfish-mining is possible (at least in part) because a larger chain can appear out of the blue and is accepted by all the nodes, because it is the longest, most-work chain, although the "honest" nodes had not seen the selfish node before at all.
Thus, the "selfish" part: The Selfish Miner did not share their work (and thus allow possible competition) until they were sure they hade a stronger chain to show.   Can you shed some more light on this ?

This is perfectly right as you describe it, though the selfish miner is at all times connected with the honest network and nodes.
The selfish miners two or more nodes are connected to the whole network and they seem to agree on the chain all nodes have (while in hidden the selfish miner advances the chain on his 2+ nodes secretly).

Say, the honest network is on block # 1000 and all nodes agree on that, then the selfish miner mines say until # 1010 but leaves the network thinking it is still on # 1000 by not releasing these blocks. Only when the selfish miner hears from one of its peers that a block has been found and broadcasted by a honest miner, he/she will release 2 or 3 blocks to invalidate the honests miners work. If he he has and advantage of ten he can even wait longer to invalidate the others blocks.

There are certainly checks and balances in most wallets that limit how many blocks one can release at once and so on, I can't say much about this as I never dug into these parts in the code. Though the attacker knows this exactly and has "tuned" wallets/nodes that make sure other blocks are only seemingly accepted from honest nodes and he/shee only releases his blocks when needed and in an interval that is acceptable for the specific network currently attacked.

In the last 2-3 yrs we saw this very same attack on quite a lot scrypt chains (don't know about others, I am only into scrypt chains) like BTM, EAC, WDC, TIPS just to name a few and I am pretty confident it is still going on, ABY seems to be a current example of it.

[dbkeys]

Those large wallets almost certainly belong to the "selfish miner" which mined from the Fall of 2016 until perhaps early 2018, the exact period with the highest emission rate. You can read about this problem, and how we as a community have dealt with it here:    Hard Fork #1 Criteria and Motivation.   The selfish miner did not attack the chain _per se_, that is, they did not double-spend or anything like that, they merely employed their superior hashing power (certainly above 51%) to mine the chain, and they are almost certainly the holders of the large sums as detailed above.

After early 2018, there is a much less pronounced emission rate from a relatively short period of honest, native SCrypt-only mining, and, now, once again, much higher emission from honest, distributed mining on the 8mPoW algos, dominated by merge-mining. Honest merge-mining, yes, but very cheap to produce merge-mining, which is driving the price down.

 I do believe that there must be a reward policy which accounts for the production cost differential of pure native mining from near zero-cost merge-mining. I think it's unwise to foster a complete reliance on foreign chains for our mining.   I do believe the best way to maintain balance, retain dedicated native Bitmark miners and still benefit from the security of a measure of merge-mining is simply to account for that production cost differential in the subsidy.

And yes, certainly that selfish-mining period was centralized mining, and it is for that very reason that we went from a primitive diffalgo with single PoW SCrypt  to  8mPoW with DGWv3 diffalgo.

You don't need 51% for selfish mining at all, roughly 30-40% are sufficient depending on the specific selfish mining technique used by the attacker/selfish miner, even much less if the chain is stalled for weeks like BTM was at that time.

Selfish mining is not to be confused with a 51% attack where the goal is to doublespend inputs. The selfish miner just wants all blocks at lowest possible (hash-)price and to annoy honest miners until they leave by constantly invalidating the blocks the honest miners find.

Thanks for the clarification @psycodad. And this is what was happening. Nobody but Mr./Ms. Selfish mined Bitmark until they left, and shortly thereafter we switched to 8mPoW with DGWv3 anyway.  

 IIUC, this selfish-mining is possible (at least in part) because a larger chain can appear out of the blue and is accepted by all the nodes, because it is the longest, most-work chain, although the "honest" nodes had not seen the selfish node before at all.
Thus, the "selfish" part: The Selfish Miner did not share their work (and thus allow possible competition) until they were sure they hade a stronger chain to show.   Can you shed some more light on this ?

This is perfectly right as you describe it, though the selfish miner is at all times connected with the honest network and nodes.
The selfish miners two or more nodes are connected to the whole network and they seem to agree on the chain all nodes have (while in hidden the selfish miner advances the chain on his 2+ nodes secretly).

Say, the honest network is on block # 1000 and all nodes agree on that, then the selfish miner mines say until # 1010 but leaves the network thinking it is still on # 1000 by not releasing these blocks. Only when the selfish miner hears from one of its peers that a block has been found and broadcasted by a honest miner, he/she will release 2 or 3 blocks to invalidate the honests miners work. If he he has and advantage of ten he can even wait longer to invalidate the others blocks.

There are certainly checks and balances in most wallets that limit how many blocks one can release at once and so on, I can't say much about this as I never dug into these parts in the code. Though the attacker knows this exactly and has "tuned" wallets/nodes that make sure other blocks are only seemingly accepted from honest nodes and he/shee only releases his blocks when needed and in an interval that is acceptable for the specific network currently attacked.

In the last 2-3 yrs we saw this very same attack on quite a lot scrypt chains (don't know about others, I am only into scrypt chains) like BTM, EAC, WDC, TIPS just to name a few and I am pretty confident it is still going on, ABY seems to be a current example of it.

Yes, this happened to Verge and is the reason they went 5mPoW.

[onelineproof]

As you see on the project-bitmark github, they have pushed to master the fork dbkeys proposed (so he can easily sell his stash). Not only does it fundamentally change Bitmark from a P2P cryptocurrency to a crowdfunding campaign for investors, but it uses cheap hacks to get the thing done (forced block height not even waiting for user or miner votes), doesn't fix important bugs, and still continues to be advertised as a "decentralized cryptocurrency". If it is not 100% crystal clear to someone that this fork is about manipulating the price from the supply side, then ask me and I can try to make it more clear (except for dbkeys whom I already explained this to repeatedly).

In case someone / people want to continue with the current protocol, with a couple of minor/bug fixes that technically need a hard fork, then I created a github repo called bitmark-protocol, that has this under the software version number 0.9.7.3 (dbkeys' fork is 0.9.8.x). The core block number remains as 4, just a variant/subversion number 1 is embedded into the full version number, so the version number for blocks would be called 4.1 (dbkeys's fork has version number 5). My fork would require 950 out of the last 1000 blocks signaling for version 4.1 to activate. The code is available at https://github.com/bitmark-protocol/bitmark. You can clone the latest master for stable code. It is quite well tested, though I will test more thoroughly if I see version 4.1 blocks being mined. The dev branch is for developments before they enter master. I also launched an explorer for monitoring blocks: https://explorer.bitmark.cc and https://explorer.bitmark.cc/testnet for testnet.

The 2 fixes in this release are:
1) Use Bignum for the subsidy scaling factor to prevent an overflow that has occasionally caused block rewards to be much less than they should be.
2) Activate the resurrector even right after the surge protector kicks in. Currently, 25 blocks must pass before the resurrector (lowering of difficulty after some time of no blocks of an algo) can kick in after a surge protector event (9 in a row for an algo). This is a rare case, but still needed for correctness.

If there is not enough support for my fork, then, instead of creating a new coin, I will likely work on migrating the Bitmark protocol into a Bitcoin sidechain. Sidechain technology is still not mature and requires some layer of trust, but I think it can work and help other sidechains thrive as well. You can see my post about this here https://bitcointalk.org/index.php?topic=4919679.msg44289606#msg44289606

By the way, dbkeys' fork is not even well tested, they use the requirement block.nVersion >= 5, while it should be GetBlockVersion(block.nVersion) >= 5 in order to force version 5 blocks. The raw version number only worked for the first fork where we first introduced the notion of raw (with extra data) and core version numbers. It's not a critical bug, but still shows lack of testing.

[Matiel]

As you see on the project-bitmark github, they have pushed to master the fork dbkeys proposed (so he can easily sell his stash). Not only does it fundamentally change Bitmark from a P2P cryptocurrency to a crowdfunding campaign for investors, but it uses cheap hacks to get the thing done (forced block height not even waiting for user or miner votes), doesn't fix important bugs, and still continues to be advertised as a "decentralized cryptocurrency". If it is not 100% crystal clear to someone that this fork is about manipulating the price from the supply side, then ask me and I can try to make it more clear (except for dbkeys whom I already explained this to repeatedly).

In case someone / people want to continue with the current protocol, with a couple of minor/bug fixes that technically need a hard fork, then I created a github repo called bitmark-protocol, that has this under the software version number 0.9.7.3 (dbkeys' fork is 0.9.8.x). The core block number remains as 4, just a variant/subversion number 1 is embedded into the full version number, so the version number for blocks would be called 4.1 (dbkeys's fork has version number 5). My fork would require 950 out of the last 1000 blocks signaling for version 4.1 to activate. The code is available at https://github.com/bitmark-protocol/bitmark. You can clone the latest master for stable code. It is quite well tested, though I will test more thoroughly if I see version 4.1 blocks being mined. The dev branch is for developments before they enter master. I also launched an explorer for monitoring blocks: https://explorer.bitmark.cc and https://explorer.bitmark.cc/testnet for testnet.

The 2 fixes in this release are:
1) Use Bignum for the subsidy scaling factor to prevent an overflow that has occasionally caused block rewards to be much less than they should be.
2) Activate the resurrector even right after the surge protector kicks in. Currently, 25 blocks must pass before the resurrector (lowering of difficulty after some time of no blocks of an algo) can kick in after a surge protector event (9 in a row for an algo). This is a rare case, but still needed for correctness.

If there is not enough support for my fork, then, instead of creating a new coin, I will likely work on migrating the Bitmark protocol into a Bitcoin sidechain. Sidechain technology is still not mature and requires some layer of trust, but I think it can work and help other sidechains thrive as well. You can see my post about this here https://bitcointalk.org/index.php?topic=4919679.msg44289606#msg44289606

By the way, dbkeys' fork is not even well tested, they use the requirement block.nVersion >= 5, while it should be GetBlockVersion(block.nVersion) >= 5 in order to force version 5 blocks. The raw version number only worked for the first fork where we first introduced the notion of raw (with extra data) and core version numbers. It's not a critical bug, but still shows lack of testing.

if you two are right, what truth should I believe?

[dbkeys]

As you see on the project-bitmark github, they have pushed to master the fork dbkeys proposed (so he can easily sell his stash). Not only does it fundamentally change Bitmark from a P2P cryptocurrency to a crowdfunding campaign for investors, but it uses cheap hacks to get the thing done (forced block height not even waiting for user or miner votes), doesn't fix important bugs, and still continues to be advertised as a "decentralized cryptocurrency". If it is not 100% crystal clear to someone that this fork is about manipulating the price from the supply side, then ask me and I can try to make it more clear (except for dbkeys whom I already explained this to repeatedly).

In case someone / people want to continue with the current protocol, with a couple of minor/bug fixes that technically need a hard fork, then I created a github repo called bitmark-protocol, that has this under the software version number 0.9.7.3 (dbkeys' fork is 0.9.8.x). The core block number remains as 4, just a variant/subversion number 1 is embedded into the full version number, so the version number for blocks would be called 4.1 (dbkeys's fork has version number 5). My fork would require 950 out of the last 1000 blocks signaling for version 4.1 to activate. The code is available at https://github.com/bitmark-protocol/bitmark. You can clone the latest master for stable code. It is quite well tested, though I will test more thoroughly if I see version 4.1 blocks being mined. The dev branch is for developments before they enter master. I also launched an explorer for monitoring blocks: https://explorer.bitmark.cc and https://explorer.bitmark.cc/testnet for testnet.

The 2 fixes in this release are:
1) Use Bignum for the subsidy scaling factor to prevent an overflow that has occasionally caused block rewards to be much less than they should be.
2) Activate the resurrector even right after the surge protector kicks in. Currently, 25 blocks must pass before the resurrector (lowering of difficulty after some time of no blocks of an algo) can kick in after a surge protector event (9 in a row for an algo). This is a rare case, but still needed for correctness.

If there is not enough support for my fork, then, instead of creating a new coin, I will likely work on migrating the Bitmark protocol into a Bitcoin sidechain. Sidechain technology is still not mature and requires some layer of trust, but I think it can work and help other sidechains thrive as well. You can see my post about this here https://bitcointalk.org/index.php?topic=4919679.msg44289606#msg44289606

By the way, dbkeys' fork is not even well tested, they use the requirement block.nVersion >= 5, while it should be GetBlockVersion(block.nVersion) >= 5 in order to force version 5 blocks. The raw version number only worked for the first fork where we first introduced the notion of raw (with extra data) and core version numbers. It's not a critical bug, but still shows lack of testing.

if you two are right, what truth should I believe?

    It's unfortunate when a there is division and disagreement. However, the decision to subsidize merge-mined blocks less than native mined blocks was taken after long discussions, where everyone except @onelineproof agreed that it was in the best interest of the entire Bitmark community.  This includes users, early adopters, early investors and miners as well.

    Despite having been employed by the project for over a year and a half, @onelineproof has taken the stance that the project would either implement his vision, or he would fork. Despite having been repeatedly  invited to understand the point of view of most everyone else, and to engage in discussions whereby we could find common ground, or at least find some compromise, he chose to cut off communications, "ostrich style,  except to accuse me and the project of turning into an ICO (which is absurd as anybody who know Bitmark's history is well aware).  This radical stance and lack of balance and relational skilss are simply not qualities I would like to see in a leader, to be honest. By his own admission, he says:

"I'm not an easy person to work with, people who know me know that I am very stubborn. Though I don't have much invested so I don't know how it feels, but I am not driven at all by profit and I don't care even if the price goes to 1 satoshi"

    As a project, we cannot be held hostage to the "merge-mine fundamentalism" of a single person, especially when he appears insensitive to destroying the value of the coin and completely disregards the concerns of early adopters.

    The issue of merge-mining, and the pros and cons of seeking equitable subsidies between native mining and merge mining have been discussed at length on Project Bitmarks official github: Merge-mining as an Issue, on Project Bitmark's Slack channels and directly among interested parties.   I have invited input from the community repeatedly on this forum, and by and large, people are mostly interested in how soon the fork with the features as we propose will be ready.  

    I have sought the best advice on ths issue and have received this illustrative comment:

 ..@onelineproof]...does seem to be confused about the finer points of double spend protection. He's saying the block reward is linked to the protective factor of "confirmations", or, put another way, linked to the cost of producing those blocks, and the rewards from doing so. He's unfortunately deducing from that line of logic that reducing the merged mining block rewards will reduce security of the chain. This would be true for a non-merged chain, because the incentive to mine the coin would go down, and thus mining pressure would decrease, but with merged mining the additional cost for mining pools to mine the blocks is effectively zero, and the rewards are just gravy, so they're never going to stop mining. That's both a feature and a bug in this case. It keeps the chain secure with a high difficulty for a low cost, but completely floods the market with un-invested dumpers who see dumping Bitmark as a 0.5% profit increase on their Litecoin mining setup.
There's no doubt an economics problem with enabling merge mining rewards, I think this is why you see so few prominent merge mined coins. It simply creates a ton of market sell pressure which is hard to deal with.
 ....

    I believe that by finding balance the right rewards for native mining and merge-mined mining, the Bitmark blockchain will be both secure and produce coins at the rate that the market is calling for. It is no secret that I have sought to regulate emission in response to market demand as early as 2015, when the idea of Coin Emission Modulation was born, and finally implemented earlier this year, ( with @onlineproof's coding help: give credit where credit is due.)

    @onlineproof seems to think it is wrong to consider the hardship suffered by early investors in the coin, who have seen the BTM/BTC exchange rate drop  dramatically this year. After long periods of rather minimal emission, and then a long period dominated by a selfish miner, ( as yet not identified to my knowledge, who may be hoarding their entire mining take for some future), we have had a few months of very distributed mining, which is good, but by mostly merge-miners who are acquiring  bitmarks at nearly zero cost and liquidating them ASAP.  We seek to remediate this, unashamedly.

    @onelineproof is correct that v0.9.8.3 is an absoute hard fork, set to occur at block 511,111, in approximately 5 or 6 days, around August 30.  We may delay this a bit to address the valid issues pointed out, but ultimately, IMO we should not pretend to ask the merge-miners who we have unwittingly let dominate all of Bitmark mining if they think letting go of the "candy" is a good idea.    As we have stated, we think the compromise we have implemented in Bitmark version 0.9.8.3 between 1) the near-zero cost of merge-mining Bitmark on top of an already on-going mining operation  and 2) the value of merge-mined blocks to the Bitmark blockchain is a good one.  I believe it is even good for the merge-miners, utlimately, because altough they will get less units, these units should be worth more. And of course, they can always mine natively for the full CEM reward.

    Losing @onelineproof as a coder for the project has been unfortunate, as in truth and fairness, he is a fine coder, resourceful, and was able to implement the Bitmark Project's vision of our transition from a single-PoW algo regulated by a primitive diffalgo to an 8mPoW blockchain regulated by the DGWv3 diffalgo,  and implented also the vision of Coin Emission Modulation as CEM v0.1.
 
    @onelineproof actually likes CEM well enough, although it has the same effect of withholding and deferring a part of the coin's emission into the future, just  as reduced subsidies for merge-mined blocks does.  It bears repeating that is a strong positive, because it means mining Bitmark will be viable much longer into the future and the number of coins emitted will match market demand much closer. Also it bears underlining that the total emission of Bitmark is being respected: no more and no less than originally planned
   Rather incongruoulsly, though, @onelineproof has chosen to chacterize the improvement of adjusting merge-mining subsidies as a "scam" and an "ICO" which IMO shows an embarrassing lack of understanding, a unfortunate quickness to judge negatively  and an unwarranted propensity to ascribe dark motives.  
 @onlineproof seems to think that it's OK to modify the code, as he helped to do in the v0.9.5 to v0.9.7 transition, but then somehow a sin to do so again to fix issues and address flaws discovered since v0.9.7 went live on June 6. Incongruous is the word that come to my mind.

    In any case,  for all his positive contributions we are grateful.   If @onelineproof wishes, he may submit a pull request with  the BigNum and other technical issues he points to. If we have time before the forkheight, or if we decide to postpone the fork, these minor details will be taken care of now, or they will be addressed later.  

In short, we must move forward. Enough has been said.  

[onelineproof]

It is not true that I didn't compromise. I personally believe merge mining is better for security and decentralization than native mining, but even if you do want to reduce the rewards of merge miners, I did accept that to a certain degree. But dbkeys mixes two things that are completely separate: 1) Reducing the reward for merge miners relative to native miners, 2) Modifying the emission schedule. (1) can be done in various ways without (2). You can see the github thread for 3 of these ways: https://github.com/project-bitmark/bitmark/issues/68#issuecomment-408140614. But now dbkeys is saying that those other ways would have merged miners quickly bringing up the peak hashrate of the native algo variant, and messing up the CEM calculations, so he wants to keep native and merge miners with the same difficulty adjustment, just with a different reward. But you can still respect the supply schedule. Just like DGW adjusts the difficulty to meet a target time for blocks, you can adjust the "bonus" paid to native miners to meet the emission rate target (taking into account CEM), with small variations about the mean (also other ways I thought of that don't require any variations). So you can think of the bonuses as money saved by paying merged miners less. Like I said, I would like merge mining to remain fully dominant, but at least this solution would respect the emission schedule, thus I wouldn't call it a scam.

Then they might say, oh well lowering the emission rate will help to delay the need for a fee market. But you need to understand what the point is of Bitcoin and other decentralized cryptocurrencies. Bitcoin was created in order to prevent the manipulation of the money supply by central bankers. A predetermined algorithm is used instead of people deciding what the proper emission should be at any given time. You can even read this in the bitcoin wiki: https://en.bitcoin.it/wiki/Controlled_supply

In a centralized economy, currency is issued by a central bank at a rate that is supposed to match the growth of the amount of goods that are exchanged so that these goods can be traded with stable prices. The monetary base is controlled by a central bank. In the United States, the Fed increases the monetary base by issuing currency, increasing the amount banks have on reserve or by a process called Quantitative Easing.
In a fully decentralized monetary system, there is no central authority that regulates the monetary base. Instead, currency is created by the nodes of a peer-to-peer network. The Bitcoin generation algorithm defines, in advance, how currency will be created and at what rate. Any currency that is generated by a malicious user that does not follow the rules will be rejected by the network and thus is worthless.

If the rate could be modified on the fly then insiders could use that to profit. They could buy before the announcement of a lowering of the rate, and sell right before the rate is announced to be increased. In general it can be used to temporarily create favorable conditions for special interests. Also miners look at this and see that the rewards are not stable, no good track record, and are more likely to attack the chain as a result.

There is also 2 other changes in dbkeys' fork. Only 30 periods instead of 365 are used for calculating the peak hashrate, and CEM can reduce the reward by up to 80% instead of 50%. I can give you many reasons why these changes would harm users, but it is important to understand that any drastic protocol change without clear proof that it benefits users is clown shoes. As for setting a fork height without a miner supermajority, it is dangerous for users who may end up sending money on the wrong fork. It's irresponsible.

As for the quote of me saying I'm stubborn, well yes it's true and I have high standards for some things, maybe higher than average. I don't think I'm such a good programmer, I just work hard on whatever I'm passionate about and pay attention to details. I mostly said that because they were pressuring me to do something I don't want to do, so I didn't want to give them false hope. I would be surprised if my comments on Slack are still publicly viewable, as I was banned from there a month ago by 82ndabnmedic, just for expressing my disagreement with the fork. I can also find you quotes of dbkeys saying how he wants to send a percentage of miner rewards into a developer fund (that was blocked by Melvin) and how he wants to consider master-nodes or proof of stake voting or mining... And for the price, who knows. I think $0.10 is a strong bottom, even with all merge miners selling. A 1 satoshi price would be almost impossible and it was an exaggeration. $0.10 to $1 is easy within a year. But people have to actually work hard to improve the protocol instead of coming up with ways to work less.

As for the person who said my thoughts about double spend protection are wrong, let them come here or any other open/uncensored forum and I can debate them. I think they are wrong about this, and also there is a nice thread about merge mining security in the bitcoin-dev archives: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/003981.html. I think one conclusion from that is that as long as you are not a scam-coin, merge mining is quite secure, and still the best you can do compared to the other alternatives.

I think currently, from the Bitmark community, there is just a few people who strongly support dbkeys' fork and most people don't care or don't understand the issues. If you see the github thread, I also initially said "sure why not, let's reduce the merge miners reward by 50%". But after more careful thought, I changed my mind on that and definitely don't want to mess with the emission schedule. On my side I see some kind of support from the following users in this thread: psycodad, tync, Matiel. Also I had some level of support by someone who contacted me privately. But I need strong support from at least a few people. So please make it known or contact me privately at least, and like that I can try to submit a petition to exchange to include my vision for the fork, and even let dbkeys have his vision under the BTM ticker if he wants (though I think putting scam-coins on an exchange would be unwise for the reputation of the exchange). I am in good contact with people who work in Trade-by-trade, but I don't want to use my access to push my own vision and I definitely need an exchange to make sure I am not the only person mining the chain. So this is the last chance! dbkeys' fork may activate in less than a week.

I think in the future sidechains will enable multiple currencies to exist on one blockchain (for the purpose of paying miners for transactions). They cam also further decentralize mining (no merge mining 2 sidechains of a chain at once). You could have for example Bitcoin being transferred to the Bitmark blockchain, and people can choose to pay with Bitcoin or Bitmark, just like now USD can be used in almost any country, but you could still use the local currency if you want. To transfer the Bitcoin would have a waiting time, so sometimes it would be better to use the MARKS, or marks could just be a backup, in case there are some problems with Bitcoin. So I don't think sidechains will completely kill altcoins, and still, with the best computers and moon-math, it is very inefficient to use sidechains in a trustless manner. The network effect (strong bonds between P2P nodes) with those nodes resistant to many attacks is what makes a coin a good store of value.

[TeamBitmark]

   It's unfortunate when a there is division and disagreement. However, the decision to subsidize merge-mined blocks less than native mined blocks was taken after long discussions, where everyone except @onelineproof agreed that it was in the best interest of the entire Bitmark community.  This includes users, early adopters, early investors and miners as well.

    Despite having been employed by the project for over a year and a half, @onelineproof has taken the stance that the project would either implement his vision, or he would fork. Despite having been repeatedly  invited to understand the point of view of most everyone else, and to engage in discussions whereby we could find common ground, or at least find some compromise, he chose to cut off communications, "ostrich style,  except to accuse me and the project of turning into an ICO (which is absurd as anybody who know Bitmark's history is well aware).  This radicalism he displays and lack of a balanced vision are simply not qualities I would like to see in a leader, to be honest. By his own admission, he says:

"I'm not an easy person to work with, people who know me know that I am very stubborn. Though I don't have much invested so I don't know how it feels, but I am not driven at all by profit and I don't care even if the price goes to 1 satoshi"

    As a project, we cannot be held hostage to the "merge-mine fundamentalism" of a single person, especially when he is insensitive to destroying the value of the coin and completely disregards the concerns of early adopters.

    The issue of merge-mining, and the pros and cons of seeking equitable subsidies between native mining and merge mining have been discussed at length on Project Bitmarks official github: Merge-mining as an Issue, on Project Bitmark's Slack channels and directly among interested parties.   I have invited input from the community repeatedly on this forum, and by and large, people are mostly interested in how soon the fork with the features as we propose will be ready.  

    I have sought the best advice on ths issue and have received this illustrative comment:

 ..@onelineproof]...does seem to be confused about the finer points of double spend protection. He's saying the block reward is linked to the protective factor of "confirmations", or, put another way, linked to the cost of producing those blocks, and the rewards from doing so. He's unfortunately deducing from that line of logic that reducing the merged mining block rewards will reduce security of the chain. This would be true for a non-merged chain, because the incentive to mine the coin would go down, and thus mining pressure would decrease, but with merged mining the additional cost for mining pools to mine the blocks is effectively zero, and the rewards are just gravy, so they're never going to stop mining. That's both a feature and a bug in this case. It keeps the chain secure with a high difficulty for a low cost, but completely floods the market with un-invested dumpers who see dumping Bitmark as a 0.5% profit increase on their Litecoin mining setup.
There's no doubt an economics problem with enabling merge mining rewards, I think this is why you see so few prominent merge mined coins. It simply creates a ton of market sell pressure which is hard to deal with.
 ....

    I believe that by finding balance the right rewards for native mining and merge-mined mining, the Bitmark blockchain will be both secure and produce coins at the rate that the market is calling for. It is no secret that I have sought to regulate emission in response to market demand as early as 2015, when the idea of Coin Emission Modulation was born, and finally implemented earlier this year, ( with @onlineproof's coding help: give credit where credit is due.)

    @onlineproof seems to think it is wrong to consider the hardship suffered by early investors in the coin, who have seen the BTM/BTC exchange rate drop  dramatically this year. After long periods of rather minimal emission, and then a long period dominated by a selfish miner, ( as yet not identified to my knowledge, who may be hoarding their entire mining take for some future), we have had a few months of very distributed mining, which is good, but by mostly merge-miners who are acquiring  bitmarks at nearly zero cost and liquidating them ASAP.  We seek to remediate this, unashamedly.

    @onelineproof is correct that v0.9.8.3 is an absoute hard fork, set to occur at block 511,111, in approximately 5 or 6 days, around August 30.  We may delay this a bit to address the valid issues pointed out, but ultimately, IMO we should not pretend to ask the merge-miners who we have unwittingly let dominate all of Bitmark mining if they think letting go of the "candy" is a good idea.    As we have stated, we think the compromise we have implemented in Bitmark version 0.9.8.3 between 1) the near-zero cost of merge-mining Bitmark on top of an already on-going mining operation  and 2) the value of merge-mined blocks to the Bitmark blockchain is a good one.  I believe it is even good for the merge-miners, utlimately, because altough they will get less units, these units should be worth more. And of course, they can always mine natively for the full CEM reward.

    Losing @onelineproof as a coder for the project has been unfortunate, as in truth and fairness, he is a fine coder, resourceful, and was able to implement the Bitmark Project's vision of our transition from a single-PoW algo regulated by a primitive diffalgo to an 8mPoW blockchain regulated by the DGWv3 diffalgo,  and implented also the vision of Coin Emission Modulation as CEM v0.1.
 
    @onelineproof actually likes CEM well enough, although it has the same effect of withholding and deferring a part of the coin's emission into the future, just  as reduced subsidies for merge-mined blocks does.  It bears repeating that is a strong positive, because it means mining Bitmark will be viable much longer into the future and the number of coins emitted will match market demand much closer. Also it bears underlining that the total emission of Bitmark is being respected: no more and no less than originally planned
   Rather incongruoulsly, though, @onelineproof has chosen to chacterize the improvement of adjusting merge-mining subsidies as a "scam" and an "ICO" which IMO shows an embarrassing lack of understanding, a unfortunate quickness to judge negatively  and an unwarranted propensity to ascribe dark motives.  
 @onlineproof seems to think that it's OK to modify the code, as he helped to do in the v0.9.5 to v0.9.7 transition, but then somehow a sin to do so again to fix issues and address flaws discovered since v0.9.7 went live on June 6. Incongruous is the word that come to my mind.

    In any case,  for all his positive contributions we are grateful.   If @onelineproof wishes, he may submit a pull request with  the BigNum and other technical issues he points to. If we have time before the forkheight, or if we decide to postpone the fork, these minor details will be taken care of now, or they will be addressed later.  

In short, we must move forward. Enough has been said.  

Allow me to be as clear and concise as possible....@onelineproof did great work while he was employed by us, however his unwillingness to adopt a change that was voted on and widely accepted by the community (not to mention his attempt to hijack), has placed him outside our circle of trust. We will move as a unit toward what is in the best interest of the project & community. Sadly, since he cannot accept what we agree on as a team, then he can not work with us (or anyone of that matter "by his own admission")...who want a dev that only drives his unsubstantiated view and not the views or options of the team/project...??

[onelineproof]

Allow me to be as clear and concise as possible....@onelineproof did great work while he was employed by us, however his unwillingness to adopt a change that was voted on and widely accepted by the community (not to mention his attempt to hijack), has placed him outside our circle of trust. We will move as a unit toward what is in the best interest of the project & community. Sadly, since he cannot accept what we agree on as a team, then he can not work with us (or anyone of that matter "by his own admission")...who want a dev that only drives his unsubstantiated view and not the views or options of the team/project...??[/color][/size][/b]

TeamBitmark is a puppet account of 82ndabnmedic I assume, since the writing style is the same. What vote? Where did it take place? On slack where people get banned for disagreeing with the fork. How can you not get 100% support in such an environment?

I actually have a significant stake in Bitmark, it's not just peanuts. If I were to lose all my marks, that would be a very significant setback financially. I do have skin in the game, but for sure I would sell what I have on dbkeys' fork. The price of Bitmark never surpassed $1 except for a short time last winter when Bitcoin peaked, and the market cap never surpassed $7 million, except for that short burst. The BTC value of marks in 2014 is a useless measure since there was much less altcoins at the time, bitcoin value was lower, and there was much less marks in circulation. Same with any other BTC price / market cap. The only meaningful marketcap is USD since that's the dominant world currency right now. From 1.2 million to 7 million market cap is quite easy (we just saw a rise this month from 1 million to 1.2 million). Reducing the emission rate will not magically increase the price, it will reduce selling pressure so investors can more easily dump. Any gains will likely be temporary and unstable.

The email I listed previously in my signature seems to have problems so I am changing it back to my previous email:
<my username>@gmail.com
Like I said, this is the last chance if you support the uncorrupted version of Bitmark. Block reward changes that favor special interests will be visible on the blockchain forever. You cannot hide it.