Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

From: Aymeric Vitte <[email-masked]>
Date: Sat, 4 Feb 2023 21:55:47 +0100

Thanks Christopher, then I understand the process:

- I must issue a PR where I switch 80 to another number, even if I am
not a C/C++ expert it looks easy

- I  must stay calm and answer all outstanding concerns about this
trivial change

- Since I am not as clever as the bitcoin devs I must be ready to revise
my PR at any time

- This could lead for the change to be from 80B to 82.xB where x comes
from a non understandable crypto formula

- I must evangelize the change worldwide

- Once accepted, I must collude (pay) with the nodes/miners so they
update at a subtile block height decided by the community

And then I must pray that the PR does not survive myself

Looks like a pretty straight forward process

I am on this list since quite some time, so, seriously, this change is
needed, or, as I said before, deviant behaviours will happen, because
the "witness trick" or others do not work at all, and are clearly
similar to ethereum messy stuff

Le 04/02/2023 à 19:54, Christopher Allen a écrit :
> On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte <[email-masked]
> <mailto:[email-masked]>> 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 
>
>

-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com