path: root/01/43f16e35a574a9f99e5e9e8e01aad31abc953d

Return-Path: <gmkarl@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 94C8BC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 May 2020 12:34:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 8A68886155
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 May 2020 12:34:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ViMe7I4IQ4gX
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 May 2020 12:34:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f48.google.com (mail-io1-f48.google.com
 [209.85.166.48])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id ADB988614E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 May 2020 12:34:05 +0000 (UTC)
Received: by mail-io1-f48.google.com with SMTP id q8so17065924iow.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 25 May 2020 05:34:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=bb276ugBhtt6tDP50EZtGr55mJNHClfanXBjzjyztb8=;
 b=qQ8VeZSMvsddGJ35o+UKDB+R65t2M+VnHGbH2U8Uu2IYbdSzJumH59vJFtRIwCuygV
 unexrgukFajWY9r47Y4wMmFPtkyWxvBs6vaxxqaVwaVw0v0IC07RfIpYsasSmewDPqKD
 gT4EtLImI0zOT43iCxagf5lN8z77xiwPVClswJv99/ZyOsLzB+/1iT4lBzI4KfvJQI6p
 KxLfV0AEDefm1EpQsq26z6qj5tIK3cTIpkVlKiuX2Uf+iutGbnb9W0/X+p+Y52WteyDK
 qGKI6vC+dQUqmdBuYeHJXtAGjD7mZlDK5vubFaZW9pcfbKZqHoAWu48Qk3m8cTnhUbTg
 5w0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=bb276ugBhtt6tDP50EZtGr55mJNHClfanXBjzjyztb8=;
 b=QA5Y/v/KjaM+FRhH+28w4BhcOTDUa1da1E8KnNY0XV5Gbt+g+Z4lmfbqJT1gndWBP7
 BKq3JlBSldM1R08b//GYE8pQ1cFf4WkMuUIk6xYUqmbwdX4wm8NLVWbYh5RgQHxmN/oU
 /g9s0OokM9JC+yfSDmblJXqTzKg33j7twBzwM2njZ3ATay7Va8qXYpfoVp6gtirgCMAo
 3CHJV0MxmZ5AzTXfX0oHma9wxoFP/KlAvOtzdJsVCM59jFQmRqWM0iFgdSrbEL+CpBs7
 K2I/6xOxs743XWMrfgHvqI740MIOQox33E0r7LdsNLbiCTqhyVFwkQjYCill9nHaES+b
 jRJg==
X-Gm-Message-State: AOAM532KNQLpMtdGZmfnF8kl9Txf/TV2PgUFjdxsRyf2kH//gaLD8kF7
 ZSUBUACiw7V/JgzACci4iZZtnLKjE8gMltUJnvs=
X-Google-Smtp-Source: ABdhPJzD5LacHOoAIaA+BrOS7NWVIwtGURRQ5rcRNeR9GvktI8pwXiHyOEIZkSwmqcJw4R7RTgY9QRPc1uwsr9BzduY=
X-Received: by 2002:a05:6638:1405:: with SMTP id
 k5mr18634970jad.108.1590410044903; 
 Mon, 25 May 2020 05:34:04 -0700 (PDT)
MIME-Version: 1.0
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>
 <cR1ZDwP76-IljeSxpbx7WNI5t_d0eIbRTnUO8z3h7fQLJzAYVG_D427p_1NWfrJtWfyyBwnzjzgZClUCeZrZWg9ZNTbZKzmfuHHSO7D-9tA=@protonmail.com>
In-Reply-To: <cR1ZDwP76-IljeSxpbx7WNI5t_d0eIbRTnUO8z3h7fQLJzAYVG_D427p_1NWfrJtWfyyBwnzjzgZClUCeZrZWg9ZNTbZKzmfuHHSO7D-9tA=@protonmail.com>
From: Karl <gmkarl@gmail.com>
Date: Mon, 25 May 2020 07:54:58 -0400
Message-ID: <CALL-=e50OUCgGTYW5HzGoxjLQYAEsua+4i6QqSkPha2Q6KKEDQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000c615fd05a6783172"
X-Mailman-Approved-At: Mon, 25 May 2020 12:39:11 +0000
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 12:34:07 -0000

