š
Original date posted:2017-04-09
š Original message:I can speak from personal experience regarding another very prominent
altcoin that attempted to utilize an asic-resistant proof of work
algorithm, it is only a matter of time before the "asic resistant"
algorithm gets its own Asics. The more complicated the algorithm, the more
secretive the asic technology is developed. Even without it,
multi-megawatt gpu farms have already formed in the areas of the world with
low energy costs. I'd support the goal if I thought it possible, but I
really don't think centralization of mining can be prevented.
On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Curious: I'm not sure why a serious discussion of POW change is not on the
> table as a part of a longer-term roadmap.
>
> Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
> the proven, np-complete graph-theoretic or polygon manipulation POW would
> keep Bitcoin in commodity hardware and out of the hands of centralized
> manufacturing for many years.
>
> Clearly a level-playing field is critical to keeping centralization from
> being a "defining feature" of Bitcoin over the long term. I've heard the
> term "level playing field" bandied about quite a bit. And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware. Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
> Perhaps regular, high-consensus POW changes might even be *necessary* as a
> part of good maintenance of cryptocurrency in general. Killing the
> existing POW, and using an as-yet undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year.... A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date. This would enable
> rapid-response to quantum tech, or some other needed POW switch as well...
> because the mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
>
> On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Jimmy Song,
>>
>> Why would the actual end users of Bitcoin (the long term and short term
>> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
>> policy in order to make their money more vulnerable to 51% attack?
>>
>> If anything, we would be making policy changes to prevent the use of
>> patented PoW algorithms instead of making changes to enable them.
>>
>> Thanks,
>> Praxeology Guy
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/8d1ffe05/attachment-0001.html>;
Jared Lee Richardson [ARCHIVE] /
npub149ā¦5vasy
2023-06-07 17:59:51
in reply to nevent1qā¦h9ew
Author Public Key
npub149tvqh6gesh22h60jrehl5clrxscx6q65wznq9ty6pae8sxq00esg5vasyPublished at
2023-06-07 17:59:51Event JSON
{
"id": "d67b8927aed03ec17a16991005b68a008bd5021570305615aa06df44fc27c355",
"pubkey": "a956c05f48cc2ea55f4f90f37fd31f19a183681aa385301564d07b93c0c07bf3",
"created_at": 1686160791,
"kind": 1,
"tags": [
[
"e",
"b3abda28c58fcdd36a7f3d79347d12387effc8cb5f326fca3c05e821d4348755",
"",
"root"
],
[
"e",
"480c77638509257a07c341b7fc8bb1d11aed36b9dbf1896f6dab257af858f910",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "š
Original date posted:2017-04-09\nš Original message:I can speak from personal experience regarding another very prominent\naltcoin that attempted to utilize an asic-resistant proof of work\nalgorithm, it is only a matter of time before the \"asic resistant\"\nalgorithm gets its own Asics. The more complicated the algorithm, the more\nsecretive the asic technology is developed. Even without it,\nmulti-megawatt gpu farms have already formed in the areas of the world with\nlow energy costs. I'd support the goal if I thought it possible, but I\nreally don't think centralization of mining can be prevented.\n\nOn Apr 9, 2017 1:16 PM, \"Erik Aronesty via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Curious: I'm not sure why a serious discussion of POW change is not on the\n\u003e table as a part of a longer-term roadmap.\n\u003e\n\u003e Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of\n\u003e the proven, np-complete graph-theoretic or polygon manipulation POW would\n\u003e keep Bitcoin in commodity hardware and out of the hands of centralized\n\u003e manufacturing for many years.\n\u003e\n\u003e Clearly a level-playing field is critical to keeping centralization from\n\u003e being a \"defining feature\" of Bitcoin over the long term. I've heard the\n\u003e term \"level playing field\" bandied about quite a bit. And it seems to me\n\u003e that the risk of state actor control and botnet attacks is less than\n\u003e state-actor manipulation of specialized manufacturing of \"SHA-256 forever\"\n\u003e hardware. Indeed, the reliance on a fairly simple hash seems less and\n\u003e less likely a \"feature\" and more of a baggage.\n\u003e\n\u003e Perhaps regular, high-consensus POW changes might even be *necessary* as a\n\u003e part of good maintenance of cryptocurrency in general. Killing the\n\u003e existing POW, and using an as-yet undefined, but deployment-bit ready POW\n\u003e field to flip-flop between the current and the \"next one\" every 8 years or\n\u003e or so, with a ramp down beginning in the 7th year.... A stub function that\n\u003e is guaranteed to fail unless a new consensus POW is selected within 7\n\u003e years.\n\u003e\n\u003e Something like that?\n\u003e\n\u003e Haven't thought about it *that* much, but I think the network would\n\u003e respond well to a well known cutover date. This would enable\n\u003e rapid-response to quantum tech, or some other needed POW switch as well...\n\u003e because the mechanisms would be in-place and ready to switch as needed.\n\u003e\n\u003e Lots of people seem to panic over POW changes as \"irresponsible\", but it's\n\u003e only irresponsible if done irresponsibly.\n\u003e\n\u003e\n\u003e On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Jimmy Song,\n\u003e\u003e\n\u003e\u003e Why would the actual end users of Bitcoin (the long term and short term\n\u003e\u003e owners of bitcoins) who run fully verifying nodes want to change Bitcoin\n\u003e\u003e policy in order to make their money more vulnerable to 51% attack?\n\u003e\u003e\n\u003e\u003e If anything, we would be making policy changes to prevent the use of\n\u003e\u003e patented PoW algorithms instead of making changes to enable them.\n\u003e\u003e\n\u003e\u003e Thanks,\n\u003e\u003e Praxeology Guy\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/8d1ffe05/attachment-0001.html\u003e",
"sig": "e00be7bb10922ef46af5828e41314c8b243056b6e626a790fce60cb065231ee1fe7c5c41deb089955df9f13fbb6b7ee1aaef7b73ae28b85aaff3229c7e99cbfa"
}