In-Reply-To: <CALL-=e6_hrT9W2j73==cyX4Q=yt+guJn7RSgW1quA4JAgjD42w@mail.gmail.com>
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>
Thread-Topic: Re: [bitcoin-dev] hashcash-newhash
User-Agent: Android
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----X6G6VT7LWUI84Y1CPS7SHGG8H3UGRS"
Content-Transfer-Encoding: 7bit
From: Ariel Lorenzo-Luaces <arielluaces@gmail.com>
Date: Sun, 24 May 2020 16:51:10 -0700
To: Karl <gmkarl@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <f74fc5a4-b09b-41d0-a3c4-7d6726cee016@gmail.com>
Subject: Re: [bitcoin-dev] hashcash-newhash
Precedence: list

------X6G6VT7LWUI84Y1CPS7SHGG8H3UGRS
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
 charset=UTF-8


On May 24, 2020, 1:26 PM, at 1:26 PM, Karl via bitcoin-dev <bitcoin-dev@l=
ists=2Elinuxfoundation=2Eorg> wrote:
>Hi ZmnSCPxj,
>
>Thanks for your reply=
=2E  I'm on mobile so please excuse me for
>top-posting=2E
>
>I'd like to s=
ort these various points out=2E  Maybe we won't finish the
>whole
>discussi=
on, but maybe at least we can update wiki articles like
>https://en=2Ebitco=
in=2Eit/wiki/Hashcash#Cryptanalytic_Risks with more
>points or
>a link to c=
onversations like this=2E
>
>Everything is possible but some things take a =
lot of work=2E
>
>You mention ASICs becoming commoditized=2E  I'd remind yo=
u that
>eventually
>there will be a public mathematical breaking of the alg=
orithm, at which
>point all ASICs will become obsolete regardless=2E  Would=
 you agree it
>would
>be better to prepare for this by planning algorithm c=
hange?
>
>You mention many coordinated hardforks=2E  Would you agree that i=
f we
>came up
>with a way of programmatically cycling the algorithm, that o=
nly one
>hardfork work be needed?  For example one could ask nodes to conse=
nt to
>new
>algorithm code written in a simple scripting language, and reje=
ct old
>ones
>slowly enough to provide for new research=2E
>
>You mention t=
he cost of power as the major factor influencing
>decentralized
>mining=2E =
 Would you agree that access to hardware that can do the mining
>is
>an equ=
ally large factor?  Even without ASICs you would need the
>physical
>cycles=
=2E  Including this factor helps us discuss the same set of
>expected
>situ=
ations=2E
>
>You describe improving electricity availability in expensive a=
reas as a
>way
>to improve decentralization=2E  Honestly this sounds out of=
 place to me
>and
>I'm sorry if I've upset you by rehashing this old topic=
=2E  I believe
>this
>list is for discussing the design of software, not in=
ternational energy
>infrastructure: what is the relation?  There is a lot o=
f power to
>influence
>behavior here but I thought the tools present are so=
ftware design=2E
>
>On Sat, May 23, 2020, 9:12 PM ZmnSCPxj <ZmnSCPxj@proton=
mail=2Ecom> wrote:
>
>> Good morning Karl,
>>
>> > Hi,
>> >
>> > I'd like t=
o revisit the discussion of the digest algorithm used in
>> hashcash=2E
>> =
>
>> > I believe migrating to new hashing algorithms as a policy would
>> s=
ignificantly increase decentralization and hence security=2E
>>
>> Why do y=
ou believe so?
>>
>> My understanding is that there are effectively two str=
ategies for
>ensuring
>> decentralization based on hash algorithm:
>>
>> * =
Keep changing the hash algorithm to prevent development of ASICs
>and
>> en=
sure commodity generic computation devices (GPUs) are the only
>practical
>=
> target=2E
>> * Do not change the algorithm, to ensure that knowledge of h=
ow best
>to
>> implement an ASIC for the algorithm becomes spread out (thro=
ugh
>corporate
>> espionage, ASIC reverse-engineering, patent expiry, and s=
heer
>engineering
>> effort) and ASICs for the algorithm are as commoditize=
d as GPUs=2E
>>
>> The former strategy has the following practical disadvan=
tages:
>>
>> * Developing new hash algorithms is not cheap=2E
>>   The chan=
ges to the hashcash algorithm may need to occur faster than
>the
>> speed a=
t which we can practically develop new,
>cryptographically-secure
>> hash a=
lgorithms=2E
>> * It requires coordinated hardforks over the entire network=
 at an