--000000000000c615fd05a6783172
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

We have been addressing many concepts.  Let's try to slowly trim it down
for simplicity.

> Reddit claims two entities controlled 62% of the hashrate recently:
> https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/
> .  Compromising the systems of these two groups 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
> of hashrate", which I do not quite agree with.
>

I am trying to say that both of these different things result in danger to
the integrity of the transaction log, which would be reduced by changing
the hash function.  They both have those 2 similarities.

Most human beings cannot think without constant communication with other
> human beings.

Thus, it is unlikely that a private break of the hash function is possible.
>

I disagree with you here: Andrew Wiles solved Fermat's Last Theorem in
isolation, academic research paper culture supports researching and then
publishing once you have privately developed results, and the CVE database
has 136k system vulnerabilities that were developed and shared privately
before public release, to prevent chaos.  This shows private advances in
ways to produce bitcoins are likely.

> Would it be helpful if I outlined more ideas that address your concerns?
> I want to make sure the idea of changing the algorithm is acceptable at all
> first.
>
> Go ahead.
>

Thanks: are you saying you would support changes if they addressed the
concerns you've listed?  Or are those concerns only the tip of the iceberg,
per se?

> > > You mention the cost of power as the major factor influencing
> decentralized mining.  Would you agree that access to hardware that can do
> the mining is an equally large factor?  Even without ASICs you would need
> the physical cycles.  Including this factor helps us discuss the same 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 expertise.
> > >
> > > Generally, such experts can saturate the locally-available energy
> sources, until local capacity has been saturated, and they can earn even
> more by selling extra hardware to entities located at other energy sources
> whose local capacities are not still underutilized, or expanding themselves
> to those sources.
> > > 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-hardware to just sell the hardware to them than to
> attempt to expand in places 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'm considering short-term obsolescence here.  Since hashrate rises
exponentially, only top-of-the-line hardware is competitively profitable.

> 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.
> 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
> electricity 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 electricity supply with your own mining operations and causing the
> local prices to rise up, or equivalently, until some governmental or other
> limits your usable electricity supply, which is equivalent to saying that
> the price of even more electricity would be your incarceration or other
> punishment, which might be too expensive for you to pay, thus selling the
> hardware is more lucrative).
>

If consumers who do not have the capacity to build their own hardware fast
enough to be competitive, do not have as much access to such hardware, then
their excess electricity is not being used to mine bitcoins.  A bit below
you propose spreading access via mass teaching, but I'm not aware of that
happening for now.


You could also analyze the transient economic behaviors here, specifically
> that an increase in Bitcoin price makes it more lucrative to mine in more
> places, which would start to put in orders for more hardware, and the
> hardware will take time to deliver, so the price at those places will
> increase only 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 average speed in many different fields.
>

I was thinking the transient changes would operate in cycles, and the
amplitude and frequency of those could be important to designing a safe
hard fork, but I think I was getting ahead of myself.  Let's move on.

> Something to raise here is that all of these things take time and respond
> in ebbs and flows.  If there were to be a plan to migrate to a new
> algorithm, 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
> acts as a buffer against transient ebbs and flows of the supply of
> hashpower.
>

Nice thoughts here on that same topic.  Thanks.

> > 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 be
> copied.
> >
> > Also takes measurable months to do.
>
> But can be massively parallelized, you can have a teacher or mentor
> teaching an entire classroom of students, and created lectures can be
> stored and re-given to many students, in the form of books, videos, etc.
> Human beings have been doing this since time immemorial, and possibly
> before recorded history, in such things as oral traditions and so on.
>

