📅 Original date posted:2015-06-18
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Regarding this proposal from Mike Hearn to remove consensus process
from the BIP, which I think is unsound philosophy. I will address
this briefly below.
On 06/18/2015 09:05 AM, Mike Hearn wrote:
> So then: make a proposal for a better process, post it to this
> list.
>
>
> Alright. Here is a first cut of my proposal. It can be inserted
> into an amended BIP 1 after "What belongs in a successful BIP?".
> Let me know what you think.
>
>
>
> The following section applies to BIPs that affect the block chain
> consensus rules or the peer to peer protocol and thus require
> changes to Bitcoin Core.
>
> Once a draft BIP has been submitted to bitcoin-development for
> consideration, the Bitcoin Core maintainer will deliver a
> preliminary yes/no verdict within three weeks.
For many things, that will simply be too fast. It is better to allow
the primary maintainer to collaborate with other people who normally
work on the code and determine what the schedule will be based on
life, volume of work, and so on.
> This verdict may be informed by the debate that has taken part in
> the previous three weeks. If more time is required, the maintainer
> is required to request an extension from the BIP author, who may
> then elect to force an immediate decision (risking a no), or
> choosing to allow more time.
Again, this three week thing doesn't work. But assume for a moment
that there is a certain amount of time that is such and so and it is
set by the maintainer. The notion that the maintainer would be
"required" to request an extension from the BIP author is sheer
lunacy. There is no need to codify the actions of the project
maintainer such that he/she would be needing to be subject to the
whims of whatever BIP author. In like manner, a BIP author should not
have to be subject to forever delay of a BIP due to inaction of a
maintainer, but should have an answer regarding whether it can be
assigned a number, published as draft and so forth after a reasonable
time. To me, a "reasonable time" is something that should be
discussed amongst the maintainer, those who work regularly on code,
and the BIP author.
>
> The verdict will meet the following criteria:
>
> * It will address the latest version of the BIP at the time the
> verdict is rendered.
>
> * In case of a rejection, it will spell out and describe the
> technical rationale for this decision. Opinions held by other
> people are not considered technical rationales: if the maintainer
> agrees with a technical point made during discussion, he must own
> that opinion for himself. Therefore no BIP will be rejected on
> grounds of controversy, disagreement, lack of consensus or
> otherwise.
No, this is ridiculous, because the notion that "no BIP will be
rejected on grounds of controversy, disagreement, lack of consensus,
or otherwise," is clearly an attempt to do away with consensus models
of business, and it is also not a very logical statement because
controversy and disagreement are a natural part of... coming to what
eventually is an agreement.
>
> * In case of rejection, the maintainer will provide a clear,
> specific list of actionable steps the BIP author can take next. For
> example, a list of what changes would address the technical
> objections raised.
This above section I agree with.
In case the maintainer believes no change could ever make
> the BIP acceptable, the list must consist of instructions for how
> to create a patch set and, in the case of changes to the consensus
> rules, how to initiate a hard fork.
This above section I do not agree with because of the obvious bias in
favor of the hard fork. Everything here seems to be aligned to push
for hard fork, hard fork, hard fork. It's like the author can't tear
his mind off it.
>
> A BIP, even once rejected, may live on in the BIPS repository,
> though its entry in the index may be sorted below others. The BIP
> author may update the BIP with a summary of any resulting
> discussion. As such a summary may be inherently contentious in case
> of a dispute, the authors wording of that summary is final and may
> not be subject to meta-debate.
>
>
This doesn't seem right at all.
>
>
> ----------------------------------------------------------------------
- --------
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVg0sHAAoJEGxwq/inSG8CuFcH/0tzRWWyy3wmDegNx463xoaq
EhG/dNqoIvavMlyJrKfKWPK6Mndgo9BtxkYbvOlO40Y51SW4SaisWGzHRg4HyIbJ
0Orp+C0jXhvnrJ7hRwKhrdZQUIRAI19NLVthSb9W6mHnXWJC8ilhlK9Ei9ILRjGl
tM5pZ28SkyJ/b+CnltnYW8t6AvE4zlggC4QsCuUwA2cFoFWjQeESpqjy4kJNv464
yKlsrqoIzs2vNnoLIx1B0aLX9mNTQUwB1yMXtu8IVcAQe/G1LEEnNO56LGf8O0yJ
KcBTSpDAtCxvfkwtr3DS6LtCzXcej974NW068n/92zZIKzsdcZk/o3O5ZxEO7Wg=
=YwvU
-----END PGP SIGNATURE-----
odinn [ARCHIVE] /
npub1xv…5j2ga
2023-06-07 15:38:43
in reply to nevent1q…w6gg
Author Public Key
npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2gaPublished at
2023-06-07 15:38:43Event JSON
{
"id": "f1b17351ebfcdf83393272af8bc623756706686b61eb49a234cec98b1ad932c1",
"pubkey": "33228a8ed797b24e872fc0257c1515fc9bca74c0b230dcbb7d3d2bd38fd97ed7",
"created_at": 1686152323,
"kind": 1,
"tags": [
[
"e",
"23c1bb2f25b9e7356b48aa2a86751c4f26fb3977b440917a1cb3512c200b0b2f",
"",
"root"
],
[
"e",
"972ea6888cc8efb26d2281da91332ed6834baa1b2f33b2b165a621fb14d9974c",
"",
"reply"
],
[
"p",
"5c0b7fca51fd4830b4d9f840de063faebeeabd3bb5dd118de9cdf50a6feaaf98"
]
],
"content": "📅 Original date posted:2015-06-18\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nRegarding this proposal from Mike Hearn to remove consensus process\nfrom the BIP, which I think is unsound philosophy. I will address\nthis briefly below.\n\nOn 06/18/2015 09:05 AM, Mike Hearn wrote:\n\u003e So then: make a proposal for a better process, post it to this\n\u003e list.\n\u003e \n\u003e \n\u003e Alright. Here is a first cut of my proposal. It can be inserted\n\u003e into an amended BIP 1 after \"What belongs in a successful BIP?\".\n\u003e Let me know what you think.\n\u003e \n\u003e \n\u003e \n\u003e The following section applies to BIPs that affect the block chain \n\u003e consensus rules or the peer to peer protocol and thus require\n\u003e changes to Bitcoin Core.\n\u003e \n\u003e Once a draft BIP has been submitted to bitcoin-development for \n\u003e consideration, the Bitcoin Core maintainer will deliver a\n\u003e preliminary yes/no verdict within three weeks.\n\nFor many things, that will simply be too fast. It is better to allow\nthe primary maintainer to collaborate with other people who normally\nwork on the code and determine what the schedule will be based on\nlife, volume of work, and so on.\n\n\n\u003e This verdict may be informed by the debate that has taken part in\n\u003e the previous three weeks. If more time is required, the maintainer\n\u003e is required to request an extension from the BIP author, who may\n\u003e then elect to force an immediate decision (risking a no), or\n\u003e choosing to allow more time.\n\nAgain, this three week thing doesn't work. But assume for a moment\nthat there is a certain amount of time that is such and so and it is\nset by the maintainer. The notion that the maintainer would be\n\"required\" to request an extension from the BIP author is sheer\nlunacy. There is no need to codify the actions of the project\nmaintainer such that he/she would be needing to be subject to the\nwhims of whatever BIP author. In like manner, a BIP author should not\nhave to be subject to forever delay of a BIP due to inaction of a\nmaintainer, but should have an answer regarding whether it can be\nassigned a number, published as draft and so forth after a reasonable\ntime. To me, a \"reasonable time\" is something that should be\ndiscussed amongst the maintainer, those who work regularly on code,\nand the BIP author.\n\n\u003e \n\u003e The verdict will meet the following criteria:\n\u003e \n\u003e * It will address the latest version of the BIP at the time the \n\u003e verdict is rendered.\n\u003e \n\u003e * In case of a rejection, it will spell out and describe the\n\u003e technical rationale for this decision. Opinions held by other\n\u003e people are not considered technical rationales: if the maintainer\n\u003e agrees with a technical point made during discussion, he must own\n\u003e that opinion for himself. Therefore no BIP will be rejected on\n\u003e grounds of controversy, disagreement, lack of consensus or\n\u003e otherwise.\n\nNo, this is ridiculous, because the notion that \"no BIP will be\nrejected on grounds of controversy, disagreement, lack of consensus,\nor otherwise,\" is clearly an attempt to do away with consensus models\nof business, and it is also not a very logical statement because\ncontroversy and disagreement are a natural part of... coming to what\neventually is an agreement.\n\n\u003e \n\u003e * In case of rejection, the maintainer will provide a clear,\n\u003e specific list of actionable steps the BIP author can take next. For\n\u003e example, a list of what changes would address the technical\n\u003e objections raised.\n\nThis above section I agree with.\n\n\n In case the maintainer believes no change could ever make\n\u003e the BIP acceptable, the list must consist of instructions for how\n\u003e to create a patch set and, in the case of changes to the consensus \n\u003e rules, how to initiate a hard fork.\n\nThis above section I do not agree with because of the obvious bias in\nfavor of the hard fork. Everything here seems to be aligned to push\nfor hard fork, hard fork, hard fork. It's like the author can't tear\nhis mind off it.\n\n\u003e \n\u003e A BIP, even once rejected, may live on in the BIPS repository,\n\u003e though its entry in the index may be sorted below others. The BIP\n\u003e author may update the BIP with a summary of any resulting\n\u003e discussion. As such a summary may be inherently contentious in case\n\u003e of a dispute, the authors wording of that summary is final and may\n\u003e not be subject to meta-debate.\n\u003e \n\u003e \nThis doesn't seem right at all.\n\n\u003e \n\u003e \n\u003e ----------------------------------------------------------------------\n- --------\n\u003e\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ Bitcoin-development\n\u003e mailing list Bitcoin-development at lists.sourceforge.net \n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVg0sHAAoJEGxwq/inSG8CuFcH/0tzRWWyy3wmDegNx463xoaq\nEhG/dNqoIvavMlyJrKfKWPK6Mndgo9BtxkYbvOlO40Y51SW4SaisWGzHRg4HyIbJ\n0Orp+C0jXhvnrJ7hRwKhrdZQUIRAI19NLVthSb9W6mHnXWJC8ilhlK9Ei9ILRjGl\ntM5pZ28SkyJ/b+CnltnYW8t6AvE4zlggC4QsCuUwA2cFoFWjQeESpqjy4kJNv464\nyKlsrqoIzs2vNnoLIx1B0aLX9mNTQUwB1yMXtu8IVcAQe/G1LEEnNO56LGf8O0yJ\nKcBTSpDAtCxvfkwtr3DS6LtCzXcej974NW068n/92zZIKzsdcZk/o3O5ZxEO7Wg=\n=YwvU\n-----END PGP SIGNATURE-----",
"sig": "426588a707c00e7662c020b610d3ea3e4d9ae1b9579588b539fcfca189b672aa7e17f640cd5ee0346139a88c5a23d39e28fa39659f1e9f19f1b87423bd95a319"
}