>> alarmingly high rate=2E
>> * It arguably puts too much power to t=
he developers of the code=2E
>>
>> On the other hand, the latter strategy r=
equires us only to survive an
>> intermediate period where ASICs are develo=
ped, 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=
=2E
>>
>> Non-ASIC-resistance is, by my understanding, a non-issue=2E
>>
>>=
 Regardless of whether the most efficient available computing
>substrate fo=
r
>> the hashcash algorithm is CPU, GPU, or ASIC, ultimately miner
>earning=
s are
>> determined by cost of power supply=2E
>>
>> Even if you imagine th=
at 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 ext=
ract from the battery afterwards, because thermodynamics=2E
>>
>> Similarly=
, geographic locations with significant costs of electrical
>power
>> will =
still not be practical places to start a mine, regardless if the
>mine
>> i=
s composed of commodity server racks, commodity video cards, or
>commodity
=
>> ASICs=2E
>>
>> If you want to solve the issue of miner centralization, t=
he real
>solution
>> is improving the efficiency of energy transfer to incr=
ease the areas
>where
>> cheap energy is available, not stopgap
>change-the=
-algorithm-every-6-months=2E
>>
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> >
>> > =
I believe the impact on existing miners could be made pleasant by
>> gradua=
lly moving the block reward from the previous hash to the next
>(such
>> th=
at both are accepted with different rewards)=2E  An appropriate rate
>could=

>> possibly be calculated from the difficulty=2E
>> >
>> > You could devel=
op the frequency of introduction of new hashes such
>that
>> once present-d=
ay ASICs are effectively obsolete anyway due to
>competition,
>> new ones d=
o not have time to develop=2E
>> >
>> > I'm interested in hearing thoughts =
and concerns=2E
>> >
>> > Karl Semich
>>
>>
>>
>
>
>-----------------------=
-------------------------------------------------
>
>______________________=
_________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists=2Eli=
nuxfoundation=2Eorg
>https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo=
/bitcoin-dev

------X6G6VT7LWUI84Y1CPS7SHGG8H3UGRS
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div class=3D"gmail_quote" >On May 24, 2020, at 1:=
26 PM, Karl via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=2Elinux=
foundation=2Eorg" target=3D"_blank">bitcoin-dev@lists=2Elinuxfoundation=2Eo=
rg</a>&gt; wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt=
 0pt 0=2E8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">
<div dir=3D"auto"><div dir=3D"auto">You mention ASICs becoming commoditi=
zed=2E&nbsp; I'd remind you that eventually there will be a public mathemat=
ical breaking of the algorithm, at which point all ASICs will become obsole=
te regardless=2E&nbsp; Would you agree it would be better to prepare for th=
is by planning algorithm change?</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Cryptographic algorithms don't usually break this way=2E In the c=
ase of hash functions it may be possible to find an exploit that reduces th=
e function's security from 256 bits to 128 for example=2E So an algorithm t=
hat could find 80 zero bits per energy unit before can now find 160 zero bi=
ts per energy unit with an exploit=2E</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">If this exploit can be deployed as a software patch to most A=
SICs then the issue will sort itself out on the next difficulty adjustment=
=2E</div><div dir=3D"auto"><br></div><div dir=3D"auto">If the exploit inste=
ad requires an entirely new ASIC then GPUs and FPGAs that could previously =
find 40 zero bits per energy unit can now compete with the less adaptive AS=
ICs until new ASICs that use the exploit start getting produced and shipped=
=2E</div><div dir=3D"auto"><br></div><div dir=3D"auto">There's never any of=
ficial "public breaking" of a hash function=2E The function will just loose=
 security over time until it's deemed to not be "secure enough" for certain=
 applications=2E Thankfully mining is an application where the only importa=
nt thing is that the difficulty can be increased=2E In other words, if the =
entire world can consistently find 256 zero bits of SHA-256 in under 10 min=
utes then definitely the hash function needs to be changed=2E But this won'=
t happen in a day=2E</div></div></blockquote></div></body></html>
------X6G6VT7LWUI84Y1CPS7SHGG8H3UGRS--