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

[dbkeys]

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:

replace Yescrypt with YesPower at the next fork.

[1715103680]

1715103680

[1715103680]

1715103680

[1715103680]

1715103680

[Isinngulur]

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…

[dbkeys]

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…

Anyone can claim a Bitmark Bounty.

[dbkeys]

making some algos native only would obviously benefit those who want to mine and gather Bitmarks easily without much competition, and in the same time reduce supply on exchanges.

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.

[dbkeys]

     NLPOOL.NL
......

NLPOOL.NL and @mine_phun:   Thanks for joining the Bitmark community !

Question for you, @mine_phun:  would you consider mining Gulden (NLG) and Bitmark (MARKS) simultaneously through Bitmark's SCrypt AuxPoW function ?    (I'm aware also of FlorinCoin (FLO) and eGulden (EFL) ... but kind of like NLG because of their ability to deposit straight into Euro IBAN accounts from the NLG wallet    )

Nogmaals Gefeliciteerd en welkom bij de Bitmark-familie!

[dbkeys]

In general any change should show support from all 3 parties who have an interest in Bitmark: users, investors, and miners. Users can show support by voting when they make transactions (weighted by fees). Investors can show support by voting with stake (weighted by amount owned). Miners can show support by voting with hashpower. In the end users decide, since investors will follow users, and miners will then follow them since they want the highest market value of the coin they mine. But there should be a guideline written in the wiki that all 3 parties should agree with a strong supermajority (95%) in order to make a change to the protocol.

Generally in agreement with this, except perhaps to the 5% minority holding the rest back. I think a simple majority ( > 50% ) is already considerable. Other thresholds to consider: 2/3 (66.7 %) and 3/4 (75%), so I would say let's stick to the rule employed to activate Fork #1: 75%, but perhaps of a larger sample, maybe 720 blocks (nominal day) :   540/720 blocks.

I do still think that investors (aka, large "rich list" holders of the coin) can masquerade as users for any given vote, by having a bot generate many transactions from one wallet to another (where the HODL entity controls both), but it's not trivial (although it could also be done manually).
 I don't know how this could be mitigated, and in essence it means that votes by users might be influenced, at least to some extent, by stake-holders. Perhaps coin-age can come into play here. If coin-age being destroyed in the TX is high, it could be assumed to come from a stakholder, also if it can be seen on chain that the source address has a large amount of change being produced.  
But all these are complications and assumptions.

My main point is that while Users should be considered, we must bear in mind that Stakeholders can very easily assume the identity of Users. After all, in a real sense stakeholders are the first users.

[onelineproof]

For the time for peak hashrate calculation (1 year) I think it is good because it is the time needed for a full rotation of the Earth about the Sun. Yes maybe in the Northern hemisphere, summers in June-August may make mining more costly, but we should encourage decentralization, thus that should be offset by mining in the Southern hemisphere. As for EMP/UFO/asteroid attacks, we have no obligation to protect from them in the protocol, but of course we should adapt to changing conditions. If all continents except Australia get attacked by "aliens" then you are left with a centralized group of miners in Australia, and if the peak hashrate requirement dissipates quickly, they will have no incentive to help the other parts of the world to rebuild and make mining competitive again. They will probably attack the other parts of the world (take out the competition). I don't know why I am still responding to these obvious/troll questions.

