<div dir="auto">This is a great solution. <div dir="auto"><br></div><div dir="auto">8 or more secure hashes, each of which can be implemented on GPU/CPU, but rotate through them - per block round robin.<div dir="auto"><br></div><div dir="auto">Hardware, infrastructue investment is protected. ASIC is not.</div><div dir="auto"><br></div><div dir="auto">Each pow has different tracking metrics and difficulty adjustments. This means the difficulty adjust will be less accurate (1/8th the samples), but that's never been an issue.</div><div dir="auto"><br></div><div dir="auto">ASIC will never beat this - because it will be 8x more expensive to maintain the cold circuits. </div><div dir="auto"><br></div><div dir="auto">Miners with gpu/generalized hardware will always be in business. </div><div dir="auto"><br></div><div dir="auto">Should be done gradually and pre-emptively. Change one at a time on a slow schedule, allowing a graceful transition.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mar 20, 2017 8:59 AM, "Marcos mayorga via bitcoin-dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
Just a thought,<br>
Bitcoin developers shouldn't care about miners business model, they can<br>
always sell their hw and close the bz as soon as bitcoin hardforks to<br>
better ways of doing.<br>
Just focus on making a better cryptocurrency, the more decentralized the<br>
best.<br>
<br>
M<br>
<br>
> By doing this you're significantly changing the economic incentives behind<br>
> bitcoin mining. How can you reliably invest in hardware if you have no<br>
> idea<br>
> when or if your profitability is going to be cut by 50-75% based on a<br>
> whim?<br>
><br>
> You may also inadvertently create an entirely new attack vector if 50-75%<br>
> of the SHA256 hardware is taken offline and purchased by an entity who<br>
> intends to do harm to the network.<br>
><br>
> Bitcoin only works if most miners are honest, this has been known since<br>
> the<br>
> beginning.<br>
><br>
> On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
><br>
>> I’m very worried about the state of miner centralisation in Bitcoin.<br>
>><br>
>> I always felt the centralising effects of ASIC manufacturing would<br>
>> resolve<br>
>> themselves once the first mover advantage had been exhausted and the<br>
>> industry had the opportunity to mature.<br>
>><br>
>> I had always assumed initial centralisation would be harmless since<br>
>> miners<br>
>> have no incentive to harm the network. This does not consider the risk<br>
>> of a<br>
>> single entity with sufficient power and either poor, malicious or<br>
>> coerced<br>
>> decision making. I now believe that such centralisation poses a huge<br>
>> risk<br>
>> to the security of Bitcoin and preemptive action needs to be taken to<br>
>> protect the network from malicious actions by any party able to exert<br>
>> influence over a substantial portion of SHA256 hardware.<br>
>><br>
>> Inspired by UASF, I believe we should implement a Malicious miner<br>
>> Reactive<br>
>> Proof of Work Additions (MR POWA).<br>
>><br>
>> This would be a hard fork activated in response to a malicious attempt<br>
>> by<br>
>> a hashpower majority to introduce a contentious hard fork.<br>
>><br>
>> The activation would occur once a fork was detected violating protocol<br>
>> (likely oversize blocks) with a majority of hashpower. The threshold and<br>
>> duration for activation would need to be carefully considered.<br>
>><br>
>> I don’t think we should eliminate SHA256 as a hashing method and<br>
>> change<br>
>> POW entirely. That would be throwing the baby out with the bathwater and<br>
>> hurt the non-malicious miners who have invested in hardware, making it<br>
>> harder to gain their support.<br>
>><br>
>> Instead I believe we should introduce multiple new proofs of work that<br>
>> are<br>
>> already established and proven within existing altcoin implementations.<br>
>> As<br>
>> an example we could add Scrypt, Ethash and Equihash. Much of the code<br>
>> and<br>
>> mining infrastructure already exists. Diversification of hardware (a mix<br>
>> of<br>
>> CPU and memory intensive methods) would also be positive for<br>
>> decentralisation. Initial difficulty could simply be an estimated<br>
>> portion<br>
>> of existing infrastructure.<br>
>><br>
>> This example would mean 4 proofs of work with 40 minute block target<br>
>> difficulty for each. There could also be a rule that two different<br>
>> proofs<br>
>> of work must find a block before a method can start hashing again. This<br>
>> means there would only be 50% of hardware hashing at a time, and a<br>
>> sudden<br>
>> gain or drop in hashpower from a particular method does not dramatically<br>
>> impact the functioning of the network between difficulty adjustments.<br>
>> This<br>
>> also adds protection from attacks by the malicious SHA256 hashpower<br>
>> which<br>
>> could even be required to wait until all other methods have found a<br>
>> block<br>
>> before being allowed to hash again.<br>
>><br>
>> 50% hashing time would mean that the cost of electricity in relation to<br>
>> hardware would fall by 50%, reducing some of the centralising impact of<br>
>> subsidised or inexpensive electricity in some regions over others.<br>
>><br>
>> Such a hard fork could also, counter-intuitively, introduce a block size<br>
>> increase since while we’re hard forking it makes sense to minimise the<br>
>> number of future hard forks where possible. It could also activate<br>
>> SegWit<br>
>> if it hasn’t already.<br>
>><br>
>> The beauty of this method is that it creates a huge risk to any<br>
>> malicious<br>
>> actor trying to abuse their position. Ideally, MR POWA would just serve<br>
>> as<br>
>> a deterrent and never activate.<br>
>><br>
>> If consensus were to form around a hard fork in the future nodes would<br>
>> be<br>
>> able to upgrade and MR POWA, while automatically activating on<br>
>> non-upgraded<br>
>> nodes, would be of no economic significance: a vestigial chain<br>
>> immediately<br>
>> abandoned with no miner incentive.<br>
>><br>
>> I think this would be a great way to help prevent malicious use of<br>
>> hashpower to harm the network. This is the beauty of Bitcoin: for any<br>
>> road<br>
>> block that emerges the economic majority can always find a way around.<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
>> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
>><br>
> --<br>
> Andrew Johnson<br>
> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
><br>
<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>