Quote from: Matiel on August 24, 2018, 01:37:08 AM

Quote from: onelineproof on August 23, 2018, 03:38:11 PM

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:

Quote

"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:

Quote

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