What I can work on is to develop an automated system for changing algos. I think we should keep 8 algos, and just change 1 at time in an automated way using a rigorous voting process and deterministically compiled binaries for the algo specification. In order to replace a new algo, we should have 75% vote from all 3 parties: users, investors, and miners. We look back at the last 5000 blocks (1 week), and this is in line with Bitcoin which uses 1000 blocks for fork activation and 10 minute block time. The blocks/transactions used for voting will include the hash of a deterministically compiled binary that specifies the algorithm, so that it is absolutely clear what is being voted on. Also, the weight to assign to the algo should be included (set some limits on this). The source code should be distributed in a way that anyone can exactly reproduce the binary (that's what I mean by deterministic). Miners/validators don't have to work with the same binary, but should be able to prove it's the same algorithm by comparing their source code with the source code that we distribute for producing the deterministic binary.

Once a new algo is activated, the block reward should be equal to the average of the block rewards of the other algos for maybe 5000 blocks, to prevent abuse by people creating new algos just to have easy mining.

If all 3 parties agree to replacing an algo with some new algo that no other chain mines (thus is basically native), then it can happen. It would look bad on Bitmark in my view if this became abused, but at least it is done within a fair system, and the algos can improve in the future. We already have a lot of native mining going on and actually I would propose to replace Cryptonight with the new cryptonight that monero will use in October. That would give us a lot more honest hashing power in my view.

Basically, with mining you want to maximize honest hashing power. A miner is providing honest hashing power if he doesn't attack (double spend, censor transactions...). The expected value of the honest hashing power is h*P, where h is the hashrate and P is the probability that a miner is honest. For native mining, it is not hard to imagine P being greater on average, though h is very small and there can be quick burst attacks where dishonest miners suddenly flood in, so variance is high on honest hashpower and expected value is low when you are a small coin. That's why I think merge mining is safer, so if you're going to propose a replacement algorithm, you should have a justification for why it will increase the honest hashing power.

Another thing I would support is reducing the max block size to 200 kB to prevent spam, allow a fee market to develop, and ensure good decentralization. Bitcoin uses 1 MB per 10 min, so for 2 min, 200 kB makes sense, and Segwit can be added if needed. This would also be useful if we have a user voting system, as currently fee requirements are minimal, so it is cheap for people to create many transactions that support their vote.

[CharlesCobaxter]

it seems like it takes a lot longer to really believe in this, the website is too simple and the information is not enough, although it has a total supply of quite a lot, but I cannot believe the price, hope the future gets better, I'll keep seeing this

[maser82]

Maybe having an easy and functional Marking feature will benefit more the Bitmark price than the CEM or the available algos. Once the users start purchasing Bitmarks to mark documents on the  blockchain, then the demand will grow. Most of the users will prefeer purchase Bitmarks than to put their computers to mine or to buy ASICs.

An easy marking and an easy way to query the marked data is the key to put at Bitmark where it belongs (Along with more exchanges having the Bitmark trading enabled).

I would not like to be rude (I do not fully understand all you are talking about the CEM, the algos and their consequences), but you look like perfectionists trapped in the details, without throwing the project forward because it is still not perfect for the next step, when you already have achieved a very very good project.
 

[dbkeys]

deterministically compiled binaries

This is what the gitian build system does I believe.

[RidenourPrin]

I just went through the whitepaper. Do you plan to offer the service worldwide from Day #1 or do you have a first geographical area in mind to start with ?

[dbkeys]

Maybe having an easy and functional Marking feature will benefit more the Bitmark price than the CEM or the available algos. Once the users start purchasing Bitmarks to mark documents on the  blockchain, then the demand will grow. Most of the users will prefeer purchase Bitmarks than to put their computers to mine or to buy ASICs.

An easy marking and an easy way to query the marked data is the key to put at Bitmark where it belongs (Along with more exchanges having the Bitmark trading enabled).

I would not like to be rude (I do not fully uderstand all you are talking about the CEM, the algos and their consequences), but you look like perfectionists trapped in the details, without throwing the project forward because it is still not perfect for the next step, when you already have achieved a very very good project.
 

I completely agree with you:
"A functional Marking feature will benefit the Bitmark price more than the CEM or the available algos."

Apologies, regarding the block chain mechanics, CEM, etc., indeed, the chain is functioning well now (compared to what was going on with single SCrypt and old diffalgo, and we have been discussing details, which have less bearing on the success of Bitmark than the core functionality.  I agree:  Let's focus on Marking Apps and Marking Functionality.  I'll keep working on it all, but I will shift my focus primarily to Marking.

[dbkeys]

I would propose to replace Cryptonight with the new cryptonight that monero will use in October. That would give us a lot more honest hashing power in my view.

This has been the plan in regards to Cryptonight, although it imposes a develoment burden that must be met, every 6 months. For this reason, in my mind, it is reasonable to keep Cryptonight exempt from any proposed mmRRf, so that the mining community is motivated to keep the merge-mineability of Bitmark with Monero viable.  This commitment to change from the Monero devs means that they are committed to de-centralized mining.

It is mainly the ASIC algos (sha, scrypt & equihash) that have known and varied ASIC implementations, where I think a merge-reduction factor is justified;   My feeling on the CPU / GPU friendly algos is that any mmRRf reduction on merge-mining must be substantially less than would be for the ASIC algos, in particular Lyra2REv2, where @metalicjames and the VertCoin community are also committed to remain democratic and de-centralized. As a composite algo, like Lyra2REv2, X17  is also CPU/GPU friendly by nature.    

Yescrypt/Yespower  is CPU friendly and ASIC agnostic/neutral, as per @solardesigner.  My inclination on Yescrypt is to take heed of @solardesigner's advice, and tune it for cryptocurrency use (our use) by evolving it into Yespower.  Further,  I suggest we, as The Bitmark Foundation, join the Yespower Consortium to have a voice on its future development, although this will require that we pool funds to gather 1 BTC.
Because, it is one of two existing algos, along with  Argon2d, that are not implemented (at least not yet) on ASIC's and that do not have large parent chains, I propose them as the least-disruptive route back to having some native-only algos.   I believe that reserving some (a minority, in this case 25% of our algos) for native mining is entirely reasonable and appropriate. The security of the chain is well-assured in any case, and fostering native mining and yes, giving core supporters a bit of a "home team advantage" if you will, is desirable, logical, has been done by practically every other mPoW coin, and is called for by a segment of our mining community.

The expected value of the honest hashing power is h*P, where h is the hashrate and P is the probability that a miner is honest. For native mining, it is not hard to imagine P being greater on average, though h is very small and there can be quick burst attacks where dishonest miners suddenly flood in, so variance is high on honest hashpower and expected value is low when you are a small coin.

Indeed, because in the equation h * P, we can fairly reasonably assume that P is higher for native algos, we should at least have some. If the native algos are ones where CPU mining is dominant (maybe GPU to a lesser extent), it is less likely that there will be attack attempts. Further, because there are 8 algos, and many are merge-mined, truly, the probability of a succesful attack overall is vanishingly small. So, in the balance of things, I think it is wise to have somewhere between 1/3 to 1/4 of native algos in the mix.

[Jeffrey_Cycde]

Been around in this business for a while now and I really think there's a huge potential. Price is ridiculously low at the moment in contrast to the development that's being made by the team in this idea.

[onelineproof]

Maybe having an easy and functional Marking feature will benefit more the Bitmark price than the CEM or the available algos. Once the users start purchasing Bitmarks to mark documents on the  blockchain, then the demand will grow. Most of the users will prefeer purchase Bitmarks than to put their computers to mine or to buy ASICs.

An easy marking and an easy way to query the marked data is the key to put at Bitmark where it belongs (Along with more exchanges having the Bitmark trading enabled).

I would not like to be rude (I do not fully understand all you are talking about the CEM, the algos and their consequences), but you look like perfectionists trapped in the details, without throwing the project forward because it is still not perfect for the next step, when you already have achieved a very very good project.
 

If you follow the discussion since July, you will see that I was ready to work on a Marking protocol months ago, and one that I think has the potential to bring a lot of user demand. But dbkeys (and some others) wanted to fork, and I strongly opposed it. For now, the fork is not happening, but there is still some things stirring, and if people really want to change the mining system, then at least with my automated system it will happen fairly, with less politics, and no messy patchwork of forks that make the coin look like a joke.

If we can't even agree on such basic things, then who knows how messy it will be now to create the "marking protocol".

As for Monero merge mining, I don't care so much, it can be delayed without much problems.

[dbkeys]

As for Monero merge mining, I don't care so much, it can be delayed without much problems.

What is the status of Cryptonight / Monero ? What do you mean by "it can be delayed without much problems." ??

My thought process was perfect/finish the mining /blockchain dynamics work (that is, respond to the flaws found and criticism leveled at Fork#1) via a Fork#2  and then move on to Marking.  (We can argue all day long about it, but the bottom line is that I think it was excessive to go full AuxPoW on everything. There is a strong call for some measure of native mining, so the easy fix is to revert Argon2d native, evolve Yescrypt to Yespower native, and perhaps introduce 9th native-only algo.   )

Marking itself is a very broad field, but the essence is to be able to easily hash large data sets to obtain a "fingerprint" of this data, and to embed that "fingerprint" hash on an in-blockchain transaction, with an identifying comment or meta-information.

The fundamentals of this simple operation are what we should focus on first IMO: the core commands, as  JSON RPC calls, and then how to implement & present this facility most effectively GUI QT Wallets.  Much more sophisticated applications can surely be built on this basic functionality.

[onelineproof]

If an algo can already be "attacked" by merge miners, then those merge miners can become native miners and attack it also. So it is better to change the algo completely if you really want a different way of mining it. But changing algos needs to be done properly, not just with a centralized group of developers handpicking new algos whenever they want. Anyway there is already a good amount of native mining going on for about half the algos. Argon2 is only merge mineable with Unitus which is a tiny coin, equihash still no merge mining happening with Zcash because it requires more understanding of the code. Only sha and scrypt are really dominated by other chains. Monero we don't have to follow, we can leave it as it is and follow them later on. So I don't know what you're complaining about, there is already a good mix of native and merge mining, and nothing needs fixing, except for the overflow bug which should be done soon. I already told you what I agree with / don't agree with, and I only want to work on something that supports my vision, I have no interest in working on sloppy code just for the purpose of pumping the price.

[Matiel]

when will they release the polo and cryptopia wallets

[dbkeys]

when will they release the polo and cryptopia wallets

Good question, not sure what their criteria is.  But chain is working reliably under the current protocol and most nodes are in the v0.9.7.x series, as they should be at this time.

But, there are a few v0.9.8.3 nodes still appearing, and in fact someone mined a few blocks beyond height 518191 (iirc, like 20 blocks or so) on that fork, which I found odd. No one should be running a v0.9.8.3 node or wallet. I have taken down the Release binaries for that version, (because there were last minute questions about it right before the forkheight); but it's possible that a few are out there.

Please make sure that your nodes and wallets are on the Bitmark v0.9.7.x series.
This is the correct version to be on at this time.

There are also a couple of nodes listed on the Chainz explorer as v0.9.5 and one as v0.9.2.2.
Those version are old and totally obsolete.
¿ Maybe an old VM running somewhere, forgotten.... Or just ...
¿ A monitor to see if anyone mines that old fork ?  
v0.9.5 had a SCrypt diff in the 20,000 IIRC    

 

[dbkeys]

.%.