This post was originally placed here.

About 11 months ago, I posted to this sub the following article and I’m writing now, to follow up with results.

Lynx Hybrid Proof of Work – for consideration from CryptoTechnology

It took several months to seamlessly phase in the various Rules 1, 2 & 3 and we did it in a manner that allowed the Rules to start out less strict and then progressively get more restrictive over time. The final phases of implementation are posted with our latest release below.

What we learned.

We learned that the timing on the phased release of Rules 1, 2 & 3 was too conservative. We ended up accelerating the release phases more than once in the series of releases we did over time. We ended up releasing 4 versions of lynxd that encapsulated these changes. The final .9 release is the only one supported now.

We learned that the Rules work, but they (as predicted) negatively impact block time. With Digishield, the goal is to get a 30 second block time before we started working on the Rules of HPoW. We knew from research that a 30 seconds block time is REALLY much too fast and that a block time of 2.5 minutes is ideal. Before we decided to address that we wanted to see if the Rules would have a heavy impact. They did, and it’s not hard to understand why. In order for the HPoW Rules to work well, we need a LOT of nodes, well over 150 nodes to have a minimum number of candidate blocks being submitted by miners. If we fell short, nodes would start to display warning messages about out of date ‘tips’. This was frustrating, but the answer was to fire up more nodes. As this was done, day after day, the ‘tip’ warnings went away, block times improved and overall the network health improved. That frustrating wait time before a first confirmation started to diminish.

As for the block time, we just dropped below the 3 minute barrier about 36 hours prior to writing this. That is a great sign. Since we are a very experimental scrypt coin project, we don’t have a lot of nodes coming online right now, but we hope to change that soon. (For those of you reading this, Lynx has a built in miner and the eco-friendly design Rules of HPoW make Lynx unprofitable to run on an ASIC. Our hashing times are currently trending ~7 kH/s while still being resistant to a 50% attack.) The idea is that if block time settles at 2.5 – 3 minutes we would be very happy with that, but if more nodes come online and the network grows, then our users will benefit from an even faster block time. If we find over time that network latency is a problem for the mesh of nodes, then we modify Digishield to slow down the block time as needed. This might happen once we get 2,000+ nodes in the mix. (Our latency planning is based on direct node to node latency of 160ms on average.)

We learned that Rule 3 created a serious throttle on candidate block release. A chance of 1 in 16 for a candidate block to be accepted was very strict and if I could have lowered it a bit I would have. The nice thing is that our Raspberry Pi nodes are getting their candidate blocks accepted almost as frequently as our more powerful VPS nodes that are pushing 6x the hashing rate. I personally have looked over the hashing outputs of 40+ nodes and the range of hashing power being generated by each is vast. But the immature coins from mining that each has on hold (Lynx has a 20,000 block maturity) is averaged out nicely across the infrastructure.

We also learned that hardly anyone read our whitepaper. The time and effort we put into getting it right and documenting our philosophy as well as business rules – they were ignored for the most part. Most of the feedback we received was either ‘You can’t do that.’ or ‘When will my coins be worth X so I will be rich off your work?’ Yes, slightly frustrating, but we did a good job of ignoring these statements. (For an aspiring coin developer, we recommend you develop a thick skin before getting into the space – the members of your community can be brutal at times.)

Overall, the implementation of HPoW went relatively smooth and the Rules work. This Litecoin clone has a FAR more energy efficient mining algorithm. We feel our direct (friendly) competition is Nano and Algorand. We aren’t trying to beat those projects with regard to transactions per second, but instead network security and low energy consumption. While miners with ASICS can mine this coin, they find out quickly that it’s not worth the energy cost. Additionally, the ability for a fast miner to predictably win a block (or control a series of block) makes this blockchain project a success. We have already begun building an application on top of Lynx and our hope is to keep Lynx stable and functioning properly.