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.

[dbkeys]

Thanks for your input. Your ideas have merit and certainly deserve thoughtful consideration. First impressions after first read are that reduced reward for merge-mined block is an interesting idea, it expands the CEM concept; One advantage of merge-mining is that the security of the chain is increased, it is much harder for a bad actor to mis-use a hashpower advantage.

[piratelinux]

I think merge mining is good because it increases the security of the chain, more hashpower, means less chance of wild swings in hashrate or being controlled by just a few miners. For each algo, the best miners in that algo will specialize in that algo and compete to provide the best security. Yes, price may be affected due to miners not being so loyal to Bitmark, and that can lead to Bitmark perhaps being in the hands of not so loyal holders, does possibly some negative effects. This is why I proposed (in a private discussion) to make the coinbase maturity longer for merge mined blocks, to give a market advantage to pure Bitmark miners. Making the reward less? I don't know if that's a good solution.

[jarr0s]

I partially agree that merged mining increase security. If some tries to buy hash power to attack a chain, he will have to spend a lot of money, and that attack would be unprofitable. But if couple of pool operators make agreement to attack the chain, they could do it with zero cost(This happen before). A lot more details in the document I've linked above. That is why I like Myriad solution, with just 2 of 5 merged mining algorithm.

Miners don't know they aren't loyal to Bitmark. They don't know that Bitmark exist. They are sending their hashes for some larger cap coin.

Making the reward less wouldn't affect merged mining. Because pool electricity cost is almost 0. Pool would mine as long there is any reward for them.

I don't see how increasing coinbase maturity would help with anything. Pool will just wait a little longer before selling the coins.

[dbkeys]

Removing merge-mine capabilities from a PoW algorithm, or implementing a distinct subsidy policy depending on whether a block was AuxPoW mined or not, necessarily imply a hard-fork. This is fine, and we anticipate there will be more hard forks down the road, but it is not something to be done lightly. Monero announced that they will be modifying CryptoNote protocol routinely to keep it ASIC-free, so if we wish to remain merge-mineably with them, we will naturally, have to adapt accordingly. We could perhaps introduce a 9th algorithm, with the specific purpose of being non-merge-mineable, not only remove the merge-mineability from other algos.

[piratelinux]

I'm pretty ok with setting a lower reward for merge mined blocks (like 50% of non merge mined reward). The only problems I see is

1) It can lower the hashpower. You may think that it's zero cost to merge mine, but there are networking and computing resources being used to do so, and 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.

2) Bad for environment? Punishing people (through opportunity cost) for wanting to use the same energy source to mine two chains.

[jarr0s]

Will adding 9th algorithm fix, mining centralization, possible mining pool attack, or negative impact on price. Maybe a little, but that would be negligible. Bitmark and Bitcoin are different categories, and it is highly doubtfully that Bitmark difficultly will ever reach Bitcoins, even with merged mining. But who knows? Bad for environment? If Bitmark is environment friendly coin than it should be POS coin. Punishing people? I see it differently. 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. What POW of coins gives value, after all is electricity spend to generate coin. It is not environment friendly but that is the way it is. What POS coin gives a value is a stake that every node has to have to produce a block. Now, what gives a value coin created for cost of 0?

[dbkeys]

@jarr0s, in your view, what would be an appropriate setup? and why ?
How many algos & which to be non-merge-mineable ? If we add an algo, which algo ?

Let’s number your proposals P1, P2 & P3, here paraphrased in italics.

P1: Reduce reward for merged mined blocks. Something like third of the regular mined block. This would have positive impact on price.

I like this, as it would be relatively simple to implement; and I agree with the reasoning that very low marginal cost to obtain the block should be equally rewarded. In this regard, I would suggest: 20% of the CEM modulated reward for merge-mined blocks.

Note: CEM v0.1 currently affects only 50% of the epoch max reward; I propose that CEM be extended: perhaps increased to affect up to 80% of the epoch max reward.
In an extreme case, this could result (in merge-mined blocks of algos experiencing very low relative hashrate) in a reward of only 0.6 MARKS per block, (instead of the 15 MARKS of the current epoch’s full max, although this is unlikely given the trends we have observed)

P2: Not allow every block to be merge-mined. Allow a couple of regular blocks before merged block can be solved again.

A hybrid like this brings up peculiar difficulties. This would negate the work of the diffalgo (DGWv3), OR would require maintaining two difficulties per merge-mineable algorithm, one for the string of merged blocks and another for the string of non-merge-mineable (or native-only) blocks.

Let’s take SCrypt for example What you propose here amounts to having, for example, a merge-mined version of SCrypt, with its corresponding difficulty, and a non-merge-mineable version of SCrypt, with another, distinct difficulty. Essentially, we must treat each instance, a) merge-mineable Scrypt and b) non-merge mineable Scrypt as if they were two different algorithms.

Let’s label the merge-mined version Sm and the non-merge-mined (or native) version Sn.
In 8mPoW Bitmark, each algo has a target inter-block time of 16 minutes, for a combined inter-block time of 2 minutes (Beta=120 seconds). In P2’s proposed refinement, where we want the ratio of Sm blocks to Sn blocks to be 1:2, Sm blocks should have an inter-block time target of 48 minutes and Sn blocks of 24 minutes. (Think about it this way: the day has 1440 minutes; with a 48 minute block time, Sm will produce 1440/48=30 blocks per day, and Sn will produce 1440/24=60 per day, for a combined total of 90 blocks per day)

If we wanted the ratio to be 3 native blocks : 1 merged block, then the block times should be 64minutes for Sm and 21+1/3 minute for Sn, or stated in seconds: 3840 seconds for SCrypt merge-mineable and 1280 seconds for Scrypt native.

