rich1.0npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwclhttps://nostr.ae/npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwclnjumphttps://nostr.ae📅 Original date posted:2021-03-05 📝 Original message:On Fri, Mar 5, 2021 at 9:39 AM Lonero Foundation via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > Hello, I want to start a new BIP proposal aiming to tackle some of > the energy efficiency issues w/ Bitcoin mining. Excuse my ignorance > given this is my first time making a BIP proposal, but is there a > specific format I need to follow? Hi Andrew, I would like to discourage you from writing a BIP on this topic, as any such proposal is guaranteed to be rejected based on prior discussions in the community. Please update your priors with the following: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki BIP: 2 Title: BIP process, revised https://www.truthcoin.info/blog/pow-cheapest/ "Nothing is Cheaper than Proof of Work" on | 04 Aug 2015 Your topic brings up an interesting edge case, which is whether the BIP repository is an open forum for all possible arguments that are technically well constructed. Obviously: no; but by what non-arbitrary process do we decide? I propose that the BIP Editor's role should include preserving signal in the table of contents generated from our proposal repository, by unilaterally rejecting - without any fuhrer comment - technically well constructed proposals which are guaranteed to be rejected based on prior discussions in the community, as spam. I think this is already how it works, but we haven't actually written down this part of the norms. Since censorship is always a concern, it would be appropriate to maintain a moderation log of spam BIPs, so that observers could judge whether the BIP Editor is misusing the BIP assignment process to censor proposals with some merit. Since one of the requirements for submitting a BIP is to notify bitcoin-dev, the log is already maintained. Since bitcoin-dev is moderated, the moderators take on a low level of responsibility for gauging spam proposals (and they are pretty relaxed about it, since it is better to err on the side of inclusion for new developers, except for obvious patent bombing). Since the bitcoin-dev moderation log is public and anyone can subscribe to it, protective transparency is again achieved. https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/