From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B3A24C000A for ; Wed, 17 Mar 2021 07:06:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A25F542C2A for ; Wed, 17 Mar 2021 07:06:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdpZzIM4OvKc for ; Wed, 17 Mar 2021 07:06:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by smtp2.osuosl.org (Postfix) with ESMTPS id 90A8740172 for ; Wed, 17 Mar 2021 07:06:45 +0000 (UTC) Received: by mail-yb1-xb2a.google.com with SMTP id n195so39464997ybg.9 for ; Wed, 17 Mar 2021 00:06:45 -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=8ricxN0ye9xJoR0EPMMmo96nZABbWouLhPbNvws/WZk=; b=QkFaZUIbBTV9zPQL5DZnnRRbqDy0HXNDXbsCCs/DD/07HZpFcPIULuOIMSvaNLh1uV GCLzpiy9q/xkJq5rSiEkPkBgIyJuTiH9abfNNIQJIsHDzl5yVmbn58SVt5a4m9jLsoWX ga1I00ml258PMpjAWInp+y/s79sCcUBfYrJ+jis4zWcpUICgbgmKK1pKqobyDpx2AbRS JcGHBEcEmLmM7LMVx1zPlN0FeF/ZTN8YJuhTOZqfx86hXJ+4cVeeqTWI6nPKAqdzSaoA J7A5CwQ4ematUsJ/HGOtdhBHxOLDC2PP/fEpqC+8Nt6773MPkr41MHrI5N8UKHy65bne cR0w== 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=8ricxN0ye9xJoR0EPMMmo96nZABbWouLhPbNvws/WZk=; b=P3NHA8HxhoMzcVWumpiHCDMWlXKax5ypHRhFGlRdWBWEiaIrQLS03cW0/BBBXzjfLR Z0yfR7UxFFXfneudYwcZ4yZfKFZCvrdDsAahtyESRUCOzbrUbGD/iwtvaCye/vdWfnu/ bTjFxICb/a1lWKODGD5wcjP3WTabwaQAPvXneUu8sOtQxo19iAn9f0MViptYIZv76FUc e64L3TwW6kh5N2Lw+6SlzeWp0y4RwY/zbDVz/g61yv4rpOVXtC1j9L/BpklggTKiXlN3 V1zzQKjWuNIZTLiI/dsGWn33CxaBmethQ++7Mf4Ma49qFlvX4er0/Ke2FtaAOgaFnE0f UYAw== X-Gm-Message-State: AOAM53101XpDLN7AweRvz+TGRi9RL7vGLxBb+uWmUOSQwEEXUl6uXXxA k/hVJYOrPu2wlG8O0C/EC+cDHtf8WF9lJSrri2k= X-Google-Smtp-Source: ABdhPJxqO16iaEc0GBbwUDY3mabNJyhe+/rH+1mNTD58JhIaTfzsKIs1dNbpyUr/vOO8iKEBLRxvoWotx6Sh3SEh1Fc= X-Received: by 2002:a25:ae14:: with SMTP id a20mr2819991ybj.129.1615964804579; Wed, 17 Mar 2021 00:06:44 -0700 (PDT) MIME-Version: 1.0 References: <3eY-dfJ9c5qbmAL2gnRAkTFw_HYki0sNAwTtGptRleabpGhy7r5BApXD7qQs8OA63zAGrLha2ZIfGCbqyn1zHIbCaUgZv6Qmoqkz7M6mKV4=@protonmail.com> In-Reply-To: <3eY-dfJ9c5qbmAL2gnRAkTFw_HYki0sNAwTtGptRleabpGhy7r5BApXD7qQs8OA63zAGrLha2ZIfGCbqyn1zHIbCaUgZv6Qmoqkz7M6mKV4=@protonmail.com> From: Lonero Foundation Date: Wed, 17 Mar 2021 03:06:32 -0400 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="00000000000025848005bdb62090" X-Mailman-Approved-At: Wed, 17 Mar 2021 19:10:49 +0000 Cc: Bitcoin Protocol Discussion 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 07:06:46 -0000 --00000000000025848005bdb62090 Content-Type: text/plain; charset="UTF-8" The advantage is simple, access to more computational opportunities means a more scalable network and other reasons, including further options for optimization. There are also lots of reasons to believe a huge demand of unmet needs in this space. Why force people to mine Chia if they want to mine BTC, and why can't highly specialized HPC clusters mine in similar ways to many of the large ASIC farms? Like I said the design and implementation needs to be correct for that to work, and I intended to look towards improving the algo to get the best of both worlds. In regards to SHA256d, that is an entirely different discussion, but even if one was to stick to SHA256d for an hashing algo, there are still implementations of PoW likely more adaptable. Best regards, Andrew On Wed, Mar 17, 2021, 2:56 AM ZmnSCPxj wrote: > Good morning Andrew, > > > 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. > > What would the advantage of this be? > > As I see it, changing the underlying algorithm is simply an attempt to > reverse history, by requiring a new strain of specialization to be started > instead of continuing the trend of optimizing SHA256d very very well. > > I think it may be better to push *through* rather than *back*, and instead > spread the optimization of SHA256d-specific hardware so widely that anyone > with 2 BTC liquidity in one location has no particular advantage over > anyone with 2 BTC liquidity in another location. > For one, I expect that there will be fewer patentable surprises remaining > with SHA256d than any newer, much more complicated construction. > > Regards, > ZmnSCPxj > --00000000000025848005bdb62090 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The advantage is s= imple, access to more computational opportunities means a more scalable net= work and other reasons, including further options for optimization. There a= re also lots of reasons to believe a huge demand of unmet needs in this spa= ce. Why force people to mine Chia if they want to mine BTC, and why can'= ;t highly specialized HPC clusters mine in similar ways to many of the larg= e ASIC farms? Like I said the design and implementation needs to be correct= for that to work, and I intended to look towards improving the algo to get= the best of both worlds. In regards to SHA256d, that is an entirely differ= ent discussion, but even if one was to stick to SHA256d for an hashing algo= , there are still implementations of PoW likely more adaptable.

Best regards, Andrew

On Wed, Mar 17, 2021, 2:56 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good morning Andrew,

> I wouldn't fully discount general purpose hardware or hardware out= side of the realm of ASICS. BOINC (https= ://cds.cern.ch/record/800111/files/p1099.pdf) implements a decent distr= ibuted computing protocol (granted it isn't a cryptocurrency), but it f= ar computes data at a much cheaper cost compared to the competition w/ dece= nt 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 CPU= s, the algorithmic implementation I am providing would likely make them mor= e adaptable. More than likely, evidently there would be specialized HDDs si= milar to BurstCoin Miners, and 128-core CPUs, and all that. This could be i= nevitable, but the main point is providing access to other forms of computa= tion along w/ ASICs. At the very least, the generic guys can experience it,= and other infrastructures can have some form of compatibility.

What would the advantage of this be?

As I see it, changing the underlying algorithm is simply an attempt to reve= rse history, by requiring a new strain of specialization to be started inst= ead of continuing the trend of optimizing SHA256d very very well.

I think it may be better to push *through* rather than *back*, and instead = spread the optimization of SHA256d-specific hardware so widely that anyone = with 2 BTC liquidity in one location has no particular advantage over anyon= e with 2 BTC liquidity in another location.
For one, I expect that there will be fewer patentable surprises remaining w= ith SHA256d than any newer, much more complicated construction.

Regards,
ZmnSCPxj
--00000000000025848005bdb62090--