public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dave Scotese <dscotese@litmocracy.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm
Date: Fri, 2 Oct 2015 14:37:09 -0700	[thread overview]
Message-ID: <CAGLBAhc1kE2ahuUe8hpSC2kh4Z49=-jDS+6U=mE+L7foWMoo=g@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTSjnjk60_c0nc4UYYV-w3ZonO_6HuLW+k-SVPyCSc-jQ@mail.gmail.com>

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

If the PoW function is changed, it ought to change slowly so as not to drop
a brick wall in front of the miners speeding toward the ever-receding goal
of protecting the blockchain.  Who's going to get on that path if the
bitcoin community does that?

But it can be done slowly.  If most of the entries is the list of possible
PoW functions are double-SHA256, then the few that aren't will offer the
healthy goal sought by those who like the idea of changing it.  The healthy
goal is for general computing machines to help protect the blockchain in an
incentivized way.  There's a sick goal too, which is to destroy large
investments in mining.  I hope no one has that goal.

At
http://bitcoin.stackexchange.com/questions/35679/is-it-possible-to-make-pow-asic-resistant-through-dynamically-generated-hash-cha/40475#40475
I proposed that ongoing competitions for the creation of new hash
algorithms could feed an ASIC-resistant PoW, defined using the
as-yet-unknowable winners of such competitions.  It is possible to make an
ASIC resistant algorithm, but it isn't a programmable algorithm - it's one
that requires human intervention.  The hash of the next block is a good
example - there's no programmable algorithm that can find it because too
much human intervention is required, but it's an algorithm well-enough
defined for us to build a billion dollar system on top of it.

That being said, I've started looking at two different kinds of
decentralization.  The literal actually-in-different-places kind is
categorically different than the much more important, virtual
impervious-to-coercion kind.  The behavior of the "centralized" oil cartel
is a good example.  The participants cheat.  This is a fundamental
principle in the debate between free-marketeers and authoritarians
regarding the emergence of monopoly.  Without coercion, monopolies fall
apart.  There's nothing coercive about our use of the double-SHA256, so in
my mind, the centralization it has so far produced is not dangerous.  It's
scary, sure, but until coercion is used to prevent me and my friends from
buying our own ASICs, it remains impervious to coercion.

Sorry for the long email that didn't make any apparent progress.  The
thinking is what matters to me, and seeing two kinds of decentralization
and recognizing that a change in PoW can be slow enough to avoid hurting
existing miners are items I haven't seen anyone else recognize, so I had to
bring them up.

notplato

On Fri, Oct 2, 2015 at 9:45 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Oct 2, 2015 at 8:30 AM, Daniele Pinna via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The recently published paper I referenced cite's the Cuckoo cycle
> algorithm,
> > discusses its limitations and explains how their proposed algorithm
> greatly
> > improves on it.
>
> They discuss a very old version of the Cuckoo cycle paper, and I
> believe none of their analysis is applicable to the most recent
> revision. :(
>
> In any case, I commented more about functions of this class here:
>
> https://www.reddit.com/r/Bitcoin/comments/3n5nws/research_paper_asymmetric_proofofwork_based_on/cvl922x
>
> I don't believe changing the POW function is impossible in principle,
> but I expect it would only happen due to problems with the composition
> of current hash-power and not even if it were universally agreed that
> some other construction were technically better (though that is a high
> bar.)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

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

  reply	other threads:[~2015-10-02 21:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02  8:02 [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm Daniele Pinna
2015-10-02  8:20 ` Jorge Timón
2015-10-02  8:30   ` Adam Back
2015-10-02  8:31   ` Daniele Pinna
2015-10-02 10:46   ` NxtChg
2015-10-02 11:00     ` Jorge Timón
2015-10-02 16:38   ` Peter R
     [not found] ` <CALqxMTH6r8eJN2Xw+nn1z=6x9Q3TRSQQ6ZMXsmHPyX8dNx+EgA@mail.gmail.com>
2015-10-02  8:30   ` Daniele Pinna
2015-10-02 16:45     ` Gregory Maxwell
2015-10-02 21:37       ` Dave Scotese [this message]
2015-10-02 21:31 ` Luke Dashjr
2015-10-02 23:19   ` Milly Bitcoin

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='CAGLBAhc1kE2ahuUe8hpSC2kh4Z49=-jDS+6U=mE+L7foWMoo=g@mail.gmail.com' \
    --to=dscotese@litmocracy.com \
    --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