public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: David Vorick <david.vorick@gmail.com>
To: Jared Lee Richardson <jaredr26@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
Date: Sun, 9 Apr 2017 19:51:29 -0400	[thread overview]
Message-ID: <CAFVRnyoqfzJevK5m68bhBuAvUui+eAQsD9ngwDKuGWxVjRBJwQ@mail.gmail.com> (raw)
In-Reply-To: <CAD1TkXvjtd-LBt6sC=DrkPwk-owRCMEUCEdB9WAVL4LsnTOOSg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]

On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" <
bitcoin-dev@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@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@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


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.

[-- Attachment #2: Type: text/html, Size: 4478 bytes --]

  reply	other threads:[~2017-04-09 23:51 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 20:06 [bitcoin-dev] A Small Modification to Segwit Jimmy Song
2017-04-08  0:05 ` Jimmy Song
2017-04-08 14:59   ` Luke Dashjr
2017-04-08 15:17     ` Jimmy Song
2017-04-08 16:05       ` Luke Dashjr
2017-04-08 16:16         ` Jimmy Song
2017-04-08 16:19   ` Timo Hanke
2017-04-08  1:48 ` praxeology_guy
2017-04-08  2:46   ` Jimmy Song
2017-04-08  8:33     ` Pavel Moravec
2017-04-08 14:35       ` Jimmy Song
2017-04-08 16:38         ` Pavel Moravec
2017-04-08 22:19           ` Jimmy Song
2017-04-08 18:15         ` praxeology_guy
2017-04-08 18:51           ` Eric Voskuil
2017-04-08 20:38             ` praxeology_guy
2017-04-09 11:46           ` Jorge Timón
2017-04-08 16:27     ` Jorge Timón
2017-04-08 17:22       ` Jorge Timón
2017-04-08 22:26         ` Jimmy Song
2017-04-09 11:48           ` Jorge Timón
2017-04-09 14:01             ` Jimmy Song
     [not found]               ` <CABm2gDqfsBREj2x5Uz9hxwt-Y6m=KHd2-hRw4gV0CbO+-8B0dg@mail.gmail.com>
2017-04-10  9:16                 ` Jorge Timón
2017-04-09 18:44   ` Erik Aronesty
2017-04-09 21:16     ` Jared Lee Richardson
2017-04-09 23:51       ` David Vorick [this message]
2017-04-10  0:20         ` Erik Aronesty
2017-04-10  1:45           ` Thomas Daede
2017-04-10 14:34     ` Bram Cohen
2017-04-10 14:46     ` Bram Cohen
2017-04-10 15:25     ` g
2017-04-10 18:17       ` Erik Aronesty
2017-04-11  2:39         ` g
2017-04-11 18:39           ` Staf Verhaegen
2017-04-11  9:31       ` Sancho Panza
2017-04-11 13:00         ` Jorge Timón
2017-04-11  7:59 ` Tom Zander
2017-04-11 13:25   ` Sancho Panza
2017-04-11 14:40     ` Jimmy Song
2017-04-11 21:25       ` Jorge Timón
2017-04-11 23:42         ` Jimmy Song

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=CAFVRnyoqfzJevK5m68bhBuAvUui+eAQsD9ngwDKuGWxVjRBJwQ@mail.gmail.com \
    --to=david.vorick@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jaredr26@gmail.com \
    /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