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 <loneroassociat...@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 >> <loneroassociat...@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 <ricardojdfil...@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.mcclell...@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.mcclell...@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 >>>> >>>>> <loneroassociat...@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.devran...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
