Hi, I know the differences between the cryptographic hashing algorithm and key validation. I know hashing is for SHA, but was referring to asymmetric cryptography in regards to the key validation. I should have used a different term though instead of, "In regards to cryptographic hashing,", I should have stated in regards to cryptographic key validation. There are a few other dubious clarifications or minor edits I should make in order to not draw confusion. I will do a repo update today. Honest mistake, but enough with the sarcasm.
Best regards, Andrew On Sat, Mar 13, 2021, 3:13 AM em...@yancy.lol <em...@yancy.lol> wrote: > My email was not intended as an insult. Your proposal seemed a bit like > gibberish and made some obvious mistakes as pointed out before (such as > conflating secp256k1 with sha256), and so I was genuinely curious if you > were a bot spamming the list. > > > Maybe a more interesting topic is, can GPT3 be used to generate a BIP? > How long before our AI overlord produces improvements to Bitcoin? At what > point will the AI have more than 51% of commit frequency? Will we have > lost the war to our new centralized overlord? > > Cheers, > -Yancy > > > On Saturday, March 13, 2021 00:31 CET, Lonero Foundation < > loneroassociat...@gmail.com> wrote: > > > 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 < > loneroassociat...@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 em...@yancy.lol <em...@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@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 <e...@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@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
