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