P3: Only a couple of merge-mineable POW algorithms; the rest to be regularly mined. (Plus reward is reduced for merged blocks = P1 + P3)

This is relatively simple to implement, but would require making some difficult choices in regards to which algorithms will have merge-minining privileges revoked. As the most widely merge-mined algos for Bitmark are SCrypt, SHA256d & X17, I would want those to remain merge-mineable Argon2d is not much merge-mined, so it is easy choice to revoke merge-mineability Lyra2REv2 specific goal is to avoid mining centralization, so philosophically, this is a natural algo to exclude from the merge-mineable set, or at least allow very few (high Sn:Sm ratio)

What about EquiHash, CryptoNight & Yescrypt ?

Which algo to adopt for a 9th PoW algo ? Blake ? Keccak ?

[jarr0s]

Ok, here are my proposals with pros and cons:

P1: Reduce reward for merged mined blocks.

Agreed 20% is more than enough for merged mined blocks. Bear in mind that if every algorithm is merged mined, eventually nobody would mine just Bitmark, because block reward difference wouldn't be bigger than difficulty difference. So practically every block reward would be just 20% of reward.

Pros: This would have positive impact on the price. Cons: Pool mining centralization and possible pool mining attack remains.

P2: Not allow every block to be merge-mined. Allow a couple of regular blocks before merged block can be solved again.

Yeah, two difficulty adjustment functions would have to be implemented for every algorithm. Even 4:1 ratio will work because every 8 minutes high difficulty block would be injected. I would also decrease reward for at least 60% for merged mined blocks.

Pros: Fair mining, more people can mine Bitmark directly, positive impact on the price, no more mining pool centralization and possible mining pool attack.

Cons: Probably a little harder to implement.

P3: Only a couple of merge-mineable POW algorithms; the rest to be regularly mined. (Plus reward is reduced for merged blocks = P1 + P3)

Usually for merged-mined algos are used the one from the larger cap coins. So SHA256d and Scrypt definitely, and in that case should be Equihash, but X17 is also fine. There is no right or wrong answer here. More than 3 merged mined algos would be overhead. Other algos are regularly mined. Reward is reduced for at least 60% for merged mined blocks.

Pros: Fair mining, more people can mine Bitmark directly, positive impact on the price, no more mining pool centralization and possible mining pool attack. Easier to implement than P2.

Cons: -

If P2 or P3 solution is voted, I don't see a reason to add new algorithm. There is already 3 asics(SHA256d, Scrypt and Equihash), 3 gpus(X17, Lira2rev2 and Cryptonight) and 3 cpus(Argon, Yescrypt and Cryptonight) algos. So more than enough. Rather than adding new aglo, I would explore possibility of adding some staking reward simple POS or even masternodes to stabilize the price. But that is probably some other discussion.

If I have a vote, I would vote for P3, it is straightforward to implement and maintain.

[dbkeys]

Ok, so proposed v0.9.7.3 is shaping up be:

1) A more pronounced Coin Emission Modulation Policy. Instead of ranging over one-half the full epoch reward, CEM v0.2 will have authority over 80% of the epoch full reward.

2) Block Reward for Merge-Mined Blocks to be 20% of CEM v0.2 modulated subsidy value. The rationale is that Merge-Mined blocks are much less expensive to mine. And frankly, none of the stakeholders like the dive from the now steady block & coin productions

3) Proof-of-Work Algorithms which allow merge-mining would each have two variants: the native and the merge-mineable. This arises from the suggestion to "allow a couple of regular [native] blocks before merged blocks can be solved again." Native variants would be set to have a shorter inter-block target time than the merge-mined variants, and consequently mining will be easier for native blocks, resulting in more native blocks produced than merged. With distinct block times and difficulties, the desired ratio of native vs. merged can be achieved naturally. In addition, (analogous to the SurgeSupressor function), there could also be a policy which strictly disallows a merged block if there has not been a certain number of intervening native blocks.

4. Some PoW algorithms could have their merge-mined capability eliminated entirely, although with #3 above, this does not seem as important.

[jarr0s]

@dbkeys Do you have rough release date estimate of above changes?

[dbkeys]

We are coding now, and we want to start testing early next week. Work is happening on @piratelinux repo, dev branch (https://github.com/piratelinux/bitmark/tree/dev)

[dbkeys]

To be clear, we're coding to have 2 variants of each of the 8mPoW algos, the native variant (not merge-mineable, no AuxPoW) and a merge-mineable variant (AuxPoW-enabled).
This means we are not taking away anything, so that merge-mining operations that are supporting Bitmark can continue to do so, as they have been since v0.9.7.2 introduced AuxPoW merge-mined blocks. We are restoring all PoW algos to have native-only mining once again, which will be equitably rewarded somewhat better than merge-mined blocks. In effect, there will be 16 choices to mine Bitmark: 8 PoW algos in either native or merge-mined variants. ( n-blocks or mm-blocks) For now, we are coding to have block time targets for each variant the same: 32 minutes. (This is necessary to maintain the overall block times at 2 minutes) This means that the ratio of native:merged blocks will be 1:1 We could favor native blocks more by adjusting the target block times.

The question is: ¿ Should we favor the ratio of native blocks over merge-mined blocks ? For example to get 2:1 in favor of native, (ie, on average 2 native blocks out of every 3 blocks or said another way: there should be a couple native blocks before a merge-mined block comes out) the target times would be set to 24 minutes for native and 48 minutes for merged.

                             Target  Time           Target Time        (minutes)
  native:merged                 native              merge-mined
  --------------                -------             -------------
        1:1                       32                     32
        2:1                       24                     48
        3:1                       21.333....             64
        4:1                       20                     80
        5:1                       19.2                   96

It is possible even to adjust the ratio more finely, since the choice of time unit is arbitrary. (Fractional minutes would resolve in code to the closest whole second) For example, to set native:merged 1.618 : 1 target native block time would be 25.888752 minutes, or 1553 seconds, and target merge-mined block time would be 41.888 minutes or 2513 seconds.

                             Target  Time           Target Time        (minutes)
  native:merged                 native              merge-mined
  --------------                -------             -------------
     1.618 :1                  25.888752              41.888
     3.1416:1                  21.0929582             66.265

[jarr0s]

We can safely assume that every, or most of, merged mined block reward will end up on a exchange buy wall. If the ratio is 1:1 and merged mined reward is 20% of native blocks, than merged mined reward per hour is: 15(blocks) 3(reward) = 45, and per day it would be: 24 45 = 1080. So 10% of daily reward will be merged mined(created with cost of 0), and eventually end up sold on the exchange. Per month: 1080 30 = 32,400 Per year: 32400 24 = 777,600 This is ratio would still have a great impact on price.

With ratio 4:1, this numbers are little more bearable: Per Day: 6 3 24 = 432 Per Month: 432 30 = 12,960 Per Year: 12960 24 = 311,040 With 4:1, every 8 minutes should be one merged mined (high diff) block, so security wouldn't be affected much.

Eventually the ratio, it self, it is not that important for the price. Ratio can be 1:1, but the reward can be adjusted. If reward is reduced to 10% of native block, that would give merged mining reward similar to 4:1, but the chain would be more secure than if the ratio is 4:1.

My vote goes to 1:1, and merged mined block reward is reduced to 10% of the native block or less.

[dbkeys]

One concern is that if we lower the reward on merged blocks too much, pools and other miners might not bother to merge mine us. We do want the added security of merge mining.
Remember that Coin Emission Modulation is also in effect: Only when hashrate is at maximum (relative to recent past) is full epoch reward given anyway. If hashrate drops, reward will drop. This was done specifically to throttle emission when hashrate would indicate lower demand. Bitmark v0.9.7.3 will make CEM more effective, by letting it affect more than 50% of the epoch reward (We are also debating between letting it affect 75% or 80% of the epoch reward) I think that 10% of CEM reward for meged blocks might be too restrictive. 20% seems better to me, on the general 80:20 split principle. Bitmark is still in the distribution phase: we are in the 15 MARKS epoch (next epoch: 10 MARKS, then 7.5 MARKS) I think that price can best be helped by adding value to the coin, and that is where Marking, where we have only "scratched the surface" will really come in.

[jarr0s]

20% on what ratio 4:1 or 1:1? This makes a big difference on daily merged coin emission. To have a sustainable healthy price daily merged block emission has to be as lower as possible, taking in account not to jeopardize blockchain security. So the first question is what is the daily coin emission for merged mined blocks? And when that question is answered, than we could come with a number for block reward and block ratio. If daily merged coin emission is 10% of all daily coins, that in my opinion is too high. And the price will suffer. Pool might not bother to merged mine Bitmark. Pools are currently mining native Bitmark blocks for 1% or 2% block reward. For one algo it is about 10 BTM. And they are bothering with that. It is one dollar. So event if reward is just 1% they would certainly mine. It is a free money for them. Also bear in mind that if selling pressure is reduced they reward will also grow. For instance 15 BTM with 0.1 $ price is 1.5 $, and 1.5 BTM with 1$ price is also 1.5$. Pools will get the same money, as they get dumping it on exchange now, but the coin price would have space to breathe.

[dbkeys]

Native blocks are being rewarded at full epoch CEM value, while merged would be rewarded at epoch CEM value times a reduction factor ( somewhere between 0.1 and 0.25 is our discussion). So if ratio favors native, then more coins will be produced overall, because native blocks are not affected by the reduction factor. That's why I'm inclined to believe that an even 50:50 split is fine. Maybe the reduction factor for mm-blocks should be 10%, based on the reasons stated in @jarr0s' latest post: mainly that as "free money", (ie. if not free, really of marginally small extra effort), mining ops will still merge-mine Bitmark. If this could be objectively analyzed in more depth we could come up with a reasoned number (perhaps justified to be even lower than 10%), but in any case, I could go with 10 %

[jarr0s]

What ever you decide, it would be certainly better, than what we currently have. We all hope new fork will occur soon. There is tremendous pressure on the price.

[dbkeys]

It bears pointing out that the original coin emission schedule contemplated when the coin was launched 4 years ago has been modified. First, because of the past periods of sluggish block production (when blocks always carried the epoch max reward of 20 or 15) and now, because CEM v0.1 occasionally reduces reward for the different algos. With the proposed changes, strengthenging the reduction authority of CEM v0.2, and institituing a additional reduction for merged blocks, the full distribution of approximately 27 Million Bitmarks will be pushed further into the future than was originally contemplated. CEM's purpose is to match coin production with coin demand, so I think this is a proper thing, and that coin emission will now obey demand and not any fixed schedule. Total coin emission has always been strictly respected. What is being met on schedule is the processing of transactions. Since v0.9.7.0, blocks have been flowing smoothly onto the Bitmark blockchain, and blocks of transactions processed, on average, every 2 minutes. By decoupling emission from block production, CEM allow blocks to be added on schedule without over-producing coins.

[piratelinux]

Sorry I didn't reply for a while but I was discussing this privately with @dbkeys and working on the fork code in my repo. I think we agree on everything except for one critical issue. It seems @dbkeys (and perhaps others) want to reduce the maximum reward for merge miners without proportionally increasing the reward for native miners, and thus reduce the rate of the total supply creation. I cannot agree with this.

I think we have several options that we can apply simultaneously or just choose from:

1) Increase the target time for merged mined blocks relative to native blocks so that they come at some ration like 2:1 or even 7:1. It shouldn't impact security because it will result in a higher difficulty for merge miners even though they produce blocks less often. The only drawback is slightly more block confirmations needed to be sure you are on the right chain. Though we already sort of have this system with algos. If you really want to be sure you are on the right chain, you will want multiple confirmations from the whole spectrum of algos and you will want to be on the chain that has the most proof of work, looping over each algo. If you there are 2 chains A and B with one algo having more work on A and another algo having more work on B, then there is ambiguity.

