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

[maser82]

Is this a new project? What are your key features compared to other wallets that may appeal to users? Your wallet is a new version so I think it needs to be improved, and you already have the person in charge of this part yet? You should improve the wallet so that users can use the best way

The Bitmark project was started in July of 2014.

The key feature of our Blockchain is our focus on Marking.  

Marking is a broad term that encompasses many different uses and applications, most involving anchoring data sets on the blockchain via hashes embedded in transactions. It's a deep, fascinating topic that we can expand on to many useful areas.

We welcome your suggestions on how to improve our wallet and any others you may have too.

Having the marking feature in the wallet would be nice. Like offering the option to select a file to be marked before you do a transaction and then, when it do the transaction, it hashes the file and stores the file hash into the blockchain.

If there were an option to set file name, file description and an optional storage of the file in the bitmark servers, allowing to publicty query the file, that would be very useful to many companies and entities.

I like your suggestion !

That would be a great and simple way to enable users to mark anything they had on file.

The optional storage part is interesting too because it would in essence be the storing of the file which originated in the user's machine to the Bitmark servers, or "Bitmark Storage Cloud" which could be a federation of machines which are willing to commit storage space for a length of time in exchange for MARKS.

Agreed, that would be a good way to implement Marking and leverage our "Bitmark Storage" solutions.  Thanks for the recommendation!  We will see if this is a feature the community would like/support, and if it is we can add it to our short term milestones list (after the completion of the code base upgrades).

May be it could be a new tab intended explusively for marking, showing the available fields to fill, and when the user commits the action then it automatically do the transaction, marks the file and upload it to the bitmark storage.

A webpage having a "marked files explorer" that allows anyone to search and to check the marked files, additional data, timestamp and hashes would be very useful.

The main problem I can think on this is what happens when someone marks illegal content and it is stored on the bitmark servers or bitmark storage. There should be a way to report illegal content and a way to delete it.

The question of legality is always tied to jurisdiction. It's an interesting question, because what is legal in one place might not be legal in another. There should be a way to report questionable content, and for contributors to the storage federation to decide whether they want to keep it or not.

Those are good points.

We could look into the Firewall offerings (through the web server/services provider)

It is easy to block certain types of traffic, however files (with illegal content) gets a bit trickier.

https://www.paloaltonetworks.com/documentation/71/pan-os/pan-os/policy/create-best-practice-security-profiles

https://live.paloaltonetworks.com/t5/Management-Articles/Complete-List-of-PAN-DB-URL-Filtering-Categories/ta-p/129799

Not sure if google offers an API for this. That said it would be prudent to take a similar approach as services like reddit. Relying on the community is much more feasible, since we don't have the resources/assets for this at the moment.

The distributed storage idea and to get paid in Bitmarks for hosting the marked content is pretty attractive. It is a groundbreaking idea, like what Dash did with the masternodes, but it is pretty risky too. With no content control, Bitmark could become a network to share child pornography or something scary as that. Allowing the content to be controlled by a public community could not always avoid legal problems: In an hipotetical case where someone marks a leaked hollywood movie or some content DMCA protected, publishing it without authoritzation, then maybe the users in the comunity would like to keep accessing to the content because they like it but that would be illegal in the USA where many lawyers would take action.

From my point of view, the best way would be to keep it simple: Store the content in one server, in one legislation and managed by one entity. In one hand it would imply resources in terms of hardware and support but in the other hand that would make all the marking storage easy to acomplish with laws. The fees for marking could be higher than a normal transaction and destined to pay the server storage and support. By support I mean what could be review the content complaints and content removals.

A Bitmark association or fundation backing all the process would be nice and would provide confidence to the users.

[1713509050]

1713509050

[1713509050]

1713509050

[TeamBitmark]

Another option InQuest "Deep File Inspection"

http://blog.inquest.net/blog/2018/02/12/deep-file-inspection/

[onelineproof]

As usual, incompetence walks hand-in-hand with scams. What serious developer would want to work on a scam? And no I'm not using some weird definition of scam. The fork pushed by dbkeys does 2 main things:

1) Transfers wealth from new investors to old investors (total wealth depends on demand)
2) Reduces security for users

and it is advertised as an "improvement"

If this isn't a scam then what is?

The dependence of emission rate on value of Bitmark relative to other chains was never part of the protocol, and it's basically a parametrized if statement:

If wealth of current investors is x, then take 1/x wealth from new investors.

And by current investors I mainly mean the early investors. People who just bought yesterday can still benefit from fair prices tomorrow. The earlier you bought, the more benefit you get from this fork. x would have to be big (market cap of Bitcoin) for 1/x to be negligible, so once (if) dbkeys with his 1 million coins is a billionaire, then the algorithm will allow for an almost fair emission rate (though you can't reverse what is essentially a premine caused by a past unfair rate). This is precisely a pyramid scheme, marketed as a decentralized cryptocurrency.

Obviously dbkeys told his friends to buy bitmarks right before the June fork, and when the price went down they got mad, so he wants to "regain their respect" (together with his own profit). So he thinks that by lying and stealing from other people he will regain the respect of his friends? Good luck with that.

Uncorrupted bitmarks reached $0.30 last week. I predicted $1 within a year from August 2018, so actually I think that can be reached must sooner. With uncorrupted bitmarks, the destination is moon. With scam bitmarks, the destination is dbkeys' pocket, and the amount is dependent on how many fools buy in.

I had some good discussions going on about selfish/colluding mining in the Development and Technical Discussion board (https://bitcointalk.org/index.php?topic=4998410.0). It is refreshing to talk to people who don't pretend to not understand what I'm saying. Though dbkeys / TeamBitmark did try to brigade it to push his agenda.

So if people want uncorrupted bitmarks, I can work on an exchange solution, but I need your support!

[TeamBitmark]

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.

Thanks @radeba

We hope to finish the Core Update phase of our development cycle and move toward the most exciting areas of development, "Marking: A distributed reputation based ecosystem".

[Tieluabrockrabh]

Hi, guys!
I think this is a new but promising plan. the obstacle is the number of similar competitors of the idea, all offering great service. who's the good luck.

[maser82]

https://www.livebitcoinnews.com/china-allows-evidence-authentication-through-blockchain/

[Switorusti]

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.

[gerald232]

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.

Thanks @radeba

We hope to finish the Core Update phase of our development cycle and move toward the most exciting areas of development, "Marking: A distributed reputation based ecosystem".

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.

[dbkeys]

Bitmark
Performance of current v0.9.7.x BlockChain :

[dbkeys]

As usual, incompetence walks hand-in-hand with scams. What serious developer would want to work on a scam? And no I'm not using some weird definition of scam. The fork pushed by dbkeys does 2 main things:

1) Transfers wealth from new investors to old investors (total wealth depends on demand)
2) Reduces security for users

and it is advertised as an "improvement"

If this isn't a scam then what is?

The dependence of emission rate on value of Bitmark relative to other chains was never part of the protocol, and it's basically a parametrized if statement:

If wealth of current investors is x, then take 1/x wealth from new investors.

