Date: Wed, 17 Mar 2021 05:05:36 +0000
To: Lonero Foundation <loneroassociation@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <rJRQhaMpP-Rq5oJ8nscd81M3tq8PiaSGfvlF6xr0qIjJgcoN_p3azQ9-a-RAvIxDmRa1cfoBkJZnLXILDzhYKh3SDk9TE08wbX60d6EAjQw=@protonmail.com>
In-Reply-To: <CA+YkXXy1Y407UDdEjRVjzBFOCmaUKDoZkvqtXkxkmXmMdNrwBQ@mail.gmail.com>
References: <CA+YkXXxUdZFYTa1c-F=-FzoQQVtV3GUmE2Okec-zRAD3xS1qAQ@mail.gmail.com>
 <CALeFGL31M5DAULLRtCwjPYHaPVqsVqREUg6WQ2-cuj23SNk=BA@mail.gmail.com>
 <CA+YkXXwBMG6YUAhf-2U5EV5Ep5RgG2foc9chramNFN5=AQ=-EA@mail.gmail.com>
 <CALeFGL3E-rWW9aJkwre_3UF44vbNxPH2436DvaQdHoqEQ5b+eg@mail.gmail.com>
 <CA+YkXXyBmOootb=Kt6CH3yquYVnAZd=fJQqiF_A3p_pkB8QC3g@mail.gmail.com>
 <CALC81CMDQf4PqxRisQw58OL7QSFeMcQTvLMvmtOGJ_ya4-dhLg@mail.gmail.com>
 <CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com>
 <CA+YkXXw1AiMqCoPk_pUOdDMfkGF_T+aURGAjGK=MTa7jtAQchg@mail.gmail.com>
 <CA+YkXXy1Y407UDdEjRVjzBFOCmaUKDoZkvqtXkxkmXmMdNrwBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST
	Datastore for Energy Efficient Mining
Precedence: list

Good morning Andrew,

Looking over the text...

> # I am looking towards integrating memory hard compatibility w/ the minin=
g algorithm. Memory hard computation allows for time and space complexity f=
or data storage functionality, and there is a way this can likely be implem=
ented without disenfranchising current miners or their hardware if done rig=
ht.

I believe this represents a tradeoff between time and space --- either you =
use one spatial unit and take a lot of time, or you use multiple spatial un=
its and take smaller units of time.

But such time/space tradeoffs are already possible with the existing mechan=
ism --- if you cannot run your existing SHA256d miner faster (time), you ju=
st buy more miners (space).

Thus, I think the requirement for memory hardness is a red herring in the d=
esign of proof-of-work algorithms.
Memory hardness *prevents* this tradeoff (you cannot create a smaller miner=
 that takes longer to mine, as you have a memory requirement that prevents =
trading off space).

It is also helpful to remember that spinning rust consumes electricity as w=
ell, and that any operation that requires changes in data being stored requ=
ires a lot of energy.
Indeed, in purely computational algorithms (e.g. CPU processing pipelines) =
a significant amount of energy is spent on *changing* voltage levels, with =
very little energy (negligible compared to the energy spent in changing vol=
tage levels in modern CMOS hardware) in *maintaining* the voltage levels.

> I don't see a reason why somebody with $2m of regular hardware can't mine=
 the same amount of BTC as somebody with $2m worth of ASICs.

I assume here that "regular hardware" means "general-purpose computing devi=
ce".

The Futamura projections are a good reason I see: http://blog.sigfpe.com/20=
09/05/three-projections-of-doctor-futamura.html

Basically, any interpreter + fixed program can be converted, via Futamura p=
rojection, to an optimized program that cannot interpret any other program =
but runs faster and takes less resources.

In short, any hardware interpreter (i.e. general-purpose computing device) =
+ a fixed proof-of-whatever program, can be converted to an optimized hardw=
are that can only perform that proof-of-whatever program, but consuming les=
s energy and space and will (eventually) be cheaper per unit as well, so th=
at $2M of such a specific hardware will outperform $2M of general-purpose c=
omputing hardwre.

Thus, all application-specificity (i.e. any fixed program) will always take=
 less resources to run than a generic hardware interpreter that can run any=
 program.

Thus, if you ever nail down the specifics of your algorithm, and if a thous=
and-Bitcoin industry ever grows around that program, you will find that ASI=
Cs ***will*** arise that run that algorithm faster and less energy-consumin=
g than general-purpose hardware that has to interpret a binary.
**For one, memory/disk bus operations are limited only to actual data, with=
out requiring additional bus operations to fetch code.**
Data can be connected directly from the output of one computational sub-uni=
t to the input of another, without requiring (as in the general-purpose har=
dware case) that the intermediate outputs be placed in general-purpose stor=
age register (which, as noted, takes energy to *change* its contents, and a=
s general-purpose storage will also be used to hold *other* intermediate ou=
tputs).
Specialized HDDs can arise as well which are optimized for whatever access =
pattern your scheme requires, and that would also outperform general-purpos=
e HDDs as well.

Further optimizations may also exist in an ASIC context that are not readil=
y visible but which are likely to be hidden somewhere --- the more complica=
ted your program design, the more likely it is that you will not readily se=
e such hidden optimizations that can be achieved by ASICs (xref ASICBOOST).

In short, even with memory-hardness, an ASIC will arise which might need to=
 be connected to an array of (possibly specialized) HDDs but which will sti=
ll outperform your general-purpose hardware connected to an array of genera=
l-purpose storage.

Indeed, various storage solutions already have different specializations: S=
MR HDDs replace tape drives, PMR HDDs serve as caches of SMR HDDs, SSDs ser=
ve as caches of PMR HDDs.
An optimized technology stack like that can outperform a generic HDD.

You cannot fight the inevitability of ASICs and other specialized hardware,=
 just as you cannot fight specialization.

You puny humans must specialize in order to achieve the heights of your civ=
ilization --- I can bet you 547 satoshis that you yourself cannot farm your=
 own food, you specialize in software engineering of some kind and just pay=
 a farmer to harvest your food for you.
Indeed, you probably do not pay a farmer directly, but pay an intermediary =
that specializes in packing food for transport from the farm to your domici=
le. which itself probably delegates the actual transporting to another spec=
ialist.
Similarly, ASICs will arise and focus on particularly high-value fixed comp=
utations, inevitably.


Regards,
ZmnSCPxj