public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Erik Aronesty <erik@q32•com>
To: praxeology_guy <praxeology_guy@protonmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
Date: Sun, 9 Apr 2017 14:44:47 -0400	[thread overview]
Message-ID: <CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com> (raw)
In-Reply-To: <Cwhn7YzwaDUZtOygDAgrU1UXjRPG-EiH3Fyz2c95gqOpNnNbiYL1NvhS28yK5wLJCnIqDaBrM6c574dY-O6_-bRjLIFmDe2NCxIuyV1w2dw=@protonmail.com>

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

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.


On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Jimmy Song,
>
> Why would the actual end users of Bitcoin (the long term and short term
> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
> policy in order to make their money more vulnerable to 51% attack?
>
> If anything, we would be making policy changes to prevent the use of
> patented PoW algorithms instead of making changes to enable them.
>
> Thanks,
> Praxeology Guy
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  parent reply	other threads:[~2017-04-09 18:44 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 20:06 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 [this message]
2017-04-09 21:16     ` Jared Lee Richardson
2017-04-09 23:51       ` David Vorick
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='CAJowKg+tYK9j5LTwokMGutD+-SjBQ70U=X7rqHMGSeaG2NEo9A@mail.gmail.com' \
    --to=erik@q32$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=praxeology_guy@protonmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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