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
