path: root/5e/32426643a98fc987c01f4fb23d218aa1e0d96e

Return-Path: <gmkarl@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C68A3C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 19:50:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id AEE9C855A1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 19:50:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fzSBTswIn_ek
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 19:50:27 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-il1-f172.google.com (mail-il1-f172.google.com
 [209.85.166.172])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 4FFA58551F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 19:50:27 +0000 (UTC)
Received: by mail-il1-f172.google.com with SMTP id j2so15696931ilr.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 12:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=6qNzs+BfDCfGmlJ+nYjFg1iXQs1KoEQ+ISwDzgWeQvQ=;
 b=IXTRApwo7MN5o5yTajGJrU7WFRLwICQVc/+iXX0u7QrTUavjPVnlCdE5uJ/bibcqi4
 H2Js7co3UnCb19Hymix6/1h2riUD0GQx6U1dOrxGQFNDHwjXY5TZTz46nXSYqSJ0X5U5
 bEMvJ6ve+uP9+4klD6et3JQLFGKcSZeQ4iWCCzCEkr4HiA9nMz3qmwa8nF9EQ+zo2k7D
 VkeJKAHOLAyOJlt/4HgvaXr/2k5+ZHyNFdfpaSX+Y2+UiQ0qaz2Jd4XGzM6CnWlTlGAj
 5e7pOnfFzpqTl9vZ9EiPMSRrbY3z93VhyyPzy7Xdr0n68QKAcTdV2e5CbNFWdMPamO1D
 SSuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=6qNzs+BfDCfGmlJ+nYjFg1iXQs1KoEQ+ISwDzgWeQvQ=;
 b=XDAWVXVJL8XtlIo7LoK2QAZ10Qlz7qxQU43tGvkv3JY+umSS6n8lqhYDF5w3DKuh3u
 av9ZNGuRYrOYoJNsnYUhOuAcFY3nCzXdpna83Hz1MRuOIOZcmakTzjlo56OQ4xoUoev9
 qFQr1YB4CBA2sy4JbHDwXIsxgu3lpV8Dgu73ZXinG4UzZjZ+V4hKkjn7DBYS4evjHd0e
 nXihk7Y1Id5Gya6AzyvYts1jdM/O0Z7zQFjw7tYTv8S3U8oXo4GHURE1eoE4OMyUhlQD
 yLwtV/pW9b69sNaTenK9aaGzRkemlKK1ibFQYhL7eFo83ohmoe3E4anMu6kjIj7hf4iv
 QMQg==
X-Gm-Message-State: AOAM533mLESCJlcK+/EfcWI08NC2pNwIRfSK2cGZhcyLDyfbzCz8TNux
 3qQkURFL0NXNLN/gw3resqHhXUYjBeEGB6Y8Iho=
X-Google-Smtp-Source: ABdhPJzz731zFLUdvkMuzvPYssz56P+LXX5c807H6rIpyRw9x+NCtS1iyPNLXpBYhB7E0gTxXxmfWgRasrqkIW++0Js=
X-Received: by 2002:a92:4918:: with SMTP id w24mr22397092ila.205.1590349826485; 
 Sun, 24 May 2020 12:50:26 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.2587.1590231461.32591.bitcoin-dev@lists.linuxfoundation.org>
 <CALL-=e4Eg=iRbZOV+SAzn3_NhZrS-QviDgZdSmxLQTLvoMduPw@mail.gmail.com>
 <k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com>
 <CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>
 <WqvuQWsFg50edn9nmk0DRcTsEZr__CFaQd9T3bw3b7CffGDjwXsVApzZvnsNdmeLQDrFKDMFgb5QDzHVhOhudGfu3HlvQKyR-9luPI-YCbs=@protonmail.com>
In-Reply-To: <WqvuQWsFg50edn9nmk0DRcTsEZr__CFaQd9T3bw3b7CffGDjwXsVApzZvnsNdmeLQDrFKDMFgb5QDzHVhOhudGfu3HlvQKyR-9luPI-YCbs=@protonmail.com>
From: Karl <gmkarl@gmail.com>
Date: Sun, 24 May 2020 15:50:12 -0400
Message-ID: <CALL-=e6J4QFjdbC=caux=TAHjveKaehnGfdyeEdEhgniSp7PYA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000079f66405a66a2c18"
X-Mailman-Approved-At: Sun, 24 May 2020 20:26:46 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] hashcash-newhash
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 24 May 2020 19:50:28 -0000

