rich1.0npub1raukftn2mkv6hkvhgm04tmtn0sknuc5pfzedsflz58jxved654xqe8mlyuhttps://nostr.ae/npub1raukftn2mkv6hkvhgm04tmtn0sknuc5pfzedsflz58jxved654xqe8mlyunjumphttps://nostr.ae📅 Original date posted:2021-03-12 📝 Original message:Also, I already stated I was referring to signature validation cryptography in that aspect: https://wizardforcel.gitbooks.io/practical-cryptography-for-developers-book/content/digital-signatures/ecdsa-sign-verify-examples.html My BIP has a primary purpose in regards to what I want to develop proofs for and the different cryptographic elements I want to develop proofs for. That said to those who disagree with the premise, I do prefer constructive feedback over insults or making fun of one another. After all this is an improvement proposal with a specific purpose aiming to develop a specific thing, not a guy who is just wanting to copy and paste a repository and call it a day. Best regards, Andrew On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation < loneroassociation at gmail.com> wrote: > Hi, I also want to emphasize that my main point isn't just to create a BTC > hardfork or become another Bitcoin Cash, Gold, or SV. The main point in > regards to this BIP actually expands POW rather than replaces or creates an > alternative. Many of the problems faced in regards to security in the > future as well as sustainability is something I believe lots of the changes > I am proposing can fix. In regards to technological implementation, once > this is assigned draft status I am more than willing to create preprints > explaining the cryptography, hashing algorithm improvements, and consensus > that I am working on. This is a highly technologically complex idea that I > am willing to "call my bluff on" and expand upon. As for it being a draft, > I think this is a good starting point at least for draft status prior to > working on technological implementation. > > Best regards, Andrew > > On Fri, Mar 12, 2021 at 5:37 PM email at yancy.lol <email at yancy.lol> wrote: > >> I think Andrew himself is an algo. The crypto training set must not be >> very good. >> >> Cheers, >> -Yancy >> >> On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev < >> bitcoin-dev at lists.linuxfoundation.org> wrote: >> >> >> Hi, I awkwardly phrased that part, I was referring to key validation in >> relation to that section as well as the hashing related to those keys. I >> might rephrase it. >> >> In regards to technical merit, the main purpose of the BIP is to get a >> sense of the idea. Once I get assigned a BIP draft #, I am willing to >> follow it up with many preprints or publications to go in the references >> implementation section and start dev work before upgrading to final status. >> >> This will take about 400 hours of my time, but is something I am >> personally looking into developing as a hard fork. >> >> Keep in mind this is a draft, so after it is assigned a number to >> references I do at the very least hope to describe various parts of the >> cryptographic proofs and algorithmic structure I am hoping for. >> >> Best regards, Andrew >> >> On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty <erik at q32.com> wrote: >> >>> 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 at 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 < >>> loneroassociation at 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 < >>> 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 >>> > >>> > _______________________________________________ >>> > 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/20210312/3ded64b9/attachment-0001.html>