* [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
@ 2017-03-18 16:01 John Hardy
2017-03-20 15:38 ` Andrew Johnson
2017-03-20 17:49 ` Bram Cohen
0 siblings, 2 replies; 15+ messages in thread
From: John Hardy @ 2017-03-18 16:01 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4445 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-18 16:01 [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners John Hardy
@ 2017-03-20 15:38 ` Andrew Johnson
2017-03-20 15:46 ` John Hardy
` (2 more replies)
2017-03-20 17:49 ` Bram Cohen
1 sibling, 3 replies; 15+ messages in thread
From: Andrew Johnson @ 2017-03-20 15:38 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, John Hardy
[-- Attachment #1: Type: text/plain, Size: 4678 bytes --]
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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Andrew Johnson
[-- Attachment #2: Type: text/html, Size: 6561 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-20 15:38 ` Andrew Johnson
@ 2017-03-20 15:46 ` John Hardy
2017-03-20 16:10 ` Andrew Johnson
2017-03-20 15:55 ` Marcos mayorga
2017-03-20 18:02 ` Nick ODell
2 siblings, 1 reply; 15+ messages in thread
From: John Hardy @ 2017-03-20 15:46 UTC (permalink / raw)
To: Andrew Johnson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5698 bytes --]
> 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?
Of course, that's why this is a last resort, successfully activated only in response to a contentious hard fork. If it succeeds just once it should help prevent the same situation occurring in the future.
> 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.
How so? If you have four proof of work methods, that 50-75% of SHA256 hashpower would equate to 13-18% of total hashpower. If you can harm the network with this much hashpower bitcoin was DOA.
________________________________
From: Andrew Johnson <andrew.johnson83@gmail•com>
Sent: Monday, March 20, 2017 3:38:01 PM
To: Bitcoin Protocol Discussion; John Hardy
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
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@lists.linuxfoundation.org<mailto:bitcoin-dev@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@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Andrew Johnson
[-- Attachment #2: Type: text/html, Size: 8742 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-20 15:38 ` Andrew Johnson
2017-03-20 15:46 ` John Hardy
@ 2017-03-20 15:55 ` Marcos mayorga
2017-04-16 20:04 ` Erik Aronesty
2017-03-20 18:02 ` Nick ODell
2 siblings, 1 reply; 15+ messages in thread
From: Marcos mayorga @ 2017-03-20 15:55 UTC (permalink / raw)
To: Andrew Johnson, Bitcoin Protocol Discussion
Hi,
Just a thought,
Bitcoin developers shouldn't care about miners business model, they can
always sell their hw and close the bz as soon as bitcoin hardforks to
better ways of doing.
Just focus on making a better cryptocurrency, the more decentralized the
best.
M
> 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@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
> Andrew Johnson
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-20 15:46 ` John Hardy
@ 2017-03-20 16:10 ` Andrew Johnson
0 siblings, 0 replies; 15+ messages in thread
From: Andrew Johnson @ 2017-03-20 16:10 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, John Hardy
[-- Attachment #1: Type: text/plain, Size: 7302 bytes --]
On Mon, Mar 20, 2017 at 10:47 AM John Hardy <john@seebitcoin•com> wrote:
> 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?
Of course, that's why this is a last resort, successfully activated only in
response to a contentious hard fork. If it succeeds just once it should
help prevent the same situation occurring in the future.
This seems a lot more disruptive to the network than a simple hard fork to
increase the block size. Compromise is the answer here, not taking our
ball and going home, in my humble opinion.
> 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.
How so? If you have four proof of work methods, that 50-75% of SHA256
hashpower would equate to 13-18% of total hashpower. If you can harm the
network with this much hashpower bitcoin was DOA.
I'm assuming the difficulty on the SHA256 PoW would drop by 50-75% as
well. So not nearly as bad as it would be with a single PoW and that much
hardware were available to an adversary, you're correct.
How would you handle starting difficulty on the other 3 PoWs? Seems like
it would be a race to start with, which strikes me as another potential
attack vector until the amount of hardware and price of production balances
with the price of the coin(which is likely to be volatile during this
turbulent period). Unless you start the difficulty at a higher value, then
you're just doing centralized economic planning and hoping you got the
numbers right so that you get the right balance of security vs incentive to
do malicious things like double spends.
All the solutions that people keep positing(such as Luke's complete PoW
change) seem like they'd be a whole lot more disruptive to the network than
an EC fork would be.
Isn't the main reason that everyone is up in arms because a contentious
hard fork is dangerous? I just don't understand how any of these solutions
are safer.
At that point we've lost our claim to fame, that changes to the protocol
are hard and you can trust that your value is safe. What you're advocating
seems like it would result in a huge drop in hashing security.
------------------------------
*From:* Andrew Johnson <andrew.johnson83@gmail•com>
*Sent:* Monday, March 20, 2017 3:38:01 PM
*To:* Bitcoin Protocol Discussion; John Hardy
*Subject:* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR
POWA): Protecting Bitcoin from malicious miners
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@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@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Andrew Johnson
--
Andrew Johnson
[-- Attachment #2: Type: text/html, Size: 13840 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-18 16:01 [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners John Hardy
2017-03-20 15:38 ` Andrew Johnson
@ 2017-03-20 17:49 ` Bram Cohen
2017-03-20 21:23 ` John Hardy
1 sibling, 1 reply; 15+ messages in thread
From: Bram Cohen @ 2017-03-20 17:49 UTC (permalink / raw)
To: John Hardy, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5479 bytes --]
It's possible to switch PoW algorithms with a soft fork rather than a hard
fork. You make it so that there are two different PoWs, the old one and the
new one, and each old-style block has to reference a new-style block and
contain the exact same transactions. The new work rule is that the weighted
geometric mean of the quality of the new-style block and the old-style
block has to exceed the work threshold, with the weighting starting almost
entirely on the old-style block and shifting gradually over to the
new-style block until in the end the amount of work to generate the
old-style block is completely trivial and doesn't matter any more.
The most interesting part of the whole thing is keeping it so that the new
work limit is consistently the limiting factor on mining difficulty rather
than the old one interfering. Getting that to work right is an interesting
problem which I'm not sure how to do off the top of my head but I believe
is manageable.
Using many PoWs is a bad idea, that generally gets the worst of everything
rather than the best. There are two ways to go with a PoW, either make it
as advantaged on custom hardware as possible, which means sha3, or make it
as difficult to ASIC as possible, which at this point means cuckoo since
there's already hardware for equihash.
On Sat, Mar 18, 2017 at 9:01 AM, John Hardy via bitcoin-dev <
bitcoin-dev@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 6454 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-20 15:38 ` Andrew Johnson
2017-03-20 15:46 ` John Hardy
2017-03-20 15:55 ` Marcos mayorga
@ 2017-03-20 18:02 ` Nick ODell
2017-03-20 18:51 ` David Vorick
2017-03-20 21:29 ` John Hardy
2 siblings, 2 replies; 15+ messages in thread
From: Nick ODell @ 2017-03-20 18:02 UTC (permalink / raw)
To: Andrew Johnson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5296 bytes --]
Chain work currently means the expected number of sha256d evaluations
needed to build a chain. Given that these hash functions are not equally
hard, what should the new definition of chain work be?
On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> --
> Andrew Johnson
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 8929 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-20 18:02 ` Nick ODell
@ 2017-03-20 18:51 ` David Vorick
2017-03-20 21:29 ` John Hardy
1 sibling, 0 replies; 15+ messages in thread
From: David Vorick @ 2017-03-20 18:51 UTC (permalink / raw)
To: Nick ODell, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
I am in support of having multiple PoW forks to choose from, but it is
indeed problematic to have one chain running a rotation of algorithms.
The reason I support multiple algos is because we don't want an attacker
secretly making asics ahead of time in the event of an emergency PoW fork.
We want them to be uncertain which of a large selection of algorithms are
going to be used, making pre-emptive asic manufacturing more difficult.
But once an algorithm is chosen that should be the end of the story, just
one algo without rotation.
[-- Attachment #2: Type: text/html, Size: 780 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-20 17:49 ` Bram Cohen
@ 2017-03-20 21:23 ` John Hardy
0 siblings, 0 replies; 15+ messages in thread
From: John Hardy @ 2017-03-20 21:23 UTC (permalink / raw)
To: Bram Cohen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6688 bytes --]
> It's possible to switch PoW algorithms with a soft fork rather than a hard fork.
You put forward an interesting idea if it could work, but in the adversarial emergency where an entity is contentiously using a POW monopoly, a hard fork would likely be a far easier and more efficient response.
That said unless I'm missing something I can't see how it would work without still requiring a hard fork since you still need an SHA256 block of sufficient difficulty for the existing network to accept. If the holders of SHA256 hardware didn't want to make their equipment obsolete (likely) they simply would refuse to mine these alternate PoW blocks. I guess a UASF would be an option to force this, but without co-operation (Turkeys voting for Christmas is the British idiom) you'd still end up requiring a hard fork proof of difficulty change, which kind of defeats the purpose?
> Using many PoWs is a bad idea, that generally gets the worst of everything rather than the best.
Upon what do you base this assertion?
________________________________
From: Bram Cohen <bram@bittorrent•com>
Sent: Monday, March 20, 2017 5:49:59 PM
To: John Hardy; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
It's possible to switch PoW algorithms with a soft fork rather than a hard fork. You make it so that there are two different PoWs, the old one and the new one, and each old-style block has to reference a new-style block and contain the exact same transactions. The new work rule is that the weighted geometric mean of the quality of the new-style block and the old-style block has to exceed the work threshold, with the weighting starting almost entirely on the old-style block and shifting gradually over to the new-style block until in the end the amount of work to generate the old-style block is completely trivial and doesn't matter any more.
The most interesting part of the whole thing is keeping it so that the new work limit is consistently the limiting factor on mining difficulty rather than the old one interfering. Getting that to work right is an interesting problem which I'm not sure how to do off the top of my head but I believe is manageable.
Using many PoWs is a bad idea, that generally gets the worst of everything rather than the best. There are two ways to go with a PoW, either make it as advantaged on custom hardware as possible, which means sha3, or make it as difficult to ASIC as possible, which at this point means cuckoo since there's already hardware for equihash.
On Sat, Mar 18, 2017 at 9:01 AM, John Hardy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@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@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 9212 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-20 18:02 ` Nick ODell
2017-03-20 18:51 ` David Vorick
@ 2017-03-20 21:29 ` John Hardy
1 sibling, 0 replies; 15+ messages in thread
From: John Hardy @ 2017-03-20 21:29 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6109 bytes --]
> Chain work currently means the expected number of sha256d evaluations needed to build a chain. Given that these hash functions are not equally hard, what should the new definition of chain work be?
They're not equally hard, but they can be equally relative.
If you had 4 proofs of work you can weigh them each at 25% and compare the overall chain weight from there, shouldn't be difficult.
Initially, some hardware would have an advantage, but over time the market will always average itself out.
________________________________
From: bitcoin-dev-bounces@lists•linuxfoundation.org <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Nick ODell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Monday, March 20, 2017 6:02:52 PM
To: Andrew Johnson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
Chain work currently means the expected number of sha256d evaluations needed to build a chain. Given that these hash functions are not equally hard, what should the new definition of chain work be?
On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
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@lists.linuxfoundation.org<mailto:bitcoin-dev@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@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Andrew Johnson
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 12027 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-03-20 15:55 ` Marcos mayorga
@ 2017-04-16 20:04 ` Erik Aronesty
2017-04-17 1:28 ` bfd
0 siblings, 1 reply; 15+ messages in thread
From: Erik Aronesty @ 2017-04-16 20:04 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, mm
[-- Attachment #1: Type: text/plain, Size: 6647 bytes --]
This is a great solution.
8 or more secure hashes, each of which can be implemented on GPU/CPU, but
rotate through them - per block round robin.
Hardware, infrastructue investment is protected. ASIC is not.
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.
ASIC will never beat this - because it will be 8x more expensive to
maintain the cold circuits.
Miners with gpu/generalized hardware will always be in business.
Should be done gradually and pre-emptively. Change one at a time on a
slow schedule, allowing a graceful transition.
On Mar 20, 2017 8:59 AM, "Marcos mayorga via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi,
> Just a thought,
> Bitcoin developers shouldn't care about miners business model, they can
> always sell their hw and close the bz as soon as bitcoin hardforks to
> better ways of doing.
> Just focus on making a better cryptocurrency, the more decentralized the
> best.
>
> M
>
> > 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@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@lists•linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> > --
> > Andrew Johnson
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 8898 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-04-16 20:04 ` Erik Aronesty
@ 2017-04-17 1:28 ` bfd
[not found] ` <CAJowKg+1vUBmr7cTzUy8gAdjEWTM_+07G9Z96Bo=wd6_htgv1Q@mail.gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: bfd @ 2017-04-17 1:28 UTC (permalink / raw)
To: erik, Erik Aronesty; +Cc: Bitcoin Protocol Discussion
On 2017-04-16 17:04, Erik Aronesty via bitcoin-dev wrote:
> This is a great solution.
>
> 8 or more secure hashes, each of which can be implemented on GPU/CPU,
> but rotate through them - per block round robin.
>
> Hardware, infrastructue investment is protected. ASIC is not.
>
The write time for configuring a FPGA with a fresh bitstream is measured
in tens of milliseconds.
> ASIC will never beat this - because it will be 8x more expensive to
> maintain the cold circuits.
>
Unused circuits don't consume power, which is the main cost in running a
miner.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
[not found] ` <CAJowKgJPjWb_S0jb+RJ9-90sucb=ZeU2-qrNqrVN5USTaxDjDw@mail.gmail.com>
@ 2017-04-17 7:47 ` Erik Aronesty
[not found] ` <CAJowKgKqyb7DCs-yrbj4Z8Kzmgg0GCKXh+wwdSvfPHregiwdvA@mail.gmail.com>
0 siblings, 1 reply; 15+ messages in thread
From: Erik Aronesty @ 2017-04-17 7:47 UTC (permalink / raw)
To: bfd; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]
On Apr 16, 2017 6:28 PM, <bfd@cock•lu> wrote:
On 2017-04-16 17:04, Erik Aronesty via bitcoin-dev wrote:
> This is a great solution.
>
> 8 or more secure hashes, each of which can be implemented on GPU/CPU,
> but rotate through them - per block round robin.
>
> Hardware, infrastructue investment is protected. ASIC is not.
>
>
The write time for configuring a FPGA with a fresh bitstream is measured in
tens of milliseconds.
I have no objections to the use of FPGA or any other commercially available
hardware.
ASIC will never beat this - because it will be 8x more expensive to
> maintain the cold circuits.
>
>
Unused circuits don't consume power, which is the main cost in running a
miner
They make GPUs or FPGAs (as u mentioned) far more affordable. The problem
is centralized manufacturing, which, in turn, is a side effect of a covert
hardware mining optimization leading to a monopoly.
A rotating POW seems to make ASIC manufacture impractical compared to
generalized, commercially available hardware.
It's too bad we can't make the POW somehow dynamic so that any specialized
hardware is impossible, and only GPU / FPGA is possible.
[-- Attachment #2: Type: text/html, Size: 2449 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
[not found] ` <CAJowKgL=UmJvE0KpSsa20AJBF6Ur85ghRymHY+=11VOezmaaxw@mail.gmail.com>
@ 2017-04-17 11:17 ` Erik Aronesty
2017-04-17 22:34 ` Natanael
0 siblings, 1 reply; 15+ messages in thread
From: Erik Aronesty @ 2017-04-17 11:17 UTC (permalink / raw)
To: bfd; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
It's too bad we can't make the POW somehow dynamic so that any specialized
hardware is impossible, and only GPU / FPGA is possible.
Maybe a variant of Keccak where the size of the sponge is increased along
with additional zero bits required. Seems like this would either have to
resist specialized hardware or imply sha3 is compromised such that the size
of the sponge does not incerase the number of possible output bits as
expected.
[-- Attachment #2: Type: text/html, Size: 1688 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners
2017-04-17 11:17 ` Erik Aronesty
@ 2017-04-17 22:34 ` Natanael
0 siblings, 0 replies; 15+ messages in thread
From: Natanael @ 2017-04-17 22:34 UTC (permalink / raw)
To: Erik Aronesty, erik; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]
Den 17 apr. 2017 16:14 skrev "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org>:
It's too bad we can't make the POW somehow dynamic so that any specialized
hardware is impossible, and only GPU / FPGA is possible.
Maybe a variant of Keccak where the size of the sponge is increased along
with additional zero bits required. Seems like this would either have to
resist specialized hardware or imply sha3 is compromised such that the size
of the sponge does not incerase the number of possible output bits as
expected.
Technically SHA3 (keccak) already has the SHAKE mode, an extensible output
function (XOF). It's basically a hash with arbitary output length (with
fixed state size, 256 bits is the common choice). A little bit like hooking
a hash straight into a stream cipher.
The other modes should *probably* not allow the same behavior, though. I
can't guarantee that however.
You may be interested in looking at parameterizable ciphers and if any of
them might be applicable to PoW.
IMHO the best option if we change PoW is an algorithm that's moderately
processing heavy (we still need reasonably fast verification) and which
resists partial state reuse (not fast or fully "linear" in processing like
SHA256) just for the sake of invalidating asicboost style attacks, and it
should also have an existing reference implementation for hardware that's
provably close in performance to the theoretical ideal implementation of
the algorithm (in other words, one where we know there's no hidden
optimizations).
Anything relying on memory or other such expensive components is likely to
fall flat eventually as fast memory is made more compact, cheaper and moves
closer to the cores.
That should be approximately what it takes to level out the playing field
in ASIC manufacturing, because then we would know there's no fancy tricks
to deploy that would give one player unfair advantage. The competition
would mostly be about packing similar gate designs closely and energy
efficiency. (Now that I think about it, the proof MAY have to consider
energy use too, as a larger and slower but more efficient chip still is
competitive in mining...)
We should also put a larger nonce in the header if possible, to reduce the
incentive to mess with the entropy elsewhere in blocks.
[-- Attachment #2: Type: text/html, Size: 3992 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-04-17 22:35 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-18 16:01 [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners John Hardy
2017-03-20 15:38 ` Andrew Johnson
2017-03-20 15:46 ` John Hardy
2017-03-20 16:10 ` Andrew Johnson
2017-03-20 15:55 ` Marcos mayorga
2017-04-16 20:04 ` Erik Aronesty
2017-04-17 1:28 ` bfd
[not found] ` <CAJowKg+1vUBmr7cTzUy8gAdjEWTM_+07G9Z96Bo=wd6_htgv1Q@mail.gmail.com>
[not found] ` <CAJowKgJPjWb_S0jb+RJ9-90sucb=ZeU2-qrNqrVN5USTaxDjDw@mail.gmail.com>
2017-04-17 7:47 ` Erik Aronesty
[not found] ` <CAJowKgKqyb7DCs-yrbj4Z8Kzmgg0GCKXh+wwdSvfPHregiwdvA@mail.gmail.com>
[not found] ` <CAJowKgL=UmJvE0KpSsa20AJBF6Ur85ghRymHY+=11VOezmaaxw@mail.gmail.com>
2017-04-17 11:17 ` Erik Aronesty
2017-04-17 22:34 ` Natanael
2017-03-20 18:02 ` Nick ODell
2017-03-20 18:51 ` David Vorick
2017-03-20 21:29 ` John Hardy
2017-03-20 17:49 ` Bram Cohen
2017-03-20 21:23 ` John Hardy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox