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