From: Christopher Allen <ChristopherA@lifewithalacrity•com>
To: Aymeric Vitte <aymeric@peersm•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Date: Sat, 4 Feb 2023 10:54:41 -0800 [thread overview]
Message-ID: <CACrqygB_FbsRGWYPSUEFTnP15y94Hmo4JtAuv6bH1D3YtbAw9Q@mail.gmail.com> (raw)
In-Reply-To: <3d00aacb-585d-f875-784d-34352860d725@peersm.com>
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte <aymeric@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
>
[-- Attachment #2: Type: text/html, Size: 4524 bytes --]
next prev parent reply other threads:[~2023-02-04 18:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 0:46 Christopher Allen
2023-02-01 2:07 ` Peter Todd
2023-02-01 2:22 ` Christopher Allen
2023-02-01 8:36 ` Kostas Karasavvas
2023-02-01 12:51 ` Peter Todd
2023-02-01 14:02 ` Andrew Poelstra
2023-02-02 11:22 ` Peter Todd
2023-02-02 11:45 ` Aymeric Vitte
2023-02-02 11:49 ` Peter Todd
2023-02-02 12:24 ` Aymeric Vitte
2023-02-01 12:59 ` Aymeric Vitte
2023-02-02 13:25 ` Rijndael
2023-02-03 11:15 ` Aymeric Vitte
2023-02-03 18:47 ` Christopher Allen
2023-02-04 14:11 ` Kostas Karasavvas
2023-02-04 17:01 ` Aymeric Vitte
2023-02-04 18:54 ` Christopher Allen [this message]
2023-02-04 20:55 ` Aymeric Vitte
2023-02-04 22:18 ` Christopher Allen
2023-02-04 23:09 ` Aymeric Vitte
2023-02-05 0:04 ` Peter Todd
2023-02-05 11:40 ` Aymeric Vitte
2023-02-05 12:06 ` Peter Todd
2023-02-05 12:47 ` Aymeric Vitte
2023-02-05 0:11 ` Russell O'Connor
2023-02-05 2:01 ` Peter Todd
2023-02-05 18:12 ` Russell O'Connor
2023-02-12 16:23 ` Aymeric Vitte
2023-02-16 18:23 ` Aymeric Vitte
2023-02-16 19:59 ` Claus Ehrenberg
2023-02-17 10:56 ` Aymeric Vitte
2023-02-05 18:06 ` Andrew Poelstra
2023-02-17 12:49 ` Anthony Towns
2023-02-18 18:38 ` Aymeric Vitte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACrqygB_FbsRGWYPSUEFTnP15y94Hmo4JtAuv6bH1D3YtbAw9Q@mail.gmail.com \
--to=christophera@lifewithalacrity$(echo .)com \
--cc=aymeric@peersm$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox