From: Lonero Foundation <loneroassociation@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: 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 01:59:31 -0400 [thread overview]
Message-ID: <CA+YkXXzv2Q02uwAvdwOPjk=Lkj5jyYb6AtC5B25oGfVej0y6TA@mail.gmail.com> (raw)
In-Reply-To: <rJRQhaMpP-Rq5oJ8nscd81M3tq8PiaSGfvlF6xr0qIjJgcoN_p3azQ9-a-RAvIxDmRa1cfoBkJZnLXILDzhYKh3SDk9TE08wbX60d6EAjQw=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7386 bytes --]
I wouldn't fully discount general purpose hardware or hardware outside of
the realm of ASICS. BOINC (https://cds.cern.ch/record/800111/files/p1099.pdf)
implements a decent distributed computing protocol (granted it isn't a
cryptocurrency), but it far computes data at a much cheaper cost compared
to the competition w/ decent levels of fault tolerance. I myself am running
an extremely large scale open distributed computing pipeline, and can tell
you for certain that what is out there is insane. In regards to the
argument of generic HDDs and CPUs, the algorithmic implementation I am
providing would likely make them more adaptable. More than likely,
evidently there would be specialized HDDs similar to BurstCoin Miners, and
128-core CPUs, and all that. This could be inevitable, but the main point
is providing access to other forms of computation along w/ ASICs. At the
very least, the generic guys can experience it, and other infrastructures
can have some form of compatibility. In regards to ASICBOOST, I am already
well aware of it, as well as mining firmwares, autotuning, multi-threaded
processing setups, overclocking, and even different research firms
involved. I think it is feasible to provide multiple forms of computation
without disenfranchising one over the other. I'm also well aware of the
history of BTC and how you can mine BTC just by downloading the whitepaper,
to USB block erupters, to generic CPUs, to few ASICS, to entire mining
farms. I also have seen experimental projects such as Cuckoo
<https://github.com/tromp/cuckoo>, so I know the arguments regarding
computation vs. memory boundness and whether or not they can be one of the
same. The answer is yes, but it needs to be designed correctly. I think in
regards to the level of improvement, this is just one of the improvements
in my BIPs in regards to making PoW more adaptable. I also have
cryptography improvements I'm looking into as well. Nonetheless, I believe
the implementation I want to do would at the very least be quite
interesting.
Best regards, Andrew
On Wed, Mar 17, 2021 at 1:05 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> 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
>
>
[-- Attachment #1.2: Type: text/html, Size: 8029 bytes --]
[-- Attachment #2: Screenshot_2021-03-17 BoincOverview – BOINC.png --]
[-- Type: image/png, Size: 57634 bytes --]
next prev parent reply other threads:[~2021-03-17 5:59 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
2021-03-17 5:59 ` Lonero Foundation [this message]
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='CA+YkXXzv2Q02uwAvdwOPjk=Lkj5jyYb6AtC5B25oGfVej0y6TA@mail.gmail.com' \
--to=loneroassociation@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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