path: root/77/85aab414d500a7f50c58742c4b9052d5cf8dd6

Return-Path: <arielluaces@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 144ACC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 23:51:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 073F586E9E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 23:51:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id kkbTeF5PkUd3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 23:51:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com
 [209.85.216.43])
 by whitealder.osuosl.org (Postfix) with ESMTPS id A9EF986E88
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 23:51:14 +0000 (UTC)
Received: by mail-pj1-f43.google.com with SMTP id fs4so860591pjb.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 24 May 2020 16:51:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=in-reply-to:references:thread-topic:user-agent:mime-version
 :content-transfer-encoding:subject:from:date:to:message-id;
 bh=KormV7sZECquRXniWh8hFmzldGv2pnfAryAyg/Of/XU=;
 b=MsyFKPtGxANPwd5wE1NJK9a4xuprOfN1yjv6CYyhFd5WzY+LbDoR9VvRXDkfJUrK7w
 A1D+qeBkS90pRkSf0JhNUPxgE/5UBXP/69ZAUheiyOcxeS98duCjp8p7xiyj/xO1QddL
 sfuFcCgowJSZSdBJQIiprXeIx6HMWgEXdi1pxPSGNzmRK0lHTPoTpLXlLK9tGPgCIQi3
 cEsjVVXAppx3kersCsPYwupg7QKqbfi2QxOHk1tF6WgiIRaOSQGIjJDdMcgoIqeWzhI5
 lunggw7Ees9Fehi8h/sBMDdAb1nnHLoZBLkc35ssN6KpQjm4h7Kfv13Rt7/EXDGLtnJg
 +q7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:in-reply-to:references:thread-topic:user-agent
 :mime-version:content-transfer-encoding:subject:from:date:to
 :message-id;
 bh=KormV7sZECquRXniWh8hFmzldGv2pnfAryAyg/Of/XU=;
 b=rth00V45jo+YOf6FQJxEGzi4jNXshcAzLOF3kFmUQZ+h3W8kfguG9dfCO1Ktf9hBeM
 pZ4G64BBxjhfmauusS6XmLiLY05L00iIqS2YZSEOU4hqmthMiFovc4isp6cdK982lAjc
 W+DG6nJw2WULAGLhDoEM67EydlBIb2fRW8o1W+4wCjZTRk81nZse6rksVvDc4I/G22Uy
 GIoz3XSXXq2GhYynyZefsQT1V2Yb3SE8ldmFH5nVbxH5STE5aeUXSJStcx17sQ7aGUxU
 NN1endgD+MvlmddOmp5os0NKfKxS9vvHuhk6yCB+Zq+iiQb533dabYryiBY7G/KMM86H
 URHw==
X-Gm-Message-State: AOAM533/xzL8x5MyhpI35ouQF8DhycJ1RzUdiGiaqMioZv1jp2lMR1RT
 H5mx9E5sXVVBFwyX7yzLU5pF/dZJ
X-Google-Smtp-Source: ABdhPJyolMBmlph+/fRPX4B+MQng6XVJDbE0UBgfGHGgUlA1fjLhQ0EOiQh2z25w/OY9k+q6b5HLQw==
X-Received: by 2002:a17:90b:3651:: with SMTP id
 nh17mr18032297pjb.228.1590364274235; 
 Sun, 24 May 2020 16:51:14 -0700 (PDT)
Received: from android-e4829d5afe115de1 (S01060090a9f325e0.vw.shawcable.net.
 [24.85.219.92])
 by smtp.gmail.com with ESMTPSA id gz19sm7534978pjb.33.2020.05.24.16.51.13
 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
 Sun, 24 May 2020 16:51:13 -0700 (PDT)
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>
X-Referenced-Uid: 22359
Thread-Topic: Re: [bitcoin-dev] hashcash-newhash
X-Blue-Identity: !l=0&o=96429&fo=97453&pl=0&po=0&qs=PREFIX&f=HTML&n=Ariel%20Lorenzo-Luaces&e=arielluaces%40gmail.com&m=!%3AZjEwN2MyYjMtOWE0OC00NzJhLWEzYTQtYjc3MTEzNTNhODJm%3ASU5CT1g%3D%3AMjIzNTk%3D%3AANSWERED&p=0&q=SHOW
User-Agent: Android
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----X6G6VT7LWUI84Y1CPS7SHGG8H3UGRS"
Content-Transfer-Encoding: 7bit
X-Local-Message-Id: <f74fc5a4-b09b-41d0-a3c4-7d6726cee016@gmail.com>
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>
X-Mailman-Approved-At: Mon, 25 May 2020 10:20:31 +0000
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 23:51:16 -0000

------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--