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

[dbkeys]

Request for Proposals (RFP)

Fellow Bitmarkers, please check the discussion on merge-mined vs. native mined here:

Native Mining and Merge Mining

 I would like to get some opinions on: ¿ Should we favor native blocks over merge-mined blocks ? , and if so, in what ratio.

We're coding the proposed Bitmark v0.9.7.3 fork 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).
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)
The question is: ¿ Should we favor the ratios of native blocks over merge-mined blocks ?

Here are a few possible ratios of native:merged and the resulting target block times.

              Ratio                  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

[TeamBitmark]

Poloniex.com

Bitmark (BTM) (MARKS)

Deposits & Withdrawals are now fully functional.

Many thanks to the Poloniex team !

Bitmark at Poloniex.com

[82ndabnmedic]

Poloniex.com

Bitmark (BTM) (MARKS)

Deposits & Withdrawals are now fully functional.

Many thanks to the Poloniex team !

Bitmark at Poloniex.com

Amazing Work Guys!

Extremely pleased with how our DevTeam has stepped up and made this happen...We are now on track, we have set goals and deliverables for the remaining QTRs and we should have a timeline out soon-ish. The core updates take priority as we all know...then we need to address the final touches on the website ans move forward with implementations, marketing, etc

[Matiel]

BTM is currently under maintenance or experiencing wallet issues. Deposits and withdrawals will remain disabled as we work to find, test, and audit a solution. Thank you for your patience in the meantime.
 
unbelievable

[Matiel]

Poloniex.com

Bitmark (BTM) (MARKS)

Deposits & Withdrawals are now fully functional.

Many thanks to the Poloniex team !

Bitmark at Poloniex.com

did not last 15 days

[TeamBitmark]

BTM is currently under maintenance or experiencing wallet issues. Deposits and withdrawals will remain disabled as we work to find, test, and audit a solution. Thank you for your patience in the meantime.
 
unbelievable

Reaching out to Poloniex now....we will need to ensure Polo provides us notice prior to placing the wallet under maintenance again

[Matiel]

BTM is currently under maintenance or experiencing wallet issues. Deposits and withdrawals will remain disabled as we work to find, test, and audit a solution. Thank you for your patience in the meantime.
 
unbelievable

Reaching out to Poloniex now....we will need to ensure Polo provides us notice prior to placing the wallet under maintenance again

what's the problem

[AnfisKatechkin]

What happened to Bitmark? Why it has fallen so significantly when it always cost about 10k satoshi?

[dbkeys]

What happened to Bitmark? Why it has fallen so significantly when it always cost about 10k satoshi?

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

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

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

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

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

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

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

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

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

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

[DEVTEAM_MARKS]

What happened to Bitmark? Why it has fallen so significantly when it always cost about 10k satoshi?

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

We SHALL take action NOW!

[82ndabnmedic]

What happened to Bitmark? Why it has fallen so significantly when it always cost about 10k satoshi?

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

We SHALL take action NOW!

Sorry I meant to post that under my personal account:


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

We SHALL take action NOW!

[Robin37s-]

new team for bitmark？

[insosub]

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

[onelineproof]

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

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

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

[tync]

I understand that those who now manage a coin want to stop the coin's depreciation. for this they want to use centralized methods. and the original developer does not agree to a centralized solution. correct if I do not correctly understood the situation

[coinzy4]

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

[dbkeys]

.....

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

.....

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

[dbkeys]

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

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

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

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

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


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

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

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

the quicker the reward halves the more unstable the coin and unfair the distribution, and the more likely it will be considered and act like a project/currency with no longevity.

Slow block halving reduces urgency to mine and allows more natural growth and adoption. There is no unfair benefit to mining on day 1 as opposed to day 400

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

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

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

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

As always I welcome thoughtful input and suggestions.


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

[onelineproof]

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

Now if you look at the original announcement thread of Bitmark https://bitcointalk.org/index.php?topic=660544.0 you can see that it says:

Project Bitmark is an initiative to create an every day use alternative currency. No premine, no IPO, nothing unfair, no scam, no clone, no old code bases, no untested code, no token features, just what you need.

