path: root/67/5760929aeb1f9174eb40c767ac6a425d91e6be

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 11EECC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <gmkarl@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <cR1ZDwP76-IljeSxpbx7WNI5t_d0eIbRTnUO8z3h7fQLJzAYVG_D427p_1NWfrJtWfyyBwnzjzgZClUCeZrZWg9ZNTbZKzmfuHHSO7D-9tA=@protonmail.com>
In-Reply-To: <CALL-=e6J4QFjdbC=caux=TAHjveKaehnGfdyeEdEhgniSp7PYA@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>
 <WqvuQWsFg50edn9nmk0DRcTsEZr__CFaQd9T3bw3b7CffGDjwXsVApzZvnsNdmeLQDrFKDMFgb5QDzHVhOhudGfu3HlvQKyR-9luPI-YCbs=@protonmail.com>
 <CALL-=e6J4QFjdbC=caux=TAHjveKaehnGfdyeEdEhgniSp7PYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: 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