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

[Lonero Foundation <loneroassociation@gmail.com>]

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

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
>>
>

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