public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Glen Peterson <glen@organicdesign.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Upgrading PoW algorithm
Date: Sun, 21 Jan 2018 10:29:26 -0500	[thread overview]
Message-ID: <CA+LnoU=OoUaCwV_HrLdZUx4yHY4M0TDE45tefhF08b8PrO5VBw@mail.gmail.com> (raw)
In-Reply-To: <CAKaEYhJHZ_CFeqRN_QXP-SLX+AHmbRPTx+w=D3920Fc-WPq_1A@mail.gmail.com>

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@lists.linuxfoundation.org> wrote:
>
>
> On 17 January 2018 at 23:31, Jefferson Carpenter via bitcoin-dev
> <bitcoin-dev@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



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


      reply	other threads:[~2018-01-21 15:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17 22:31 [bitcoin-dev] Upgrading PoW algorithm Jefferson Carpenter
2018-01-18 16:36 ` Peter Todd
2018-01-19 20:54 ` Jefferson Carpenter
2018-01-20  6:30   ` nullius
2018-01-20 18:36 ` Melvin Carvalho
2018-01-21 15:29   ` Glen Peterson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+LnoU=OoUaCwV_HrLdZUx4yHY4M0TDE45tefhF08b8PrO5VBw@mail.gmail.com' \
    --to=glen@organicdesign.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox