Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 144ACC016F for ; 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 ; 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 ; 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 ; Sun, 24 May 2020 23:51:14 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id fs4so860591pjb.5 for ; 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: References: 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: From: Ariel Lorenzo-Luaces Date: Sun, 24 May 2020 16:51:10 -0700 To: Karl , Bitcoin Protocol Discussion Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
On May 24, 2020, at 1:= 26 PM, Karl via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eo= rg> wrote:
You mention ASICs becoming commoditi= zed=2E  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  Would you agree it would be better to prepare for th= is by planning algorithm change?

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

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

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

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