Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

From: Lonero Foundation <loneroassociation@gmail•com>
To: "email@yancy•lol" <email@yancy•lol>
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: Fri, 12 Mar 2021 18:31:51 -0500	[thread overview]
Message-ID: <CA+YkXXw5uh4yfvqDiBBEXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com> (raw)
In-Reply-To: <CA+YkXXzNAWrPPJfDtB-DXaSf9yoojkuEXeCXzkB2_cMtyHfFXA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 16066 bytes --]

Also, I already stated I was referring to signature validation cryptography
in that aspect:
https://wizardforcel.gitbooks.io/practical-cryptography-for-developers-book/content/digital-signatures/ecdsa-sign-verify-examples.html
My BIP has a primary purpose in regards to what I want to develop proofs
for and the different cryptographic elements I want to develop proofs for.
That said to those who disagree with the premise, I do prefer constructive
feedback over insults or making fun of one another. After all this is an
improvement proposal with a specific purpose aiming to develop a specific
thing, not a guy who is just wanting to copy and paste a repository and
call it a day.

Best regards, Andrew

On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation <
loneroassociation@gmail•com> wrote:

> Hi, I also want to emphasize that my main point isn't just to create a BTC
> hardfork or become another Bitcoin Cash, Gold, or SV. The main point in
> regards to this BIP actually expands POW rather than replaces or creates an
> alternative. Many of the problems faced in regards to security in the
> future as well as sustainability is something I believe lots of the changes
> I am proposing can fix. In regards to technological implementation, once
> this is assigned draft status I am more than willing to create preprints
> explaining the cryptography, hashing algorithm improvements, and consensus
> that I am working on. This is a highly technologically complex idea that I
> am willing to "call my bluff on" and expand upon. As for it being a draft,
> I think this is a good starting point at least for draft status prior to
> working on technological implementation.
>
> Best regards, Andrew
>
> On Fri, Mar 12, 2021 at 5:37 PM email@yancy•lol <email@yancy•lol> wrote:
>
>> I think Andrew himself is an algo.  The crypto training set must not be
>> very good.
>>
>> Cheers,
>> -Yancy
>>
>> On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>
>> Hi, I awkwardly phrased that part, I was referring to key validation in
>> relation to that section as well as the hashing related to those keys. I
>> might rephrase it.
>>
>> In regards to technical merit, the main purpose of the BIP is to get a
>> sense of the idea. Once I get assigned a BIP draft #, I am willing to
>> follow it up with many preprints or publications to go in the references
>> implementation section and start dev work before upgrading to final status.
>>
>> This will take about 400 hours of my time, but is something I am
>> personally looking into developing as a hard fork.
>>
>> Keep in mind this is a draft, so after it is assigned a number to
>> references I do at the very least hope to describe various parts of the
>> cryptographic proofs and algorithmic structure I am hoping for.
>>
>> Best regards, Andrew
>>
>> On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty <erik@q32•com> wrote:
>>
>>> 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=225690.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/bitcoin/bips/pull/1084
>>> >
>>> > Hoping to receive a BIP # for the draft prior to development/reference
>>> implementation.
>>> >
>>> > Best regards, Andrew
>>> >
>>> > On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <
>>> loneroassociation@gmail•com> 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 mode? 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ábado,
>>> >>>> 6/03/2021 à(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 finding 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 benefit 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 request 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 seen as opposed to offline discussion. Since the instructions say
>>> to email 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
>>> impolitely bother people given this is a moderated list and we already
>>> established 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@gmail•com> wrote:
>>> >>>> >>
>>> >>>> >> > A large portion of BTC is already mined through AWS servers
>>> and non-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
>>> disenfranchise 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
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> >>>> >>>
>>> >>>> >>> Actually I mentioned a proof of space and time hybrid which is
>>> much different than staking. Sorry to draw for the confusion as PoC is more
>>> commonly used then PoST.
>>> >>>> >>> There is a way to make PoC cryptographically compatible w/
>>> Proof of 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 numerous fault tolerant designs as well and what others in the
>>> cryptography community attempted to propose. The actual argument you have
>>> only against this is the Proof of Memory fallacy, which is only partially
>>> true. Given how the current hashing algorithm works, hard memory allocation
>>> wouldn't be of much benefit 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 figures 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 cryptography 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 provide 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 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
>>> capital expenditure 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-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
>>> disenfranchise currently optimized mining entities as well.
>>> >>>> >>>
>>> >>>> >>> There are other reasons why a cryptography upgrade like this is
>>> beneficial. Theoretically one can argue BItcoin isn't fully decentralized.
>>> It is few unsolved mathematical proofs away from being entirely broken. My
>>> goal outside 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 various research in regards to this area and work alot with
>>> distributed computing. I believe if the BTC community likes such a
>>> proposal, I would single handedly 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-stop-telling-us-that-you-arent-pi3s3yjl
>>> >>>> >>>
>>> >>>> >>> Best regards,  Andrew
>>> >>>> >>>
>>> >>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <
>>> keagan.mcclelland@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
>>> was useful it provides an avenue for actors to have nothing at stake when
>>> submitting 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 therefore 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 will invalidate the enormous amount of capital expenditure by
>>> mining entities and disincentivize future capital expenditure into mining
>>> hardware that may 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 entity is tying their own interests to that of the
>>> bitcoin network at large. It also puts the developers in a position where
>>> they can be bribed by entities with a vested interest in deciding what the
>>> new "useful" proof of work 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 cryptography proposal helps behind the efficiency category but also
>>> tackles problems such as NP-Completeness or Halting which is something the
>>> BTC network 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 manner and can provide useful insight to the community. If things such
>>> as bigger 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 <
>>> loneroassociation@gmail•com> wrote:
>>> >>>> >>>>>>
>>> >>>> >>>>>> Hi, this isn't about the energy efficient argument in
>>> regards to renewables or mining devices but a better cryptography layer to
>>> get the most out 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 not 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 negative 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
>>
>>
>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 21721 bytes --]