This doesn't seem relevant to me.  I'm discussing what is happening now and
what we can expect to happen from source code changes.  I don't see mining
hardware plans being taught in classrooms right now, but it sounds
interesting to try to change that if you want to change the subject of your
reply and start another thread.

> > > You describe improving electricity availability in expensive areas as
> a way to improve decentralization.  Honestly this sounds out of place to me
> and I'm sorry if I've upset you by rehashing this old topic.  I believe
> this list is for discussing the design of software, not international
> energy infrastructure: what is the relation?  There is a lot of power to
> influence behavior here but I thought the tools present are software design.
> > >
> > > I doubt there is any good software-only solution to the problem; the
> physical world remains the basis of the virtual one, and the virtual
> utterly dependent on the physical, and abstractions are always leaky (any
> non-toy software framework inevitably gains a way to query the operating
> system the application 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.
> >
> > You agreed earlier that changing the algorithm would increase
> decentralization, but expressed other concerns with the idea.  Many more
> general solutions are working in many altcoins.  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.
>

Sorry if I have misrepresented those as equal.  That's not quite what I
wanted to say and is addressed farther up in this reply.

I meant that in your first reply you listed a change of the pow algorithm
as a way to ensure decentralization: "there are effectively two strategies
for ensuring decentralization".  Let's discuss ways for improving them.

More likely, any centralization seen is due to local government
> interference in economic matters, such as creating a local artificial
> oversupply of electricity by paying for electricity generation using taxes.
>

Good thought.  Governments are kind of like big economic players that can
affect the spaces held by the small players.  They'll respond to the
scarcity, price, and mining rate of bitcoin, as well.  Moving on ...

> My motivation is security of the blockchain, which is partially held by
> decentralization.
>
> Let us be more precise and avoid the word "security".
>

Let's try to be concise and direct.

Miner decentralization supports censorship-resistance, so your motivation
> is censorship-resistance (is that correct?).
>

No.  Ensuring a 51% attack stays or becomes completely infeasible in the
future.  See the quote at the start of this reply.  I'm thinking about
https://en.bitcoin.it/wiki/Irreversible_Transactions#Majority_attack .

The space changes given private research and/or compromise of pools.

Is it okay to pursue this?

--000000000000c615fd05a6783172
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi ZmnSCPxj,<div dir=3D"auto"><br></div><div dir=3D"auto"=
>We have been addressing many concepts.=C2=A0 Let&#39;s try to slowly trim =
it down for simplicity.</div><div class=3D"gmail_quote" dir=3D"auto"><div d=
ir=3D"ltr" class=3D"gmail_attr"><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; Reddit claims two entities controlled 62% of the hashrate recently:=C2=
=A0<a href=3D"https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_th=
e_last_24_hours_bitcoins_nakamoto/" rel=3D"noreferrer noreferrer noreferrer=
" target=3D"_blank">https://old.reddit.com/r/CryptoCurrency/comments/gmhuon=
/in_the_last_24_hours_bitcoins_nakamoto/</a> .=C2=A0 Compromising the syste=
ms of these two groups seems like it is all that is needed to compromise th=
e entire blockchain (to the limited degree a 51% attack does).<br>
<br>
You seem to be equating &quot;break of the hash function&quot; with &quot;c=
entralization of hashrate&quot;, which I do not quite agree with.<br></bloc=
kquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">I am trying to s=
ay that both of these different things result in danger to the integrity of=
 the transaction log, which would be reduced by changing the hash function.=
=C2=A0 They both have those 2 similarities.</div><div dir=3D"auto"><br></di=
v><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Most human beings cannot think without constant communication with other hu=
man beings.</blockquote></div><div class=3D"gmail_quote" dir=3D"auto"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
Thus, it is unlikely that a private break of the hash function is possible.=
<br></blockquote></div><div dir=3D"auto"><br></div><div class=3D"gmail_quot=
e" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div><div dir=
=3D"auto">I disagree with you here: Andrew Wiles solved Fermat&#39;s Last T=
heorem in isolation, academic research paper culture supports researching a=
nd then publishing once you have privately developed results, and the CVE d=
atabase has 136k system vulnerabilities that were developed and shared priv=
ately before public release, to prevent chaos.=C2=A0 This shows private adv=
ances in ways to produce bitcoins are likely.</div><div dir=3D"auto"><br></=
div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; Would it be helpful if I outlined more ideas that address your concern=
s?=C2=A0 I want to make sure the idea of changing the algorithm is acceptab=
le at all first.<br>
<br>
Go ahead.<br></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Thanks: are you saying you would support changes if they addressed the c=
oncerns you&#39;ve listed?=C2=A0 Or are those concerns only the tip of the =
iceberg, per se?</div><div dir=3D"auto"><br></div><div class=3D"gmail_quote=
" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
&gt; &gt; &gt; You mention the cost of power as the major factor influencin=
g decentralized mining.=C2=A0 Would you agree that access to hardware that =
can do the mining is an equally large factor?=C2=A0 Even without ASICs you =
would need the physical cycles.=C2=A0 Including this factor helps us discus=
s the same set of expected situations.<br>
&gt; &gt;<br>
&gt; &gt; No, because anyone who is capable of selling hardware, or the exp=
ertise to design and build it, can earn by taking advantage of their partic=
ular expertise.<br>
&gt; &gt;<br>
&gt; &gt; Generally, such experts can saturate the locally-available energy=
 sources, until local capacity has been saturated, and they can earn even m=
ore by selling extra hardware to entities located at other energy sources w=
hose local capacities are not still underutilized, or expanding themselves =
to those sources.<br>
&gt; &gt; Other entities might be in better position to take advantage of p=
articular local details, and it may be more lucrative for the expert-at-bui=
lding-hardware to just sell the hardware to them than to attempt to expand =
in places where they have little local expertise.<br>
&gt;<br>
&gt; It sounds like you are saying that the supply of electricity is exhaus=
ted and the supply of hardware is not.<br>
&gt;<br>
&gt; Is that correct?<br>
<br>
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.<br=
></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m c=
onsidering short-term obsolescence here.=C2=A0 Since hashrate rises exponen=
tially, only top-of-the-line hardware is competitively profitable.</div><di=
v dir=3D"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
&gt; I&#39;ve seen that most of the time mining hardware distributors are s=
old out of their top-of-the-line mining equipment, mostly selling in preord=
ers.=C2=A0 Are implying most of the mining is done by privately built equip=
ment?<br>
<br>
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).<br></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">If consumers who do not have the capacity to build their own hardware fa=
st enough to be competitive, do not have as much access to such hardware, t=
hen their excess electricity is not being used to mine bitcoins.=C2=A0 A bi=
t below you propose spreading access via mass teaching, but I&#39;m not awa=
re of that happening for now.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
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.<br>
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.<br></blockquote></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">I was thinking the transient changes would oper=
ate in cycles, and the amplitude and frequency of those could be important =
to designing a safe hard fork, but I think I was getting ahead of myself.=
=C2=A0 Let&#39;s move on.</div><div dir=3D"auto"><br></div><div class=3D"gm=
ail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; Something to raise here is that all of these things take time and resp=
ond in ebbs and flows.=C2=A0 If there were to be a plan to migrate to a new=
 algorithm, it would be participating in those ebbs and flows.<br>