2) Yes you can reduce the max reward for merge miners, but then you need to proportionally increase the max reward for native miners (so have native miners possibly mining more than 15 marks a block), in order to make up in the loss in supply. If you don't do that then you are changing the reward schedule of the system. I think it is dishonest because if someone can do that then they can just wait for price to go up with reduced supply flow, then quickly sell. Yes eventually we will reach the same limit, but it is delayed in order to facilitate their "profitable" exit from the system. And even if this does happen I am sure price will not even go up significantly, but that's not the point of the debate.

3) We can use a different modulation curve for mining rewards relative to current hashpower. Currently we use a linear curve. We can use a quadratic one like f(x) = b (x/p)^2 where b is the base subsidy (15 marks now), x is the current hashrate, and p is the peak hashrate. This quadratic will result in less of a reward than our current linear one (except when x=p) and we can also set a minimum, so make it f(x) = min(0.25b,b(x/p)^2) for merge miners. For native we can keep it as is or also apply a quadratic. It is good because it is a simple function but nicely encapsulates the idea that mining becomes harder and harder as you reach the peak, so each equal unit of "step" upwards gets rewarded a bit more.

I think a simple solution is to use a 2:1 ratio for native to merged and apply a quadratic for merged as mentioned. That will effectively scale the merged reward by (1/3) plus a tighter CEM modulation. Say you have a typical x/p = 4/5. Then (4/5)^2 = 16/25. So (1/3)(16/25) = 0.213. So merged will then make 20% of what it currently makes. We can increase the ratio for 2:1 to something else I suppose, just it makes the need for more confirmations a bit more important.

I don't control the releases here, but I can't agree or commit any code that I believe will harm the decentralized and incorruptible nature of the protocol. I hope we can come to a consensus!

[melvincarvalho]

The total coin emission should be kept constant. That's a no brainer for consenus.

Of course the code can bet a bit tricky with the algo change and enabling wallets in good time. But it's better in the long run to get right. Our main advantage over other coins is that we have done things the hard way with no premine, no ico and community driven parameters. Over time this will show a strong track record, which is worth having!

[dbkeys]

The total coin emission contemplated over 18 halvings and quartering to an amount of some 27 million Marks would not change. Coin Emission Modulation seems to have been well received, and in v0.1 is rather mild, acting on only 50% of the epoch reward (currently 15 MARKS), so it only modulates 7.5 MARKS proportionately to current/peak hashrate. When we opened up to merge mining (on all 8 algos) I did not contemplate the down sides, pointed out kindly by @jarr0s in this paper: https://eprint.iacr.org/2017/791.pdf

[dbkeys]

The proposed solution is to separte the merge-mining from the "native" mining by setting different block time targets for each variant, and each regulated by DGWv3. In effect, creating 16 "virtual" distinct minable algos.
But, the heart of the decision we must take is whether to allow merge-mined blocks to reach full epoch block reward, or to limit them, because they are merge mined, aka the by-product of an already-existing parent chain mining operation, and so much less costly to mine than native blocks. To me this seems like an equitable propostion. Logically, just like CEM does, this shifts the complete distribution of the ~27M MARKS further into the future compared to what the distribution rate would be without it. The truth is that the original distribution schedule has not been followed, because of the very slow block production we had in the past. Now that DGWv3 has remedied the regularity of blocks being found, even with CEM v0.1 we have more coin production than ever before.
So I propose that A) we strengthen CEM into CEM v0.2, letting it act on 80% of the epoch block reward for native blocks and 99.73% of the epoch block reward for merge-mined blocks. (This number comes from the percentage under a 3-standard deviation normal distribution: https://en.wikipedia.org/wiki/68–95–99.7_rule) Also, to make it a bit more forgiving, by granting it only a 3 month memory, vs a 1 year. But for merge-mined blocks, and herein lies our question, I believe they should never reach the same reward that native blocks can, because they are produced at much lower cost. So I propose that as well as the CEM v0.2 reduction: B) merge-mined blocks be reduced by a _mergeminereduction factor of 1/3 Naturally, just like CEM does when it is in effect, reducing the reward, this reduction would further shift the completion of the distribution of the total emission further into the future. This is what concerns @piratelinux . I opine that it is no problem, because the total emission will be achieved in the future, and these proposed reductions are well grounded, and reasoned. Even so, when if they are in effect, our coin emission will be greater than it has been the last two years because of the clockwork-like regularity which the chain grows now, thanks to DGWv3.

[dbkeys]

So the question are: 1) how much to let CEM range over the native and merge mined variants (I propose 80% and 99.73%), 2) How much to reduce reward of merge-mined blocks because they are of much lower production cost than native blocks. I propose somewhere between 66% and 80% reduction, @piratelinux proposes 0 reduction in this regard. And 3) whether to tilt the proportion of native: merge-mined blocks. (Note: this could be done evenly across all 8 algos or set individually by algo on its two variants)

[dbkeys]

