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 <ayme...@peersm.com > <mailto:ayme...@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 > > -- 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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
