đź“… Original date posted:2023-02-04
🗒️ Summary of this message: Discussion on changing the OP_RETURN size in Bitcoin is ongoing, but ultimately requires code changes and community consensus for implementation.
đź“ť Original message:On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte <aymeric at peersm.com> wrote:
> What is the official bitcoin channel to request the OP_RETURN size change?
> (press often mentions that ethereum is good to manage changes and bitcoin a
> complete zero.
>
Here is the simplified version:
Most of these changes start with discussions like these, but then are moved
concretely to a PR to bitcoin-core with the code changes (in this case
there is no fork so pretty easy) and an introductory comment pointing to
discussions elsewhere.
The conversation will also move to the PR itself. Part of the challenge now
is getting review of your PRs - you’ll need to evangelize some and/or have
social capital in the bitcoin community to get sufficient ACKs to your PR
(and some NACKs which you will calmly addres), and someone will likely
point something out you missed, so you revise the PR.
At some point hopefully there looks like all reasonable objections have
been addressed.
If there is enough interest and few objections there will be discussions by
the community & maintainers to merge it. It is this last part that isn’t
very transparent, especially for even a good proposal. The maintainers,
based on their sense of the community’s interest and consensus, must choose
when to say it is ready, and then decide when and to which release they
wish to merge it.
They often start by requesting you to revise your changes to be off by
default, and be turned on as an option for a specific release. Often PR
contributors know this is coming and include it.
Even once it is released, this type of change can only happen after
sufficient miners and nodes update to the release and turn it on. If
sufficient do, then the maintainers evaluate when to have the feature on by
default.
These articles offers more perspective:
-
https://unchained.com/blog/contributing-bitcoin-core-patience/
-
https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core
-
https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365
— Christopher Allen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/55d4fec8/attachment.html>;
Christopher Allen [ARCHIVE] /
npub19g…ct5d0
2023-06-07 23:18:59
in reply to nevent1q…pm3x
Author Public Key
npub19g47w5ewcqlpd7n07wpkp5cvcu2gjwrse0vl47l0avwl9hu933xsqct5d0Published at
2023-06-07 23:18:59Event JSON
{
"id": "f7f2f94ed7a0b26a27bf3f5917daac3c329c4e8b6b0ff36ae3b3bc8d7dd898ba",
"pubkey": "2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d",
"created_at": 1686179939,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"5dd6cb39d5b6a01a7e2b11b987b56e11f600ed8361c0aae38f929e2a7d081424",
"",
"reply"
],
[
"p",
"a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df"
]
],
"content": "📅 Original date posted:2023-02-04\n🗒️ Summary of this message: Discussion on changing the OP_RETURN size in Bitcoin is ongoing, but ultimately requires code changes and community consensus for implementation.\n📝 Original message:On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte \u003caymeric at peersm.com\u003e wrote:\n\n\u003e What is the official bitcoin channel to request the OP_RETURN size change?\n\u003e (press often mentions that ethereum is good to manage changes and bitcoin a\n\u003e complete zero.\n\u003e\nHere is the simplified version:\n\nMost of these changes start with discussions like these, but then are moved\nconcretely to a PR to bitcoin-core with the code changes (in this case\nthere is no fork so pretty easy) and an introductory comment pointing to\ndiscussions elsewhere.\n\nThe conversation will also move to the PR itself. Part of the challenge now\nis getting review of your PRs - you’ll need to evangelize some and/or have\nsocial capital in the bitcoin community to get sufficient ACKs to your PR\n(and some NACKs which you will calmly addres), and someone will likely\npoint something out you missed, so you revise the PR.\n\nAt some point hopefully there looks like all reasonable objections have\nbeen addressed.\n\nIf there is enough interest and few objections there will be discussions by\nthe community \u0026 maintainers to merge it. It is this last part that isn’t\nvery transparent, especially for even a good proposal. The maintainers,\nbased on their sense of the community’s interest and consensus, must choose\nwhen to say it is ready, and then decide when and to which release they\nwish to merge it.\n\nThey often start by requesting you to revise your changes to be off by\ndefault, and be turned on as an option for a specific release. Often PR\ncontributors know this is coming and include it.\n\nEven once it is released, this type of change can only happen after\nsufficient miners and nodes update to the release and turn it on. If\nsufficient do, then the maintainers evaluate when to have the feature on by\ndefault.\n\nThese articles offers more perspective:\n\n -\n\n https://unchained.com/blog/contributing-bitcoin-core-patience/\n -\n\n\n https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core\n -\n\n https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365\n\n— Christopher Allen\n\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/55d4fec8/attachment.html\u003e",
"sig": "5604c98020e3c55a1a6cc7389272a19db3198bb5b801fbc26077a967b12825d79f58f8c9b418a8fe718120069667b9eff4a452213c122dd602eb22182ef875da"
}