Improvement Rate Of Asics Developed For Blake-256?

I see the topic of ASIC resistance and how many people desire it comes up quite often. After reading several of the responses in this thread, I'm sure my response is going to be an unpopular one, but, personally, I think the eventual development of ASICs for Decred is not only a favorable outcome, but it is necessary to help protect it.

However, before I go into the specifics of why, I'd like to touch on the feasibility of even developing such a system. To be perfectly honest, it is quite likely to be an exercise in futility. While you might be able to stave off ASIC development for a time, you simply open the door for other methods to centralization such as botnets. For example, the rotating algorithms suggestion has already been deployed by VertCoin and it was effectively defeated by botnets that took over the network. CryptoNote tried CPU-friendly mining with the same result. LiteCoin tried a memory hard algorithm (scrypt) and ASICs were eventually developed for it too.

The end result is always the same in that the mining platform and PoW 'votes' on the network is simply a matter of money. Whether you're mining with a botnet, GPU farm, or liquid immersion ASIC facility, PoW mining always results in centralization. Looking at the underlying reasons why this happens helps make it rather clear that centralization is inevitable because capital costs for mining increase over time while profits decrease. The best you can do is try to give each miner (pool, GPU farm, ASIC farm, etc) on the network a single decentralized vote which is exactly what Decred already does.

With that out of the way, let's move into why ASICs are actually a favorable outcome. You see, as long as relatively cheap ASICs do not exist for Decred, there will always be the looming vulnerability that a malicious actor could create a Blake-256 ASIC behind the scenes and then use it to wreak havoc on the network through constant reorgs. This is possible because a single ASIC could completely destroy all of the current GPUs. At the current time, the global hash rate on the network is right around 3.4TH/s. That means a single ASIC (an AntMiner S7 can do ~4.7 TH/s of double SHA-256 and Blake-256 is a more efficient algorithm, so you could expect even higher rates for the same level of hardware) could effectively provide more hash power than the entire network has right now. Once there are a proliferation of ASICs on the network, the possibility of such an occurrence greatly diminishes. Thus ASICs, even if centralized, help secure the network against malicious actors.

The absolutely best outcome would be users coming together to produce and distribute ASICs in a manner opposite of Bitcoin where they were hoarded. However, even if that doesn't happen and ASIC centralization were to occur, the results on Decred are no where near as dramatic as they are with pure PoW coins. This is because Decred's Proof-of-stake component makes it so that each block on the network is 'checkpointed' by the stakeholders. It is literally impossible to even make a two-block long fork without the collective consent of the stakeholders. As a result, a PoW miner can't create a 6-block long chain in secret and use it to double spend coins like they can in a pure PoW coin. In Decred, there will never be a need to go before a panel of voters and beg for their approval. The owners of Decred will always have the power to dictate the future of the currency.

 

These are valid questions and ones that I believe have been covered in the understanding proof of stake thread to a degree, but I'll attempt to elaborate a bit here.

I think the biggest challenge is that, at the current time, it's a little bit difficult to see what is possible because there really isn't much capability beyond voting yes or no exposed to the user. The mechanism you're looking for in order to vote more intelligently is configurable policy controls. Policy controls would make it possible to select when to vote yes or no depending on whatever criteria the particular voting software being used makes available. The expectation is that such controls will be developed and improved over time.

As a concrete example, with software available to allow it, it would be possible to configure your policy to vote no on blocks that don't include any transactions even though the memory pool has thousands. Contrast this with Bitcoin where some miners with poor connectivity intentionally choose to create blocks with no transactions in them because larger blocks lead to longer propagation time and greater chance of becoming orphaned. There is really nothing that can be done about it in Bitcoin because miners have all the power.

Perhaps another key point here is that policy controls don't have to be developed by the original Decred developers. Even though there isn't a lot of external software yet, there is absolutely nothing stopping anyone from writing voting software with any policy controls they desire. All it has to be capable of is generating a vote transaction that conforms to the spec and broadcasting it to the network. This is possible because the stake voting system was designed to allow voting rights to be delegated to a different address while the consensus-enforced reward address commitments are in the initial ticket purchase.

However, what is perhaps more important to realize than all the above is that voting has much greater implications and capabilities than simply voting whether you wish to deem the previous block as valid or not. Under the hood, a vote really consists of an extensible set of bit flags. This allows any voting agenda you can imagine to be assigned to one or more of the bits where the majority stakeholders make a public and transparent decision that is encoded into the very fabric of the blockchain. This means that whenever there are major decisions to be made about the future of the currency (an obvious example would be increasing the block size), the majority stakeholders make the decision via voting, not the developers or miners.