From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Lonero Foundation <loneroassociation@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining
Date: Wed, 17 Mar 2021 05:05:36 +0000 [thread overview]
Message-ID: <rJRQhaMpP-Rq5oJ8nscd81M3tq8PiaSGfvlF6xr0qIjJgcoN_p3azQ9-a-RAvIxDmRa1cfoBkJZnLXILDzhYKh3SDk9TE08wbX60d6EAjQw=@protonmail.com> (raw)
In-Reply-To: <CA+YkXXy1Y407UDdEjRVjzBFOCmaUKDoZkvqtXkxkmXmMdNrwBQ@mail.gmail.com>
Good morning Andrew,
Looking over the text...
> # I am looking towards integrating memory hard compatibility w/ the mining algorithm. Memory hard computation allows for time and space complexity for data storage functionality, and there is a way this can likely be implemented without disenfranchising current miners or their hardware if done right.
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 units and take smaller units of time.
But such time/space tradeoffs are already possible with the existing mechanism --- if you cannot run your existing SHA256d miner faster (time), you just buy more miners (space).
Thus, I think the requirement for memory hardness is a red herring in the design 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 well, and that any operation that requires changes in data being stored requires 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 voltage 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 device".
The Futamura projections are a good reason I see: http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html
Basically, any interpreter + fixed program can be converted, via Futamura projection, 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 hardware that can only perform that proof-of-whatever program, but consuming less energy and space and will (eventually) be cheaper per unit as well, so that $2M of such a specific hardware will outperform $2M of general-purpose computing 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 thousand-Bitcoin industry ever grows around that program, you will find that ASICs ***will*** arise that run that algorithm faster and less energy-consuming than general-purpose hardware that has to interpret a binary.
**For one, memory/disk bus operations are limited only to actual data, without requiring additional bus operations to fetch code.**
Data can be connected directly from the output of one computational sub-unit to the input of another, without requiring (as in the general-purpose hardware case) that the intermediate outputs be placed in general-purpose storage register (which, as noted, takes energy to *change* its contents, and as general-purpose storage will also be used to hold *other* intermediate outputs).
Specialized HDDs can arise as well which are optimized for whatever access pattern your scheme requires, and that would also outperform general-purpose HDDs as well.
Further optimizations may also exist in an ASIC context that are not readily visible but which are likely to be hidden somewhere --- the more complicated your program design, the more likely it is that you will not readily see 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 still outperform your general-purpose hardware connected to an array of general-purpose storage.
Indeed, various storage solutions already have different specializations: SMR HDDs replace tape drives, PMR HDDs serve as caches of SMR HDDs, SSDs serve 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 civilization --- 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 domicile. which itself probably delegates the actual transporting to another specialist.
Similarly, ASICs will arise and focus on particularly high-value fixed computations, inevitably.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-03-17 5:05 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 23:42 Lonero Foundation
2021-03-05 13:42 ` Ryan Grant
[not found] ` <CAB0O3SVNyr_t23Y0LyT0mSaf6LONFRLYJ8qzO7rcdJFnrGccFw@mail.gmail.com>
2021-03-05 15:12 ` Lonero Foundation
2021-03-05 16:16 ` Lonero Foundation
2021-03-05 21:11 ` Keagan McClelland
2021-03-05 21:21 ` Lonero Foundation
2021-03-06 0:41 ` Keagan McClelland
2021-03-06 0:57 ` Lonero Foundation
2021-03-06 15:21 ` Ricardo Filipe
[not found] ` <CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com>
2021-03-08 23:40 ` Lonero Foundation
2021-03-11 15:29 ` Lonero Foundation
2021-03-12 15:02 ` Erik Aronesty
2021-03-12 16:54 ` Lonero Foundation
2021-03-12 22:37 ` email
2021-03-12 23:21 ` Lonero Foundation
2021-03-12 23:31 ` Lonero Foundation
2021-03-13 8:13 ` email
2021-03-13 15:02 ` Lonero Foundation
2021-03-13 15:45 ` yancy
2021-03-13 17:11 ` Lonero Foundation
2021-03-13 19:44 ` email
2021-03-14 5:45 ` Lonero Foundation
2021-03-17 0:24 ` Erik Aronesty
2021-03-17 5:05 ` ZmnSCPxj [this message]
2021-03-17 5:59 ` Lonero Foundation
2021-03-17 6:56 ` ZmnSCPxj
2021-03-17 7:06 ` Lonero Foundation
2021-03-14 12:36 ` LORD HIS EXCELLENCY JAMES HRMH
2021-03-14 14:32 ` Thomas Hartman
2021-03-16 18:22 ` Lonero Foundation
2021-03-15 2:02 ` Eric Martindale
2021-03-15 2:32 ` Lonero Foundation
[not found] ` <CA+YkXXyMUQtdSvjuMPQO71LpPb8qFdy-LTSrA8FEbeWMbPWa4w@mail.gmail.com>
2021-03-15 2:58 ` Lonero Foundation
2021-03-05 20:53 Eric Voskuil
[not found] <CA+YkXXzfEyeXYMyPKL20S+2VVRZVuHRT6eRgX56FBgG_A+uVSw@mail.gmail.com>
[not found] ` <12480994-451A-4256-8EFA-4741B3EC2006@voskuil.org>
2021-03-05 22:03 ` Lonero Foundation
2021-03-05 22:49 ` Eric Voskuil
2021-03-05 23:10 ` Lonero Foundation
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='rJRQhaMpP-Rq5oJ8nscd81M3tq8PiaSGfvlF6xr0qIjJgcoN_p3azQ9-a-RAvIxDmRa1cfoBkJZnLXILDzhYKh3SDk9TE08wbX60d6EAjQw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=loneroassociation@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox