{"type":"rich","version":"1.0","author_name":"npub1raukftn2mkv6hkvhgm04tmtn0sknuc5pfzedsflz58jxved654xqe8mlyu","author_url":"https://nostr.ae/npub1raukftn2mkv6hkvhgm04tmtn0sknuc5pfzedsflz58jxved654xqe8mlyu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-03-12\n📝 Original message:Also, I already stated I was referring to signature validation cryptography\nin that aspect:\nhttps://wizardforcel.gitbooks.io/practical-cryptography-for-developers-book/content/digital-signatures/ecdsa-sign-verify-examples.html\nMy BIP has a primary purpose in regards to what I want to develop proofs\nfor and the different cryptographic elements I want to develop proofs for.\nThat said to those who disagree with the premise, I do prefer constructive\nfeedback over insults or making fun of one another. After all this is an\nimprovement proposal with a specific purpose aiming to develop a specific\nthing, not a guy who is just wanting to copy and paste a repository and\ncall it a day.\n\nBest regards, Andrew\n\nOn Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation \u003c\nloneroassociation at gmail.com\u003e wrote:\n\n\u003e Hi, I also want to emphasize that my main point isn't just to create a BTC\n\u003e hardfork or become another Bitcoin Cash, Gold, or SV. The main point in\n\u003e regards to this BIP actually expands POW rather than replaces or creates an\n\u003e alternative. Many of the problems faced in regards to security in the\n\u003e future as well as sustainability is something I believe lots of the changes\n\u003e I am proposing can fix. In regards to technological implementation, once\n\u003e this is assigned draft status I am more than willing to create preprints\n\u003e explaining the cryptography, hashing algorithm improvements, and consensus\n\u003e that I am working on. This is a highly technologically complex idea that I\n\u003e am willing to \"call my bluff on\" and expand upon. As for it being a draft,\n\u003e I think this is a good starting point at least for draft status prior to\n\u003e working on technological implementation.\n\u003e\n\u003e Best regards, Andrew\n\u003e\n\u003e On Fri, Mar 12, 2021 at 5:37 PM email at yancy.lol \u003cemail at yancy.lol\u003e wrote:\n\u003e\n\u003e\u003e I think Andrew himself is an algo.  The crypto training set must not be\n\u003e\u003e very good.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e -Yancy\n\u003e\u003e\n\u003e\u003e On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Hi, I awkwardly phrased that part, I was referring to key validation in\n\u003e\u003e relation to that section as well as the hashing related to those keys. I\n\u003e\u003e might rephrase it.\n\u003e\u003e\n\u003e\u003e In regards to technical merit, the main purpose of the BIP is to get a\n\u003e\u003e sense of the idea. Once I get assigned a BIP draft #, I am willing to\n\u003e\u003e follow it up with many preprints or publications to go in the references\n\u003e\u003e implementation section and start dev work before upgrading to final status.\n\u003e\u003e\n\u003e\u003e This will take about 400 hours of my time, but is something I am\n\u003e\u003e personally looking into developing as a hard fork.\n\u003e\u003e\n\u003e\u003e Keep in mind this is a draft, so after it is assigned a number to\n\u003e\u003e references I do at the very least hope to describe various parts of the\n\u003e\u003e cryptographic proofs and algorithmic structure I am hoping for.\n\u003e\u003e\n\u003e\u003e Best regards, Andrew\n\u003e\u003e\n\u003e\u003e On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty \u003cerik at q32.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e secp236k1 isn't a hashing algo.   your BIP needs about 10 more pages\n\u003e\u003e\u003e and some degree of technical merit.\n\u003e\u003e\u003e\n\u003e\u003e\u003e i suggest you start here:\n\u003e\u003e\u003e\n\u003e\u003e\u003e https://en.bitcoin.it/wiki/Proof_of_burn\n\u003e\u003e\u003e https://bitcointalk.org/index.php?topic=225690.0\n\u003e\u003e\u003e\n\u003e\u003e\u003e proof-of-burn is a nice alternative to proof-of-work.   i always\n\u003e\u003e\u003e suspected that, if designed correctly, it could be a proven\n\u003e\u003e\u003e equivalent.   you could spin up a fork of bitcoin that allows aged,\n\u003e\u003e\u003e burned, coins instead of POW that would probably work just fine.\n\u003e\u003e\u003e\n\u003e\u003e\u003e - erik\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundation via bitcoin-dev\n\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e Hi, I have submitted the BIP Pull Request here:\n\u003e\u003e\u003e https://github.com/bitcoin/bips/pull/1084\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e Hoping to receive a BIP # for the draft prior to development/reference\n\u003e\u003e\u003e implementation.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e Best regards, Andrew\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation \u003c\n\u003e\u003e\u003e loneroassociation at gmail.com\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e Hi, here is the list to the BIP proposal on my own repo:\n\u003e\u003e\u003e https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki\n\u003e\u003e\u003e \u003e\u003e Can I submit a pull request on the BIPs repo for this to go into\n\u003e\u003e\u003e draft mode? Also, I think this provides at least some more insight on what\n\u003e\u003e\u003e I want to work on.\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e Best regards, Andrew\n\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation \u003c\n\u003e\u003e\u003e loneroassociation at gmail.com\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e [off-list]\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e Okay. I will do so and post the link here for discussion before\n\u003e\u003e\u003e doing a pull request on BIP's repo as the best way to handle it.\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e Best regards, Andrew\n\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe \u003c\n\u003e\u003e\u003e ricardojdfilipe at gmail.com\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e As said before, you are free to create the BIP in your own\n\u003e\u003e\u003e repository\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e and bring it to discussion on the mailing list. then you can do a PR\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e Lonero Foundation via bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e escreveu no dia sábado,\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e 6/03/2021 à(s) 08:58:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e I know Ethereum had an outlandishly large percentage of nodes\n\u003e\u003e\u003e running on AWS, I heard the same thing is for Bitcoin but for mining. Had\n\u003e\u003e\u003e trouble finding the article online so take it with a grain of salt. The\n\u003e\u003e\u003e point though is that both servers and ASIC specific hardware would still be\n\u003e\u003e\u003e able to benefit from the cryptography upgrade I am proposing, as this was\n\u003e\u003e\u003e in relation to the disinfranchisemet point.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e That said, I think the best way to move forward is to submit a\n\u003e\u003e\u003e BIP pull request for a draft via GitHub using BIP #2's draft format and any\n\u003e\u003e\u003e questions people have can be answered in the reqeust's comments. That way\n\u003e\u003e\u003e people don't have to get emails everytime there is a reply, but replies\n\u003e\u003e\u003e still get seen as opposed to offline discussion. Since the instructions say\n\u003e\u003e\u003e to email bitcoin-dev before doing a bip draft, I have done that. Since\n\u003e\u003e\u003e people want to see the draft beforehand and it isn't merged manually\n\u003e\u003e\u003e anyways, I think it is the easiest way to handle this.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e I'm also okay w/ continuing the discussion on bitcoin-dev but\n\u003e\u003e\u003e rather form a discussion on git instead given I don't want to accidentally\n\u003e\u003e\u003e impolitely bother people given this is a moderated list and we already\n\u003e\u003e\u003e established some interest for at least a draft.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e Does that seem fine?\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e Best regards, Andrew\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland \u003c\n\u003e\u003e\u003e keagan.mcclelland at gmail.com\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e \u003e A large portion of BTC is already mined through AWS servers\n\u003e\u003e\u003e and non-asic specific hardware anyways. A majority of them would benefit\n\u003e\u003e\u003e from a hybrid proof, and the fact that it is hybrid in that manner wouldn't\n\u003e\u003e\u003e disenfranchise currently optimized mining entities as well.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e My instincts tell me that this is an outlandish claim. Do you\n\u003e\u003e\u003e have supporting evidence for this?\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e Keagan\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev\n\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e Actually I mentioned a proof of space and time hybrid which is\n\u003e\u003e\u003e much different than staking. Sorry to draw for the confusion as PoC is more\n\u003e\u003e\u003e commonly used then PoST.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e There is a way to make PoC cryptographically compatible w/\n\u003e\u003e\u003e Proof of Work as it normally stands:\n\u003e\u003e\u003e https://en.wikipedia.org/wiki/Proof_of_space\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e It has rarely been done though given the technological\n\u003e\u003e\u003e complexity of being both CPU compatible and memory-hard compatible. There\n\u003e\u003e\u003e are lots of benefits outside of the realm of efficiency, and I already\n\u003e\u003e\u003e looked into numerous fault tolerant designs as well and what others in the\n\u003e\u003e\u003e cryptography community attempted to propose. The actual argument you have\n\u003e\u003e\u003e only against this is the Proof of Memory fallacy, which is only partially\n\u003e\u003e\u003e true. Given how the current hashing algorithm works, hard memory allocation\n\u003e\u003e\u003e wouldn't be of much benefit given it is more optimized for CPU/ASIC\n\u003e\u003e\u003e specific mining. I'm working towards a hybrid mechanism that fixes that.\n\u003e\u003e\u003e BTW: The way Bitcoin currently stands in its cryptography still needs\n\u003e\u003e\u003e updating regardless. If someone figures out NP hardness or the halting\n\u003e\u003e\u003e problem the traditional rule of millions of years to break all of Bitcoin's\n\u003e\u003e\u003e cryptography now comes down to minutes. Bitcoin is going to have to\n\u003e\u003e\u003e eventually radically upgrade their cryptography and hashing algo in the\n\u003e\u003e\u003e future regardless. I want to integrate some form of NP complexity in\n\u003e\u003e\u003e regards to the hybrid cryptography I'm aiming to provide which includes a\n\u003e\u003e\u003e polynomial time algorithm in the cryptography. More than likely the first\n\u003e\u003e\u003e version of my BTC hard fork will be coded in a way where integrating such\n\u003e\u003e\u003e complexity in the future only requires a soft fork or minor upgrade to its\n\u003e\u003e\u003e chain.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e In regards to the argument, \"As a separate issue, proposing a\n\u003e\u003e\u003e hard fork in the hashing algorithm will invalidate the enormous amount of\n\u003e\u003e\u003e capital expenditure by mining entities and disincentivize future capital\n\u003e\u003e\u003e expenditure into mining hardware that may compute these more \"useful\"\n\u003e\u003e\u003e proofs of work.\"\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e A large portion of BTC is already mined through AWS servers and\n\u003e\u003e\u003e non-asic specific hardware anyways. A majority of them would benefit from a\n\u003e\u003e\u003e hybrid proof, and the fact that it is hybrid in that manner wouldn't\n\u003e\u003e\u003e disenfranchise currently optimized mining entities as well.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e There are other reasons why a cryptography upgrade like this is\n\u003e\u003e\u003e beneficial. Theoretically one can argue BItcoin isn't fully decentralized.\n\u003e\u003e\u003e It is few unsolved mathematical proofs away from being entirely broken. My\n\u003e\u003e\u003e goal outside of efficiency is to build cryptography in a way that prevents\n\u003e\u003e\u003e such an event from happening in the future, if it was to ever happen. I\n\u003e\u003e\u003e have various research in regards to this area and work alot with\n\u003e\u003e\u003e distributed computing. I believe if the BTC community likes such a\n\u003e\u003e\u003e proposal, I would single handedly be able to build the cryptographic proof\n\u003e\u003e\u003e myself (though would like as many open source contributors as I can get :)\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e Anyways just something to consider. We are in the same space in\n\u003e\u003e\u003e regards to what warrants a shitcoin or the whole argument against staking.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e Best regards,  Andrew\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland \u003c\n\u003e\u003e\u003e keagan.mcclelland at gmail.com\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e It is important to understand that it is critical for the work\n\u003e\u003e\u003e to be \"useless\" in order for the security model to be the same. If the work\n\u003e\u003e\u003e was useful it provides an avenue for actors to have nothing at stake when\n\u003e\u003e\u003e submitting a proof of work, since the marginal cost of block construction\n\u003e\u003e\u003e will be lessened by the fact that the work was useful in a different\n\u003e\u003e\u003e context and therefore would have been done anyway. This actually degrades\n\u003e\u003e\u003e the security of the network in the process.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e As a separate issue, proposing a hard fork in the hashing\n\u003e\u003e\u003e algorithm will invalidate the enormous amount of capital expenditure by\n\u003e\u003e\u003e mining entities and disincentivize future capital expenditure into mining\n\u003e\u003e\u003e hardware that may compute these more \"useful\" proofs of work. This is\n\u003e\u003e\u003e because any change in the POW algorithm will be considered unstable and\n\u003e\u003e\u003e subject to change in the future. This puts the entire network at even more\n\u003e\u003e\u003e risk meaning that no entity is tying their own interests to that of the\n\u003e\u003e\u003e bitcoin network at large. It also puts the developers in a position where\n\u003e\u003e\u003e they can be bribed by entities with a vested interest in deciding what the\n\u003e\u003e\u003e new \"useful\" proof of work should be.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e All of these things make the Bitcoin network worse off.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e Keagan\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via\n\u003e\u003e\u003e bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e Also in regards to my other email, I forgot to iterate that\n\u003e\u003e\u003e my cryptography proposal helps behind the efficiency category but also\n\u003e\u003e\u003e tackles problems such as NP-Completeness or Halting which is something the\n\u003e\u003e\u003e BTC network could be vulnerable to in the future. For sake of simplicity, I\n\u003e\u003e\u003e do want to do this BIP because it tackles lots of the issues in regards to\n\u003e\u003e\u003e this manner and can provide useful insight to the community. If things such\n\u003e\u003e\u003e as bigger block height have been proposed as hard forks, I feel at the very\n\u003e\u003e\u003e least an upgrade regarding the hashing algorithm and cryptography does at\n\u003e\u003e\u003e least warrant some discussion. Anyways I hope I can send you my BIP, just\n\u003e\u003e\u003e let me know on the preferred format?\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e Best regards, Andrew\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation \u003c\n\u003e\u003e\u003e loneroassociation at gmail.com\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e Hi, this isn't about the energy efficient argument in\n\u003e\u003e\u003e regards to renewables or mining devices but a better cryptography layer to\n\u003e\u003e\u003e get the most out of your hashing for validation. I do understand the\n\u003e\u003e\u003e arbitrariness of it, but do want to still propose a document. Do I use the\n\u003e\u003e\u003e Media Wiki format on GitHub and just attach it as my proposal?\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e Best regards, Andrew\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e On Fri, Mar 5, 2021, 10:07 AM Devrandom \u003c\n\u003e\u003e\u003e c1.devrandom at niftybox.net\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e Hi Ryan and Andrew,\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev \u003c\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e   https://www.truthcoin.info/blog/pow-cheapest/\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e     \"Nothing is Cheaper than Proof of Work\"\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e     on | 04 Aug 2015\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e Just to belabor this a bit, the paper demonstrates that the\n\u003e\u003e\u003e mining market will tend to expend resources equivalent to miner reward.  It\n\u003e\u003e\u003e does not prove that mining work has to expend *energy* as a primary cost.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e Some might argue that energy expenditure has negative\n\u003e\u003e\u003e externalities and that we should move to other resources.  I would argue\n\u003e\u003e\u003e that the negative externalities will go away soon because of the move to\n\u003e\u003e\u003e renewables, so the point is likely moot.\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e _______________________________________________\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e\u003e\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e _______________________________________________\n\u003e\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210312/3ded64b9/attachment-0001.html\u003e"}