Similarly on the webpage bitmark.io it says

Bitmark is a powerful decentralized reputation platform

One of the main PR guys (82ndabnmedic) says

we are a volunteer group, fully decentralized and organically grown.

https://bitcointalk.org/index.php?topic=3169983.msg40969748#msg40969748

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

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

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

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

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

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

[dbkeys]

I understand that those who now manage a coin want to stop the coin's depreciation. for this they want to use centralized methods. and the original developer does not agree to a centralized solution. correct if I do not correctly understood the situation

Hmm, not really.  First, @onelineproof is not the original developer.   But most importantly,  the changes the project is contemplating now would have a de-centralizing effect.

I recall it this way:

In years 2015, 2016 and 2017, Bitmark had a very low emission rate and block production rate, beacause it was often stuck with very high difficulty when miners came and went: (the "multipool" problem).
The original diffalgo only adjusted difficulty every 720 blocks. (The "Multipool" problem was solved with DGWv3 diffalgo).  @onelineproof was contacted in January of 2017 to help implement changes and improvements that were originally discussed in Slack and were memorialized here:   Bitmark Hard Fork (April 2017) and design objectives finalized here: Hard Fork 1 Criteria (May 2017)  

(Note: The originator of the project and original developer, @coinsolidation, left the project early on, sometime in 2015, iirc.  This is the old ANN thread where @coinsolidation announced Project Bitmark for the first time: Original Bitmark ANN thread )

Hard Fork 1, Bitmark v0.9.7.0, was succesfully deployed on June 6, 2018, solving the issues detailed in the first two links above. Eight Proof-of-Work algorithms, each governed by DGWv3 and each targeted for a 16 minute block time, replaced the single SCrypt PoW algo that had been in service since the start.  These graphs detail the performance of the 8 PoW algos and the resulting overall composite inter bock time: Bitmark 8mPoW Performance (updated frequently)
 Additionally, novel technology, Coin Emission Modulation, CEM v0.1 was introduced as well. (Coin Emission Modulation has been extensively discussed and detailed elsewhere.)

Hard Fork 1 not only introduced 7 new algos to Bitmark, but it allowed all 8 algos { SCrypt, SHA256d, Yescrypt, Argon2d, X17, Lyra2REv2, EquiHash & CryptoNote}  to be merge-mined. This proved succesful in vastly improving the hashrate and thus the security of the chain, but at the expense of eliminating most native mining.  Most other multiple Proof-of-Work (mPoW) coins allow merge mining on usually less than half their PoW algos. (For example, Argentum which has 6 PoW algos, has only AuxPoW enabled 2 of them: SCrypt and SHA256d;   likewise, Myriadcoin has only enabled merge-mining on 2 of its 5 PoW algos, also SCrypt and SHA256d. )

Merge-mining is a simple and very low cost way for an existing mining operation to mine coins. I have not seen a real-life case analysis of what the fixed costs of a mining operation are and what the extra marginal cost of adding and mining AuxPoW enabled chains is on average; but it is simple to understand that if you already have equipment in operation and are already paying electricity and other recurring costs, simply adding an AuxPoW chain in addtion to the Parent Chain you are already mining on the same hardware and infrastructure would only cost a fraction, truly a very small additional cost in using your existing storage and extra processor cycles.

Therefore the Hard Fork 2 proposed change in question is to reward native-mined blocks a bit more than merge-mined blocks and this way level the playing field.   This would have a de-centralizing effect, by incentivizing more miners to mine Bitmark algos directly (natively),  making it financially attractive to do so, discouraging centralization from large mining pools.
Even with block rewards that are less than rewards payed to native miners, I believe that it will still be advantageous for the merge-mining operations to continue merge-mining Bitmark algos.

The other changes we propose are evolutionary advancements of CEM, so that instead of acting on only 50% of the epoch reward, it can act on a larger portion, 80% and to make it somewhat more forgiving of hashrate swings by limiting its memory. (Instead of remembering hash rate peaks as far back as a year, CEM v0.2 would only look back 30 days.)