đź“… Original date posted:2017-03-20
đź“ť Original message:On Mon, Mar 20, 2017 at 10:47 AM John Hardy <john at 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 at 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 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
--
Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/c4a231a7/attachment-0001.html>;
Andrew Johnson [ARCHIVE] /
npub1lf…zuul6
2023-06-07 17:57:24
in reply to nevent1q…0csr
Author Public Key
npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6Published at
2023-06-07 17:57:24Event JSON
{
"id": "d30200fd3e6e336e2f46c69f8035a8fc277165679ead3bd325ad27754036ec54",
"pubkey": "fa69268781de33f116b423cab175d976820851d6b074d0873c920c6983eb4713",
"created_at": 1686160644,
"kind": 1,
"tags": [
[
"e",
"c045c2a2c8f66b19b06b190e72379db8373af97e98aede2e588a29a488e35ef3",
"",
"root"
],
[
"e",
"ea9c361ae1fb1e27a0b4d1cf9f4bf560ba33549d484e1b0f4fbb2b8183bddf64",
"",
"reply"
],
[
"p",
"a273a96251ea984b3ac55c2e4962be8540f5fa42ed6b56cd29c1361e0d4cf6c8"
]
],
"content": "📅 Original date posted:2017-03-20\n📝 Original message:On Mon, Mar 20, 2017 at 10:47 AM John Hardy \u003cjohn at seebitcoin.com\u003e wrote:\n\n\u003e By doing this you're significantly changing the economic incentives\nbehind bitcoin mining. How can you reliably invest in hardware if you have\nno idea when or if your profitability is going to be cut by 50-75% based on\na whim?\n\n\nOf course, that's why this is a last resort, successfully activated only in\nresponse to a contentious hard fork. If it succeeds just once it should\nhelp prevent the same situation occurring in the future.\n\n\nThis seems a lot more disruptive to the network than a simple hard fork to\nincrease the block size. Compromise is the answer here, not taking our\nball and going home, in my humble opinion.\n\n\u003e You 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\nHow so? If you have four proof of work methods, that 50-75% of SHA256\nhashpower would equate to 13-18% of total hashpower. If you can harm the\nnetwork with this much hashpower bitcoin was DOA.\n\n\nI'm assuming the difficulty on the SHA256 PoW would drop by 50-75% as\nwell. So not nearly as bad as it would be with a single PoW and that much\nhardware were available to an adversary, you're correct.\n\nHow would you handle starting difficulty on the other 3 PoWs? Seems like\nit would be a race to start with, which strikes me as another potential\nattack vector until the amount of hardware and price of production balances\nwith the price of the coin(which is likely to be volatile during this\nturbulent period). Unless you start the difficulty at a higher value, then\nyou're just doing centralized economic planning and hoping you got the\nnumbers right so that you get the right balance of security vs incentive to\ndo malicious things like double spends.\n\nAll the solutions that people keep positing(such as Luke's complete PoW\nchange) seem like they'd be a whole lot more disruptive to the network than\nan EC fork would be.\n\nIsn't the main reason that everyone is up in arms because a contentious\nhard fork is dangerous? I just don't understand how any of these solutions\nare safer.\n\nAt that point we've lost our claim to fame, that changes to the protocol\nare hard and you can trust that your value is safe. What you're advocating\nseems like it would result in a huge drop in hashing security.\n\n------------------------------\n*From:* Andrew Johnson \u003candrew.johnson83 at gmail.com\u003e\n*Sent:* Monday, March 20, 2017 3:38:01 PM\n*To:* Bitcoin Protocol Discussion; John Hardy\n*Subject:* Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR\nPOWA): Protecting Bitcoin from malicious miners\n\nBy 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\nI’m very worried about the state of miner centralisation in Bitcoin.\n\nI always felt the centralising effects of ASIC manufacturing would resolve\nthemselves once the first mover advantage had been exhausted and the\nindustry had the opportunity to mature.\n\nI had always assumed initial centralisation would be harmless since miners\nhave no incentive to harm the network. This does not consider the risk of a\nsingle entity with sufficient power and either poor, malicious or coerced\ndecision making. I now believe that such centralisation poses a huge risk\nto the security of Bitcoin and preemptive action needs to be taken to\nprotect the network from malicious actions by any party able to exert\ninfluence over a substantial portion of SHA256 hardware.\n\nInspired by UASF, I believe we should implement a Malicious miner Reactive\nProof of Work Additions (MR POWA).\n\nThis would be a hard fork activated in response to a malicious attempt by a\nhashpower majority to introduce a contentious hard fork.\n\nThe activation would occur once a fork was detected violating protocol\n(likely oversize blocks) with a majority of hashpower. The threshold and\nduration for activation would need to be carefully considered.\n\nI don’t think we should eliminate SHA256 as a hashing method and change POW\nentirely. That would be throwing the baby out with the bathwater and hurt\nthe non-malicious miners who have invested in hardware, making it harder to\ngain their support.\n\nInstead I believe we should introduce multiple new proofs of work that are\nalready established and proven within existing altcoin implementations. As\nan example we could add Scrypt, Ethash and Equihash. Much of the code and\nmining infrastructure already exists. Diversification of hardware (a mix of\nCPU and memory intensive methods) would also be positive for\ndecentralisation. Initial difficulty could simply be an estimated portion\nof existing infrastructure.\n\nThis example would mean 4 proofs of work with 40 minute block target\ndifficulty for each. There could also be a rule that two different proofs\nof work must find a block before a method can start hashing again. This\nmeans there would only be 50% of hardware hashing at a time, and a sudden\ngain or drop in hashpower from a particular method does not dramatically\nimpact the functioning of the network between difficulty adjustments. This\nalso adds protection from attacks by the malicious SHA256 hashpower which\ncould even be required to wait until all other methods have found a block\nbefore being allowed to hash again.\n\n50% hashing time would mean that the cost of electricity in relation to\nhardware would fall by 50%, reducing some of the centralising impact of\nsubsidised or inexpensive electricity in some regions over others.\n\nSuch a hard fork could also, counter-intuitively, introduce a block size\nincrease since while we’re hard forking it makes sense to minimise the\nnumber of future hard forks where possible. It could also activate SegWit\nif it hasn’t already.\n\nThe beauty of this method is that it creates a huge risk to any malicious\nactor trying to abuse their position. Ideally, MR POWA would just serve as\na deterrent and never activate.\n\nIf consensus were to form around a hard fork in the future nodes would be\nable to upgrade and MR POWA, while automatically activating on non-upgraded\nnodes, would be of no economic significance: a vestigial chain immediately\nabandoned with no miner incentive.\n\nI think this would be a great way to help prevent malicious use of\nhashpower to harm the network. This is the beauty of Bitcoin: for any road\nblock that emerges the economic majority can always find a way around.\n\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nAndrew Johnson\n\n-- \nAndrew Johnson\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/c4a231a7/attachment-0001.html\u003e",
"sig": "a9b1c18d920de0360f8eb288ec609f14bf99481e45794420954d8d215ea7efe9f6edb3ac11821b7f4a5794af88ef965ee77e1d6362b63b78efd4cbef6c9397da"
}