From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 11EECC016F for ; Mon, 25 May 2020 07:58:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id EECF586D95 for ; Mon, 25 May 2020 07:58:27 +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 lqUysTFNVDsZ for ; Mon, 25 May 2020 07:58:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by whitealder.osuosl.org (Postfix) with ESMTPS id 06D8586D81 for ; Mon, 25 May 2020 07:58:25 +0000 (UTC) Date: Mon, 25 May 2020 07:58:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1590393502; bh=mDtZFhRFNqdk1Sq87AhvLJOOYLEux9qqC0+ZhDzzLto=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=vSPUadQx7QhuzMJ3mWmNcgHS+oWdQ5hKETqM5qmlj7/ayBZy3b/ZDwF1nWBT2GHGI nHa1TaBuP+4qdf2JPjKSSkGGYhEF1cYUJx+DfvR0MpVKAyuBrvpiFGTRFob4eQ+Q/H U3rvfjnP2pmvStVnXLjrV8+KQr6Mw96qA/9NLkQA= To: Karl From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion 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: Mon, 25 May 2020 07:58:28 -0000 Good morning Kari, > > > You mention ASICs becoming commoditized.=C2=A0 I'd remind you that ev= entually there will be a public mathematical breaking of the algorithm, at = which point all ASICs will become obsolete regardless.=C2=A0 Would you agre= e it would be better to prepare for this by planning algorithm change? > > > > Possibly, but then the reason for change is no longer to promote decent= ralization, would it? > > > It helps to be clear about what your goals are, because any chosen solu= tion 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.=C2=A0 Having a public breakage of the function= simply makes the urgency obvious. Now that I have thought about it more: again, the important thing about the= proof-of-work technique is not so much the algorithm itself, only that exe= cuting it requires energy. And all algorithms require energy in order to execute. Even if some technique is found which partially breaks the hash function an= d allows faster generation of hashes for the amount of energy consumed, thi= s is not a problem for mining itself: the difficulty adjusts and mining con= tinues. The execution of this technique is unlikely to require no computation, only= reduced computational effort; and all that is needed is *some* measure of = computational effort done, the *scale* of that measure is not really materi= al for the purpose of ordering atomic transactional updates to the UTXO set= . Of course, things like the Merkle tree and txids and so on would need chang= ing in case of even a partial break of the hash function, which would requi= re a hardfork to survive; you might as well change the proof-of-work functi= on as well then. > > Reddit claims two entities controlled 62% of the hashrate recently:=C2= =A0https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_h= ours_bitcoins_nakamoto/ .=C2=A0 Compromising the systems of these two group= s seems like it is all that is needed to compromise the entire blockchain (= to the limited degree a 51% attack does). You seem to be equating "break of the hash function" with "centralization o= f hashrate", which I do not quite agree with. Most human beings cannot think without constant communication with other hu= man beings. Thus, it is unlikely that a private break of the hash function is possible. Instead, a break of the hash function is likely to be discovered in various= ways by multiple human beings who have been communicating with each other. Even historically, inventions never arose fully-formed from the head of the= inventor, like Athena from the brow of Zeus; every invention has predecess= ors, successors, and peers in the inhabited milieu. Instead, you can look up the costs of local electricity globally, and notic= e where those entities have their largest mines geographically located. > > Hence I see decentralization and cryptanalysis of the algorithm to be rou= ghly 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.=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 cons= ent to new algorithm code written in a simple scripting language, and rejec= t 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 sa= fely 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 d= o not update? > > (notice that softforks allow nodes to remain non-updated, at degraded s= ecurity, but still in sync with the rest of the network and capable of tran= sacting with them) > > I'm expressing that in considering this we have two options: repeated har= d forks or making repeated change a part of the protocol.=C2=A0 There are m= any ways to approach or implement it.=C2=A0 It sounds like you're noting th= at the second option takes some work and care? > > Would it be helpful if I outlined more ideas that address your concerns?= =C2=A0 I want to make sure the idea of changing the algorithm is acceptable= at all first. Go ahead. > > > > You mention the cost of power as the major factor influencing decentr= alized mining.=C2=A0 Would you agree that access to hardware that can do th= e mining is an equally large factor?=C2=A0 Even without ASICs you would nee= d the physical cycles.=C2=A0 Including this factor helps us discuss the sam= e 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 e= xpertise. > > > > Generally, such experts can saturate the locally-available energy sourc= es, until local capacity has been saturated, and they can earn even more by= selling extra hardware to entities located at other energy sources whose l= ocal capacities are not still underutilized, or expanding themselves to tho= se sources. > > Other entities might be in better position to take advantage of particu= lar 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 pla= ces 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? Given that electricity is consumed very quickly, and hardware takes a long = time to truly consume or obsolete, yes: rate of consumption of electricity = is expected to dominate compared to the rate of consumption of hardware. > > 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.= =C2=A0 Are implying most of the mining is done by privately built equipment= ? It seems the most lucrative thing to do, that if you have a new generation = of hardware, to mine with them yourself, until the price of local electrici= ty has increased due to your consumption, and it becomes more lucrative to = sell the hardware to other potential miners who now have lower electricity = prices compared to yours (because you have been saturating the local electr= icity supply with your own mining operations and causing the local prices t= o rise up, or equivalently, until some governmental or other limits your us= able electricity supply, which is equivalent to saying that the price of ev= en more electricity would be your incarceration or other punishment, which = might be too expensive for you to pay, thus selling the hardware is more lu= crative). I have no evidence to back this, thus it is not a claim to truth, only a cl= aim to economic logic, if we assume that mining hardware manufacturers are = economically rational, are interested only in the selfish gain of economic = power, etc. etc. Real human beings and the entities they build may not behave in such a perf= ectly rational manner, or I may be assuming details that are not accurate t= o reality. > > Would you agree that an increase in the price of bitcoin would make the a= vailability of hardware matter much more, because the price of electricity = would matter much less? Electricity is a factor with every piece of hardware that is utilized, so a= ny increase in hardware will also have an increase in electricity consumed. So I expect that the materiality of the price of electricity will increase = in lockstep with the materiality of the price of hardware (note that price = is simply demand over supply, and supply is the availability of hardware). You could also analyze the transient economic behaviors here, specifically = that an increase in Bitcoin price makes it more lucrative to mine in more p= laces, which would start to put in orders for more hardware, and the hardwa= re will take time to deliver, so the price at those places will increase on= ly after a long while, etc. But those are transient changes, and by the time any change at the software= level is coordinated, the transient economic behaviors may have resettled = to the expected long-term behavior: humans operate at around the same avera= ge speed in many different fields. > > Something to raise here is that all of these things take time and respond= in ebbs and flows.=C2=A0 If there were to be a plan to migrate to a new al= gorithm, it would be participating in those ebbs and flows. The usual engineering response is to create buffers to be resilient against= ebbs and flows. Note how we prefer to dam water supplies (i.e. create a buffer) rather than= adjust our water consumption dynamically according to the ebb and flow of = the water supply. Similarly, economic contracts like futures and options are economic buffers= against the ebb and flow of local supply of various materials. Within Bitcoin, my understanding is that the difficulty adjustment system a= cts as a buffer against transient ebbs and flows of the supply of hashpower= . > It takes time to build new hardware, and it takes time for the difficulty= to adjust to obsolete it.=C2=A0 What do you see as influencing how fast ha= rdware becomes obsolete? In the long run? We will run out of ideas of how to improve the implementation of the hashin= g function, and there will be only a few designs that implement all the kno= wn ideas for optimizing the implementation. Then hardware becomes obsolete from normal wear and tear, e.g. electromigra= tion, and that takes years to take effect. > > I ask these questions because the answers relate to how what ways would b= e 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 b= e copied. > > Also takes measurable months to do. But can be massively parallelized, you can have a teacher or mentor teachin= g an entire classroom of students, and created lectures can be stored and r= e-given to many students, in the form of books, videos, etc. Human beings have been doing this since time immemorial, and possibly befor= e recorded history, in such things as oral traditions and so on. > > > > 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'm sorry if I've upset you by rehashing this old topic.=C2= =A0 I believe this list is for discussing the design of software, not inter= national energy infrastructure: what is the relation?=C2=A0 There is a lot = of power to influence behavior here but I thought the tools present are sof= tware design. > > > > I doubt there is any good software-only solution to the problem; the ph= ysical world remains the basis of the virtual one, and the virtual utterly = dependent on the physical, and abstractions are always leaky (any non-toy s= oftware framework inevitably gains a way to query the operating system the = application is running under, because abstractions inevitably leak): and en= ergy, or the lack thereof, is the hardest to abstract away, which is the en= tire 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 decentraliz= ation, but expressed other concerns with the idea.=C2=A0 Many more general = solutions are working in many altcoins.=C2=A0 I'm interested in discussing = changing the proof of work algorithm in bitcoin. I did not so agree: in particular, I do not agree with equating a break of = the proof-of-work algorithm with centralization. More likely, any centralization seen is due to local government interferenc= e in economic matters, such as creating a local artificial oversupply of el= ectricity by paying for electricity generation using taxes. > > My motivation is security of the blockchain, which is partially held by d= ecentralization. Let us be more precise and avoid the word "security". Miner decentralization supports censorship-resistance, so your motivation i= s censorship-resistance (is that correct?). Ultimately, what really protects censorship-resistance is not the details o= f the hashing algorithm, it is the economics involved. In order to evict a censor, hashpower must be brought to bear against the c= ensor. And that hashpower has to be bought and paid for. The mechanism for doing this already exists, and is called the "mining fee"= (note that the block subsidy does not protect against the censor, as the c= ensor gets the block reward as well; what the censor cannot get is the fees= attached to a transaction that the censor does not want published). Regards, ZmnSCPxj