path: root/46/01e82a6fc41ef3b3506d5737c7ffc802bde4ee

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1F5EAC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 15:03:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E9CA1606CA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 15:03:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id r_Dq9vS3YTvM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 15:02:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com
 [IPv6:2607:f8b0:4864:20::102e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id DA96960687
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 15:02:59 +0000 (UTC)
Received: by mail-pj1-x102e.google.com with SMTP id
 q6-20020a17090a4306b02900c42a012202so11181121pjg.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 07:02:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :content-transfer-encoding;
 bh=AZo04FpCNEoBG/mzu/XqrRv400iAHM2lWEVWZmiX608=;
 b=EB1hBIk2cYg+m1h0jWZmKFOWI+DytU4Tb2Ms7Jbjwnd5FNScqc/cZMi/th7K3Y8yrP
 84ujfOHf9qVpSdBAPaJa9HdAEhxpuvgbIu9crehtiPBjK9wp9aQmi2KoR1SU31eLpJTr
 LpQzku2vDqjQalYCaSCTE4ekcCTJhd4hWS4kLQIx1bCQb+ZJxXp0wWoMbgkJBVesJdEk
 KcsKy0FS98uxbDM+7MCfBeqa6RNRMNqUiLNSpeo5n0b3EMbolgKwshXEOXyyngAP5ze+
 u7tAYRTHg1pfmQFZvWUD+TvGjuaxNPDwj2x6guEKUqja+nKz+cJxuhDsyNVlKaZV1iVL
 ZkYA==
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=AZo04FpCNEoBG/mzu/XqrRv400iAHM2lWEVWZmiX608=;
 b=erHSx1IK2HoKUupkRwlN3Jl+YGYeR7Yt/yw8qaIF29xfQJ63Ck50sRc6hfIyhJhyli
 Ddrs/jHB9l6AiiRnntxu5HjDZcgWWPv6y7iNZy8JSMZJiMs1pIkDG5A7a4sL8OWH6w5L
 sLIOB+2MQzsW3pDpuZxcb3uSMqRtn7QxrsmkTiyQ7pSIlVg9BFXQuS7NChSPgEfg6MAh
 rW8vMDeayghtd7DPxYoM4Ia17XBSYaUuabcHDe4IZqTxNEBe/lys09MGfHGlxDA88rH1
 6n/pfiFE9FcZ6NJ7ZKWpT1OtEq2z9jGpH39joQ/9+LtEbsVXY/nPTAbY+lhARYoFwiSv
 PtBg==
X-Gm-Message-State: AOAM532+7ZEx1tYgEGGfFg4b3eARX1GlRN7tn30kZBm8hdBVaiSzARd0
 4P8DRlRDhxFY7+Cc1VojmPZp/gK4ugHThYv5kX6sXWg=
X-Google-Smtp-Source: ABdhPJyd1AdbDWIWKvcPrbc3/oGZ5E+60Z0dd7/Q0Z8dImXAwmtBtrZhTrZhJGzRk+LEAtPDiRxo8gRzexv3buU/ucg=
X-Received: by 2002:a17:90a:d341:: with SMTP id
 i1mr9525977pjx.74.1615561379113; 
 Fri, 12 Mar 2021 07:02:59 -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>
 <CALC81CMDQf4PqxRisQw58OL7QSFeMcQTvLMvmtOGJ_ya4-dhLg@mail.gmail.com>
 <CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com>
 <CA+YkXXw1AiMqCoPk_pUOdDMfkGF_T+aURGAjGK=MTa7jtAQchg@mail.gmail.com>
 <CA+YkXXy1Y407UDdEjRVjzBFOCmaUKDoZkvqtXkxkmXmMdNrwBQ@mail.gmail.com>
In-Reply-To: <CA+YkXXy1Y407UDdEjRVjzBFOCmaUKDoZkvqtXkxkmXmMdNrwBQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 12 Mar 2021 10:02:48 -0500
Message-ID: <CAJowKgKPga1Cr3B7vHgGWrLdTzt-DqgbcngWNdyYF7QoAcER8w@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: Fri, 12 Mar 2021 22:02:31 +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: Fri, 12 Mar 2021 15:03:02 -0000

secp236k1 isn't a hashing algo.   your BIP needs about 10 more pages
and some degree of technical merit.

i suggest you start here:

https://en.bitcoin.it/wiki/Proof_of_burn
https://bitcointalk.org/index.php?topic=3D225690.0

proof-of-burn is a nice alternative to proof-of-work.   i always
suspected that, if designed correctly, it could be a proven
equivalent.   you could spin up a fork of bitcoin that allows aged,
burned, coins instead of POW that would probably work just fine.

- erik

On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundation via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi, I have submitted the BIP Pull Request here: https://github.com/bitcoi=
n/bips/pull/1084
>
> Hoping to receive a BIP # for the draft prior to development/reference im=
plementation.
>
> Best regards, Andrew
>
> On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <loneroassociation@gmail.c=
om> wrote:
>>
>> Hi, here is the list to the BIP proposal on my own repo: https://github.=
com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki
>> Can I submit a pull request on the BIPs repo for this to go into draft m=
ode? Also, I think this provides at least some more insight on what I want =
to work on.
>>
>> Best regards, Andrew
>>
>> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <loneroassociation@gmail=
.com> wrote:
>>>
>>> [off-list]
>>>
>>> Okay. I will do so and post the link here for discussion before doing a=
 pull request on BIP's repo as the best way to handle it.
>>>
>>> Best regards, Andrew
>>>
>>> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe <ricardojdfilipe@gmail.com=
> wrote:
>>>>
>>>> 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 runnin=
g on AWS, I heard the same thing is for Bitcoin but for mining. Had trouble=
 finding the article online so take it with a grain of salt. The point thou=
gh is that both servers and ASIC specific hardware would still be able to b=
enefit from the cryptography upgrade I am proposing, as this was in relatio=
n to the disinfranchisemet point.
>>>> >
>>>> > That said, I think the best way to move forward is to submit a BIP p=
ull request for a draft via GitHub using BIP #2's draft format and any ques=
tions people have can be answered in the reqeust's comments. That way peopl=
e don't have to get emails everytime there is a reply, but replies still ge=
t seen as opposed to offline discussion. Since the instructions say to emai=
l bitcoin-dev before doing a bip draft, I have done that. Since people want=
 to see 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 impoli=
tely bother people given this is a moderated list and we already establishe=
d some 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@gm=
ail.com> wrote:
>>>> >>
>>>> >> > A large portion of BTC is already mined through AWS servers and n=
on-asic 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 disenf=
ranchise currently optimized mining entities as well.
>>>> >>
>>>> >> My instincts tell me that this is an outlandish claim. Do you have =
supporting evidence for this?
>>>> >>
>>>> >> Keagan
>>>> >>
>>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <b=
itcoin-dev@lists.linuxfoundation.org> wrote:
>>>> >>>
>>>> >>> Actually I mentioned a proof of space and time hybrid which is muc=
h different than staking. Sorry to draw for the confusion as PoC is more co=
mmonly used then PoST.
>>>> >>> There is a way to make PoC cryptographically compatible w/ Proof o=
f Work as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>>> >>> It has rarely been done though given the technological complexity =
of being both CPU compatible and memory-hard compatible. There are lots of =
benefits outside of the realm of efficiency, and I already looked into nume=
rous fault tolerant designs as well and what others in the cryptography com=
munity attempted to propose. The actual argument you have only against this=
 is the Proof of Memory fallacy, which is only partially true. Given how th=
e current hashing algorithm works, hard memory allocation wouldn't be of mu=
ch benefit given it is more optimized for CPU/ASIC specific mining. I'm wor=
king towards a hybrid mechanism that fixes that. BTW: The way Bitcoin curre=
ntly stands in its cryptography still needs updating regardless. If someone=
 figures out NP hardness or the halting problem the traditional rule of mil=
lions of years to break all of Bitcoin's cryptography now comes down to min=
utes. Bitcoin is going to have to eventually radically upgrade their crypto=
graphy 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 p=
rovide 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 w=
here integrating such complexity in the future only requires a soft fork or=
 minor 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 capit=
al expenditure by mining entities and disincentivize future capital expendi=
ture into mining hardware that may compute these more "useful" proofs of wo=
rk."
>>>> >>>
>>>> >>> A large portion of BTC is already mined through AWS servers and no=
n-asic specific hardware anyways. A majority of them would benefit from a h=
ybrid proof, and the fact that it is hybrid in that manner wouldn't disenfr=
anchise currently optimized mining entities as well.
>>>> >>>
>>>> >>> There are other reasons why a cryptography upgrade like this is be=
neficial. Theoretically one can argue BItcoin isn't fully decentralized. It=
 is few unsolved mathematical proofs away from being entirely broken. My go=
al outside of efficiency is to build cryptography in a way that prevents su=
ch an event from happening in the future, if it was to ever happen. I have =
various research in regards to this area and work alot with distributed com=
puting. I believe if the BTC community likes such a proposal, I would singl=
e handedly be able to build the cryptographic proof myself (though would li=
ke as many open source contributors as I can get :)
>>>> >>>
>>>> >>> Anyways just something to consider. We are in the same space in re=
gards to what warrants a shitcoin or the whole argument against staking.
>>>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurren=
cy-stop-telling-us-that-you-arent-pi3s3yjl
>>>> >>>
>>>> >>> Best regards,  Andrew
>>>> >>>
>>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <keagan.mcclellan=
d@gmail.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 w=
as useful it provides an avenue for actors to have nothing at stake when su=
bmitting a proof of work, since the marginal cost of block construction wil=
l be lessened by the fact that the work was useful in a different context a=
nd therefore would have been done anyway. This actually degrades the securi=
ty of the network in the process.
>>>> >>>>
>>>> >>>> As a separate issue, proposing a hard fork in the hashing algorit=
hm will invalidate the enormous amount of capital expenditure by mining ent=
ities and disincentivize future capital expenditure into mining hardware th=
at may compute these more "useful" proofs of work. This is because any chan=
ge in the POW algorithm will be considered unstable and subject to change i=
n the future. This puts the entire network at even more risk meaning that n=
o entity is tying their own interests to that of the bitcoin network at lar=
ge. It also puts the developers in a position where they can be bribed by e=
ntities with a vested interest in deciding what the new "useful" proof of w=
ork should 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 =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> >>>>>
>>>> >>>>> Also in regards to my other email, I forgot to iterate that my c=
ryptography proposal helps behind the efficiency category but also tackles =
problems such as NP-Completeness or Halting which is something the BTC netw=
ork could be vulnerable to in the future. For sake of simplicity, I do want=
 to do this BIP because it tackles lots of the issues in regards to this ma=
nner and can provide useful insight to the community. If things such as big=
ger block height have been proposed as hard forks, I feel at the very least=
 an upgrade regarding the hashing algorithm and cryptography does at least =
warrant 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 <loneroassociati=
on@gmail.com> wrote:
>>>> >>>>>>
>>>> >>>>>> Hi, this isn't about the energy efficient argument in regards t=
o renewables or mining devices but a better cryptography layer to get the m=
ost out of your hashing for validation. I do understand the arbitrariness o=
f it, but do want to still propose a document. Do I use the Media Wiki form=
at 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 <bit=
coin-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 mi=
ning market will tend to expend resources equivalent to miner reward.  It d=
oes not prove that mining work has to expend *energy* as a primary cost.
>>>> >>>>>>>
>>>> >>>>>>> Some might argue that energy expenditure has negative external=
ities and that we should move to other resources.  I would argue that the n=
egative externalities will go away soon because of the move to renewables, =
so the 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev