📅 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/
Ryan Grant [ARCHIVE] /
npub19a…6mwcl
2023-06-07 18:30:06
in reply to nevent1q…jagp
Author Public Key
npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwclPublished at
2023-06-07 18:30:06Event JSON
{
"id": "beb63d7ea734cab90675e33a2c25a79921c3b1b93bdf3928f65ab3333a6ee526",
"pubkey": "2f55bf03677afdb15d004a39383afba6220aa6c059cafa7b8827b87934d3c254",
"created_at": 1686162606,
"kind": 1,
"tags": [
[
"e",
"7210b5b8acdbe2e6121c009480ab95c228caf8b7d28bfb78b379aab7e9d173b6",
"",
"root"
],
[
"e",
"caf08bdb87abb5608aed45ebe6c0c4cbb70eeb95b0d638ec8d1ad5019b5b5aa2",
"",
"reply"
],
[
"p",
"1f7964ae6add99abd99746df55ed737c2d3e628148b2d827e2a1e46665baa54c"
]
],
"content": "📅 Original date posted:2021-03-05\n📝 Original message:On Fri, Mar 5, 2021 at 9:39 AM Lonero Foundation via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Hello, I want to start a new BIP proposal aiming to tackle some of\n\u003e the energy efficiency issues w/ Bitcoin mining. Excuse my ignorance\n\u003e given this is my first time making a BIP proposal, but is there a\n\u003e specific format I need to follow?\n\nHi Andrew,\n\nI would like to discourage you from writing a BIP on this topic, as\nany such proposal is guaranteed to be rejected based on prior\ndiscussions in the community.\n\nPlease update your priors with the following:\n\n https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki\n BIP: 2\n Title: BIP process, revised\n\n https://www.truthcoin.info/blog/pow-cheapest/\n \"Nothing is Cheaper than Proof of Work\"\n on | 04 Aug 2015\n\nYour topic brings up an interesting edge case, which is whether the\nBIP repository is an open forum for all possible arguments that are\ntechnically well constructed. Obviously: no; but by what\nnon-arbitrary process do we decide?\n\nI propose that the BIP Editor's role should include preserving signal\nin the table of contents generated from our proposal repository, by\nunilaterally rejecting - without any fuhrer comment - technically well\nconstructed proposals which are guaranteed to be rejected based on\nprior discussions in the community, as spam. I think this is already\nhow it works, but we haven't actually written down this part of the\nnorms.\n\nSince censorship is always a concern, it would be appropriate to\nmaintain a moderation log of spam BIPs, so that observers could judge\nwhether the BIP Editor is misusing the BIP assignment process to\ncensor proposals with some merit. Since one of the requirements for\nsubmitting a BIP is to notify bitcoin-dev, the log is already\nmaintained. Since bitcoin-dev is moderated, the moderators take on a\nlow level of responsibility for gauging spam proposals (and they are\npretty relaxed about it, since it is better to err on the side of\ninclusion for new developers, except for obvious patent bombing).\nSince the bitcoin-dev moderation log is public and anyone can\nsubscribe to it, protective transparency is again achieved.\n\n https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/",
"sig": "2e17c2b38dbf0bb97c12c485eb6a1c2b885a3f66f8d234e08a79440e7c00dc37a90321411d47cb70114bbc7623b244b0b9319abfe48726b81e9da90f5383e22a"
}