<oembed><type>rich</type><version>1.0</version><author_name>npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6</author_name><author_url>https://nostr.ae/npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2017-03-20&#xA;📝 Original message:By doing this you&#39;re significantly changing the economic incentives behind&#xA;bitcoin mining. How can you reliably invest in hardware if you have no idea&#xA;when or if your profitability is going to be cut by 50-75% based on a whim?&#xA;&#xA;You may also inadvertently create an entirely new attack vector if 50-75%&#xA;of the SHA256 hardware is taken offline and purchased by an entity who&#xA;intends to do harm to the network.&#xA;&#xA;Bitcoin only works if most miners are honest, this has been known since the&#xA;beginning.&#xA;&#xA;On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev &lt;&#xA;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&#xA;&gt; I’m very worried about the state of miner centralisation in Bitcoin.&#xA;&gt;&#xA;&gt; I always felt the centralising effects of ASIC manufacturing would resolve&#xA;&gt; themselves once the first mover advantage had been exhausted and the&#xA;&gt; industry had the opportunity to mature.&#xA;&gt;&#xA;&gt; I had always assumed initial centralisation would be harmless since miners&#xA;&gt; have no incentive to harm the network. This does not consider the risk of a&#xA;&gt; single entity with sufficient power and either poor, malicious or coerced&#xA;&gt; decision making. I now believe that such centralisation poses a huge risk&#xA;&gt; to the security of Bitcoin and preemptive action needs to be taken to&#xA;&gt; protect the network from malicious actions by any party able to exert&#xA;&gt; influence over a substantial portion of SHA256 hardware.&#xA;&gt;&#xA;&gt; Inspired by UASF, I believe we should implement a Malicious miner Reactive&#xA;&gt; Proof of Work Additions (MR POWA).&#xA;&gt;&#xA;&gt; This would be a hard fork activated in response to a malicious attempt by&#xA;&gt; a hashpower majority to introduce a contentious hard fork.&#xA;&gt;&#xA;&gt; The activation would occur once a fork was detected violating protocol&#xA;&gt; (likely oversize blocks) with a majority of hashpower. The threshold and&#xA;&gt; duration for activation would need to be carefully considered.&#xA;&gt;&#xA;&gt; I don’t think we should eliminate SHA256 as a hashing method and change&#xA;&gt; POW entirely. That would be throwing the baby out with the bathwater and&#xA;&gt; hurt the non-malicious miners who have invested in hardware, making it&#xA;&gt; harder to gain their support.&#xA;&gt;&#xA;&gt; Instead I believe we should introduce multiple new proofs of work that are&#xA;&gt; already established and proven within existing altcoin implementations. As&#xA;&gt; an example we could add Scrypt, Ethash and Equihash. Much of the code and&#xA;&gt; mining infrastructure already exists. Diversification of hardware (a mix of&#xA;&gt; CPU and memory intensive methods) would also be positive for&#xA;&gt; decentralisation. Initial difficulty could simply be an estimated portion&#xA;&gt; of existing infrastructure.&#xA;&gt;&#xA;&gt; This example would mean 4 proofs of work with 40 minute block target&#xA;&gt; difficulty for each. There could also be a rule that two different proofs&#xA;&gt; of work must find a block before a method can start hashing again. This&#xA;&gt; means there would only be 50% of hardware hashing at a time, and a sudden&#xA;&gt; gain or drop in hashpower from a particular method does not dramatically&#xA;&gt; impact the functioning of the network between difficulty adjustments. This&#xA;&gt; also adds protection from attacks by the malicious SHA256 hashpower which&#xA;&gt; could even be required to wait until all other methods have found a block&#xA;&gt; before being allowed to hash again.&#xA;&gt;&#xA;&gt; 50% hashing time would mean that the cost of electricity in relation to&#xA;&gt; hardware would fall by 50%, reducing some of the centralising impact of&#xA;&gt; subsidised or inexpensive electricity in some regions over others.&#xA;&gt;&#xA;&gt; Such a hard fork could also, counter-intuitively, introduce a block size&#xA;&gt; increase since while we’re hard forking it makes sense to minimise the&#xA;&gt; number of future hard forks where possible. It could also activate SegWit&#xA;&gt; if it hasn’t already.&#xA;&gt;&#xA;&gt; The beauty of this method is that it creates a huge risk to any malicious&#xA;&gt; actor trying to abuse their position. Ideally, MR POWA would just serve as&#xA;&gt; a deterrent and never activate.&#xA;&gt;&#xA;&gt; If consensus were to form around a hard fork in the future nodes would be&#xA;&gt; able to upgrade and MR POWA, while automatically activating on non-upgraded&#xA;&gt; nodes, would be of no economic significance: a vestigial chain immediately&#xA;&gt; abandoned with no miner incentive.&#xA;&gt;&#xA;&gt; I think this would be a great way to help prevent malicious use of&#xA;&gt; hashpower to harm the network. This is the beauty of Bitcoin: for any road&#xA;&gt; block that emerges the economic majority can always find a way around.&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;&#xA;-- &#xA;Andrew Johnson&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/8083629e/attachment.html&gt;</html></oembed>