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

From: Lonero Foundation <loneroassociation@gmail•com>
To: 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: Sat, 13 Mar 2021 10:02:05 -0500	[thread overview]
Message-ID: <CA+YkXXzPt8vf=bfpW+NBqH_G7sTiyFcGSZa+j31Fx_O5ir93Cw@mail.gmail.com> (raw)
In-Reply-To: <1802-604c7400-4d1-7b635e80@91248813>

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

Hi, I know the differences between the cryptographic hashing algorithm and
key validation. I know hashing is for SHA, but was referring to asymmetric
cryptography in regards to the key validation. I should have used a
different term though instead of, "In regards to cryptographic hashing,", I
should have stated in regards to cryptographic key validation. There are a
few other dubious clarifications or minor edits I should make in order to
not draw confusion. I will do a repo update today. Honest mistake, but
enough with the sarcasm.

Best regards, Andrew

On Sat, Mar 13, 2021, 3:13 AM email@yancy•lol <email@yancy•lol> wrote:

> My email was not intended as an insult.  Your proposal seemed a bit like
> gibberish and made some obvious mistakes as pointed out before (such as
> conflating secp256k1 with sha256), and so I was genuinely curious if you
> were a bot spamming the list.
>
>
> Maybe a more interesting topic is, can GPT3 be used to generate a BIP?
> How long before our AI overlord produces improvements to Bitcoin?  At what
> point will the AI have more than 51% of commit frequency?  Will we have
> lost the war to our new centralized overlord?
>
> Cheers,
> -Yancy
>
>
> On Saturday, March 13, 2021 00:31 CET, Lonero Foundation <
> loneroassociation@gmail•com> wrote:
>
>
> 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: 26777 bytes --]