Merged mining discusion

[jarr0s]

I'm opening this issue not to report a bug, but to start a discussion about merged mining in Bitmark, which potentially could be seen as Bitmark improvement proposal.

First I want to say kudos for adding multiple mining algorithms, kudos for new Coin Emission Modulation and for merged mining only half a kudos from me.

Merged mining can be seen as positive because it increases hash power, to prevent blockchain attacks, and on the other hand it is also a weakness because of mining centralization. Good summary about this: https://eprint.iacr.org/2017/791.pdf

Making every algorithm merged mineable, in my opinion, is unnecessary decision, and will eventually lead to mining centralization around small number of large pools.

But the biggest impact merge mining will have on the price. There are already couple of large mining pools that are merged mining some of the Bitmark algorithms. This pools doesn't send their miners Bitmarks. Mined Bitmarks are market sold on the exchanges and a miner receives Bitcoin or some more value coin. You can probably see where this is going to lead.

Also CEM doesn't have much sense with every POW is merged mineable, pool operator doesn't cost anything to produce new blocks, and they probably wont stop mining at any price.

So my biggest question is why every mining algorithm is made merged mineable?

Myriad coin is a good mPOW merged mineable coin example. Myriad coin has 5 POW algorithms, but only two of them are merged mineable - SHA256d and Scrypt. That way they made optimal solution that insures blockchain security, fair mining and coin price.

Some of mine ides how to overcome the above issues: 1) Reduce reward for merged mined block. Something like third of the regular mined block. This would have positive impact on price. 2) Not allow every block to be merged minded. Allow couple of regular blocks before merged block can be solved again. 3) And maybe the best would be have only a couple of merged mineable POW algorithms, and the rest to be regularly mined. Plus reward is reduced for merged blocks.

[jarr0s]

It looks to me that this guy is keeping the whole community as a hostage, because you all expect of him to implement a fix. Do you have any other developer that can do the work?

If you don't have, I can implement fork that I have suggested above (2 or 3 merged mined algorithms with reduced reward), in just a couple of hours. This will give coin a chance, and you will have enough time to find another developer to continue the work. What do you say?

[dbkeys]

jarr0s, most of the type of discussion we've had here takes place on Slack. (https://projectbitmark.slack.com) Please check in there so we can continue discussing these possibilities.

[dbkeys]

@piratelinux, I disagree that community = only users. Investors and miners are an inextricable part of the system, and so, the community, IMO, includes not only users but also investor, miners, developers and anyone else with an interest or a stake in the system. It's true that by focusing on users, and serving their needs, investors and miners and developers do well and can do better, the better they serve the user's needs. The purpose of the system is to serve its users. But if investors are losing and miners aren't rewarded, there would be no system to serve the users. By definition, community is the group of all those with a common interest: what I've been calling 'the system'. They have a common interest in the 'system' (the blockchain, the protocol, the wallet ). As long as they all get what they want out of the system, then it will thrive. If any one of these groups is dissatisified, the system won't work.

[dbkeys]

@piratelinux, you said this:

I find for example that sha256 always ramps up when the price of Bitcoin goes down, so more miners are getting desperate to squeeze what they can from their sha ASICs in those times. The current difficulty of sha 256d on Bitmark seems to be only 0.002 of the difficulty of Bitcoin, so if it was really zero cost that number would be much bigger.

This is interesting, because, overall to me, it underlines that economics are important. But specifically, what is likely happening is that as the price of Bitcoin goes down, individual ASIC owners who know about us quit the pools where they are mining only BTC and move their SHA hashrate to a another pool which is mining Bitmark SHA (either natively or merge-mined), or directly mine Bitmark SHA themselves, since it is possible to 'native' mine an AuxPoW enabled algo.
What we have to realize is that just because it is free money (practically zero cost to add Bitmark SHA merge mining), not all sha pools will add us. Many people won't bend down to pick up a penny. I bet we are not even on the radar of the majority of pools. They just don't care about us, as hard as it sounds. They are mining for bitcoins, and they're not bothering to add less prominent coins. Coinmarketcap has variously ranked us between 800 to 300 (we go to the low 300's when the price went up to USD $3.25 in January)

[dbkeys]

Jarr0s: You hit the nail on the head when you said this:

Miners, who are interested in Bitmark are punished because they have to mine on extreme difficulty, but the miners who doesn't know what Bitmark is, are rewarded with free money.

That is the rationale to bring back native mining, (either as a native-only variant of a PoW algo, or by eliminating AuxPoW support entirely on the algo), and the rationale to reduce rewards for merge-miners.

Perhaps simply by rewarding native blocks at full CEM value and reducing block reward if it relies on AuxPoW with a mergeReduction factor, we could get pools to switch from merge-mining us to native mining us (so they could the full CEM reward rather than a mergeReduction fraction), but I think that's not likely. It's cleaner and fairer to have native-only and separate merge-mineable algos.

[jarr0s]

@dbkeys It pointless to discuss any further. Everything is already said. If you want me to implement above proposed fork, let me know here what are the exact parameters, and I'll try to implement it as soon as possible. Almost a month has been lost in a discussion. During that time around 150k to 200k BTM has being created from the thin air, and with every day discussing another ~6k BTM is created. Discussion time has expired, and now it is now time to react, while hoping it is not to late.

[dbkeys]

I agree. Can you please log on to Slack where we can make contact privately or my email: dbkeys@bitmark.io

[WitchDoctor-Six]

See on Slack @jarr0s

feel free to email me as well

devteam (at) bitmark.co

[dbkeys]

Here is what I suggest, based on your recommendations, to simplify things. Eliminate AuxPoW support on : { Scrypt, Argon2d & CryptoNote } These become native-only. (After all, SCrypt is our original algo, make it all native. Argon2d and CryptoNote have not much merge minining anyway, and keeping up with CryptoNote changes would be troublesome going forward. We can keep CryptoNote v7 even if Monero changes.)

The remaining 5 algos {SHA256d, Yescrypt, X17, Lyra2REv2 & EquiHash} maintain with AuxPoW support (they may be merge mined, or native mined, if someone want to pit their hashrate against a bigger parent chain hashrate) Pools have worked to integrate merge-mine support, we want to revoke AuxPoW on as few as possible.

The CEM rewards for mm-algos need to have a mergeReduction factor of 0.8 applied to the modulated portion in the case of mm-blocks. I'm leaving the CEM base unaffected by mergeReduction so that merge-miners can count on a minimum reward of 0.75 MARKS, regardless of what other merge-miners have done or how they affected the hashrate.

CEM itself needs to be adjusted too: NATIVE: Range of action: 80% Memory: 48 days // more forgiving MERGED: Range of action: 95% Memory 128 days // less forgiving CEM goes from v0.1 to v0.2

