<unnamed>

Public Key

npub15fe6jcj3a2vykwk9tshyjc47s4q0t7jza444dnffcympur2v7myq6get3u

Profile Code

nprofile1qqs2yuafvfg74xzt8tz4ctjfv2lg2s84lfpw666ke55uzds7p4x0djqpzpmhxue69uhkummnw3ezuamfdejsfay7rf

Publishing to

nostr.wine

Last Notes

2023-06-07 17:57:24 UTC

- reply

📅 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?
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 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<mailto: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<mailto: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/f7748943/attachment-0001.html>

2023-06-07 17:57:23 UTC

- reply

📅 Original date posted:2017-03-18
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170318/34aa05cd/attachment.html>

2023-06-07 17:55:59 UTC

- reply

📅 Original date posted:2017-02-02
📝 Original message:Currently in order to signal support for changes to Bitcoin, only miners are able to do so on the blockchain through BIP9.
One criticism is that the rest of the community is not able to participate in consensus, and other methods of assessing community support are fuzzy and easily manipulated through Sybil.
I was trying to think if there was a way community support could be signaled through transactions without requiring a hard fork, and without increasing the size of transactions at all.
My solution is basically inspired by hashcash and vanity addresses.
The output address of a transaction could basically have the last 4 characters used to signal support for a particular proposal.
To generate an address with 4 consecutive case-insensitive characters should be roughly 34^4 which is just over a million attempts. On typical hardware this should take less than a second.
An example bitcoin address that wanted to support the core roadmap might be:
1CLNgjuu8s51umTA76Zi8v6EdvDp8qCorE
or to signal support for a big block proposal might be:
1N62SRhBioRFrigS5eJ8kR1WYcfcYr16mB
Popularity could be measured weighted by fee paid per voting kb.
Issues are that this could lead to transactions been censored by particular miners for political reasons. Also miners might attempt to manipulate the results by stuffing their block with 'fake' transactions. Such attempts could be identified if a large number of voting transactions were not in the mempool.
Despite the limitations, I believe this offers a very accessible way to immediately allow the entire economic community to signal their support within transactions. The only cost is that of a tiny hashing PoW that should tie up a CPU for a barely noticeable amount of time, and could be implemented relatively easily into wallet software.
For its weaknesses, surely it is better than the existing methods we use to assess support from the wider economic community?
While it could just be used for signaling support and giving users a 'voice' on chain, if considered effective it could also be used to activate changes in the future.
Any thoughts welcome.
Thanks,
John Hardy
john at seebitcoin.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170203/1916d1f2/attachment-0001.html>