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

Just found MARKS
Am I able to mine it via equihash through z9m?
Anyone know?

I'm very excited about the amazing potential of this project. The most promising project of the year in my opinion. So great to see more and more mature and professional teams entering the market. It will definitely help not-so-tech-savvy people get involved with the crypto space.

.%.

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.


 

when will they release the polo and cryptopia wallets

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.

The plan is still new and we can still expect more new updates and developments from the team. But they should be more active so that possible serious investors will join the project.

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.

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.

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.

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.


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.

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.

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 ?

This is what the gitian build system does I believe.

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.
 

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

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.

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.

Open API means that developers and will have access to data and app and will have ability to develop on it and from it further to make additional features , other applications that communicate with this one to make a better solutions and similar things like that.

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    )