rich1.0npub1raukftn2mkv6hkvhgm04tmtn0sknuc5pfzedsflz58jxved654xqe8mlyuhttps://nostr.ae/npub1raukftn2mkv6hkvhgm04tmtn0sknuc5pfzedsflz58jxved654xqe8mlyunjumphttps://nostr.ae📅 Original date posted:2021-03-08 📝 Original message: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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at niftybox.net> >> wrote: >> >>>>>>> >> >>>>>>> Hi Ryan and Andrew, >> >>>>>>> >> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev < >> bitcoin-dev at 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 at lists.linuxfoundation.org >> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >>> >> >>> _______________________________________________ >> >>> bitcoin-dev mailing list >> >>> bitcoin-dev at lists.linuxfoundation.org >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210308/848af606/attachment-0001.html>