To address @piratelinux concern, native blocks could be favored 2:1 over merged blocks, for example, by setting different target block times for native algos vs. merge-mined algos resulting in an agregate of 2 minute blocks as always. This results in the emission rate potentially getting close to 80% of the originally envisioned rate. That said, I reiterate, I really do not see a problem with reduced emission rates, as long as the eventual total emission will be reached. That was in fact the intent of CEM: to decouple coin emission from block production (where before the were strictly linked) so as to reduce emission (when it is warranted by low demand) . One upside of reduced emission rate is that the potential uncertainty of sustaining a network just on fees is delayed into the future, because the minable coin supply is protected: it is not wasted by needlessly being issued when demand is low, (as evidenced by low hashrate.)

[jarr0s]

I don't see a problem in reducing coin emission. I as a miner would receive less coins, but that coins would probably worth more. If merged mined coins (free coins) aren't reduced to some tolerable amount, the price will continue to suffer. Taking in account that BTM is still in high yearly inflation merged mined coins shouldn't be more than 5% percent per day.

It seems that this discussion will consume much more time. Time this coin doesn't have now. Are you aware of this: https://medium.com/circle-blog/asset-delistings-on-august-2nd-bff3018c6555

This coin needs some solution for merged mined blocks, and it needs it yesterday. The simplest and quickest is the best. That is why I proposed to leave merged mining on just 3 algos, and reduce their reward to 10%, 20%, whatever. This could be probably implemented in just couple of lines. When the hole is plugged, we could discuss about new ideas as long as we want.

[jarr0s]

Also, merged mining in crypto, is more or less considered as outdated now. In theory it sounds good but in practice it never really reached the expectation. There are much better solutions to protect the chain now. For instance using Komodo notary service. Komodo notary service notarizes every couple of blocks, and eventually that notarized information saves in bitcoin blockchain. So if someone wants to attack the notarized chain, he will have to attack bitcoin as well. The best thing about Komodo notarization is that is free (or something really small). It beats merged mining on security and the cost. There are other solutions, but they require a lot more infrastructure to build around the chain.

[piratelinux]

@jarros I just read about Komodo. Basically investors of komodo elect people to do the notarization and what's the big deal that it gets stored on the Bitcoin blockchain? This is basicaly a proof of stake security mechanism and I can show you many weaknesses with this if you want. We have here 8 independent algos securing the blockchain. A miner's best strategy is to specialize in one algo, because mining is a low profit margin game, so it is unlikely for one miner to control multiple algos (only 1/8 the hashpower). Merge miner's have some incentive to care about Bitmark as they need to hold it for at least 720 blocks...

What does the circle article have to do with Bitmark? Volume actually gets higher due to increased flow of supply, which is what exchanges like and is good for liquidity for buyers/sellers.

Still don't see any response to my issue with how changing the mining rate (even though total supply will remain the same) cannot be abused by people looking for a temporary boost to cash out. And how exactly is price so important to the functioning of the system? You are willing to compromise the system for that? Like @melvincarvalho said I feel like it is a no brainer, but always open to well reasoned arguments.

[jarr0s]

Komodo block notarization prevents any possible double spend, because every notarized block act as a checkpoint. Couple of larger cap coins already adopted komodo notarization, and for now it proved successful. Anyway, it was a just a side note, I don't want to expand this discussion further.

Miners have just one strategy, and that is money. They don't care about a coin. Merged miners have specialized in only one thing, and that is dumping free Bitmarks on a exchange. If a merged miner starts mining today, yeah he will have to wait one day to dump it on exchange, but after one day he will have constant influx on new coins that he can immediately dump on exchange.

What does the circle article have to do with Bitmark? Circle just delisted couple of coins with larger market cap of Bitmark from their exchange. If the price of BTM continues to drop like a rock, guess which coin would be on next that list. Time is ticking.

I don't see how reducing mining rate would be just a 'temporary' boost of the price. It would be constant boost of the price, which would be opposite of the current situation, when there is constant attack on the price. Even current emission is fine, as long as it is not dominated by merged miners.

[piratelinux]

Miners have just one strategy, and that is money. They don't care about a coin. Merged miners have specialized in only one thing, and that is dumping free Bitmarks on a exchange. If a merged miner starts mining today, yeah he will have to wait one day to dump it on exchange, but after one day he will have constant influx on new coins that he can immediately dump on exchange.

Yes of course, just as for native miners merge miners typically want to cash out they are not expected to be "users" of marks. But they will be less likely to cause double spend attacks if they have to wait 720 blocks for their coins to mature. So my point was about the security of merge mining.

I don't see how reducing mining rate would be just a 'temporary' boost of the price. It would be constant boost of the price, which would be opposite of the current situation, when there is constant attack on the price. Even current emission is fine, as long as it is not dominated by merged miners.

Well what some have proposed that I disagree with is to slow down the overall rate by reducing the max merge mining reward without compensating for that with an increase in mining reward for native mining. This will slow down the rate, though as we go further into the future it won't matter as we will keep decreasing the rate according to schedule and we will still reach the same total amount. The good thing is you said "Even current emission is fine, as long as it is not dominated by merged miners." which I agree with. Like I explained in my points, there's various ways to reduce the dominance of merge miners, but it doesn't mean we have to change the rate of total supply creation. So maybe we can move the discussion about that to another thread.

[dbkeys]

I think that we have to agree that merge-mined blocks are of lower cost to produce than native blocks. Since that is true (no one denies it) they should be rewarded less than native blocks. That does not mean that the difference from full epoch reward has to be issued somewhere. Much better for the algorithm to keep those coins in reserve, to be issued in the future as mining demand calls for them. Of course lowering block rewards prolong completing the emission. That was an expected, by-design consequence of CEM, and likewise something we must accept when we allow merge-mining.

So, if we want to have the extra security of merge-mined blocks (we do), AND if we acknowledge that they are lower cost to produce blocks (no denying it), we have to accept that the full emission is going to be deferred a bit more. That's just a consequence of having and paying for cheaper-to-produce blocks at an the right price. A slower emission rate is a good thing. There is no dishonesty and nothing underhanded is going on. Its not arbitrary; there are justifying reasons for it. The full emission will be reached.

