From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3D5CFC000A for ; Wed, 17 Mar 2021 05:05:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 31D3782E0E for ; Wed, 17 Mar 2021 05:05:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.676 X-Spam-Level: X-Spam-Status: No, score=0.676 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, LOTS_OF_MONEY=0.001, MONEY_FREEMAIL_REPTO=0.274, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qx_09unhSPe for ; Wed, 17 Mar 2021 05:05:44 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp1.osuosl.org (Postfix) with ESMTPS id 4EAF28391F for ; Wed, 17 Mar 2021 05:05:43 +0000 (UTC) Date: Wed, 17 Mar 2021 05:05:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1615957540; bh=3vjOdy7kTV64qkuF+Mq6aZWKIJAKpakgHPQC9Hm6hWY=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=IrFRQpi/RAnsu1HT1q99CQwxa448cuWnisyj6jOd753FHYNyPwq5bA9rANct4JQTT Rv96h3aTq28g93H9gsz2/kHwkukP5R+jHFPT/z0Or69hlkeO/ZnsMQuAIwITKamsKl DXq04FnNwDNPMfWq3xrtxZUJ3TMoUlSGb4dfLpss= To: Lonero Foundation , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 05:05:46 -0000 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