Corey Haddad [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-07 📝 Original message:>Billy, > >Proof of work ...
📅 Original date posted:2022-07-07
📝 Original message:>Billy,
>
>Proof of work and the difficulty adjustment function solve literally
everything you are talking about already.
>Bitcoin does not need active economic governanance by devs or meddlers.
>Please stop spamming this list with this nonsensical thread.
>
>Love,
>John
Sorry John, but this is a divisive comment. You are the spammer here. While
it is unclear why you are trying to harm the Bitcoin development process,
you are, and anyone reading this should know that.
Proof of work and the difficulty adjustment have no capability to ensure
that the amount of security is adequate or reasonable.The only proximate
incentive-compatible feedback mechanisms would either make the security too
low or too high, and not approach 'just right'. If the price falls, and the
hashrate goes down, people might conclude that Bitcoin is looking
vulnerable to attack and therefore sell, which would be a negative feedback
loop. Conversely, if a price rise leads to a higher hashrate, people might
think Bitcoin is now even more secure than before and buy, causing a
positive feedback loop. These are not stable equilibria.
PoW and the difficulty adjustments hold block times at 10 minutes, and by
the same token, keep coin issuance roughly on schedule. They have also
turned out to - thus far - have charted a reasonable (albeit predetermined)
course through the various hash-based attacks that lurk out there in the
world. Without any sort or restorative force that guides the security
budget to an optimum, or even towards a reasonable range, we have to
recognize that we are just lucky that Satoshi got it right. When navigating
via dead reckoning, the uncertainty accumulates over time and distance.
Eventually external corrections are needed. We absolutely need to keep
apprised of the current and future threats, assess Bitcoin's resilience in
the face of those threats, and when needed make changes to ensure Bitcoin
remains secure.
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/37458d86/attachment-0001.html>
📝 Original message:>Billy,
>
>Proof of work and the difficulty adjustment function solve literally
everything you are talking about already.
>Bitcoin does not need active economic governanance by devs or meddlers.
>Please stop spamming this list with this nonsensical thread.
>
>Love,
>John
Sorry John, but this is a divisive comment. You are the spammer here. While
it is unclear why you are trying to harm the Bitcoin development process,
you are, and anyone reading this should know that.
Proof of work and the difficulty adjustment have no capability to ensure
that the amount of security is adequate or reasonable.The only proximate
incentive-compatible feedback mechanisms would either make the security too
low or too high, and not approach 'just right'. If the price falls, and the
hashrate goes down, people might conclude that Bitcoin is looking
vulnerable to attack and therefore sell, which would be a negative feedback
loop. Conversely, if a price rise leads to a higher hashrate, people might
think Bitcoin is now even more secure than before and buy, causing a
positive feedback loop. These are not stable equilibria.
PoW and the difficulty adjustments hold block times at 10 minutes, and by
the same token, keep coin issuance roughly on schedule. They have also
turned out to - thus far - have charted a reasonable (albeit predetermined)
course through the various hash-based attacks that lurk out there in the
world. Without any sort or restorative force that guides the security
budget to an optimum, or even towards a reasonable range, we have to
recognize that we are just lucky that Satoshi got it right. When navigating
via dead reckoning, the uncertainty accumulates over time and distance.
Eventually external corrections are needed. We absolutely need to keep
apprised of the current and future threats, assess Bitcoin's resilience in
the face of those threats, and when needed make changes to ensure Bitcoin
remains secure.
Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/37458d86/attachment-0001.html>