CEM lowers emission if there is lower hashrate. Fine. Merge-mined blocks are rewarded less because they cost less to produce. Equally Fine.

The emission hasn't kept to the rate that was estimated once-upon-a-time when the coin was launched. That schedule was just "this is what the emission rate will be at 720 blocks / day." But it has not adhered to, because blocks were very irregular. So now , to try to force meet it "just because" doesn't make sense and is counterproductive.
I bears repeating that we have actually increased emission rate from the historical lows, (even with CEM and even with a specific merge-mining reduction), and that the rate of total supply creation is and will be greater than it has been in the past.

We adoped CEM after much discussion and input, knowing that it would mean a longer time to reach full emission. This was expected & accepted. Now we have the extra security of merge mining, and we acknowledge that these are cheaper to produce, so we need to accept a longer time to complete emission. Which is in fact desired by most of us. It's time to move beyond this discussion and just implement it.

[piratelinux]

@dbkeys I think this belongs in a different thread but one thing that should be noted is that the amount of reward does matter for merge mining. I didn't think of this before. But the larger the reward given to merge miners, the more they have to lose by doing a 51% / double spend attack, so is it worth giving them less of a reward relative to the native miners even though it reduces security? What is the justification for doing that? I think every block should have the same max reward, just put a higher target time for merge mining blocks to make them less frequent, and change the min reward a bit.

Also the paper about merge mining, I didn't read it in full detail but what I saw is a bunch of experimental data, that can be interpreted in various ways, without much theoretical backing for the claim of centralization by merge mining.

[dbkeys]

It's a good point, but if they have any stake, even a small one, why would the merge miners want to do harm at all? They would be damaging themselves, whatever size reward they get . I was reading about Marginal Cost (https://en.wikipedia.org/wiki/Marginal_cost). For merge-mininig, most of the costs are fixed costs which don't even enter into a marginal cost consideration, because those don't change at all. (Same hardware, basically) The marginal costs would be extra storage for the Bitmark blockchain data, and processor cycles and network bandwidth for the node. Truly small. So if arguendo, ie: just for the sake of argument, you did agree that merge-mined blocks should only be rewarded the marginal extra cost of mining them, what would you estimate that to be ? A single machine mining could probably merge-mine 10 or 100 additional currencies without noticing any extra load.

[jarr0s]

Risking to prolong this discussion even further I'll give my comment.

First of all double spend attack doesn't have anything with waiting coin blocks to mature. Double spend attack is following: Someone accumulates large amount of coins. In this case Bitmarks. Sends those Bitmarks on exchange, and immediately starts mining hidden side chain without that transaction, but with more pow than visible chain. Dumps Bitmarks on exchange to BTC, and initiates BTC withdrawal, when there is a BTC withdrawal transaction on network, he makes hidden chain public. Thus removing BTM transaction to exchange, and thus getting in possession of Bitmarks and Bitcoins. So if coin maturity is 720 or 72000 it doesn't make any difference.

Again, miners don't care about coins, they care about profit. If they have opportunity and knowledge to do a double spend attack they will most certainly do it. Even if the reward is 1 BTM, 15 BTM or 150 BTM. It doesn't matter. With merged mining is even simpler because there are just a couple of big pools, they can very easily make an agreement.

What exactly pool have to lose if they perform double spend attack? One day they perform double spend attack, accumulates some BTC, and the second day they just continue merged mining and usual dumping on the exchange. So what is they stake in the system? There is none, except to maximize the profit. Thats all.

Merged mining is now ancient technology in crypto, that proved disastrous for any coin that implemented it. Bitmark is one of them. There is no coin in first 300 coins (or even more) on coinmarket cap that is merged mineable. It doesn't increase security and it kills the price.

If you don't like Komodo notarization, there is currently ZenCash 51% attack proposal that looks very promising - https://zencash.com/assets/files/A-Penalty-System-for-Delayed-Block-Submission-by-ZenCash.pdf. The idea is to penalize delay published blocks, so for instance if block is delayed for 3 block his pow work is calculated with decrease factor, the more block is delayed his decrease factor increases. As a factor increases soon it becomes impossible to mine long hidden chain, that will overwrite public chain. This or any other new 51% attack proposal can easily been implemented in any chain and it doesn't cost a bunch of coins just given to some pool, and hopping that pool will behave nicely.

[dbkeys]

@Jarr0s: specific recommendations then in regards to Bitmark merged mining? Keep only 2 or 3 algos on merge mining? Lower mm reward by what % ?? ?? What is the ideal situation for Bitmark mining, in your view ?

[piratelinux]

Ya I don't want to waste too much time on double spend attacks. But I think it is clear that a miner will be less likely to double spend the more stake he has in the currency. To be safe, an exchange, or anyone receiving coins shouldn't receive more than the block reward in one transaction. That can ensure some degree of safety (block reward = fees + subsidy). If the miner's stake (block reward) is more than the amount double spent, then why would he want to double spend and mess up the value of the currency he has stake in (this is kind of the argument in the Bitcoin whitepaper). And ya pool operators can attack blockchains but individual miners are always free to pull out, just like with any other PoW blockchain, native or merge-mined.

As for the Zencash idea it relies on monitoring the network for delayed submission. Someone synching from scratch will never know how the network behaved in the past, so you lose some nice properties of the typical Bitcoin protocol.

Seriously if it were up to me I wouldn't rush this hard fork. I would just hard fork 2 technical fixes we need and can do quickly. The whole merge mining concerns seem low priority for me while we have a lot of work to do with getting up to date with Bitcoin 0.16 and building the a proper marking protocol. We worked hard on the previous fork and I think we currently have one of the safest blockchains available. Splitting up into merged and native seems interesting and even may add some security, but complicated and distracting from more fundamental issues, especially all the boundary conditions that need to be added for transition from fork 1 blocks to fork 2 blocks. Mining pools and the community are just starting to get used to our system...Does anyone else feel this or I'm the only one?

[jarr0s]

@dbkeys I already said couple of times, the simplest and the quickest is the best. Because you don't have much time. In my opinion you can go with just 2 merged mined alogs (like Myriad), and reduce reward to 20% of native block. Or you can go with 3 algos and reduce reward to 15% percent. This gives daily merged mined emission of 5%. This is tolerable. Anyone can make this changes in just couple of hours and then you can publish new fork as soon as possible.

If you go with 8 native and 8 merged mined algos, that would require a lot of programming and testing time. Time you don't have. It would also prove living hell to maintaining all those alogs.

[jarr0s]

@piratelinux As already pointed out a couple of time, merged miner doesn't have any stake in a currency.

To be safe, an exchange, or anyone receiving coins shouldn't receive more than the block reward in one transaction.

I don't know how to comment this.

In ZenCash proposal time is measured in blocks. It is still a proposal and I don't feel like discussing it now.

If you don't act quickly, you will get even safer blockchain. You will be probably more safer than Bitcoin. Why? Because this coin will become worthless. And no one will attack worthless coin. Currently around 6K of 10k daily coins are just dumped on exchange buy wall. That is enormous sum. Price will go down. The only thing keeping the price even at this levels is Poloniex. It is a big exchange, and there is a lot of volume there. If the price keep falling Bitmark market cap will fall below 1 milion, and then Poloniex will delist Bitmark from the exchange. After that Bitmark will quickly fall near 0. There is always some speculators out there to buy at 1 sathoshi. To be perfectly clear the biggest value of this coin currently is exchange. You lose that, you've killed the coin.

[piratelinux]

To be safe, an exchange, or anyone receiving coins shouldn't receive more than the block reward in one transaction.

I don't know how to comment this.

Let me make that more clear for people reading. If you want to receive 100 BTM and the block reward is 10 BTM, then you should idealy wait 10 confirmations to be sure that the cost for the person to double spend is more than the gain of the double spend. With multi algo it gets even harder and these are just rough estimates. But the point is that the security of the chain is proportional to the reward given to miners (whether they are merge mining or not).

[jarr0s]

LOL. This is getting hilarious. So if I want to send 1000 BTM (100$) I'll have to wait 100 confirmation 3,3 hours. And if want to send 10000 BTM (1000$) I'll have to wait day and a half. Why would anyone use a blockchain with such a properties?

But it still doesn't make any sense. I think you still didn't understand what is double spend. Mined blocks aren't important. And the value mined is always negligible. Also during double spend attack all the block mined will eventually belong to the attacker, so there is no connection between cost of double spend and block reward, whatsoever.

How can you develop a blockchain not knowing how double spend works?

How old are you? I'm getting impression I'm having discussion with a kid?

You made a mistake and now you would rather let whole project sink, as long as you don't have to admit and fix your mistake. Grow up.

[piratelinux]

I don't want to sidetrack the discussion to make a full lecture on double spending and rewards. We can make another thread for that if people are interested. But I already stated my point about reward being important for security and I can prove that as well if it's still not clear.

I'm old enough to have been passionate about Bitcoin and decentralized consensus since 2011. No need to get into personal details. I do not think I made a mistake, I helped develop a fork of Bitmark that was successful in it's purpose, there are only 2 small bugs I would like to fix with a hard fork. But reducing merge mining dominance looks like it will reduce security from my point of view and I cannot accept to waste more time tweaking the protocol when we have more important things to do. But of course you don't care, that's fine keep spreading the FUD, let people decide, I don't control anything over here.

[jarr0s]

I think I heard enough nonsense about double spending. I don't have strength for separate thread.

No offense, but most of the time you sounds like complete rookie. I can't comprehend how everybody but you can't understand, that current implementation screw ups miners and investors, and rewards couple of large mining pools with free money. How possible that can be good for the coin? Not to mention security is reduced, and not increased.

But you said one right thing. Let the people decide. If this is decentralized community driven project, than community should decide. Someone should create a poll, with a question should free BTM coin giveaway continue, or it should be reduced to reasonable measure.

[dbkeys]

I take exception at calling the proposals "a recipe for a scam". A scam is an intent to defraud. If anything, it's all the oppostie. They are proposals to make the mining system more equitable, by rewarding merge-miners in proportion to their efforts, (just as CEM is equitable by rewarding miners proportionately to the max effort we know they can make.) If anything, we are going to protect all the people who have invested in Bitmark. It's a fact that the emission rate was very low for many years. That was the real emission rate. The theoretical stuff posted never happened, so we are actually addressing a flaw that Fork 1 created. Adjusting the emission rate, with well understood, reasoned and justified means towards where it had been for many years.

[dbkeys]

My current thinking is :
Keep merge-mining on all algos, because pools have already worked to adopt Bitmark, linked it to parent chains, etc., and we don't want to waste their work and renege on the promise of merge-mineability; but, apply a further mergeFactor reduction to the CEM 0v2 part of the reward for merge mined blocks. mergeFactor = 0.1 , AND: Bring back native-only mining on all algos, for a total of 16 "virtual" algos: 8mPoW base algos with 2 variants each, a native and merge-mineable. Further, calibrate DGWv3 for each algo so that native algo blocks occur in a 2:1 ratio to merge-mined blocks. [ This is easily achieved. For Native algos, set target block time to 24 min (1440 seconds) block time, Merged targets 48 minutes (2880 seconds). ]

