{"type":"rich","version":"1.0","title":"Keagan McClelland [ARCHIVE] wrote","author_name":"Keagan McClelland [ARCHIVE] (npub1f2…ms289)","author_url":"https://yabu.me/npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-05-10\n📝 Original message:To reiterate some of the points here. My problem with proof of stake is\ntwofold.\n\n1. It requires permission of coin holders to enter into the system. This is\nnot true of proof of work. You may even attempt (though not successfully) a\nproof of work with pencil and paper and submit the block from a regular\nlaptop if you so choose. Whether this level of permissionlessness is\nnecessary is up to individual risk tolerance etc. but it is definitely the\ndefault preference of Bitcoin.\n\n2. Proof of stake must have a trusted means of timestamping to regulate\noverproduction of blocks. This introduction of trust is generally\nconsidered to be a nonstarter in Bitcoin. Proof of Work regulates this by\nmaking blocks fundamentally difficult to produce in the first place.\n\nLike Jeremy, I’m always interested to learn about new attempts in consensus\nalgorithms, but the bar to clear is very high and proof of stake to date\nhas not proposed much less demonstrated a set of properties that is\nconsistent with Bitcoins objectives.\n\nKeagan\n\nOn Mon, May 10, 2021 at 8:43 AM Erik Aronesty via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e personally, not speaking for anyone else, i think that proof-of-burn\n\u003e has a much higher likelihood of being a) good enough security and b)\n\u003e solving the nothing-at-stake problem\n\u003e\n\u003e  the only issue i see with a quality PoB implementation is a robust\n\u003e solution to the block-timing problem.\n\u003e\n\u003e https://grisha.org/blog/2018/01/23/explaining-proof-of-work/\n\u003e\n\u003e i do think there *could* be other low-energy solutions to verifiable\n\u003e timing, just haven't seen one\n\u003e\n\u003e\n\u003e On Fri, May 7, 2021 at 6:50 PM SatoshiSingh via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e Hello list,\n\u003e \u003e\n\u003e \u003e I am a lurker here and like many of you I worry about the energy usage\n\u003e of bitcoin mining. I understand a lot mining happens with renewable\n\u003e resources but the impact is still high.\n\u003e \u003e\n\u003e \u003e I want to get your opinion on implementing proof of stake for bitcoin\n\u003e mining in future. For now, proof of stake is still untested and not battle\n\u003e tested like proof of work. Though someday it will be.\n\u003e \u003e\n\u003e \u003e In the following years we'll be seeing proof of stake being implemented.\n\u003e Smaller networks can test PoS which is a luxury bitcoin can't afford.\n\u003e Here's how I see this the possibilities:\n\u003e \u003e\n\u003e \u003e 1 - Proof of stake isn't a good enough security mechanism\n\u003e \u003e 2 - Proof of state is a good security mechanism and works as intended\n\u003e \u003e\n\u003e \u003e IF PoS turns out to be good after battle testing, would you consider\n\u003e implementing it for Bitcoin? I understand this would invoke a lot of\n\u003e controversies and a hard fork that no one likes. But its important enough\n\u003e to consider a hard fork. What are your opinions provided PoS does work?\n\u003e \u003e\n\u003e \u003e Love from India.\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210510/a45a8038/attachment.html\u003e"}