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)