<br>
The usual engineering response is to create buffers to be resilient against=
 ebbs and flows.<br>
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.<br>
<br>
Similarly, economic contracts like futures and options are economic buffers=
 against the ebb and flow of local supply of various materials.<br>
<br>
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=
.<br></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">Nice =
thoughts here on that same topic.=C2=A0 Thanks.</div><div dir=3D"auto"><br>=
</div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
&gt; &gt; And expertise is easy to copy, it is only the initial expertise t=
hat is hard to create in the first place, once knowledge is written down it=
 can be copied.<br>
&gt;<br>
&gt; Also takes measurable months to do.<br>
<br>
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.<br>
Human beings have been doing this since time immemorial, and possibly befor=
e recorded history, in such things as oral traditions and so on.<br></block=
quote></div><div dir=3D"auto"><br></div><div dir=3D"auto">This doesn&#39;t =
seem relevant to me.=C2=A0 I&#39;m discussing what is happening now and wha=
t we can expect to happen from source code changes.=C2=A0 I don&#39;t see m=
ining hardware plans being taught in classrooms right now, but it sounds in=
teresting to try to change that if you want to change the subject of your r=
eply and start another thread.</div><div dir=3D"auto"><br></div><div class=
=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; &gt; &gt; 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&#39;m sorry if I&#39;ve upset you by rehashing this o=
ld topic.=C2=A0 I believe this list is for discussing the design of softwar=
e, not international energy infrastructure: what is the relation?=C2=A0 The=
re is a lot of power to influence behavior here but I thought the tools pre=
sent are software design.<br>
&gt; &gt;<br>
&gt; &gt; I doubt there is any good software-only solution to the problem; =
the physical world remains the basis of the virtual one, and the virtual ut=
terly dependent on the physical, and abstractions are always leaky (any non=
-toy software framework inevitably gains a way to query the operating syste=
m the application 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. dif=
ficult to virtualize) clock in the first place.<br>
&gt; &gt;<br>
&gt; &gt; Still, feel free to try: perhaps you might succeed.<br>
&gt;<br>
&gt; You agreed earlier that changing the algorithm would increase decentra=
lization, but expressed other concerns with the idea.=C2=A0 Many more gener=
al solutions are working in many altcoins.=C2=A0 I&#39;m interested in disc=
ussing changing the proof of work algorithm in bitcoin.<br>
<br>
I did not so agree: in particular, I do not agree with equating a break of =
the proof-of-work algorithm with centralization.<br></blockquote></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Sorry if I have misrepresented th=
ose as equal.=C2=A0 That&#39;s not quite what I wanted to say and is addres=
sed farther up in this reply.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">I meant that in your first reply you listed a change of the pow algor=
ithm as a way to ensure decentralization: &quot;there are effectively two s=
trategies for ensuring decentralization&quot;.=C2=A0 Let&#39;s discuss ways=
 for improving them.</div><div dir=3D"auto"><br></div><div class=3D"gmail_q=
