📅 Original date posted:2017-04-09
📝 Original message:On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
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.
>
> _______________________________________________
> 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
The real bottleneck today is the amount of capex required to achieve
optimal mining. I am strongly in favor of PoW research that investigates
better PoW, but I do not think that any obvious strategies are known yet to
improve substantially on computation heavy hashcash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/76d8a516/attachment.html>;
David Vorick [ARCHIVE] /
npub14h…9yjx0
2023-06-07 17:59:51
in reply to nevent1q…e36g
Author Public Key
npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0Seen on
wss://relay.nostr.bandPublished at
2023-06-07 17:59:51Event JSON
{
"id": "3dc9b5b7e7a3f5f1bf358d3b51fe239bb4ff94f9571a49adaf387e1d7b0243ef",
"pubkey": "adcb53cdbd72e2a0c22452a9087f173c6b55edc7b504ff9b861e9c02af9a87d4",
"created_at": 1686160791,
"kind": 1,
"tags": [
[
"e",
"b3abda28c58fcdd36a7f3d79347d12387effc8cb5f326fca3c05e821d4348755",
"",
"root"
],
[
"e",
"d67b8927aed03ec17a16991005b68a008bd5021570305615aa06df44fc27c355",
"",
"reply"
],
[
"p",
"a956c05f48cc2ea55f4f90f37fd31f19a183681aa385301564d07b93c0c07bf3"
]
],
"content": "📅 Original date posted:2017-04-09\n📝 Original message:On Apr 9, 2017 7:00 PM, \"Jared Lee Richardson via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\nI 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\" \u003cbitcoin-dev at lists.\nlinuxfoundation.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 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_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n\nThe real bottleneck today is the amount of capex required to achieve\noptimal mining. I am strongly in favor of PoW research that investigates\nbetter PoW, but I do not think that any obvious strategies are known yet to\nimprove substantially on computation heavy hashcash.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/76d8a516/attachment.html\u003e",
"sig": "628e0fa7b227ab7e1221089648a93e4cb2dedae53b98da5d91eee9f4ffef8a32fe1ad568abdc11489d4107597c2df6c7a848638dbb739cd1476eb692a4ae6ad7"
}