Hi Murch, I had a full review on the updatses to BIP 2, and overall it sounds reasonable. I have only 3 observations, to be addressed or not. About the "What is the scope of the BIPs repository ?" "The BIPs repository is focused on information and technologies that aim to support and expand the utility of the bitcoin currency. Related topics that are of interest to the Bitcoin community may be acceptable. Proposals that are in direct contradiction to this mission, e.g. by undermining fungibility, facilitating unrelated protocols, using Bitcoin for data storage, or hobbling mining decentralization, may be considered out-of-scope." There is no need to strictly define bitcoin mission in any fashion...Even if you go back to Satoshi's writings far more than the currency aspect of bitcoin was designed for with the inclusion of a wide bitcoin script programming languages, rather than just signature verification [0]. Even historically, if you go back to all the BIPs which have been discussed during the block size wars (bip 103, bip 104, bip 105, etc) some of those BIPs in themselves are ways to articulate the technical debate about scalability, and the impact or not on mining decentralization. Same if you take fungibility, is BIP 431 good for fungibility ? No words inside this BIP about the impact to have policy only semantics encoded in the nVersion field, forever marked in the transaction logs, and as such eventual protocol semantics leaked by the bit setting as such affecting the fungibility of the coins. Should have all the BIPs in the future to have a mandatory privacy section ? I don't know, it's a question worthy to be raised. If I have a suggestion it would be to remove the "mission" term. It is implying that Bitcoin has some kind of eschatologic mission, and sooner or latter, we'll be back to what did happen during the block size war, people doing whitepaper fundamentalism and someone like CSW or a faction pretending to be "Satoshi Vision", while being to have been proven a fraud so far in front of a public court of justice [1]. Bitcoin has a rich enough technical and cultural history in itself in case of community's lack of consensus. "Off-list BIP-related correspondence should be sent (or CC'd) to the BIP editors." I can see why you could reach out off-list to the BIP editors, e.g for security reasons if you wish some clarification on an old BIP, and you don't have the level of experience to know who to reach out in the ecosystem to ask more. Though apart of that, I would discourage off-list BIP-related correspondence with the BIP editors. Is there any other good reason ? I cannot see any, if it's for complaining that BIP editors are not taking fast enough administrative and editorial tasks, I think it should be done on some public communication channels. About the "BIP Editors" workflow. I think there should be explicitely a public process detailed to nominate new BIP editors in the presence of some fragment of the community being unsatisfied with the current way of BIP editors work is done. Let's learn from what did happen with the taproot activation years ago, when there was only one BIP editor, and it was claimed by some he was too slow in assigning a BIP number to the activation logic [2]. Finally, I think it could be good to have a historical note pointing that the BIP process was originally authored by Amir Taaki in September 2011, at a time he was working on a consensus-compatible re-implementation of a bitcoin full node, which has become libbitcoin and which was not necessarily affected by all the sec issues of core over the recent years. Best, Antoine ots hash: a3efafd1b7a49306a7f7683ae142af088f9f31955a2eaa9bf1d8fd6fcae1c372 [0] https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 [1] Indeed, there has been an appeal of the justice decision by CSW. If in appeal there is a need to have more technical experts in defense of the historical devs quoted / against CSW, I'm here. [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018835.html Le mercredi 18 septembre 2024 à 19:30:16 UTC+1, Murch a écrit : > Hey y’all, > > Continuing the conversation about an update to the BIP process, I have > clobbered together a draft proposal. > > It aims to make determinations on all the topics that were covered by > BIP 2, but tries to address many of the pain points brought up in the > discussion earlier this year, the BIP Process Wishlist, and issues > surfaced by sighting the open pull requests. > > The main changes compared to BIP 2 are: > > - Sunset the comments system > - Rework the workflow > - Use only four Status values (Preliminary, Ready, Active, and > Abandoned) instead of nine, clarify the meaning of statuses > - Replace the "Standards Track" BIP type with the "Specification" BIP > type, and update definitions for all BIP types > - Declare Process BIPs to be living documents > - Discourage adoption tracking in the BIPs repository > - Introduce Revision header and Change Log to record changes to BIPs > after they have been recommended for adoption > - Update description of repository’s scope > - Reduce BIP Editor role to checking editorial and formal criteria, > reassigning judgment calls to authors and audience > > I’m open to reconsider most aspects of this proposal, provided > convincing arguments and tenable alternatives. Please consider relevant > rationale provided in the footnotes when suggesting changes. > > Please especially take note of the description of the repository’s scope. > > You can find the draft here: > https://github.com/murchandamus/bips/pull/2 > > I may also open a pull request to the main BIPs repository later this > week assuming this draft is well-received. > > Best, > Murch > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/92b43444-7048-4882-ab06-4a34616b2c46n%40googlegroups.com.