uote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">Good thought.=C2=A0 Go=
vernments are kind of like big economic players that can affect the spaces =
held by the small players.=C2=A0 They&#39;ll respond to the scarcity, price=
, and mining rate of bitcoin, as well.=C2=A0 Moving on ...</div><div dir=3D=
"auto"><br></div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
&gt; My motivation is security of the blockchain, which is partially held b=
y decentralization.<br>
<br>
Let us be more precise and avoid the word &quot;security&quot;.<br></blockq=
uote></div><div dir=3D"auto"><br></div><div dir=3D"auto">Let&#39;s try to b=
e concise and direct.</div><div dir=3D"auto"><br></div><div class=3D"gmail_=
quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Miner decentralization supports censorship-resistance, so your motivation i=
s censorship-resistance (is that correct?).<br></blockquote></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">No.=C2=A0 Ensuring a 51% attack stays=
 or becomes completely infeasible in the future.=C2=A0 See the quote at the=
 start of this reply.=C2=A0 I&#39;m thinking about <a href=3D"https://en.bi=
tcoin.it/wiki/Irreversible_Transactions#Majority_attack">https://en.bitcoin=
.it/wiki/Irreversible_Transactions#Majority_attack</a> .</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">The space changes given private research a=
nd/or compromise of pools.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Is it okay to pursue this?</div></div>

--000000000000c615fd05a6783172--