From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8E0FAC0032 for ; Tue, 24 Oct 2023 01:28:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 541E841932 for ; Tue, 24 Oct 2023 01:28:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 541E841932 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=n+IzV1WW X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0vmDNyNsJnJ for ; Tue, 24 Oct 2023 01:28:44 +0000 (UTC) Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com [188.165.51.139]) by smtp2.osuosl.org (Postfix) with ESMTPS id 57901400B8 for ; Tue, 24 Oct 2023 01:28:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 57901400B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1698110915; x=1698370115; bh=tyv/+6XEZKM7UA9NkamGBMQvFxRAQbyP3QMvzN7chxg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=n+IzV1WWND2N5e8DMz2l1qyJx25qKP6scdqOMDgw9bH8MfUIixnnG0SHKdDpFR0/B X1IyvxM4zXNfwkOtFdt6QJnO6ke4ejqrh1/HbNhnqxBFpIlNklf2xDw6iXvLg6qz67 tFAvHIWYWEw9bK3Q9G0S8aeJIc5p2CFgVjuWSAjZjIWa1HUJTWKVCQa6N32Ckmb2Sj J+yi4/Fte4AdXSG4vIupx2aI58+JwnsKbfDmC7RNwRGCxelEZbs0AjFYsgTkhQvUvf rSCDGTnyJ44GPoxYCEhunP4BLDuOT2De3neHXKzVrqkuewY0BYRDMdsZxjiRiO2x8s WrO8/p74nU+iA== Date: Tue, 24 Oct 2023 01:28:17 +0000 To: Luke Dashjr From: alicexbt Message-ID: In-Reply-To: <5b641ddc-a30b-4dd7-2481-6d9cdb459359@dashjr.org> References: <5b641ddc-a30b-4dd7-2481-6d9cdb459359@dashjr.org> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 24 Oct 2023 02:48:29 +0000 Cc: Bitcoin Protocol Discussion 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: Tue, 24 Oct 2023 01:28:46 -0000 Hi Luke, > Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time > to keep up. There are several PRs far more important than Ordinals > nonsense that need to be triaged and probably merged. I don't think adding another editor solves the problem discussed in this th= read.=20 Last time we had similar situation and Kalle was added as editor instead of= making BIP process decentralized. It was discussed in this [thread][0]. BIP editors can have personal opinions and bias but if it affects PRs getti= ng merged, then repo has no use except for a few developers. > The issue with Ordinals is that it is actually unclear if it's eligible > to be a BIP at all, since it is an attack on Bitcoin rather than a > proposed improvement.=20 What makes it an attack on bitcoin? Some users want to use their money in a= different way. How is it different from taproot assets and other standards to achieve simi= lar goals? Some users and developers believe drivechain is an attack on bitcoin, BIP 4= 7 is considered bad, use of OP_RETURN in colored coins is controversial, increasing blocksize is= not an improvement etc. Still these BIPs exist in the same repository. > proposed improvement. There is a debate on the PR whether the > "technically unsound, ..., or not in keeping with the Bitcoin > philosophy." or "must represent a net improvement." clauses (BIP 2) are > relevant. Those issues need to be resolved somehow before it could be > merged. Can we remove terms like "philosophy", "net improvement" etc. from BIP 2? B= ecause they could mean different things for different people. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018= 859.html /dev/fd0 floppy disk guy Sent with Proton Mail secure email. ------- Original Message ------- On Monday, October 23rd, 2023 at 11:59 PM, Luke Dashjr via bitcoin-dev wrote: > Everything standardized between Bitcoin software is eligible to be and > should be a BIP. I completely disagree with the claim that it's used for > too many things. >=20 > SLIPs exist for altcoin stuff. They shouldn't be used for things related > to Bitcoin. >=20 > BOLTs also shouldn't have ever been a separate process and should really > just get merged into BIPs. But at this point, that will probably take > quite a bit of effort, and obviously cooperation and active involvement > from the Lightning development community. >=20 > Maybe we need a 3rd BIP editor. Both Kalle and myself haven't had time > to keep up. There are several PRs far more important than Ordinals > nonsense that need to be triaged and probably merged. >=20 > The issue with Ordinals is that it is actually unclear if it's eligible > to be a BIP at all, since it is an attack on Bitcoin rather than a > proposed improvement. There is a debate on the PR whether the > "technically unsound, ..., or not in keeping with the Bitcoin > philosophy." or "must represent a net improvement." clauses (BIP 2) are > relevant. Those issues need to be resolved somehow before it could be > merged. I have already commented to this effect and given my own > opinions on the PR, and simply pretending the issues don't exist won't > make them go away. (Nor is it worth the time of honest people to help > Casey resolve this just so he can further try to harm/destroy Bitcoin.) >=20 > Luke >=20 >=20 > On 10/23/23 13:43, Andrew Poelstra via bitcoin-dev wrote: >=20 > > On Mon, Oct 23, 2023 at 03:35:30PM +0000, Peter Todd via bitcoin-dev wr= ote: > >=20 > > > I have not requested a BIP for OpenTimestamps, even though it is of m= uch > > > 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. > > >=20 > > > Frankly we've been using BIPs for too many things. There is no avoidi= ng the act > > > that BIP assignment and acceptance is a mark of approval for a protoc= ol. Thus > > > we should limit BIP assignment to the minimum possible: extremely wid= espread > > > standards used by the entire Bitcoin community, for the core mission = of > > > Bitcoin. > >=20 > > This would eliminate most wallet-related protocols e.g. BIP69 (sorted > > keys), ypubs, zpubs, etc. I don't particularly like any of those but if > > they can't be BIPs then they'd need to find another spec repository > > where they wouldn't be lost and where updates could be tracked. > >=20 > > The SLIP repo could serve this purpose, and I think e.g. SLIP39 is not = a BIP > > in part because of perceived friction and exclusivity of the BIPs repo. > > But I'm not thrilled with this situation. > >=20 > > In fact, I would prefer that OpenTimestamps were a BIP :). > >=20 > > > 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 warren= t BIPs, > > > Lightning doesn't need the approval of Core maintainers, and using th= eir > > > separate BOLT process makes that clear. > >=20 > > Well, LN is a bit special because it's so big that it can have its own > > spec repo which is actively maintained and used. > >=20 > > While it's technically true that BIPs need "approval of Core maintainer= s" > > to be merged, the text of BIP2 suggests that this approval should be a > > functionary role and be pretty-much automatic. And not require the BIP > > be relevant or interesting or desireable to Core developers. > >=20 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev