[bitcoin-dev] Upgrading PoW algorithm

Glen Peterson glen at organicdesign.org
Sun Jan 21 15:29:26 UTC 2018


Popular hashing algorithms have historically managed 10-15 years of
intense use before flaws are found in the algorithm.  This chart
suggests SHA-256 is already aging:
http://valerieaurora.org/hash.html
If history is any guide, any long-term cryptocurrency/blockchain will
need the cryptography updated every decade or so.

On Sat, Jan 20, 2018 at 1:36 PM, Melvin Carvalho via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On 17 January 2018 at 23:31, Jefferson Carpenter via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Bitcoin's difficulty will be maxed out within about 400 years, by Moore's
>> law.  (After that - supposing the software does not crash when difficulty
>> overflows - block time will start decreasing, and it will not take long
>> before blocks are mined faster than photons can be sent across the planet).
>>
>> Bitcoin is the dominant cryptocurrency today, as the first mover: the
>> perfectly fair worldwide game of inventing the cryptocurrency has been
>> played and won.  However, unfortunately, it has a built-in end date: about
>> 400 years from now.  After that, it won't necessarily be clear what the
>> dominant cryptocurrency is.  It might be a lot like VHS vs Betamax, and a
>> lot of people could lose a lot of money.  It seems to me, this could be
>> mitigated by planning today for what we are going to do when Bitcoin finally
>> breaks 400 years from now.
>>
>> Are there any distinct plans today for migrating to a PoW supporting an
>> even higher difficulty?
>
>
> Crypto algorithms have a lifetime, and consensus is no different.
>
> Is it likely to be more than a few years?  Yes.
>
> Is likely to be less than a few hundred years.  Yes.
>
> Every algorithm involves trade offs and it's the job of a thoughtful dev
> team to examine those trade offs and come to a consensus optimal solution.
>
> This field is only 9 years old, and there is a large amount of R & D in this
> area.  So we can evaluate what seems to working better and what seems to be
> working worse, transfer that to BIPs, create code, test it, try to achieve
> consensus.  The normal path that has served free software projects well.
>
>>
>> _______________________________________________
>> 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
>



-- 
Glen K. Peterson
(828) 393-0081


More information about the bitcoin-dev mailing list