ASIC's, Block times, and Current Focus


The question on everyone’s mind is what is the team’s plan for STRAKS?

It’s important to remind everyone STRAKS is an open source project, and anyone is able to contribute to the STRAKS blockchain tools.

We strongly encourage you to leave your comments below. Nothing! is set in stone. We truly want to get feedback from the community. After enough time for collecting comments has passed we will use those to help formalize a specific direction.

We are working on implementing lyra2rev3 as an interim POW solution for testnet. We understand this is a short term solution and may not be the best route. The best solution for the interim is to come up with our own variant that is not implemented by any other coin to minimize the impact of hashrate fluctations on block generation time caused by multi-coin profit switching. However, there would be a lot more work required to implement our own POW algo. Since that would also require mining software support.

Long-term we are evaluating HyperLedger. HyperLedger has many features that would directly support the long-term vision of the STRAKS project as outlined in Squb’s memo that was published November 2018. We will release more details as to why we feel HyperLedger is a good fit for the STRAKS Project in another post in the next few weeks.

Block generation, block times, and stalled network issues. Anyone who has read the STRAKS core details is likely wondering why the blockchain has been struggling to maintain an average of 60 second block generation. We selected the D106 difficulty algorithm due to its dynamic difficulty adjustment in short time-frames. At the time of its selection it had been tested and proven to maintain an average of 60 second block times with hashrate variations of up to 40x average levels. In layman’s terms if the average hashrate on the network was averaging 20 GH/s the difficulty methodology could easily handle up to 800 GH/s mining of STRAKS in bursts without adversely affecting the average block time in a given timeframe. However, since the release of ASICS, and combined with the impact of multi-coin profit mining pools bringing upwards of 1.5 TH/s to the blockchain, when the average hashrate is at times only 8-10 GH/s causes the difficulty to spike to such a level that it can take a few hours for the next block to be generated at which point the difficulty will only fall by 1/4. thereby requiring 2 or 3 blocks before block generation times will decrease. Which then in turn often triggers the multi-coin pools to jump back onto the project. creating a never-ending cycle of fast block generation and then a stall.


Well, in recent days, many people are asking us what our position in the matter of ASICs is.Squbs proposed Progpow. As I read it looks more interesting for long-term solution than lyra2rev3. As you said, these hashrate spikes definitely destroys current idea of mining STRAKS and the priority should be changing it. However, I am not familiar enough to be able to decide what could be better in implementation for us.

Hyperledger looks to be fine too especially if you consider these large corporations that have “partnership” on this project.They described an interesting algorithm there. Maybe I’m wrong but I am afraid that it would require a lot of work to implement especially it seems to be a system for overall blockchain solutions not usual coin/tokens solutions we know and it will require much more work than preparing hard fork.



At present, a large majority of the community is focusing purely on the network and hashrate spikes due to ASICs. Whilst this is an issue, if the network had more support behind it, current players would lose their foothold. Personally, I feel that focus should always be on the use of a chain. When the use becomes one that is demanded and wanted in the community, additional network support will appear.

With current market sentiment I do realise that use is going to be minimal at present, especially with the network issues we are currently facing. Hence further discussion of algo’s is below.

Hashing Algorithms

Lyra2rev3 - Implementation of R3 as an interim solution is fairly straight forward as it has already been done with Vert. It is, after all, their creation I believe. Currently there exists a branch of STRAKS Core that has R3 implemented and is working locally. Migrating to testnet and then mainnet is not a difficult task, however the time-frame of when it becomes activated on the chain would need to be fairly substantial to allow community, masternodes, exchanges, satellite services, etc, to update their wallets and implement any necessary changes.

It must be considered that R3 will not remain ASIC proof forever. As is the case with Vert, they are only doing it due to pressure from their community, otherwise they would wait for their upcoming Verthash and just switch straight to that. For us, we would need to then start works on our next algo jump, and with the time needed to move to R3, that jump might have to be fairly immediate.

