đź“… Original date posted:2023-02-04
🗒️ Summary of this message: To request a change in the OP_RETURN size for Bitcoin, one must create a PR and address concerns, revise as needed, and gain community consensus.
đź“ť Original message: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 at peersm.com
> <mailto: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
>
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/889a52b1/attachment-0001.html>;
Aymeric Vitte [ARCHIVE] /
npub15f…g5grz
2023-06-07 23:18:59
in reply to nevent1q…rnj8
Author Public Key
npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzPublished at
2023-06-07 23:18:59Event JSON
{
"id": "5da0039dcc0854e6ba41fc3c5968349b44680bed942f1bab5df6959ce2fd1d9c",
"pubkey": "a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df",
"created_at": 1686179939,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"f7f2f94ed7a0b26a27bf3f5917daac3c329c4e8b6b0ff36ae3b3bc8d7dd898ba",
"",
"reply"
],
[
"p",
"2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d"
]
],
"content": "📅 Original date posted:2023-02-04\n🗒️ Summary of this message: To request a change in the OP_RETURN size for Bitcoin, one must create a PR and address concerns, revise as needed, and gain community consensus.\n📝 Original message:Thanks Christopher, then I understand the process:\n\n- I must issue a PR where I switch 80 to another number, even if I am\nnot a C/C++ expert it looks easy\n\n- I must stay calm and answer all outstanding concerns about this\ntrivial change\n\n- Since I am not as clever as the bitcoin devs I must be ready to revise\nmy PR at any time\n\n- This could lead for the change to be from 80B to 82.xB where x comes\nfrom a non understandable crypto formula\n\n- I must evangelize the change worldwide\n\n- Once accepted, I must collude (pay) with the nodes/miners so they\nupdate at a subtile block height decided by the community\n\nAnd then I must pray that the PR does not survive myself\n\nLooks like a pretty straight forward process\n\nI am on this list since quite some time, so, seriously, this change is\nneeded, or, as I said before, deviant behaviours will happen, because\nthe \"witness trick\" or others do not work at all, and are clearly\nsimilar to ethereum messy stuff\n\n\nLe 04/02/2023 à 19:54, Christopher Allen a écrit :\n\u003e On Sat, Feb 4, 2023 at 9:01 AM Aymeric Vitte \u003caymeric at peersm.com\n\u003e \u003cmailto:aymeric at peersm.com\u003e\u003e wrote:\n\u003e\n\u003e What is the official bitcoin channel to request the OP_RETURN size\n\u003e change? (press often mentions that ethereum is good to manage\n\u003e changes and bitcoin a complete zero.\n\u003e\n\u003e Here is the simplified version:\n\u003e\n\u003e Most of these changes start with discussions like these, but then are\n\u003e moved concretely to a PR to bitcoin-core with the code changes (in\n\u003e this case there is no fork so pretty easy) and an introductory comment\n\u003e pointing to discussions elsewhere. \n\u003e\n\u003e The conversation will also move to the PR itself. Part of the\n\u003e challenge now is getting review of your PRs - you’ll need to\n\u003e evangelize some and/or have social capital in the bitcoin community to\n\u003e get sufficient ACKs to your PR (and some NACKs which you will calmly\n\u003e addres), and someone will likely point something out you missed, so\n\u003e you revise the PR. \n\u003e\n\u003e At some point hopefully there looks like all reasonable objections\n\u003e have been addressed.\n\u003e\n\u003e If there is enough interest and few objections there will be\n\u003e discussions by the community \u0026 maintainers to merge it. It is this\n\u003e last part that isn’t very transparent, especially for even a good\n\u003e proposal. The maintainers, based on their sense of the community’s\n\u003e interest and consensus, must choose when to say it is ready, and then\n\u003e decide when and to which release they wish to merge it.\n\u003e\n\u003e They often start by requesting you to revise your changes to be off by\n\u003e default, and be turned on as an option for a specific release. Often\n\u003e PR contributors know this is coming and include it.\n\u003e\n\u003e Even once it is released, this type of change can only happen after\n\u003e sufficient miners and nodes update to the release and turn it on. If\n\u003e sufficient do, then the maintainers evaluate when to have the feature\n\u003e on by default.\n\u003e\n\u003e These articles offers more perspective: \n\u003e\n\u003e *\n\u003e\n\u003e https://unchained.com/blog/contributing-bitcoin-core-patience/\n\u003e\n\u003e *\n\u003e\n\u003e https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core\n\u003e\n\u003e *\n\u003e\n\u003e https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365\n\u003e\n\u003e — Christopher Allen \n\u003e\n\u003e\n\n-- \nSophia-Antipolis, France\nCV: https://www.peersm.com/CVAV.pdf\nLinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26\nGitHub : https://www.github.com/Ayms\nA Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7\nA bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7\nMove your coins by yourself (browser version): https://peersm.com/wallet\nBitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions\ntorrent-live: https://github.com/Ayms/torrent-live\nnode-Tor : https://www.github.com/Ayms/node-Tor\nAnti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com\nPeersm : http://www.peersm.com\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/889a52b1/attachment-0001.html\u003e",
"sig": "2a293f38f7e364a245b01d2167e93d6fad380fddaac85ab8e557cb91300655a067543d1c5607bf002415ee1069766427701dbb902bfdf6c0126c3f57a1bf13c4"
}