Rebooting development: call for participation

[melvincarvalho]

Project health check

As we will soon enter our 8th year, this is a quick health check to call to see who's around to help reboot the development process for this project

It's been a challenging year all round, for many external reasons, and the project has been largely on auto pilot

Good news is that behind the scenes there's been some great work from @dbkeys on maintaining the website, the BTT thread, explorers, plots, mining, exchanges, block chain dev, and other things

Our software clients still work on windows, macos, and ubuntu 16.04 (I just checked). Ubuntu 20.04 will need some updated instructions due to the upgrades of libboost and openssl

We are still trading on freiexchange, and bisq. More than one explorer works, and the plots from the fork can be examined. The blocks seem to be coming in regularly without reported issues, so we have largely achieved our main goal of having a stable block chain

However, there has been a lack of activity and understandably our price has suffered with many thinking the project is abandoned. So this is a call to see who's interested in rebooting the development effort

What's left to do

There is a bit of maintenance work to explain the history of the project better, why certain choices were made, and what they do. And also to explain how we are different from most alts in being a provably fair coin, with a probably fair emission schedule. ie no ICO, no premine, no instamine, not dev tax, no proof of stake etc.

The eco system needs documentation to show where all the different pieces are

The instructions for building need to be updated so that we can more easily run and build on linux

Our code base is behind upstream bitcoin by some years. So we might need to import some of the fixes there, which is a big task in itself. Some of the newer optimizations we dont need just yet, as our blocks are not full

The idea of grounding reputation trees in the block chain needs to be fleshed out and documented. There was some talk about OP_RETURN and OP_COMMENT, but I think we are actually able to do this today with a modified chainpoint and single use seals, and so, not requiring any low level changes. I've been doing some experimental work on this, and it's gone very well. Happy to share findings on this soon, and write up

There's been some talk about having 1 of our 8 algorithms as a special bitmark algo that can be CPU mined, to generate interest in decentralized mining. This might be an avenue to explore, provided that the proposal is clearly documented, reviewed, and our code base is in a good and well maintained state

We are also I think close to the point where the first reputation trees can start to be grounded in our block chain. I may have this working quite soon. Again, this requires a bit of documentation

Call for participation

We continue to work, as we have from the start, as a 100% volunteer based team, on a best effort basis. That means that things can be slow, but we are a community designed coin, which will have an emission period over many years to ensure fairness. Whether or not that model will work in the long-term, time will tell!

If any devs (new or old) wish to help out with the project and the vision of marking, please feel free to drop a note here. Or visit us on slack. Or you can mail me a (melvincarvalho@gmail.com)

Thanks!

[Swissnode]

This is a GREAT little project. Well not so little, but a gem of a hidden concept. Can't wait to see what happens with it...

[dbkeys]

TLS / SSL Updates

The update for libboost and openssl has been done; branch 'ssl-only' on my github page takes care of that . It was developed as v0.9.7.3. Now that it is stable, I will soon merge it to the official master branch and tag it v0.9.7.4 and make an official release with binaries.

Faster Initial Blockchain Download (IBD)

Also, I'm doing final testing on development v0.9.7.5, which implements the "headers first, blocks-in-parallel" initial blockchain download (IBD/HF-BIP) strategy which debuted in bitcoin v0.10 This enables faster initial blockchain download, because only the block headers are initially obtained from a single peer; once the entire chain of headers is obtained and verified as correct, then the actual block data for each block is filled in, from several peers in parallel, concurrently. I believe this is perhaps the most significant feature in the later versions from upstream, short of SegWit, which, as Melvin points out, is really not needed in our chain at the moment. Once that is done, I will report on the IBD speed improvement, tag it v0.9.7.6 and likewise make an official release with binaries.

Algorithm and Merge-Mining Line-Up

I am convinced that we must have some algorithms returned to native-only status. Currently, since Fork 1 in June of 2018, all 8 Proof-of-Work algorithms are merge-mine enabled. The advantage of merge-mining is that very large hashpower secures our blockchain throught harnessing hashrate of other coins via the AuxPoW mechanism. (This is particularly true of SHA256 and Scrypt)
The disadvantage is that there is no native mining any longer, and anyone interested in the Bitmark project and in mining bitmark must compete with very large "foreign" hashrate, unrelated to the Bitmark project. There is no focused, Bitmark-only dedicated mining for us now; all the mining is mostly the by-product of miners mining other coins and regarding Bitmark as a mere "small bonus". Most other, if not all other, coins that allow merge-mining, always reserve some algos as exclusive to their blockchain I believe we must address this by returning at least 1/3 or perhaps as many as 1/2 of our algorithms to native-only status. This will be a net improvement, with no downsides. This change does not affect neither the emission rate nor the total emission. We have always respected the total cap on emission. Security is rock solid with several algos and several of those with very large hash rates. It only means that those with an interest in Bitmark for its own sake will have the ability to mine it without having to compete with any foreign, unrelated hashrate; in the native-only algos, they will have to compete only with other Bitmark miners.

We are due to freshen our algos in any case, because as several were chosen because of the hashrate or philosophy (democratic mining) of the coins implementing them and those coins have improved or changed the algos as well, we should keep up to date. This is the case with Lyra2REv2, which was used by VertCoin. Now, VertCoin has adopted a proof-of-space algo developed by their team, to ensure widespread democratic mining, "VertHash". I believe we should replace Lyra2REv2 with VertHash CryptoNight has also evolved and we should update it accordingly to harness the hashrate of the popular privacy coin, Monero; the same is true for ZCash's EquiHash. To achieve at least 1/3 native algos, I recommend: 1) Swapping Yescrypt merge-mined for Yespower as a native algo. The developer of both these algos, SolarDesigner, developed Yespower expressly for cyrptocurrency. 2) Returning Argon2d to native mining. 3) Introducing a 9th algo as native-only: our original algorithm SCrypt. We would then have merge-mined SCrypt, and the same algorithm SCrypt but in a native-only flavor.

I think these algo updates and restoring a measure of native mining are justified and desirable. There are also some minor bugs outstanding that need to be fixed, but require a hard fork. For these reasons, I think that another fork, Fork 2 is warranted and should be undertaken. We have traveled that road, and done it before, succesfully.

Roadmap

Beyond Fork 2, Andrew & I are envisioning the possibility of implementing blockchain-based voting by miners and stakeholders to decide these kind of algorithm changes and to have the framework transition from static mPoW to an intrinsic virtual machine whose programming can be voted on. If we implement a virtual machine in our blockchain that does voting AND smart contracts, that would be very positive, and would bring us major interest. My interest in voting systems is general; I would like it to be applicable to a much broader, larger target markets or audiences. I think it's very interesting that we can use it for our technical issues with the bitmark blockchain, but I wouldn't want it to be limited to that narrow, rather technical scope.

[melvincarvalho]

@dbkeys this is awesome, thanks!

For those that are unaware odd minor number versions are development, and even number are release

I'm going to test out v0.9.7.4 in the coming days

Let's get together on slack and talk about 0.9.7.6 and beyond

[melvincarvalho]

I'd like to add to this my recent successful experiments with using the bitmark block chain to ground git trees (including reputation trees) in the bitmark block chain

https://git-mark.com/

Still early and experimental but it's currently working, and im using it for more and more projects

[melvincarvalho]

Regarding one comment above:

This change does not affect neither the emission rate nor the total emission

I get this question a bit. ie has the emission rate changed from the original community designed schedule

I can point them to the plots:

https://explorer.bitmark.co/plots.week/

But at times people are unsure of what they are looking at. Now that we've had 2+ years with the new emission is there way determine how the new 8 algos plus dark gravity wave v3 compares to the original halving schedule

It does seem to me that the fork has worked very well, tho it's harder to explain how and why. Merge mining has made the chain quite secure, and that's one attractive reason to use it more

[melvincarvalho]

Beyond Fork 2, Andrew & I are envisioning the possibility of implementing blockchain-based voting by miners and stakeholders to decide these kind of algorithm changes and to have the framework transition from static mPoW to an intrinsic virtual machine whose programming can be voted on. If we implement a virtual machine in our blockchain that does voting AND smart contracts, that would be very positive, and would bring us major interest.

Sounds fascinating!

@dbkeys while bitmark was specifically designed not to be a smart contract platform, but rather, to allow smart contracts at higher layers, I do see a few ways forward with this

Firstly, smart style contracts can be grounded in the bitmark block chain, my git-mark is a early example of grounding side trees in the block chain, and so is work being done on RGB and this requires no modification to bitmark. There are also centralized virtual machines like the one written in lua on etleneum. There are varying degrees of trust and assurance models associated with this

Another option would be a pegged side chain which allows ability to experiment with different consensus methods and federations. And also to add features such as smart contracting, virtual machines and atomic swaps. Federations are required to do the peg ins and peg outs. Liquid is an example of such a side chain using the elements project. Bitmark with reputation trees, if they become applied to nodes might be well suited to pioneering the federated model using a trusted set of nodes. That would be a completely new innovation, and also one that could interest bitcoin researchers that wish to make sybil attack resistant systems

A third approach, and this might generate some serious interest, would be to implement drive chains

https://www.drivechain.info/

Drive chains enable side chains with a two way peg, that are not based on a trust based federation. This allows experimentation with new features such as smart contracts, issuance, voting etc. without impacting the main chain.

Drivechains are a popular feature that has been on the bitcoin wish list for many, for a while, but has not made it to production yet, and it might take a while to do so. No project has implemented drive chains yet to my knowledge. So if we were to go in that direction it could provide some interest, in a similar way to how litecoin helped with segwit. And if it works it could also become part of bitcoin

So I dont see a virtual machine and smart contracts getting an ACK on the main chain, but if there was a desire to work on such things as part of the bitmark family that might be a way forward that keeps people motivated to innovate

[melvincarvalho]

Thanks for the responses to this so far. Good discussion!

I propose 2 next steps

• Let's split out the points raised here into new issues, and continue there (documentation, IBD, CEM fix, compile on ubuntu 20.04, OP_RETURN / OP_COMMENT, Fork 2, Virtual machine, smart contracts, voting, git mark, emission verification, future hard forks, new mining algos, merged mining, dive chains) etc.

• Lots to talk about. Lets see if we can work out a time (mini summit) where we can catch up and chat about the different aspects, there are also some new people and communities that may want to get involved. Maybe on slack, or somewhere else if that suits you better @dbkeys

Keeping this thread open probably for the whole of Q2, in case others want to weigh in ...

[WitchDoctor-Six]

@dbkeys & @melvincarvalho Catching Up

[melvincarvalho]

@WitchDoctor-Six nice to hear from you!

Been catching up with @dbkeys and I think we've made good progress

I made this site to start to document the bitcoin eco system

https://bitmark.rocks/

Our slack area is still going, but it's quiet there because github notifications seem to have stopped working (I'm not sure how to fix that) and we dont have a marking bot there currently Tho maybe that's something that can change. Feel free to pop in any time, as is convenient to you. No urgency, tho

[bitmarkcc]

The VM system for running algos has two main purposes. One is to secure the blockchain. With dynamically changing PoW, we can make it much harder for 51% attacks to occur since our algos would be unpredictable and ASICs would be useless, and we would have our algos future proofed, so no hard forks would be needed. The second reason (I think Melvin would like this) is to create a settlement hub for all reputation systems. Any reputation system can be defined by the code it runs. By having our users vote for it, and miners run it, gives it reputation. Most code also has "exceptions" that occur. The code can be set to give an all 0's hash (winning block) if an exception occurs. If it happens too often, it gets shut down for that slot, until a revote. Like this, our miners will be leveraged to run unit tests on the code, with random input coming from the block headers (can even use full blocks for more general hashing), proving that the code has reputation (large hashpower with no exceptions). There are also applications for theorem proving, protein folding.

