@mtrycz
edited
more from that month
Request for comments: An evidence-based process for Bitcoin Cash
中文 https://read.cash/@mtrycz/bch-db6fd0af This document is a DRAFT or Request for Comments. Check out also a more detailed writeup, and the accompanying decentralized cooperation proposal and writeup. https://read.cash/@mtrycz/how-i-envision-an-evidence-based-process-for-bitcoin-cash-5acc9074 https://read.cash/@mtrycz/request-for-comments-decentralized-cooperation-on-bitcoin-cash-c9c8c75e https://read.cash/@mtrycz/how-i-envision-decentralized-cooperation-on-bitcoin-cash-9876b9e9 Scope The scope of this process is explicitly consensus changes for Bitcoin Cash. Non-consensus protocol changes are possible candidates, but not necessarily. Explicitly not in scope is non-technical discussion. Process A person or group willing to spearhead a consensus change will nominate themselves as the leaders of that initiative. They will assure open communication of the following points. These are not to be interpreted as a step-by-step process, rather as a checklist - for a proposal to be valid, all of them these need to be completed, not necessarily in-order and possibly with iterations. (Objective) Define what the change it aims to achieve or what problem it needs to solve (Solution) Provide a solution that's a clear improvement for the objective (Specification) Provide a clear spec, which might initially be a draft (Implementation) Provide a reference implementation for testing (Burden of proof) Provide a clear case in favor of the change and reproducible evidence (possibly a test suite) (Feedback) Gather feedback to improve all of the above (Evaluate) Allow reasonable time for people to evaluate and propose alternative solutions
5 comments
I recommend you use bitcoincashresearch.org for this specific purpose. My feedback: 1. There must be a social contract firewall between this process and the protocol itself. Wiring it up in a mechanical way to the protocol will create a much lower barrier to gaming the whole process. It also reduces the need for social contract commitment to *actual* collaboration as opposed to leaning on / gaming whatever mechanism was created. 2. Just like the original BIP process, I think it misses an explicit call for RFC and explicit consideration of costs (as well as benefits). Burden of proof is a much larger issue than just testing and technical feasibility.
thanks bro for sharing this article.
I will like you to write more on this.
same as the BIP process, it is missing the last and critical part - https://read.cash/@tula_s/briefly-on-governance-ff06770f
I support this process.