From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 91EAFC002B for ; Sat, 4 Feb 2023 20:55:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 668AE41CB8 for ; Sat, 4 Feb 2023 20:55:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 668AE41CB8 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft4dvivLnEuI for ; Sat, 4 Feb 2023 20:55:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 90CEB41CB4 Received: from smtpout2.mo529.mail-out.ovh.net (smtpout2.mo529.mail-out.ovh.net [79.137.123.220]) by smtp4.osuosl.org (Postfix) with ESMTPS id 90CEB41CB4 for ; Sat, 4 Feb 2023 20:55:56 +0000 (UTC) Received: from mxplan6.mail.ovh.net (unknown [10.109.156.206]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 23EB920ACF; Sat, 4 Feb 2023 20:55:54 +0000 (UTC) Received: from peersm.com (37.59.142.103) by DAG6EX2.mxp6.local (172.16.2.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Sat, 4 Feb 2023 21:55:47 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-103G0053e88a075-391f-44e2-b0f4-9026ae562407, 83B9442A37C74570B8CB15ECCD3A86C2760700E6) smtp.auth=aymeric@peersm.com X-OVh-ClientIp: 92.184.100.83 To: Christopher Allen References: <57f780b1-f262-9394-036c-70084320e9cf@peersm.com> <3d00aacb-585d-f875-784d-34352860d725@peersm.com> From: Aymeric Vitte Message-ID: Date: Sat, 4 Feb 2023 21:55:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B76D54563ACD6B327BA734D1" X-Originating-IP: [37.59.142.103] X-ClientProxiedBy: DAG9EX2.mxp6.local (172.16.2.82) To DAG6EX2.mxp6.local (172.16.2.52) X-Ovh-Tracer-GUID: 73eac680-7b40-4e30-b9da-442716ab266b X-Ovh-Tracer-Id: 14291047519313617885 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -51 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudegvddgudegudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefuvfhfvefhkffffgggjggtihesrgdtreertdefjeenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepgfetteevieetvefhfeevuddtgeffvdejhfdtueeitdegleevffefkeeuieejhedunecuffhomhgrihhnpehunhgthhgrihhnvggurdgtohhmpdhgihhthhhusgdrihhopdhmvgguihhumhdrtghomhdpphgvvghrshhmrdgtohhmpdhlihhnkhgvughinhdrtghomhdpghhithhhuhgsrdgtohhmnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutdefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpeeorgihmhgvrhhitgesphgvvghrshhmrdgtohhmqedpnhgspghrtghpthhtohepuddprhgtphhtthhopehkkhgrrhgrshgrvhhvrghssehgmhgrihhlrdgtohhmpdgsihhttghoihhnqdguvghvsehlihhsthhsrdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdevhhhrihhsthhophhhvghrteeslh hifhgvfihithhhrghlrggtrhhithihrdgtohhmpdfovfetjfhoshhtpehmohehvdelpdhmohguvgepshhmthhpohhuth X-Mailman-Approved-At: Sat, 04 Feb 2023 20:59:51 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2023 20:55:59 -0000 --------------B76D54563ACD6B327BA734D1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 =C3=A0 19:54, Christopher Allen a =C3=A9crit : > On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte > 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.=20 > > The conversation will also move to the PR itself. Part of the > challenge now is getting review of your PRs - you=E2=80=99ll 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.=20 > > 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=E2=80=99t very transparent, especially for even a go= od > proposal. The maintainers, based on their sense of the community=E2=80=99= 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:=20 > > * > > 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 > > =E2=80=94 Christopher Allen=20 > > --=20 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/Ay= ms/029125db2583e1cf9c3209769eb2cdd7 A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b= eed1bfeba7 Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac= tions 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.p= eersm.com Peersm : http://www.peersm.com --------------B76D54563ACD6B327BA734D1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

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 <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: 

— 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
--------------B76D54563ACD6B327BA734D1--