Topic: [ANN] [MARKS] Incentivize Content Creators & Build a Reputation Value Framework - page 12. (Read 32577 times)

Is the plan open source? Where can I find the source code? Does your business have a bug bounty program? Where can I find your GitHub, Twitter, Facebook, LinkedIn, Slack and/or Subreddit? What is the web address for your business?

Yes, and No.  

Yes: because, indeed, this is why most mPoW coins only allow merge-mining on some of their algos - definitely not all. There is the desire to let the core supporters of the coin mine them, not just as an afterthought or mere bonus, but as the main target of the mining.
(This does not mean that native mining is restricted, or exclusive. Not at all.
After all, it is an open, decentralized P2P network. Anyone can mine natively)
Taking advantage of powerful hashrate through auxPoW merge-mining is a good idea, but totally eliminating native mining is not, IMO.
Therefore, I propose that at least 1/4 to 1/3 of algos be native-only.
Mining is open. But pitting native miners in all algos against the much larger hash rates  (at least for now) of other chains is an apples:oranges comparison.     ( That's why in boxing, for example, you have weight classes: welter-weight, heavy-weight, etc..)
Relying exclusively on merge-mining seems unwise and is in fact a centralizing measure. In order to de-centralize, mining must be specific to our blockchain, at least on some algos.

No: because, since the proposed Fork#2 has no proposed merge-mine_Reward_Reduction_factor (mmRRf ) at all for native-mined coins, reverting some algos to native mining actually increases the emission rate and supply. We can speculate that native-miners aren't as prone to liquidate everything mined immediately, but this is just speculation. Native miners can sell their mined coins just as easily as merge-miners.  ( Note: If mmRRf is not applied at all to any algos, then reverting some algos to native-only is emission & supply neutral. )

The CEM lookback-period could be tailored, (specific to a class of algo, or to individual algos) or, for simplicity, be the same for all.  However, I do believe that a 1 year lookback is too long, and that about 1/3 year is sufficient, for the original stated purpose of matching supply to demand, and also for the side-effect of keeping miners at peak performance.     And again, this proposed change has the effect of more quickly restoring the basic emission rate after a high-hashrate event, rather than keeping it supressed for a whole year.

Anyone can claim a Bitmark Bounty.

Do I understand right that I need to be minimum a Junior member and then I can join the bounty? Or can I go for airdrops until I have become a junior member? It would be a good way to support the business also…

Interesting note on Yescrypt from its developer, SolarDesigner:  (https://www.openwall.com/yespower/)
"   For historical reasons, multiple CPU mining focused cryptocurrencies use yescrypt 0.5'ish as their proof-of-work (PoW) scheme. We currently have a separate project for the PoW use case: yespower. Thus, rather than misuse yescrypt 1.0+ for PoW, those and other projects are advised to use yespower 1.0+ instead.  "

Because its developer has a specific version for the Proof-of-Work case, I suggest that we:

     We invite all developers to review our code, provide feedback, and report any issues. In return, our bug bounty program will compensate you for discovering issues that could potentially impact the security and performance of the Bitmark blockchain

    Our team will assess each submission individually and assign a severity level according to its likelihood and security and performance impacts. Compensation will depend on the severity of the issue found.



* Critical: 10000 MARKS - A critical bug is a bug that will enable stealing or loss of funds
* High: 5000 MARKS - A high bug significantly affects the ability of the system to operate.
* Medium: 2500 MARKS - Medium bugs entail an issue regarding operation not exactly as designed or intended, but not causing the loss of funds nor impeding operation completely.
* Low: 1000 MARKS - Low bugs are less significant errors
* Informational: 1 MARKS - Informational errors have no impact on the operation of a the system but should be brought to attention, such as a comment not matching the updated code, etc.

Note:
These MARKS denominated bounties are good thru October 1, 2018
(will revise after that date to adjust for possible value changes)


Twitter

Slack
Bitmark Subreddit

Facebook, LinkedIn :   "In the Works"

There is no sneakiness involved. I'm actively soliciting input.  

I think it makes sense to have distinctions based on whether or not algos have been implemented on ASIC's

Also, reducing the CEM look back window returns the emission rate toward the "standard" curve (the one based on just the quartering and halving system) faster than 'remembering' a long ago peak.  1 years seems a bit excessive to me now. In light of the possibility of a large amount of hashrate disappearing through some type of force-majeure, (like an EMP) which is not the decision or fault of any miner, should not be affecting the entire network for so long, IMO. So I suggest reducing 365 day lookback to 120 day, or 127 to be binary and prime, (about 1/3 year)

I do think that some algos should be native-only, if not the majority, at least a third; that is why the least disruptive path to this ideal seems to be to revert 2 of the lesser used ones (no huge parent chains anyway) and introducing a third which has never been mm'd in Bitmark.  

So, first, I propose the non-controversial, non-forking improvements be adopted into a new tag 0.9.7.3; this is the squelching of the excessively sensistive "mining difficulties" warning, any other useful improvements & fixes, as well as  the simple ability to Mark a file via an embedded transaction comment.  (The issue of long-term cloud storage and accesibility of the marked data is left for later).

Then, more than likely, we should go through a vetting & testing phase determines what the next Forking version may look like, and set it to activate as we did with Fork #1, perhaps with a 75% supermajority over 256 blocks, or perhaps 1000. But I think a 95% requirement is a bit much.


For the First Fork, the current v0.9.7.2 @melvincarvalho laid out a good guide document of what should be achieved.

The GitHub wiki has the example:

I don't know what your plan is @dbkeys but I don't support any sneaky moves. 9 th algo I don't see a point, it would just overcomplicate things, and any new algo changes I think should be done through proper miner (and perhaps user) voting systems to remove special interests biasing it. To increase the effect of CEM by more than 50% also looks sneaky, as does changing the time to look back for peak hashrate. Even if there is good reasons (I don't see them), doing them after the parameters are already set allows for special interest manipulation, and that's why I recommend user voting to sort things like this out. And reducing the total emission rate, of course I can't support even if you just make it affect some algos. I don't know if there's a point to try to compromise with me because I don't have any interest to work on something that is "hand-waved" and not following the highest standards.

I think the 9th algo version, ( with or perhaps without, the return of 1 or 2 algos to native-only status ) with stronger CEM parameters in v0.2 and   {maybe or perhaps not}, :
       Applying a reduction factor to merge-mined block, moreso if this mmRf factor was dynamically set (as is done with the SSF= current/peak hash_ratio in CEM) ( and as a set, subset or individually to the PoW algos, Ax_mmRF),
       Are questions that perhaps are best resolved with some kind of voting based on dynamic fund motion stress testing, aka, user transaction fee voting, as AK suggested. I proposed a bi-cameral system that would also represent Stakeholders ( maybe with with threshold over 1024 MARKS, so that they didn't feel compelled to bounce marks and markoshis around to themselves and clutter up the blockchain), but along with @onelineproofs idea of a user transaction fee - weighed voting system.  

~ dbkeys :

Something that I didn't see before : it might be profitable to set up a co-mining operation on a stronger parent chain combo with bitmark as aux-PoW, but without the full Bitmark CEM Epoch Reward, it might not be profitable against established miners of the parent chain

So, unless they are ASIC, perhaps other algos should no be hit so hard for being merge-mined or merge-mineable (ie, instead of merge-mine down to 10-20% CEM, the would be 20-88% CEM Range. I do think some reduction is appropriate for merge, ie, combined mining or 'promiscuous' mining. But a minimum 12% for some algos, particularly if they are ASIC resitant / CPU-friendly, Democratic-Distributed Mining committed, they should be exempt from the more pronounced reduction of 80% for the classic ASIC algos {SHA256d, SCrypt, EquiHash }

The plan is interesting and I think this is a good plan for the investors. but many plans are similar in the market. I hope with the innovation and strategy of the team will be effective in getting investors to support this business.

#Lovin_the _PirateTalk_!

Wish I had a Million MARKS    !!!

Bitmark (BTM) (MARKS)  Donation Address for db Keys:  

$marks gna:

bN8bCsyhJXMQMVTrqvoJV1zwhDLLAofoeG

---

The platform presented here opens up wide opportunities for us to successfully realize our ideas, with a generous bounty program, where everyone can participate.

Yup, the Bitmark BlockChain is Secure. And Fast.

Perhaps just the crowning addition of a 9th, and finial algo, Groestl, which would be native only.

we have the sketch of a v0.9.9 that does that, and returns 2 algos { Argon2d & Yescrypt } to native - only as well,


I now feel in no rush to fork, because I think @onelineproof has a point, that the security and stability of our present setup are not to be let go of lightly.

I think the 9th algo version, ( with or perhaps without, the return of 1 or 2 algos to native-only status ) with changed CEM parameters for a version 0.2 and perhaps or perhaps not, the application of a reduction factor to merge-mined algos, (as a whole or individually) are question that perhaps are best resolved with some kind of voting based on dynamic fund motion stress testing, aka, user transaction fee voting. I proposed a bi-cameral system, One that would represent Stakeholders with votes over 1024 MARKS, along with @onelineproofs idea of a user transaction fee - weighed voting system.  But in general, I like the democratic approach.

And regarding price, well, if MARKS are cheap on market, let's buy 'em up guys.

I do thank @onelineproof for finding something to like in CEM as it is, so ...  I do suggest that  accentuating CEM @least an additional 25% of the epoch max reward for a trailing 90 days {as is coded in the present v0.9.8.x series (current master branch)} is in whole is a good idea. Variants of this rule could be accentuated over different algos for different reasons

Hey guys.
If your idea is the most perfect decentralized platform in the world for immediate payment without the risk of volatility for the implementation of the crypto receiver, then in the near future it will be successful.

I hope the renewal stage is accelerated because competition in this sector is very great. indeed all need to process and need time, but that is a challenge for you. Updates create platform development and leave a good image in the minds of users of this platform.

Attentive dev team, active community and a coin that has a purpose beyond just existing. I dig, man, I dig. I see this coin as one that will establish a place beyond the coin exchanges to be used in the real world.