Note: the VM isn't really executing smart contracts as in the traditional sense, and unlike other smart contract platforms, our miners run the code, which is more efficient. You can also read about 'proofs of useful work', which is gaining interest these days.

I think the number of slots for algos can be infinite, but we need to keep our 8 original algos as anchors, to prevent certain attacks. Their contribution can be reduced like terms in the infinite series Sigma_i=1^inf 1/n, which diverges, so you still need infinite energy to control their hashpower

I changed my mind on OP_COMMENT. I am now working on OP_PUSHCODE, as you can see in my dev branch (https://github.com/akrmn2021/bitmark/tree/dev). Already this one give us one nice application: ability to create a decentralized github. Once that's done, I want to implement a VM with LLVM (to compile C code into bytecode). Then, the voting system, to put it all together. I've thought of ways to implement confidential voting without complicated ring signatures.

I also came up with a way to pay content creators and give them a reputation in general on the blockchain. In science, reputation is based on a 'citation' index. Similar idea but more general, and involves efficient proofs being published to the blockchain. The content can be anything, not just code, and most parts of it can be hashed to save block space.

Also, I think CEM should be parameterized (to allow for more algo slots), and adjusted to work also on fees, not just subsidies. This would help with 'feast before the famine' and can help with paying the content creators, as I will explain later.

AK (piratelinux)

[bitmarkcc]

We should decide whether we need a hard fork. I think all changes we want can be made via a soft fork if we are creative.

The overflow bug for CEM and the resurrector bug (can think of it as a feature) are what I had in mind for a hard fork, but I don't want to cause too much disruption to the ecosystem just for these. The effects are small and I think we are fine even without fixing them, but I can imagine some workarounds for fixing them. Also note that CEM only acts on the subsidies, not fees, so the effect will be less with time.

For all changes that I think we need, OP_PUSHCODE is critical. It is not just for code but for any data, and it allows linking parts together and creating different branches. Nodes would need to index the 'code' so that they have random access, at least for some past number of blocks (like 1 year of blocks).

I think we also need a separate operator that gives a script hash or address associated with a code/data push, so that content creators have a way to get paid in the future if their work is 'cited'.

Would anyone be interested if I made a BIP (Bitmark Improvement Proposal) laying out the specifications of OP_PUSHCODE?

I'm working very offgrid now, but soon will have a better connection :)

[melvincarvalho]

@akrmn2021 hi Andrew!

Firstly thanks for all the amazing work you've done on the chain. The blocks are now flowing freely, and this is really no small achievement, considering where we started. Not only that, the thought and creativity that went into the design was immense given our small and volunteer based team. The merge mining also gives peace of mind regarding security, and has a side-effect that miners will distribute bitmarks onto the market at cost, creating a provably fair distribution

I think there's not been enough credit for this work, and everyone definitely wants to say a big thank you

Regarding the different topics, namely, resurrector edge case, op codes stuff (RETURN / COMMENT / PUSHCODE), dynamic PoW, I think a good starting point would be to create separate issues, as they merit their own discussion. I've tried to do this a bit in some of the recently raised issues

Procedurally, I think the best route for suggesting a fork would be a BIP which is sort of industry best practice. Appreciate we've been in emergency mode for a while so sometimes the code has to be prioritized, but that in turn has bought us some breathing space to do a bit of maintenance and tie up loose ends. The bar for forks is quite high in our project as our aim is for a simple block chain, and then to put the complexity at a higher layer, closer to the user level

On the topic of opcodes, I would like to discuss some hypothetical issues, which are better suited to chat, if you get time. I was wondering if we currency have OP_RETURN in production. And I'd like to learn more about OP_PUSHCODE as that's new to me

In general I think there's a will to start to focus less on the now functioning chain, and focus on the layers above, layers 2 and 3. There's lots of ways of looking at the project but one I like, and that I think could align all of our thinking is that the value of bitmark is the sum total of all the marking that goes on. And then use that to guide our thinking

One thing I really like and is along those lines is the work that I think you did with open timestamps, on timestamp.bitmark.one. I think we can take this to the next level by extending some of the Peter Todd ideas towards his use of single use seals. You might find that you really love this concept once you get your head round it. There's a lot of crypto in it and a lot of power. For example the idea of smart contracts and preventing double spend could actually occur in a richer environment, in a way that's not been done anywhere before. We can solve some big problems I think, and RGB is doing something similar there

Regarding being off grid, no issues at all, our chain now I think can support 100 developers / communities / projects easily. And people can dip in and out of the work they want to do in a permissionless way. So drop in and chat anytime you feel, we aim to be a long-term project!

[bitmarkcc]

@melvincarvalho: Thanks, the architecture of the last hard fork was mainly pioneered by @dbkeys so I would like to credit him as well.

There's a lot to discuss, so I don't know where to start...

But first note that OP_PUSHCODE is my own invention, so that's why you never heard of it. And yes I think this is needed for the next layer of functioning, i.e. creating a reputation system instead of a vanilla chain, though it can even be used to create a highly secure vanilla chain.

@melvincarvalho : you mentioned sidechains, and I think there are various definitions of sidechains, so maybe what I want to do with the VMs can end up as a sort of sidechain. But most important is that proof of work on the VMs is validated by users. I know with the federated peg you need some kind of reputation system for who to trust in the federated peg, and last time I checked, drivechains is where miners validate and keep track of the various sidechains, and I know it's controversial because top Bitcoin developers like Peter Wuille were not interested in working on that.

I think there are 3 types of reputation we have in mind. 1) Reputation of people to not steal your money, like with federated pegs 2) Reputation of code, like with the unit testing miners idea I mentioned 3) Reputation of people to produce useful content