--00000000000079f66405a66a2c18
Content-Type: text/plain; charset="UTF-8"

Good afternoon ZmnSCPxj,

Thanks for holding your end of this discussion with me.

Sorry I am so verbose; I am still learning to communicate efficiently.

> You mention ASICs becoming commoditized.  I'd remind you that eventually
> there will be a public mathematical breaking of the algorithm, at which
> point all ASICs will become obsolete regardless.  Would you agree it would
> be better to prepare for this by planning algorithm change?
>
> Possibly, but then the reason for change is no longer to promote
> decentralization, would it?

It helps to be clear about what your goals are, because any chosen solution
> might not be the best way to fix it.
> I admit that, if the problem were to be avoid the inevitable obsoletion of
> SHA-2, then this is the only solution, but that is not the problem you
> stated you were trying to solve in the first place.
>

To be up front, the reason for decentralization is due to concern around
the security of the hashing.  Having a public breakage of the function
simply makes the urgency obvious.

Reddit claims two entities controlled 62% of the hashrate recently:
https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/
.  Compromising the systems of these two groups seems like it is all that
is needed to compromise the entire blockchain (to the limited degree a 51%
attack does).

Hence I see decentralization and cryptanalysis of the algorithm to be
roughly similar security concerns.

It sounds like you agree that a change of algorithm is needed before the
current one is publicly broken.

>
> > You mention many coordinated hardforks.  Would you agree that if we came
> up with a way of programmatically cycling the algorithm, that only one
> hardfork work be needed?  For example one could ask nodes to consent to new
> algorithm code written in a simple scripting language, and reject old ones
> slowly enough to provide for new research.
>
> Even *with* a scripting language, the issue is still what code written in
> that language is accepted, and *how*.
>
> Do miners vote on a new script describing the new hashing algorithm?
> What would their incentive be to obsolete their existing hardware?
> (using proof-of-work to lock in a hashing change feels very much like a
> chicken-and-egg problem: the censorship-resistance provided by Bitcoin is
> based on evicting any censors by overpowering their hashpower, but requires
> some method of measuring that hashpower: it seems unlikely that you can
> safely change the way hashpower is measured via a hashpower election)
>
> Do nodes install particular scripts and impose a switchover schedule of
> some sort?
> Then how is that different from a hardfork, especially for nodes that do
> not update?
> (notice that softforks allow nodes to remain non-updated, at degraded
> security, but still in sync with the rest of the network and capable of
> transacting with them)


I'm expressing that in considering this we have two options: repeated hard
forks or making repeated change a part of the protocol.  There are many
ways to approach or implement it.  It sounds like you're noting that the
second option takes some work and care?

Would it be helpful if I outlined more ideas that address your concerns?  I
want to make sure the idea of changing the algorithm is acceptable at all
first.

> You mention the cost of power as the major factor influencing
> decentralized mining.  Would you agree that access to hardware that can do
> the mining is an equally large factor?  Even without ASICs you would need
> the physical cycles.  Including this factor helps us discuss the same set
> of expected situations.
>
> No, because anyone who is capable of selling hardware, or the expertise to
> design and build it, can earn by taking advantage of their particular
> expertise.
>
> Generally, such experts can saturate the locally-available energy sources,
> until local capacity has been saturated, and they can earn even more by
> selling extra hardware to entities located at other energy sources whose
> local capacities are not still underutilized, or expanding themselves to
> those sources.
> Other entities might be in better position to take advantage of particular
> local details, and it may be more lucrative for the
> expert-at-building-hardware to just sell the hardware to them than to
> attempt to expand in places where they have little local expertise.
>

It sounds like you are saying that the supply of electricity is exhausted
and the supply of hardware is not.

Is that correct?

I've seen that most of the time mining hardware distributors are sold out
of their top-of-the-line mining equipment, mostly selling in preorders.
Are implying most of the mining is done by privately built equipment?

Would you agree that an increase in the price of bitcoin would make the
availability of hardware matter much more, because the price of electricity
would matter much less?

Something to raise here is that all of these things take time and respond
in ebbs and flows.  If there were to be a plan to migrate to a new
algorithm, it would be participating in those ebbs and flows.

It takes time to build new hardware, and it takes time for the difficulty
to adjust to obsolete it.  What do you see as influencing how fast hardware
becomes obsolete?

I ask these questions because the answers relate to how what ways would be
good to change the mining function to increase decentralization.

And expertise is easy to copy, it is only the initial expertise that is
> hard to create in the first place, once knowledge is written down it can be
> copied.
>

Also takes measurable months to do.

> You describe improving electricity availability in expensive areas as a
> way to improve decentralization.  Honestly this sounds out of place to me
> and I'm sorry if I've upset you by rehashing this old topic.  I believe
> this list is for discussing the design of software, not international
> energy infrastructure: what is the relation?  There is a lot of power to
> influence behavior here but I thought the tools present are software design.
>
> I doubt there is any good software-only solution to the problem; the
> physical world remains the basis of the virtual one, and the virtual
> utterly dependent on the physical, and abstractions are always leaky (any
> non-toy software framework inevitably gains a way to query the operating
> system the application is running under, because abstractions inevitably
> leak): and energy, or the lack thereof, is the hardest to abstract away,
> which is the entire point of using proof-of-work as a reliable, unfakeable
> (i.e. difficult to virtualize) clock in the first place.
>
> Still, feel free to try: perhaps you might succeed.


You agreed earlier that changing the algorithm would increase
decentralization, but expressed other concerns with the idea.  Many more
general solutions are working in many altcoins.  I'm interested in
discussing changing the proof of work algorithm in bitcoin.

My motivation is security of the blockchain, which is partially held by
decentralization.

--00000000000079f66405a66a2c18
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Good afternoon=C2=A0ZmnSCPxj,<div dir=3D"auto"><br></div>=
<div dir=3D"auto">Thanks for holding your end of this discussion with me.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Sorry I am so verbose; I =
am still learning to communicate efficiently.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
&gt; You mention ASICs becoming commoditized.=C2=A0 I&#39;d remind you that=
 eventually there will be a public mathematical breaking of the algorithm, =
at which point all ASICs will become obsolete regardless.=C2=A0 Would you a=
gree it would be better to prepare for this by planning algorithm change?<b=
r>
<br>
Possibly, but then the reason for change is no longer to promote decentrali=
zation, would it?</blockquote></div></div><div dir=3D"auto"><div class=3D"g=
mail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It helps to be clear about what your goals are, because any chosen solution=
 might not be the best way to fix it.<br>
I admit that, if the problem were to be avoid the inevitable obsoletion of =
SHA-2, then this is the only solution, but that is not the problem you stat=
ed you were trying to solve in the first place.<br></blockquote></div></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">To be up front, the reason f=
or decentralization is due to concern around the security of the hashing.=
=C2=A0 Having a public breakage of the function simply makes the urgency ob=
vious.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Reddit claims two=
 entities controlled 62% of the hashrate recently:=C2=A0<a href=3D"https://=
old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoi=
ns_nakamoto/" target=3D"_blank" rel=3D"noreferrer">https://old.reddit.com/r=
/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/</a>=
 .=C2=A0 Compromising the systems of these two groups seems like it is all =
that is needed to compromise the entire blockchain (to the limited degree a=
 51% attack does).</div><div dir=3D"auto"><br></div><div dir=3D"auto">Hence=
 I see decentralization and cryptanalysis of the algorithm to be roughly si=
milar security concerns.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>It sounds like you agree that a change of algorithm is needed before the c=
urrent one is publicly broken.</div><div dir=3D"auto"><div class=3D"gmail_q=
uote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; You mention many coordinated hardforks.=C2=A0 Would you agree that if =
we came up with a way of programmatically cycling the algorithm, that only =
one hardfork work be needed?=C2=A0 For example one could ask nodes to conse=
nt to new algorithm code written in a simple scripting language, and reject=
 old ones slowly enough to provide for new research.<br>
<br>
Even *with* a scripting language, the issue is still what code written in t=
hat language is accepted, and *how*.<br>
<br>
Do miners vote on a new script describing the new hashing algorithm?<br>
What would their incentive be to obsolete their existing hardware?<br>
(using proof-of-work to lock in a hashing change feels very much like a chi=
cken-and-egg problem: the censorship-resistance provided by Bitcoin is base=
d on evicting any censors by overpowering their hashpower, but requires som=
e method of measuring that hashpower: it seems unlikely that you can safely=
 change the way hashpower is measured via a hashpower election)<br>
<br>
Do nodes install particular scripts and impose a switchover schedule of som=
e sort?<br>
Then how is that different from a hardfork, especially for nodes that do no=
t update?<br>
(notice that softforks allow nodes to remain non-updated, at degraded secur=
ity, but still in sync with the rest of the network and capable of transact=
ing with them)</blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I&#39;m expressing that in considering this we have two options: =
repeated hard forks or making repeated change a part of the protocol.=C2=A0=
 There are many ways to approach or implement it.=C2=A0 It sounds like you&=
#39;re noting that the second option takes some work and care?</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">Would it be helpful if I outlined mo=
re ideas that address your concerns?=C2=A0 I want to make sure the idea of =
changing the algorithm is acceptable at all first.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
&gt; You mention the cost of power as the major factor influencing decentra=
lized mining.=C2=A0 Would you agree that access to hardware that can do the=
 mining is an equally large factor?=C2=A0 Even without ASICs you would need=
 the physical cycles.=C2=A0 Including this factor helps us discuss the same=
 set of expected situations.<br>
<br>
No, because anyone who is capable of selling hardware, or the expertise to =
design and build it, can earn by taking advantage of their particular exper=
tise.<br>
<br>
Generally, such experts can saturate the locally-available energy sources, =
until local capacity has been saturated, and they can earn even more by sel=
ling extra hardware to entities located at other energy sources whose local=
 capacities are not still underutilized, or expanding themselves to those s=
ources.<br>
Other entities might be in better position to take advantage of particular =
local details, and it may be more lucrative for the expert-at-building-hard=
ware to just sell the hardware to them than to attempt to expand in places =
where they have little local expertise.<br></blockquote></div></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">It sounds like you are saying that t=
he supply of electricity is exhausted and the supply of hardware is not.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">Is that correct?</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">I&#39;ve seen that most of the ti=
me mining hardware distributors are sold out of their top-of-the-line minin=
g equipment, mostly selling in preorders.=C2=A0 Are implying most of the mi=
ning is done by privately built equipment?</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Would you agree that an increase in the price of bitcoin=
 would make the availability of hardware matter much more, because the pric=
e of electricity would matter much less?</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Something to raise here is that all of these things take t=
ime and respond in ebbs and flows.=C2=A0 If there were to be a plan to migr=
ate to a new algorithm, it would be participating in those ebbs and flows.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">It takes time to build n=
ew hardware, and it takes time for the difficulty to adjust to obsolete it.=
=C2=A0 What do you see as influencing how fast hardware becomes obsolete?</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">I ask these questions bec=
ause the answers relate to how what ways would be good to change the mining=
 function to increase decentralization.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
And expertise is easy to copy, it is only the initial expertise that is har=
d to create in the first place, once knowledge is written down it can be co=
pied.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Also takes measurable months to do.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
&gt; You describe improving electricity availability in expensive areas as =
a way to improve decentralization.=C2=A0 Honestly this sounds out of place =
to me and I&#39;m sorry if I&#39;ve upset you by rehashing this old topic.=
=C2=A0 I believe this list is for discussing the design of software, not in=
ternational energy infrastructure: what is the relation?=C2=A0 There is a l=
ot of power to influence behavior here but I thought the tools present are =
software design.<br>
<br>
I doubt there is any good software-only solution to the problem; the physic=
al world remains the basis of the virtual one, and the virtual utterly depe=
ndent on the physical, and abstractions are always leaky (any non-toy softw=
are framework inevitably gains a way to query the operating system the appl=
ication is running under, because abstractions inevitably leak): and energy=
, or the lack thereof, is the hardest to abstract away, which is the entire=
 point of using proof-of-work as a reliable, unfakeable (i.e. difficult to =
virtualize) clock in the first place.<br>
<br>
Still, feel free to try: perhaps you might succeed.</blockquote></div></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">You agreed earlier that chan=
ging the algorithm would increase decentralization, but expressed other con=
cerns with the idea.=C2=A0 Many more general solutions are working in many =
altcoins.=C2=A0 I&#39;m interested in discussing changing the proof of work=
 algorithm in bitcoin.</div><div dir=3D"auto"><br></div><div dir=3D"auto">M=
y motivation is security of the blockchain, which is partially held by dece=
ntralization.</div></div>

--00000000000079f66405a66a2c18--