path: root/32/f80c1303d646b68c3107b83f2787421e8b0885

Return-Path: <ricardojdfilipe@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 21A75C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 15:21:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 03AFA43001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 15:21:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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,
 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 L8pQkywXFwWA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 15:21:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 781A642FB0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 15:21:25 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id bd6so7319094edb.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 06 Mar 2021 07:21:25 -0800 (PST)
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
 :content-transfer-encoding;
 bh=43oA/MMNav6YMY6kApkYlI2AlIDAbEXHGxNtXAr1dv0=;
 b=k7v8F7BY3r/8jhoABBh50FyI0GBZ54J1kVCvTX9IvhWUnJlZ6TMVmMNlw3WSTa897+
 fDZO9U9RwSe70dbR7njrt3PKOjNchK12/qMy0pegQpdNG4q/fCFpZcZYnSJYt+wNfZRH
 X64UMFTP5rxs7cczLyqQ17Y6gzsT0cqgmZl7vU14R2y6eIiP+aAMR4/AYG12HMV8Uw6p
 hz7gXCRwCclOX4zSeHodzyGbWOqkPZUmobWLL/O4uH4KrnmmhIjUqlk/GQxuN87G+Vrt
 RN16c5SNgHyhOSI5ys9/Qypy+Gs995gVxId7dIgTlxDBdVwx2LzlDyRCvUS+7i7gMxHM
 0IGA==
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:content-transfer-encoding;
 bh=43oA/MMNav6YMY6kApkYlI2AlIDAbEXHGxNtXAr1dv0=;
 b=a5bkIS+QtrE1JALpXTCFcgbd/STYU5WQDWXQkaiYZThxrMfVIE86zfsmlFmIJP1Zqg
 /rBxJalBepGlghbSR37KWMucHr3++wbirCWEMPPWVoqLhjeJKdMnNL/hO0jPFkYQhbaE
 SrFT7iWRAy0nczVLMn3zE3rC+yS4/a2w1UBIhr8TKgCTfQ3iISMraOEtMiU1RU4Ddzay
 IjyzNBtLkPtPyGJwF5Fn0Crvzqv/jJI57ICiftwQgY9cL+Tpx8iguG43VxEFGWYcm3k9
 vRK8LlYg3S/MuOTepsPBUpRmzzc4P+5ZNbHIjdAkknPW0cs44V5bUPiLX+pm1LToC1R9
 ckQg==
X-Gm-Message-State: AOAM533hLuMt+A4RpyqPaXiAIl45hlVZtwzYbV/o2tKygji+mFjO+lCl
 B7r3Uw65/O/93/OCVS6X3gSBwcIIRyPyhhDuu9c=
X-Google-Smtp-Source: ABdhPJyGhRYjIfq8JoOSiX8Xnrgxv1BJ93s2zeIWfhziWMZJZ8sbrDujRaUevWhdRL4L5K2vUlv7MfYk+oR37ov+55s=
X-Received: by 2002:a50:fe06:: with SMTP id f6mr14283852edt.349.1615044084185; 
 Sat, 06 Mar 2021 07:21:24 -0800 (PST)
MIME-Version: 1.0
References: <CA+YkXXxUdZFYTa1c-F=-FzoQQVtV3GUmE2Okec-zRAD3xS1qAQ@mail.gmail.com>
 <CAMnpzfop8ttqjMAKoS37zpQV6WiZfi1Bn+y_e-HaepTiD4Vm1Q@mail.gmail.com>
 <CAB0O3SVNyr_t23Y0LyT0mSaf6LONFRLYJ8qzO7rcdJFnrGccFw@mail.gmail.com>
 <CA+YkXXwkSCu=2UOEhzFBzGDHo1c=Ewqsnxp632ke3jdH1ff5WA@mail.gmail.com>
 <CA+YkXXwfS7eer5Za_ed9tCNdfOp4c3nV_X=mfXzoDxMm6BrizQ@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>
In-Reply-To: <CA+YkXXyBmOootb=Kt6CH3yquYVnAZd=fJQqiF_A3p_pkB8QC3g@mail.gmail.com>
From: Ricardo Filipe <ricardojdfilipe@gmail.com>
Date: Sat, 6 Mar 2021 15:21:12 +0000
Message-ID: <CALC81CMDQf4PqxRisQw58OL7QSFeMcQTvLMvmtOGJ_ya4-dhLg@mail.gmail.com>
To: Lonero Foundation <loneroassociation@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 06 Mar 2021 18:13:21 +0000
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2021 15:21:28 -0000

As said before, you are free to create the BIP in your own repository
and bring it to discussion on the mailing list. then you can do a PR

Lonero Foundation via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> escreveu no dia s=C3=A1bado,
6/03/2021 =C3=A0(s) 08:58:
>
> I know Ethereum had an outlandishly large percentage of nodes running on =
AWS, I heard the same thing is for Bitcoin but for mining. Had trouble find=
ing the article online so take it with a grain of salt. The point though is=
 that both servers and ASIC specific hardware would still be able to benefi=
t from the cryptography upgrade I am proposing, as this was in relation to =
the disinfranchisemet point.
>
> That said, I think the best way to move forward is to submit a BIP pull r=
equest for a draft via GitHub using BIP #2's draft format and any questions=
 people have can be answered in the reqeust's comments. That way people don=
't have to get emails everytime there is a reply, but replies still get see=
n as opposed to offline discussion. Since the instructions say to email bit=
coin-dev before doing a bip draft, I have done that. Since people want to s=
ee the draft beforehand and it isn't merged manually anyways, I think it is=
 the easiest way to handle this.
>
> I'm also okay w/ continuing the discussion on bitcoin-dev but rather form=
 a discussion on git instead given I don't want to accidentally impolitely =
bother people given this is a moderated list and we already established som=
e interest for at least a draft.
>
> Does that seem fine?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland <keagan.mcclelland@gmail.c=
om> wrote:
>>
>> > A large portion of BTC is already mined through AWS servers and non-as=
ic specific hardware anyways. A majority of them would benefit from a hybri=
d proof, and the fact that it is hybrid in that manner wouldn't disenfranch=
ise currently optimized mining entities as well.
>>
>> My instincts tell me that this is an outlandish claim. Do you have suppo=
rting evidence for this?
>>
>> Keagan
>>
>> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
>>>
>>> Actually I mentioned a proof of space and time hybrid which is much dif=
ferent than staking. Sorry to draw for the confusion as PoC is more commonl=
y used then PoST.
>>> There is a way to make PoC cryptographically compatible w/ Proof of Wor=
k as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>> It has rarely been done though given the technological complexity of be=
ing both CPU compatible and memory-hard compatible. There are lots of benef=
its outside of the realm of efficiency, and I already looked into numerous =
fault tolerant designs as well and what others in the cryptography communit=
y attempted to propose. The actual argument you have only against this is t=
he Proof of Memory fallacy, which is only partially true. Given how the cur=
rent hashing algorithm works, hard memory allocation wouldn't be of much be=
nefit given it is more optimized for CPU/ASIC specific mining. I'm working =
towards a hybrid mechanism that fixes that. BTW: The way Bitcoin currently =
stands in its cryptography still needs updating regardless. If someone figu=
res out NP hardness or the halting problem the traditional rule of millions=
 of years to break all of Bitcoin's cryptography now comes down to minutes.=
 Bitcoin is going to have to eventually radically upgrade their cryptograph=
y and hashing algo in the future regardless. I want to integrate some form =
of NP complexity in regards to the hybrid cryptography I'm aiming to provid=
e which includes a polynomial time algorithm in the cryptography. More than=
 likely the first version of my BTC hard fork will be coded in a way where =
integrating such complexity in the future only requires a soft fork or mino=
r upgrade to its chain.
>>>
>>> In regards to the argument, "As a separate issue, proposing a hard fork=
 in the hashing algorithm will invalidate the enormous amount of capital ex=
penditure by mining entities and disincentivize future capital expenditure =
into mining hardware that may compute these more "useful" proofs of work."
>>>
>>> A large portion of BTC is already mined through AWS servers and non-asi=
c specific hardware anyways. A majority of them would benefit from a hybrid=
 proof, and the fact that it is hybrid in that manner wouldn't disenfranchi=
se currently optimized mining entities as well.
>>>
>>> There are other reasons why a cryptography upgrade like this is benefic=
ial. Theoretically one can argue BItcoin isn't fully decentralized. It is f=
ew unsolved mathematical proofs away from being entirely broken. My goal ou=
tside of efficiency is to build cryptography in a way that prevents such an=
 event from happening in the future, if it was to ever happen. I have vario=
us research in regards to this area and work alot with distributed computin=
g. I believe if the BTC community likes such a proposal, I would single han=
dedly be able to build the cryptographic proof myself (though would like as=
 many open source contributors as I can get :)
>>>
>>> Anyways just something to consider. We are in the same space in regards=
 to what warrants a shitcoin or the whole argument against staking.
>>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-st=
op-telling-us-that-you-arent-pi3s3yjl
>>>
>>> Best regards,  Andrew
>>>
>>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <keagan.mcclelland@gma=
il.com> wrote:
>>>>
>>>> It is important to understand that it is critical for the work to be "=
useless" in order for the security model to be the same. If the work was us=
eful it provides an avenue for actors to have nothing at stake when submitt=
ing a proof of work, since the marginal cost of block construction will be =
lessened by the fact that the work was useful in a different context and th=
erefore would have been done anyway. This actually degrades the security of=
 the network in the process.
>>>>
>>>> As a separate issue, proposing a hard fork in the hashing algorithm wi=
ll invalidate the enormous amount of capital expenditure by mining entities=
 and disincentivize future capital expenditure into mining hardware that ma=
y compute these more "useful" proofs of work. This is because any change in=
 the POW algorithm will be considered unstable and subject to change in the=
 future. This puts the entire network at even more risk meaning that no ent=
ity is tying their own interests to that of the bitcoin network at large. I=
t also puts the developers in a position where they can be bribed by entiti=
es with a vested interest in deciding what the new "useful" proof of work s=
hould be.
>>>>
>>>> All of these things make the Bitcoin network worse off.
>>>>
>>>> Keagan
>>>>
>>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>> Also in regards to my other email, I forgot to iterate that my crypto=
graphy proposal helps behind the efficiency category but also tackles probl=
ems such as NP-Completeness or Halting which is something the BTC network c=
ould be vulnerable to in the future. For sake of simplicity, I do want to d=
o this BIP because it tackles lots of the issues in regards to this manner =
and can provide useful insight to the community. If things such as bigger b=
lock height have been proposed as hard forks, I feel at the very least an u=
pgrade regarding the hashing algorithm and cryptography does at least warra=
nt some discussion. Anyways I hope I can send you my BIP, just let me know =
on the preferred format?
>>>>>
>>>>> Best regards, Andrew
>>>>>
>>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <loneroassociation@gm=
ail.com> wrote:
>>>>>>
>>>>>> Hi, this isn't about the energy efficient argument in regards to ren=
ewables or mining devices but a better cryptography layer to get the most o=
ut of your hashing for validation. I do understand the arbitrariness of it,=
 but do want to still propose a document. Do I use the Media Wiki format on=
 GitHub and just attach it as my proposal?
>>>>>>
>>>>>> Best regards, Andrew
>>>>>>
>>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom@niftybox.net> =
wrote:
>>>>>>>
>>>>>>> Hi Ryan and Andrew,
>>>>>>>
>>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>   https://www.truthcoin.info/blog/pow-cheapest/
>>>>>>>>     "Nothing is Cheaper than Proof of Work"
>>>>>>>>     on | 04 Aug 2015
>>>>>>>>
>>>>>>>
>>>>>>> Just to belabor this a bit, the paper demonstrates that the mining =
market will tend to expend resources equivalent to miner reward.  It does n=
ot prove that mining work has to expend *energy* as a primary cost.
>>>>>>>
>>>>>>> Some might argue that energy expenditure has negative externalities=
 and that we should move to other resources.  I would argue that the negati=
ve externalities will go away soon because of the move to renewables, so th=
e point is likely moot.
>>>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev