Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-09 📝 Original message:Have you read the cuckoo ...
📅 Original date posted:2017-04-09
📝 Original message:Have you read the cuckoo cycle paper? Finding cycles in massive graphs is
just about the worst thing to use an ASIC for.
It might be a hitherto before unknown emergent property of cryptocurrencies
in general that POW *must* change every 7-9 years. Could bake that into
the protocol too...
On Apr 9, 2017 7:51 PM, "David Vorick" <david.vorick at gmail.com> wrote:
>
>
> 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/7a8d0a1e/attachment.html>;
📝 Original message:Have you read the cuckoo cycle paper? Finding cycles in massive graphs is
just about the worst thing to use an ASIC for.
It might be a hitherto before unknown emergent property of cryptocurrencies
in general that POW *must* change every 7-9 years. Could bake that into
the protocol too...
On Apr 9, 2017 7:51 PM, "David Vorick" <david.vorick at gmail.com> wrote:
>
>
> 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/7a8d0a1e/attachment.html>;