So we need to clarify what types of reputation we want to cover. I think (1) can actually be solved similarly to how I solved (2). The algo for the miners can be set to iterate over various sidechains of interest, and validate that the federated peg is not cheating people. I know mining algos have to be fast and can't run for hours, but we can save some sort of state in our block data (like disk space for miners), so I think the VM / voting system idea can have many applications I still didn't even think of. Basically, it will turn our miners into workers that can perform all sorts of useful work including giving reputation to people/things.

I think for 'proofs of useful work' to work, we need two ingredients: 1) multi algo, so that an algo that is producing too many exceptions gets shut off without impacting the target time/flow of the blocks. We have this. 2) dynamically changing algos – I think this should be our next step.

I still didn't explain the voting system, but basically I want all parameters that we may want to change to be controlled by the 2 most important stakeholders of Bitmark: 1) users – those who pay fees to make transactions 2) shareholders – those who own a significant share of marks User votes are the fee weighted transactions, and shareholder votes are volume weighted transactions. (they signal the vote in each transaction) We need both to agree with 75% to make a change. Probably there would be a proposal period (like 3 days), and the proposal with the most fees supporting would be the binary yes or no vote in the voting period (next 3 days). Then we repeat but the most volume weighted proposal taking precendence, and we alternate like that. To prevent miners from censoring votes they don't like we can let the votes be hashed, and later revealed in future blocks, and our hash function can also be one of the dynamically changing algos, to future proof it from quantum attacks. I think a join market can make votes more confidential, and we can even allow for fractional votes. Maybe in the future most users will be on a lightning network and will vote through those who settle in the chain, so a vote won't be just 0 or 1 but 1 of 100 possibilities from 0.00 to 1.00. More details later.

I think this can all work out as a series of soft forks as I can explain later...But if we want a hard fork then I think we need both an urgent need and it would be too cumbersome to satisfy it with a soft fork.

And yes I will look into the single seals and other things Melvin mentioned.

By the way are we confirmed tradeable on Bisq? Lets make sure we don't lose that.

[bitmarkcc]

Also I encourage people to use the timestamping functions of Bitmark to store a record of their work. I think soon we can implement a v1.0 reputation algorithm that also gives reputation to past work submitted to the blockchain. We don't currently have a way to specify tipping addresses with OP_RETURN, but if you embed an address with your work, then hash all that and timestamp it, our algorithm could use the first embedded address by default, or it can look at ther other outputs in the tx.

The general idea is that any time your work is 'reused' for some other work, you can claim BTM with just a transaction that provides a short proof, and more goes to those who created the work earlier than later. These transactions can possibly live on a sidechain, but some stuff like code for dynamic PoW should live on the main chain, so everyone validates it. The BTM for paying people for the work someone reused can come from CEM on fees and all work (initial work and remixed work) would be timestamped on the chain.

Like Melvin said, we could use more volunteers in order to speed up development.

[melvincarvalho]

@akrmn2021 I've separated out the first point you raised on OP_PUSHCODE into its own issue, https://github.com/project-bitmark/bitmark/issues/115 As this thread is more of a general nature (tho there's some overlap). We can do similar for other proposals. I think it would be perhaps helpful to also have a headed section on motivation

Regarding side chains, there are various definitions indeed. But the idea is that various systems can experimented with, without impacting the main chain

I think there's benefit from separating work into two work streams

• permissionless dev
• permissioned dev

The first, "permissionless dev", I think is where marking uses the chain in one of two ways. Either using bitmark as a glue between reputation systems and funding source, like we piloted successfully with poloniex. Or to use the chain, say for time stamping reputation trees like with chainpoint, opentimestamps, or single use seals. By my estimation, the chain as it is today (vanilla chain) could support over 100 developers / communities / projects, working independently, and all adding value to the bitmark ecosystem. In this way bitmark becomes the value of the sum of all the marking going on. Our aim is to lower the bar for participation in this regard as we only have a handful of devs right now, and can support many more

The second stream, "permissioned dev", would be something that affects everyone in the eco system. So something like on-chain changes, forks. There is a much higher bar for this, and requires unanimous consent, motivation, documentation and testing. At the same time we want to provide space for people to work on the things that they are motivated to, so hopefully we can work out a way to do that in a way that everyone can be happy with

The concept of a side chain is a middle ground in this regard, so that new ideas can be developed and experimented with on a side chain, and without impacting the existing chain

The challenge, which I think is still sort of an unsolved problem is the peg in, and particularly peg out (which involves some degree of trust and reputation). A way to solve this in a general sense would be a far reaching innovation. That ties neatly into the next point

I think there are 3 types of reputation we have in mind.

Reputation of people to not steal your money, like with federated pegs

Yes, so that's a topic in itself. There's emerging R&D in this space, for example the Liquid federation, RSK, and increasingly many new projects. When we develop our reputation algorithms further, we can perhaps make some advances here

Reputation of code, like with the unit testing miners idea I mentioned

Important yes. I've heard in recent days ideas of a git commit being marked, of checkpoints being marked or of bounties being awarded for pull requests after a merge. This is perhaps something that can be explored more (new issue)

Reputation of people to produce useful content

This is the heart of the marking project. Our most successful period was when we had this going, in the poloniex troll box. We, in a sense, had to pause our deployments for user generated marking (generally at the web layer) as we wanted to get a base chain that would work and be on at least one exchange. We have that now, so the opportunity is there to try and kick start that again

Re voting system, would also like to understand that better (new issue pls)

shareholders – those who own a significant share of marks

We dont differentiate someone who ones 1 bitmark from someone that holds 1000 bitmarks. That's why we have proof of work and a fair distribution, no premine, no instamine etc. While this has put us as a short term disadvantage to our competition, hopefully will differentiale us in the long term. This has been a hard route for all the developers, but there is a kind of social contract with everyone that has gone that route so far, that have donated, have sacrificed, invested time or capital etc. on a volunteer basis

Also, we have been guilty in the first years of taking on too much. With a small volunteer team, there's only so much that be achieved at one time. The work on the fork meant that the work on marking came to a stand still. It didnt have to be that way, but just one of those things of divided focus. Part of the motivation for this issue would be to try and get back focus to marking, based on our small sized team, without too much central coordination required

We don't currently have a way to specify tipping addresses with OP_RETURN, but if you embed an address with your work

Does OP_RETURN actually work on the current chain. I have some questions and thoughts on this, that are better suited to the chat format