On the native-only algos set DGWv3 block time to 8 minutes (480 seconds) and the AuxPoW algos set to 40 minutes (2400 seconds). Native algos produce 5x faster than merge-mined algos, but there are 5 mm-algos and 3 n-algos, so overall this results in a 3:1 ratio of n-blocks to mm-blocks. ( Think about it this way: when 40 minutes pass, on average, each mm algo will produce 1 block ([total of 5 mm blocks in 40 minutes from 5 mm algos] but...... in the same 40 minutes the native algos will have produced 5 blocks each [because 40/8 =5] for a total of 15 blocks, since there are 3 of those native algos.
15:5 = 3:1)

Max emission of merge-mined coins is 7.4% of total max possible emission. (648 out of a possible total 8748 MARKS per day if CEM is at 100% for all algos)

[piratelinux]

I have one proposal that may help to unite us. Like I said, the goal of the protocol is maximize freedom for users, so let them decide. For each transaction, let users specify with a flag whether they support auxpow or not (can be no by default), and using these "votes" weighted by the fees they put in, you can decide dynamically what the merged to native ratio should be. To preserve anonymity of the votes, a hash of the vote should be sent and then actual vote revealed in the next transaction the user makes (don't reuse addresses if you want anonymity). This voting mechanism can by used for other purposes in the future as well. I would say the merged to native ratio can float from 99:1 to 1:99. Since people seem to be confident that most users are early investors, then the ratio will probably end up in 1:99 very quickly and it will dynamically change as the user base grows and it will depend on how well the dominant miners are treating the users. And no changes in total emission rate. Each miner will be rewarded the same amount based on the same CEM curve. Just ratio will change (the target time). That is something I can work on.

[dbkeys]

Overly complex. I have trouble even understanding exactly what is being proposed, even after reading 3 or 4 times. Except no change in total emission rate. That is a given. Basically we need a mining ecosystem where we would like to have the added security of merge-mining, it's enough to have somewhere between 20% to 33% of blocks merge-mined. But that number of blocks should not cost more than 5% to 10% of the emission because the blocks are very low cost, near zero cost. By paying 5% to 10% of the emission for them, we are acknowledging their value to the chain. That is a good bargain for the merge-miner, and a good bargain for Bitmark. No need to overpay for them.

[jarr0s]

@WitchDoctor-Six I couldn't join Slack, I have to have @bitmark.co address. @dbkeys I've send you an email.

[dbkeys]

I will send you an invite

[piratelinux]

@dbkeys then please read it carefully because it does exactly what is proposed, to reduce dominance of merge mining based on users (possibly investors) demand. It is not so complex to implement. But if you want to make it so that the total (pre-CEM) emission rate is modified, then I have no hesitation with calling it a scam.

[dbkeys]

You really need to do the excercise I have asked you: graph the emission rate. Simple to do, start at genesis block, on up to the tip. Record block time and cumulative emission. Graph it with gnuplot. I believe you will be surprised at how low the emission rate has been, and especially how far below that "theoretical" emission rate of 20 BTM x 720 blocks/day, then quartering to 15 MARKS x 720 blocks/day.
You are actually the one advocating for keeping an emission rate FAR ABOVE the pre-CEM emission rate. The REAL pre-CEM emission rate. Not the fairy tale rate which never happened.

[dbkeys]

People who use the coin "the users", the average users have no time to ponder & understand the intricacies of blockchain functioning, much less vote on it. Their vote would be fairly meaningless, IMO, if they even bothered to offer it.. A vote of stakeholders, where 1 MARKS = 1 vote could be interesting though. That could be set up, no transactions even need to happen. Just sign messages to an email with the address containing MARKS.

[WitchDoctor-Six]

In our efforts to maintain a variant 8 Algo Blockhain Ecosysyem, which fairly distributes MARKS.

I think at this point we Jarr0s is coding to keep AuxPoW only on Scrypt and Sha256d, and remove it from all other algos. so ratio of native:merged is 4:1 increase CEM to 90% range of action for all algos and put in the mergeReduction factor at 0.95, which will apply to the portion of the reward which CEM modulates for merge-mined algos (edited)

of course the "miners disagreeing" warning will be relaxed so it's not "crying wolf" all the time This is in the interest of getting it out fairly quickly; perhaps after he has seen the code, Jarr0s won't think it so complicated to proceed on the slighlty more detailed plan where we have the native and merged variants for each algo, and we can tilt the ratio toward the native variants. We'll see what he reports tommorrow in the current, simpler plan, merge mined blocks will range from 1.5 to 2.75 MARKS reward, and native blocks can range from 1.5 to the full 15 MARKS reward

- This is how we have chosen to move forward 1) increase CEM range so it is more effective reducing emission if hash rate drops 2) allow merge mining, but not so much that we lose our whole identity and independence. The idea of merge mining is that you get extra security from a higher-hashpower parent chain (plenty of those in the sha and scrypt ASIC world) so we are letting 1 out of every 5 blocks be merge-mined; but 3) because merge-mined blocks are near zero cost for the miner, they should not be payed the same as native mined. they really are near zero cost to them, BUT to us they have value, so we do reward them between 1.5 and 2.75 MARKS, (depending on CEM) this is the part Andrew just can't understand, and thinks is "scammy" etc. I also suggested that CEM memory be reduced from 1 year (365 days) to something like 45 days for natives and 120 days for merged this makes it a bit more "forgiving". Instead of remembering that there was peak hashrate nearly a year ago, it will forget that and grant the full reward again sooner

shortened it even more for native algos to protect agains an attack where you can imagine jealous merge-miners jacking up the native hashrate just for a day so they suffer lower rewards for the CEM period. They would have to do this every 45 days instead of every 120 days we could also protect against this by not expanding the native CEM range so much ... maybe 60% for native (instead of 90%)

[WitchDoctor-Six]

### The community has spoken and this issue is now resolved We will move forward and take action to bring about the change we feel is in the best interest of the Project, its Community and the Currency