Lyra2rev2 + Lyra2rev3 - A shower thought today was the possibility of moving to a dual algo to allow both GPU and ASIC to live in harmony. The idea would be that more weight is placed on the GPU miners via R3, whilst still maintaining some of the ASIC hashrate through retaining R2.

The vision would be that for X number of GPU R3 blocks, ASICs can mine a block using R2. e.g. 10 blocks require a hash with R3, and block 11 must be R2, repeat.

One positive with this is that the hashrate does not instantly disappear, and ASICs would continue to provide network stability, however GPUs get back the power in a sense, and miners around the world rejoice. The issue though is once R3 is ASIC’d, we are back to where we are. Also, each algo would require a unique diff calculation so the switch from R2 back to R3 doesnt result in a massive diff for GPUs to solve.

ProgPoW - The premise behind this solution appears sound. It allows for ASIC and GPU mining to live in harmony, without ASIC having a massive advantage. Essentially, ASIC and GPU are back to a level playing field due to the complexity required for ASICs to calculate this algo.

A transition to ProgPoW is a lot more work than R3, but since there are already codebases out there and working implementations it should not be an impossible task. I will be looking at this option over the next week and bashing out a working local solution to see if it is a possibility for STRAKS future.

Blockchain Frameworks

Hyperledger - Backed by some big players, Hyperledger has a wide range of blockchain solutions and products for specific edge cases and corporate needs. Switching to something like Sawtooth would be a huge challenge, as we would have to learn their codebase, but the biggest challenge would be bringing it into the public field. They are heavily focused on internal enterprise networks and this could all collapse when the general public start smashing the network with all the abuse that most chains see. Understanding exactly how their products work is again, a massive undertaking.

Long term, I would not be surprised of an alt appears that uses one of their products. I am actually surprised one has not already. I am all for being first, but a shift to Hylerledger at this stage is a massive risk.

Current Difficulty

ASICs. Not much we can do without implementing a new algo, unless we rent out bulk hash and that is a bank breaker.


This would also significantly reduce the likelyhood of ASIC owners not updating their wallets.


The entire solution could be replaced by an interest in the project…
Not a big price increase has increased the network’s hash rate…


Not to disagree with your observation, but I will add an additional observation. With Vertcoin having moved to lyra2rev3 that has removed a rather large project off of the lyra2rev2 mining pools. Allowing STRAKS to be jumped back onto by the miners more often. Which has definitely increased the frequency in which signficant hashpower has been mining on the project.

Also for a week straight I personally rented an ASIC to mine STRAKS on a pool that does not switch coins based on profitability. Which also helped reduce the lagging blocks during that period. Leading up to Vertcoin’s switch to another algo.


I think that the team has made fantastic technical decisions to this point. Lyra2Rev3 sounds like a fantastic stopgap to get us through the crypto-winter, and would also generate some buzz that the coin is keeping up with technological advancements. I agree that this would be a non-issue if overall network hashrate were higher, though I suspect that we don’t see as much as we do because of the distribution of rewards between masternodes and miners. As a fairly substantial stakeholder I benefit greatly from this distribution so it’s in my best interest to promote a new algorithm that can’t be gamed as easily over a modification to the masternode distribution scheme.

I admit that as a technologist I am very interested in seeing a popular coin come to hyperledger, as I don’t think anyone has done it yet. However, I am immediately skeptical that a swap mechanic to the new chain would be less than equitable to existing hodlers, who would be your greatest supporters. If the team does decide to proceed with the plan to move to a new type of blockchain, I would strongly urge you to account for your early adopters and those who have joined in the past year and provide a swap mechanic that does not dilute owner equity of supply on the new chain.

Anyways, thank you for your hard work on this project!

1 Like

Not speaking for Core Dev, but commenting on what is likely, The circumstances of the swap for Signatum coins vs. a swap to upgrade technology are significantly different.


I would suggest moving to POS only. POW hasn’t been profitable for long time. I personally have only 1/6 of all mining rigs left and not planning to buy FCPGA or ASICs at least not with current prices. You even can make thinks interesting and link MN to marketplace with discount and fee sharing to stakers.