Hope I've covered some of your points. In general I think the 'vanilla' chain that we have today is robust enough to support 10x or 100x the number of developers and projects that we have today. Also in a permissionless way so that everyone can work independently without impacting each other, requiring central coordination, or having to learn about what others are doing. We just need to use it and battle test it now!

[bitmarkcc]

Thanks for the comments, I know theres a lot to digest, and except for PUSHCODE it's all just ideas in my head right now.

We need to figure out why there is a shortage of activity. Why am I so interested, and very few other developers are interested? I remember when I first researched Bitmark in 2017 it looked a bit scammy, there was some description of reputation as some 'purple bar of trust' (silly) and in the wiki the description of marking basically reduced to 'marking is the sending of BTM to someone'. Lets fix some of these things as well as the confusion between bitmark.com and bitmark.io.

I think in the future when historians study the informatic history of the current times, they will look at Bitcoin for timestamps from 2009 to 2018. But after our hard fork in 2018, they will use the Bitmark blockchain for accurate timestamp information. Due to merge mining, we are not only timestamping the Bitcoin chain but also other chains, and our multi-pow and diff adjustment makes the timestamps more accurate and secure in some sense.

For the voting system, I think we should create new topic. I'm not saying that people with a large share of coins should decide on changes, I'm just saying that they should need to show some sort of consent (in addition to consent from fee paying users). The consent from both parties is needed only to make changes, if 1 of the 2 doesn't consent, then no changes happen. I think this is most conservative for making sure that the changes are not controversial and will not cause a large disruption in the ecosystem. But we can discuss in another thread.

[melvincarvalho]

@akrmn2021 sounds great

I think in general its really hard to get developers interested in a project, mainly because, there's so many projects out there. It's also hard to retain developers, and part of the reason for that is burn out, of which we had quite a lot. One big reason for in our case was that we were spread thinly and took on too much, at a time when we were getting quite successful. We've had about 1 developer a year get interested enough to get marking done in a particular community, and by far the most successful was Tristan of poloniex with the troll box implementation. So, that shows it can be done, our pilot went really well, only problem was the poloniex got bought. But the good thing about marking is that each marking is a mini advert for the project. So eventually as communities use it (if they do!) people find their way to us, create more marking instances and it becomes a virtuous circle (we hope!)

Thanks for these suggestions, and they do deserve issues in their own rights

Regarding voting, this is historically a big can of worms in reputation systems due to 'vote stuffing' meaning that votes can be bought. So voting is normally a last resort in consensus systems, which often are better with ack/nack type systems. Bearing in mind no consensus system is perfect. Then again, hopefully we can experiment and innovate in that problem space, over time!

[bitmarkcc]

If anyone wants to contact me, I am reachable on keybase (https://keybase.io) with username akrmn1.

In particular I want to chat with people who are interested in pushing forward development (core protocol, marking apps, mining)

I suggest creating a public development channel on keybase or telegram, and I am ready to make a marking bot, whichever we choose.

[melvincarvalho]

@akrmn2021 thanks for sharing those details

I'm on keybase, but I'm less of a fan since they shoe horned in stellar as their crypto currency

We do have slack right now, but it's not hugely used currently, however there's 500+ people in there. We had marking going pretty well at one point

I think a telegram bot could work very well with marking as there are 1000s of communities that could potentially benefit. We've seen from the past that introducing marking to communities is a big win on many levels:

• communities get more helpful and stronger
• bitmark does well as it is the sum of all the marking that goes on
• each marking is a mini promotion of the overall project, creating a viral path
• people that use marking find their way to the project and contribute more

I've had a quick go at creating a telegram bot, but it's still very much under construction, however may be some food for thought for you

https://github.com/melvincarvalho/telemarking/tree/gh-pages/commands

[melvincarvalho]

@akrmn2021 @dbkeys you mentioned in the past some interest in chainpoint. I've heard some increased interest in chainpoint lately as a way to scale up marking massively. I was wondering if you had any thoughts on that or, if it lead to some prototyping?