On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote: > Dear List, > > The Ordinals BIP PR has been sitting open for nine months now[0]. I've > commented a few times asking the BIP editors to let me know what is needed > for the BIP to either be merged or rejected. I've also reached out to the > BIP editors via DM and email, but haven't received a response. > > There has been much misunderstanding of the nature of the BIP process. > BIPS, in particular informational BIPs, are a form of technical > documentation, and their acceptance does not indicate that they will be > included in any implementation, including Bitcoin Core, nor that they they > have consensus among the community. > > Preexisting BIPs include hard-fork block size increases, hard-fork > proof-of-work changes, colored coin voting protocols, rejected soft fork > proposals, encouragement of address reuse, and drivechain. I have _not_ requested a BIP for OpenTimestamps, even though it is of much wider relevance to Bitcoin users than Ordinals by virtue of the fact that much of the commonly used software, including Bitcoin Core, is timestamped with OTS. I have not, because there is no need to document every single little protocol that happens to use Bitcoin with a BIP. Frankly we've been using BIPs for too many things. There is no avoiding the act that BIP assignment and acceptance is a mark of approval for a protocol. Thus we should limit BIP assignment to the minimum possible: _extremely_ widespread standards used by the _entire_ Bitcoin community, for the core mission of Bitcoin. It's notable that Lightning is _not_ standardized via the BIP process. I think that's a good thing. While it's arguably of wide enough use to warrent BIPs, Lightning doesn't need the approval of Core maintainers, and using their separate BOLT process makes that clear. -- https://petertodd.org 'peter'[:-1]@petertodd.org