In a nod to @piratelinux, CEM v0.2 will have some differences between native and merged: The fraction of the epoch reward over which CEM acts, (its range) is 90% for merge, and 67% for native; The look-back time-frame window from which CEM finds the peak rate to use as the denominator in the SSF factor would be reduced for both, from 365 days in current CEM v0.1 down to:
A) 4 months (120 days) for merge-mined blocks and down to B) 30 days for native blocks.

This measures would mitigate to some degree the potential attack that high-hashrate merge miners could inflict on native miners by temporarily mining the native chain for a day, and then leaving, artificially inflating the denominator in the current/peak SSF ratio.

And, it means that: if the all miners are at max CEM look-back period capacity, emission rate could get up to 50% of the rate advertised in the original post, (which in the 15 MARKS epoch is 10,800 MARKS / day if every single block was rewarded at 15 MARKS). And, again, it bears repeating, that for years even, in times past, the actual rate of emission was 100 BTM or 80 BTM /day, which was less than 1% of the "theoretical" emission rate which was in fact never delivered on. IMO, it's silly to have any kind of allegiance to that theoretical rate, first because it wasn't real, it was not adhered to and further because most people who care about it and holders of the coin welcome rational measures like CEM to avoid producing coins the market isn't calling for.

[dbkeys]

If my calcs are right, in this scenario, native blocks would contribute between 87% and 91.3 % of the emitted coins, and merge-mined blocks would contribute between 13.7% and 8.7% of the emitted coins. The actual numbers are:

Daily Emission:                Min               Max
        Native:               1,600            4,800
        Merged:                 240              456
                             --------         -------
         Total:               1840              5256

I think these numbers also address the concerns posted by @jarr0s

[dbkeys]

Time Frames: I think we can have this coded in the next 4 or 5 days, and tested and polished within a couple of weeks, ready to go.

[jarr0s]

I don't think you can pull such a big change, in such a short time, and to be bug free. But I could be proven wrong.

[WitchDoctor-Six]

I/we have always sought to do what is in the best interest of the Project & Community. I firmly believe that we are on the right path and our work has and will continue drive toward the goal of establishing a web-scale reputation framework. @melvincarvalho is correct to state that our integrity and commitment to doing so organically is imperative we move forward. @akrmn I doubly commend your work and I truly appreciate that you stepped up to be one of our leads dev's. Obviously we want to continue working together in developing what will be a great reputation system. Let us first address our oversight, we should ensure "Native Miners" maintain the larger stake in Bitmark, as this will be of greater consequence to the project. Allowing 'Merge-Miners' to acquire Bitmark at the rate they have been does not seem responsible to me, because it places more MARKS in the wallets of those who care little of Project Bitmark and more about their profit. Let us place more Bitmark in the hands/control to those who want and care about the Project's long term outcome...does this not provide security to our long term goals? I think it would. I truly appreciate that we have been able to have civil discourse about the direction we are taking and I agree with @akrmn in that we cannot do this alone. Let's find a middle ground guys, strengthen the blockchain and move toward "Marking" as a web-scale reputation system.

[piratelinux]

It appears that some people here think that they are working in the marketing department of a corporation, working hard to raise profits for shareholders. Or maybe they just want to raise funding for development. In that case why not start a crowdfunding campaign or start a fork called "Bitmark Investments" and leave Bitmark the protocol alone. There's even a guy on bitcointalk.org that offered $50000 for development possibly. A discussion about improving the protocol of decentralized framework should never include the words "price" and "investors". Do I have to state the obvious? Or just say you want to transition from a PoW system to a PoS system, then fine, but that adds centralization and changes the original path of the protocol.

Like I said I still believe that reducing the influence of merge mining will reduce security since we will have less hashpower preventing big centralized players from manipulating. I actually think we have a beautiful system working security wise... And even if we are removed from an exchange (unlikely) we can still function perfectly well, I can even create my own exchange or trade on a decentralized exchange with atomic swaps. But if we can't pass the greed and fear stage and there's no developers/users pushing to save this, then what can I do. I can try to operate my own fork if I have enough power, maybe that will even raise the price because there will be 2 coins early investors can choose to sell on. But I can't work on something that I don't fundamentally believe in.

Centralization works great, except when you really need it, and then it doesn't.

[jarr0s]

I'll say it completely free this time. I think this kid is retarded. There is no other explanation. Like what are you saying? You want price to go down, to 0. You will build your decentralized exchange? Who will trade on your stupid retarded exchange?

Decentralized blockchain always include the words "price" and "investors". Bitcoin as a protocol is build on three pillars. Developers, miners and investors. Miners are compete to resolve a block to get something of value. Here it doesn't have a value because it is created from the thin air. Investors are buying coins because they are hopping the price of a coin will rise. Yes because of the greed. Thats how it is. Who will buy this shit if it continues to go only down. And developers are developing a project to make community (miners and investors) happy. You can build the best protocol every, but if there is no community, you don't need blockchain, you can build everything as a sql database.

Please fork a chain, and go away. This community doesn't needs such a retards.

[piratelinux]

What the troll above just said in case someone didn't notice is that community = miners and investors, while in reality community = only users. Miners are incentivized to give security to users. Investors are free to buy and sell as they want, but it is their responsibility to understand the protocol and calculate the risks. The purpose of the protocol is to maximize freedom for users, no one else. Can someone please find me a Bitcoin Improvement Proposal (BIP) that mentions the words "price" or "investor"? Of course for scam-coins, these things are reversed. Also, for Bitmark, as I understand, the purpose is not to create a "coin" for buying/selling goods but a meaningful web of trust, with well thought out incentives to stimulate user demand for creating these special kinds of blockchain transactions.