And by current investors I mainly mean the early investors. People who just bought yesterday can still benefit from fair prices tomorrow. The earlier you bought, the more benefit you get from this fork. x would have to be big (market cap of Bitcoin) for 1/x to be negligible, so once (if) dbkeys with his 1 million coins is a billionaire, then the algorithm will allow for an almost fair emission rate (though you can't reverse what is essentially a premine caused by a past unfair rate). This is precisely a pyramid scheme, marketed as a decentralized cryptocurrency.

Obviously dbkeys told his friends to buy bitmarks right before the June fork, and when the price went down they got mad, so he wants to "regain their respect" (together with his own profit). So he thinks that by lying and stealing from other people he will regain the respect of his friends? Good luck with that.

Uncorrupted bitmarks reached $0.30 last week. I predicted $1 within a year from August 2018, so actually I think that can be reached must sooner. With uncorrupted bitmarks, the destination is moon. With scam bitmarks, the destination is dbkeys' pocket, and the amount is dependent on how many fools buy in.

I had some good discussions going on about selfish/colluding mining in the Development and Technical Discussion board (https://bitcointalk.org/index.php?topic=4998410.0). It is refreshing to talk to people who don't pretend to not understand what I'm saying. Though dbkeys / TeamBitmark did try to brigade it to push his agenda.

So if people want uncorrupted bitmarks, I can work on an exchange solution, but I need your support!

MARK Ops - BlockChain Security & Dynamic Guiding Comm

Many Thanks to the Following Devs, whose Spirit Lives in Bitmark:

in no particular order ...


@82abnmedic
@melvincarvalho
@onelineproof <--- I'm starting to understand your point of view a little bit better, and I think that the current version does deserve a longer run because it has proven succesful.
The last few suggested absolute forkheight I have felt the need to pull the breaks on and avoid because of last minute code corrections and bug catches that just don't feel right .
And I see a point in that perhaps it is wise to leave nearly the full CEM reward (thinking of magic £ 88.888888 % figure) on some merge-mined algos, perhaps up to 3, but to certainly downgrade the ASIC algos by some harsher factor. Don't know ? What do you think ?

@jarr0s
@coinmoon
@dogedarkdev
@ecucoin
@amarha
@mark.pfennig
@docharibo
@luke-jr
@sipa


Many thanks, wherever you are, dear ones, departed dear ones, dear ones to come

Our own Satoshi, Mark Pfennig, little is know of him, more than that he hailed from beyond the wall . .  .       .\\`

We call our 1 / 100,000,000 unit the Markoshi for him, wherever he may walk today.

A pfennig for his thoughts  !  

Cheers Mates !

~~~ @dbkeys ~~~


First, let's give thanks that our blockchain is secure, working well, and promptly processing transactions in a very secure way.

We are ready to make the leap into Marking ... inWallet

[dbkeys]

BTW

By The Way

Bitmark Truth Wiki

I Always Tell People to Buy Bitmark !!!

Unashamedly, it's as good or better technology than Bitcoin for keeping account !

and more lightweight  (  ¡¿ Have you checked the size of the Bitcoin full blockchain lately ? !)


 

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,

For a   1:3   ~   Native:Merge-Mineable Ratio.

Seems like an attractive Tesla Numbers Combination

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

[Forcovaljudg]

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

[dbkeys]

#Lovin_the _PirateTalk_!

Wish I had a Million MARKS    !!!

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

$marks gna:

bN8bCsyhJXMQMVTrqvoJV1zwhDLLAofoeG

---

Latest 1-Day, 8-mPoW BlockChain Performance, Bitmark v0.9.7.2 :

http://explorer.bitmark.co/plots.day/

[sokuyaku]

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.

[dbkeys]

Call for Ideas as to What the next 750/1000 Fork of Bitmark could look like

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.  

BitmarkCause,  I do, as a general principle,  I like the democratic approach.

~ 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 }

   ¿¿¿  Marking Facilities in Wallet / File Selector   more   Ideas ? ? ?

[onelineproof]

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.

[dbkeys]

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:

Fork #1 (Current Bitmark Version 0.9.7.2, now in operations) Historical Proposal and Cautionary Notes from Melvin

[mine_phun]

     NLPOOL.NL https://www.nlpool.nl/images/bct/bitmark.png

NLPOOL.NL | Highly profitable Bitmark Mining Pool


Start Mining:

Code:

z-Enemy -a lyra2z -o stratum+tcp://mine.nlpool.nl:6233 -u WALLET_ADDRESS -p c=BTM

Our features:

- Approximately 20 - 30% extra profits with custom finetuned profit switching system in the Lyra2Z pool
- Payouts possible in any currency present in our pool (LTC / Smart / XVG / BTM etc.)
- High profits for miners by lowering latency and stale shares
- Blocks are distributed proportionally among valid submitted shares.
- High security / DDOS protection with 99% uptime, multiple nodes, loadbalancers and status system
- Professional pool - No un-announced downtime. We care for your profits.
- Hourly payments
- 0.9% fee

Support
Telegram - Telegram
Discord - Discord

[dbkeys]

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?

The Bitmark Project is an Open Source Project: Bitmark Project on GitHub

- - -   %   - - -

We do have a bug-bounty program, which was announced in July:

Bitmark (MARKS)

Bug Bounty Program

     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

Compensation

    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.

Rewards:

* 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)

- - -   %   - - -

Forums / Social Media

Twitter

Slack
Bitmark Subreddit

Facebook, LinkedIn :   "In the Works"

[onelineproof]

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:

Fork #1 (Current Bitmark Version 0.9.7.2, now in operations) Historical Proposal and Cautionary Notes from Melvin

Maybe you can fool others with this but 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. And then "conveniently" the lookback period is less to give these native miners more rewards. Maybe people don't realize this but blockchains are very unintuitive. There are no real world analogies to blockchains. Details matter. One small detail is the difference between a serious cryptocurrency and a joke. So it's your choice...

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. If there is a division, then better just fork into 2 coins.

I already learned not to trust dbkeys, so I will try my best to get an exchange to support my "uncorrupted" vision. Like that if I do a bunch of work on Bitmark, at least there is a chance it can continue being used. But I also need support from people who support my vision.

By the way, I already have a 0.9.7.3 (with technical fixes) released on the bitmark-protocol repository: https://github.com/bitmark-protocol/bitmark/releases/tag/v0.9.7.3
It requires 950 out of the last 1000 blocks to signal it in order to activate. I even have a 0.9.7.4, with stricter block reward requirements, so people can signal for that too.