From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C5350C0032 for ; Fri, 27 Oct 2023 09:40:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id A0DA781DA0 for ; Fri, 27 Oct 2023 09:40:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A0DA781DA0 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=alexmoser.com header.i=@alexmoser.com header.a=rsa-sha256 header.s=default header.b=ExYgaq7m X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pDGYBzfAm7R for ; Fri, 27 Oct 2023 09:40:04 +0000 (UTC) Received: from h5.fbrelay.privateemail.com (h5.fbrelay.privateemail.com [162.0.218.228]) by smtp1.osuosl.org (Postfix) with ESMTPS id 4E6D981CEF for ; Fri, 27 Oct 2023 09:40:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4E6D981CEF Received: from MTA-11-3.privateemail.com (mta-11.privateemail.com [198.54.118.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by h5.fbrelay.privateemail.com (Postfix) with ESMTPSA id 0A42A60162 for ; Fri, 27 Oct 2023 09:40:01 +0000 (UTC) Received: from mta-11.privateemail.com (localhost [127.0.0.1]) by mta-11.privateemail.com (Postfix) with ESMTP id C3AB41800122 for ; Fri, 27 Oct 2023 05:39:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alexmoser.com; s=default; t=1698399597; bh=sOwSRbAmbe44Uzv+2nmKrJySgfsIr8i8SIyN7qLaWaI=; h=From:Subject:Date:References:In-Reply-To:To:From; b=ExYgaq7mlifjGY3Y65hGMtweYw+GlFKBYxYYalzYWLuiKWCEduX5EEsI+IQdjh8jd 4tBZsy8/Sy/EjnHvj5QgkuyMU6gBhibCkNrzxJifZhPNjj/d2WnE3Ku4ph5GGxj/pJ LTlveJDtNhIOuDHgtPDM8fkUB4m6lA6OXxTpUkLnt/999PEyW8ZM7PVKZK+opXlojY NQTFgN+QHNhRvR8+xTHzUv5GK4aVZmY2+ayDU8QfPL3FAuWR5Beh3bmxdQnDG0fLge 9N3SnN0B/q5sXJSWOqmgCLtP4aaAgy3gnzKKkvfJjrsO0xpQzIhaw9DvMI0hZd29Xr 9HKaVwAo34hcw== Received: from smtpclient.apple (unknown [213.55.224.109]) by mta-11.privateemail.com (Postfix) with ESMTPA for ; Fri, 27 Oct 2023 05:39:57 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Alexander F. Moser" Mime-Version: 1.0 (1.0) Date: Fri, 27 Oct 2023 11:39:44 +0200 Message-Id: <15AD6E27-D6C7-4848-B961-A313BBFFB396@alexmoser.com> References: In-Reply-To: To: Bitcoin Protocol Discussion X-Mailer: iPhone Mail (21A360) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Fri, 27 Oct 2023 11:52:03 +0000 Subject: Re: [bitcoin-dev] Ordinals BIP PR 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: Fri, 27 Oct 2023 09:40:05 -0000 A mostly self-managed scheme without exploding number spaces and half-decent= quality control: New ideas and proposals-in-development are in a draft/discussion state witho= ut any assigned or reserved BIP ordinal and remain as such until the followi= ng three conditions are true: 1 - author(s) consider the proposal final and want to promote it to a BIP. Purpose: quality ensured by reputation=20 Risk: Expectations, Experience, Ego 2 - enough non-author interactions with the draft exist. This can be platfor= m agnostic, with =E2=80=9Einteractions=E2=80=9C meaning comments, non-author= contributors, likes, stars, threads,.. and =E2=80=9Eenough=E2=80=9C meaning= flat thresholds, a function of various factors, a combination of the two or= nothing specific at all.=20 Purpose: quality ensured by many=20 Risk: heated discussions on stupid topics and spam inflate interactions=20 3 - no other drafts exist that fulfill condition 1 and 2 and seek the ordina= l =E2=80=9ElastBIP#+1=E2=80=9C.=20 Purpose: avoiding coincidental concurrency issues and fights over esoteric n= umbers.=20 Risk: resolutions may need moderation and can be tedious=20 Draft promotions are done in batches at e.g. every quadruple-zero ending blo= ck number (xx0000) - a bit more often than once a quarter or more often at e= .g every 2016 blocks (~2w) at difficulty adjustment.=20 Fairly straightforward and simple methodology, but should still provide - in= an ideal world - enough framework for proposers to self manage fully. In re= alistic worlds, we can use BIP maintainers to moderate and protect the proce= ss.=20 Condition 2 =E2=80=9EInteractions=E2=80=9C could be changed to =E2=80=9EEnou= gh non-authors consider proposal final=E2=80=9C to ensure more quality by en= ticing co-responsibility, but it=E2=80=99d need a new approval process, whic= h is more annoying than soft-defining required levels of community engagemen= t and relying on the authors for common sense.=20 Best, A On 27.10.2023, at 00:12, Peter Todd via bitcoin-dev wrote: =EF=BB=BFOn Tue, Oct 24, 2023 at 03:56:55PM -0700, Olaoluwa Osuntokun via bi= tcoin-dev wrote: > TL;DR: let's just use an automated system to assign BIP numbers, so we can= > spend time on more impactful things. Yes, an easy way to do that is to use a mathematical function, like SHA256(<= bip contents>) or Pubkey(). Of course, that's also silly, as we might as well use URLs at that point... > IIUC, one the primary roles of the dedicated BIP maintainers is just to ha= nd > out BIP numbers for documents. Supposedly with this privilege, the BIP > maintainer is able to tastefully assign related BIPs to consecutive number= s, > and also reserve certain BIP number ranges for broad categories, like 3xx > for p2p changes (just an example). >=20 > To my knowledge, the methodology for such BIP number selection isn't > published anywhere, and is mostly arbitrary. As motioned in this thread, > some perceive this manual process as a gatekeeping mechanism, and often > ascribe favoritism as the reason why PR X got a number immediately, but PR= Y > has waited N months w/o an answer. >=20 > Every few years we go through an episode where someone is rightfully upset= > that they haven't been assigned a BIP number after following the requisite= > process. Most recently, another BIP maintainer was appointed, with the ho= pe > that the second maintainer would help to alleviate some of the subjective > load of the position. Fast forward to this email thread, and it doesn't > seem like adding more BIP maintainers will actually help with the issue of= > BIP number assignment. >=20 > Instead, what if we just removed the subjective human element from the > process, and switched to using PR numbers to assign BIPs? Now instead of > attempting to track down a BIP maintainer at the end of a potentially > involved review+iteration period, PRs are assigned BIP numbers as soon as > they're opened and we have one less thing to bikeshed and gatekeep. >=20 > One down side of this is that assuming the policy is adopted, we'll sorta > sky rocket the BIP number space. At the time of writing of this email, the= > next PR number looks to be 1508. That doesn't seem like a big deal to me, > but we could offset that by some value, starting at the highest currently > manually assigned BIP number. BIP numbers would no longer always be > contiguous, but that's sort of already the case. >=20 > There's also the matter of related BIPs, like the segwit series (BIPs 141,= > 142, 143, 144, and 145). For these, we can use a suffix scheme to indicate= > the BIP lineage. So if BIP 141 was the first PR, then BIP 142 was opened > later, the OP can declare the BIP 142 is BIP 141.2 or BIP 141-2. I don't > think it would be too difficult to find a workable scheme. At that point, why are we bothering with numbers at all? If BIP #'s aren't memorable, what is their purpose? Why not just let people publish ideas on their own web pages and figure out what we're going to call those ideas on a= case-by-case basis. All this gets back to my original point: a functioning BIP system is *inherently* centralized and involves human gatekeepers who inevitably have t= o apply standards to approve BIPs. You can't avoid this as long as you want a B= IP system. -- https://petertodd.org 'peter'[:-1]@petertodd.org _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev