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>
In-Reply-To: <k4J1fJMk2ySTLdlj8RgYxgb4_U3gtRH65Au5FLsCsVZPiEBRKU1cqy_S--2IxiRUGI1-5P1SMZkxnwlBf8YJ8ZQM_AM7jeuA6Y6dpT9jwi0=@protonmail.com>
From: Karl <gmkarl@gmail.com>
Date: Sun, 24 May 2020 05:02:59 -0400
Message-ID: <CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000000ca3c005a661292a"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] hashcash-newhash
Precedence: list

--0000000000000ca3c005a661292a
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

Thanks for your reply.  I'm on mobile so please excuse me for top-posting.

I'd like to sort these various points out.  Maybe we won't finish the whole
discussion, but maybe at least we can update wiki articles like
https://en.bitcoin.it/wiki/Hashcash#Cryptanalytic_Risks with more points or
a link to conversations like this.

Everything is possible but some things take a lot of work.

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?

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.

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.

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.

On Sat, May 23, 2020, 9:12 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Karl,
>
> > Hi,
> >
> > I'd like to revisit the discussion of the digest algorithm used in
> hashcash.
> >
> > I believe migrating to new hashing algorithms as a policy would
> significantly increase decentralization and hence security.
>
> Why do you believe so?
>
> My understanding is that there are effectively two strategies for ensuring
> decentralization based on hash algorithm:
>
> * Keep changing the hash algorithm to prevent development of ASICs and
> ensure commodity generic computation devices (GPUs) are the only practical
> target.
> * Do not change the algorithm, to ensure that knowledge of how best to
> implement an ASIC for the algorithm becomes spread out (through corporate
> espionage, ASIC reverse-engineering, patent expiry, and sheer engineering
> effort) and ASICs for the algorithm are as commoditized as GPUs.
>
> The former strategy has the following practical disadvantages:
>
> * Developing new hash algorithms is not cheap.
>   The changes to the hashcash algorithm may need to occur faster than the
> speed at which we can practically develop new, cryptographically-secure
> hash algorithms.
> * It requires coordinated hardforks over the entire network at an
> alarmingly high rate.
> * It arguably puts too much power to the developers of the code.
>
> On the other hand, the latter strategy requires us only to survive an
> intermediate period where ASICs are developed, but not yet commoditized;
> and during this intermediate period, the centralization pressure of ASICs
> might not be more powerful than other centralization pressures
>
> --
>
> Which brings us to another point.
>
> Non-ASIC-resistance is, by my understanding, a non-issue.
>
> Regardless of whether the most efficient available computing substrate for
> the hashcash algorithm is CPU, GPU, or ASIC, ultimately miner earnings are
> determined by cost of power supply.
>
> Even if you imagine that changing the hashcash algorithm would make CPUs
> practical again, you will still not run it on the CPU of a mobile, because
> a mobile runs on battery, and charging a battery takes more power than what
> you can extract from the battery afterwards, because thermodynamics.
>
> Similarly, geographic locations with significant costs of electrical power
> will still not be practical places to start a mine, regardless if the mine
> is composed of commodity server racks, commodity video cards, or commodity
> ASICs.
>
> If you want to solve the issue of miner centralization, the real solution
> is improving the efficiency of energy transfer to increase the areas where
> cheap energy is available, not stopgap change-the-algorithm-every-6-months.
>
>
> Regards,
> ZmnSCPxj
>
>
> >
> > I believe the impact on existing miners could be made pleasant by
> gradually moving the block reward from the previous hash to the next (such
> that both are accepted with different rewards).  An appropriate rate could
> possibly be calculated from the difficulty.
> >
> > You could develop the frequency of introduction of new hashes such that
> once present-day ASICs are effectively obsolete anyway due to competition,
> new ones do not have time to develop.
> >
> > I'm interested in hearing thoughts and concerns.
> >
> > Karl Semich
>
>
>

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

<div dir=3D"auto">Hi ZmnSCPxj,<div dir=3D"auto"><br></div><div dir=3D"auto"=
>Thanks for your reply.=C2=A0 I&#39;m on mobile so please excuse me for top=
-posting.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;d like t=
o sort these various points out.=C2=A0 Maybe we won&#39;t finish the whole =
discussion, but maybe at least we can update wiki articles like <a href=3D"=
https://en.bitcoin.it/wiki/Hashcash#Cryptanalytic_Risks">https://en.bitcoin=
.it/wiki/Hashcash#Cryptanalytic_Risks</a> with more points or a link to con=
versations like this.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Ev=
erything is possible but some things take a lot of work.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">You mention ASICs becoming commoditized.=
=C2=A0 I&#39;d remind you that eventually there will be a public mathematic=
al breaking of the algorithm, at which point all ASICs will become obsolete=
 regardless.=C2=A0 Would you agree it would be better to prepare for this b=
y planning algorithm change?</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">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.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">You mention the cost of power as the major fac=
tor influencing decentralized mining.=C2=A0 Would you agree that access to =
hardware that can do the mining is an equally large factor?=C2=A0 Even with=
out ASICs you would need the physical cycles.=C2=A0 Including this factor h=
elps us discuss the same set of expected situations.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">You describe improving electricity availabilit=
y in expensive areas as a way to improve decentralization.=C2=A0 Honestly t=
his sounds out of place to me and I&#39;m sorry if I&#39;ve upset you by re=
hashing this old topic.=C2=A0 I believe this list is for discussing the des=
ign of software, not international energy infrastructure: what is the relat=
ion?=C2=A0 There is a lot of power to influence behavior here but I thought=
 the tools present are software design.</div><br><div class=3D"gmail_quote"=
 dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, May 23, 2020, 9=
:12 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@pro=
tonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good mor=
ning Karl,<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; I&#39;d like to revisit the discussion of the digest algorithm used in=
 hashcash.<br>
&gt;<br>
&gt; I believe migrating to new hashing algorithms as a policy would signif=
icantly increase decentralization and hence security.<br>
<br>
Why do you believe so?<br>
<br>
My understanding is that there are effectively two strategies for ensuring =
decentralization based on hash algorithm:<br>
<br>
* Keep changing the hash algorithm to prevent development of ASICs and ensu=
re commodity generic computation devices (GPUs) are the only practical targ=
et.<br>
* Do not change the algorithm, to ensure that knowledge of how best to impl=
ement an ASIC for the algorithm becomes spread out (through corporate espio=
nage, ASIC reverse-engineering, patent expiry, and sheer engineering effort=
) and ASICs for the algorithm are as commoditized as GPUs.<br>
<br>
The former strategy has the following practical disadvantages:<br>
<br>
* Developing new hash algorithms is not cheap.<br>
=C2=A0 The changes to the hashcash algorithm may need to occur faster than =
the speed at which we can practically develop new, cryptographically-secure=
 hash algorithms.<br>
* It requires coordinated hardforks over the entire network at an alarmingl=
y high rate.<br>
* It arguably puts too much power to the developers of the code.<br>
<br>
On the other hand, the latter strategy requires us only to survive an inter=
mediate period where ASICs are developed, but not yet commoditized; and dur=
ing this intermediate period, the centralization pressure of ASICs might no=
t be more powerful than other centralization pressures<br>
<br>
--<br>
<br>
Which brings us to another point.<br>
<br>
Non-ASIC-resistance is, by my understanding, a non-issue.<br>
<br>
Regardless of whether the most efficient available computing substrate for =
the hashcash algorithm is CPU, GPU, or ASIC, ultimately miner earnings are =
determined by cost of power supply.<br>
<br>
Even if you imagine that changing the hashcash algorithm would make CPUs pr=
actical again, you will still not run it on the CPU of a mobile, because a =
mobile runs on battery, and charging a battery takes more power than what y=
ou can extract from the battery afterwards, because thermodynamics.<br>
<br>
Similarly, geographic locations with significant costs of electrical power =
will still not be practical places to start a mine, regardless if the mine =
is composed of commodity server racks, commodity video cards, or commodity =
ASICs.<br>
<br>
If you want to solve the issue of miner centralization, the real solution i=
s improving the efficiency of energy transfer to increase the areas where c=
heap energy is available, not stopgap change-the-algorithm-every-6-months.<=
br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
&gt;<br>
&gt; I believe the impact on existing miners could be made pleasant by grad=
ually moving the block reward from the previous hash to the next (such that=
 both are accepted with different rewards).=C2=A0 An appropriate rate could=
 possibly be calculated from the difficulty.<br>
&gt;<br>
&gt; You could develop the frequency of introduction of new hashes such tha=
t once present-day ASICs are effectively obsolete anyway due to competition=
, new ones do not have time to develop.<br>
&gt;<br>
&gt; I&#39;m interested in hearing thoughts and concerns.<br>
&gt;<br>
&gt; Karl Semich<br>
<br>
<br>
</blockquote></div></div>

--0000000000000ca3c005a661292a--