Date: Sun, 24 May 2020 16:51:36 +0000
To: Karl <gmkarl@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <WqvuQWsFg50edn9nmk0DRcTsEZr__CFaQd9T3bw3b7CffGDjwXsVApzZvnsNdmeLQDrFKDMFgb5QDzHVhOhudGfu3HlvQKyR-9luPI-YCbs=@protonmail.com>
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>
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
Precedence: list

Good morning Kari,


> You mention ASICs becoming commoditized.=C2=A0 I'd remind you that eventu=
ally there will be a public mathematical breaking of the algorithm, at whic=
h point all ASICs will become obsolete regardless.=C2=A0 Would you agree it=
 would be better to prepare for this by planning algorithm change?

Possibly, but then the reason for change is no longer to promote decentrali=
zation, would it?
It helps to be clear about what your goals are, because any chosen solution=
 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 stat=
ed you were trying to solve in the first place.

>
> 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 consent =
to new algorithm code written in a simple scripting language, and reject ol=
d ones slowly enough to provide for new research.

Even *with* a scripting language, the issue is still what code written in t=
hat 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 chi=
cken-and-egg problem: the censorship-resistance provided by Bitcoin is base=
d on evicting any censors by overpowering their hashpower, but requires som=
e method of measuring that hashpower: it seems unlikely that you can safely=
 change the way hashpower is measured via a hashpower election)

Do nodes install particular scripts and impose a switchover schedule of som=
e sort?
Then how is that different from a hardfork, especially for nodes that do no=
t update?
(notice that softforks allow nodes to remain non-updated, at degraded secur=
ity, but still in sync with the rest of the network and capable of transact=
ing with them)

>
> You mention the cost of power as the major factor influencing decentraliz=
ed mining.=C2=A0 Would you agree that access to hardware that can do the mi=
ning is an equally large factor?=C2=A0 Even without ASICs you would need th=
e physical cycles.=C2=A0 Including this factor helps us discuss the same se=
t 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 exper=
tise.

Generally, such experts can saturate the locally-available energy sources, =
until local capacity has been saturated, and they can earn even more by sel=
ling extra hardware to entities located at other energy sources whose local=
 capacities are not still underutilized, or expanding themselves to those s=
ources.
Other entities might be in better position to take advantage of particular =
local details, and it may be more lucrative for the expert-at-building-hard=
ware to just sell the hardware to them than to attempt to expand in places =
where they have little local expertise.

And expertise is easy to copy, it is only the initial expertise that is har=
d to create in the first place, once knowledge is written down it can be co=
pied.

>
> You describe improving electricity availability in expensive areas as a w=
ay 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 bel=
ieve this list is for discussing the design of software, not international =
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 software des=
ign.

I doubt there is any good software-only solution to the problem; the physic=
al world remains the basis of the virtual one, and the virtual utterly depe=
ndent on the physical, and abstractions are always leaky (any non-toy softw=
are framework inevitably gains a way to query the operating system the appl=
ication is running under, because abstractions inevitably leak): and energy=
, or the lack thereof, is the hardest to abstract away, which is the entire=
 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.

Regards,
ZmnSCPxj