path: root/5e/1b83177770466fb530aea121a032bc49f3952b

Delivery-date: Thu, 04 Apr 2024 02:12:54 -0700
Received: from mail-yw1-f192.google.com ([209.85.128.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCRY7FFSIEII5XVZWADBUBEXHJ77A@googlegroups.com>)
	id 1rsJ9Q-0002zJ-T2
	for bitcoindev@gnusha.org; Thu, 04 Apr 2024 02:12:54 -0700
Received: by mail-yw1-f192.google.com with SMTP id 00721157ae682-60a20c33f06sf9292067b3.2
        for <bitcoindev@gnusha.org>; Thu, 04 Apr 2024 02:12:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1712221967; x=1712826767; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=X3Jl68OnO4JWsg0VdH90XHDdIwN4+WqVI786DT2Se+M=;
        b=artIAc/ooQ95tnjsIjZi/BzgM+lGw2aoK3Q5auhXuzXpE27VNSg4e9bnsBqYRCD1D1
         7ZLzjJlS4Gxw8ajhSpMg0ZjBt04w+YcNwbKtW78LRHsRl4OrAtGLkWHLlUgushHXlUUS
         spmcJTitwuMTe1x+nTzlJiMokVZlviXoX8Lu6qYR4i1lgq5CKd3KCMbanQMfxgoU9ovB
         LeK+znnM7KL5ydbmysMayX+3d6v7XhYlORSPEqg/BHZN2VObZUjyKGppRI+AQEvFvq+F
         1aWIULUvlLc8d0MnIjwsdp/hY3KSBDdCvrYzeJrTW4I+32IGdSLAnYN7rHVsrnSlgxP4
         EuBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1712221967; x=1712826767; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=X3Jl68OnO4JWsg0VdH90XHDdIwN4+WqVI786DT2Se+M=;
        b=FiRMfxdoB6lmp0N78Z0HhdT/A2EMlKswAwJkGpo01l2TaF6n/8F+BLB44tXY95Wn0s
         vfjB6r96w5dTxjOai4GG3NtBYoPgz3YXLaohAgi4wWS88W9VCzHvUqZRbOxWXbMvePKo
         yMl12CkQ6KISiuADB8L+REuw4M3en/xkLmHhCIy1AMxE9upL02fnXmxWeJRYegXw4E0a
         XDkLnit/R+qoiz+oM73cUjWKI0TZlCdg1mJP+ITXMMmk3ZyS/ciC+xMzjvBxJ9db9Lvc
         GL98KOMbhYhHCx6RQbcSbi+zkuTkRTe/znQFxfKnyf0UMMTzVFEYUPK3YmreoGPJbRxM
         L8iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1712221967; x=1712826767;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=X3Jl68OnO4JWsg0VdH90XHDdIwN4+WqVI786DT2Se+M=;
        b=CRBqB+lFbalTqOaXsJadHJJRZWZc4MI2DOhrj4++/Fd0pLn7IrwjFM3ggsZzi7cc8r
         Hyc5Q24Gh+xMe9UdwYcLjt/dgr+1EFsaNaYRyHsihZOop2PZJo42H+Lj6/MUNU6EMwOF
         nwSFbWZ8/SpDxWLPKkBW4IiXgRC7NUnjOSudFq9QgdOnVL/nGRwB/dYvYdYI+MwzrCNP
         JZNytOGA1e0iJ7MRVXlGmQ2KmH3Za4Y3pR1FBWNQa2Cyutp07SXiSy27kdrSiKlVgqu/
         yJ5Je0byl2r3ur97jQh8IALt8gGwRqzWVc829L3qpOa2ZfBgfiEV4A8bGgsZnMKVTQBv
         Z8pQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVup64wI3rZJDXOe+Tgzc2xhhBUdUZHjBHnurOX5a9iYeevU56sB1zgwaeoWvbHiqosKNVDMsr0YefQOeCBJ6tFN/KcMeY=
X-Gm-Message-State: AOJu0YwtPivhgVbhDrCVUnxV8HDnFJEMLWtHFKYnY4B3XKcuARcn++tZ
	mYg/yYqgs1ej6PCrO+1w2DSLaN8ceRk9lohscsQg3OgU+uXcrgQ+
X-Google-Smtp-Source: AGHT+IGVeQIP+/zYbFV9AOTJ/cG0BTJIO8+QQ26nmFAfmaWqa6nCNAJYbWzVwj3jPt75UkopjcShpA==
X-Received: by 2002:a25:ac94:0:b0:dcf:c7ef:e4e0 with SMTP id x20-20020a25ac94000000b00dcfc7efe4e0mr1960192ybi.1.1712221966654;
        Thu, 04 Apr 2024 02:12:46 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:7a47:0:b0:dcb:b370:7d12 with SMTP id v68-20020a257a47000000b00dcbb3707d12ls713928ybc.1.-pod-prod-00-us;
 Thu, 04 Apr 2024 02:12:45 -0700 (PDT)
X-Received: by 2002:a05:6902:2b83:b0:dd9:2782:d1c6 with SMTP id fj3-20020a0569022b8300b00dd92782d1c6mr707125ybb.1.1712221965757;
        Thu, 04 Apr 2024 02:12:45 -0700 (PDT)
Received: by 2002:a05:690c:f88:b0:611:9f18:9d1 with SMTP id 00721157ae682-61584202cdems7b3;
        Thu, 4 Apr 2024 02:09:33 -0700 (PDT)
X-Received: by 2002:a25:aaca:0:b0:dcd:88e9:e508 with SMTP id t68-20020a25aaca000000b00dcd88e9e508mr541193ybi.5.1712221772905;
        Thu, 04 Apr 2024 02:09:32 -0700 (PDT)
Date: Thu, 4 Apr 2024 02:09:32 -0700 (PDT)
From: Niklas Goegge <n.goeggi@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <10ffcb51-9389-4127-800c-0b8f16ba0a10n@googlegroups.com>
In-Reply-To: <Zg4z7P+MKzEfCkdM@erisian.com.au>
References: <e4048607-64b7-4772-b74e-4566a4b50bc0n@googlegroups.com>
 <9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org>
 <42e6c1d1d39d811e2fe7c4c5ce6e09c705bd3dbb.camel@timruffing.de>
 <d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com>
 <52a0d792-d99f-4360-ba34-0b12de183fef@murch.one>
 <f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com>
 <ZgWRu32FXzqqg69V@console>
 <9ebd08b0-7680-4896-aad3-1c225b764bcb@mattcorallo.com>
 <59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de>
 <4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0=@wuille.net>
 <Zg4z7P+MKzEfCkdM@erisian.com.au>
Subject: Re: [bitcoindev] Time for an update to BIP2?
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_41528_1273343625.1712221772542"
X-Original-Sender: n.goeggi@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_41528_1273343625.1712221772542
Content-Type: multipart/alternative; 
	boundary="----=_Part_41529_1390850799.1712221772542"

------=_Part_41529_1390850799.1712221772542
Content-Type: text/plain; charset="UTF-8"

Hi,

Assuming they are willing, I am supportive of Kanzure, Ruben, Laolu and 
Murch as BIP editors.

Best
Niklas

Anthony Towns schrieb am Donnerstag, 4. April 2024 um 06:33:05 UTC+1:

> On Wed, Apr 03, 2024 at 07:44:00PM +0000, Pieter Wuille wrote:
> > - Scope: related to technology that supports the bitcoin currency.
>
> > This last one may be controversial, but I feel that some of the 
> discussion the past months about the process has shown that there is 
> unclarity/disagreement here, and it would be good to have some guideline 
> written out here. I think scope will inevitably be somewhat of a grey zone, 
> but I feel some limits (whether spelled out or not) will exist regardless 
> (nobody would consider including the HTTP spec in scope for a BIP, I 
> think?).
>
> > I also don't think scope should be tied to specific technologies (e.g. 
> it shouldn't just be about on-chain transactions, as e.g. that would 
> exclude address formats), but if not that, what scoping is useful? And to 
> me, restricting to technology that supports the bitcoin currency is fairly 
> clear, reasonable, and avoids a circular definition. As an example, that 
> would exclude OpenTimestamps from scope (which was suggested in 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022077.html). 
> I see that as an unrelated application which happens to make use of the 
> Bitcoin blockchain, which on itself is one of the technologies that 
> supports bitcoin - but is an indirection too far to be in scope.
>
> For BINANA I phrased that as "proposals only being rejected if they are
> ... unrelated to Bitcoin", on the basis that deciding some BIP/BIN is
> dumb and ignoring it wastes a lot less time than arguing about whether
> it's a good thing for the monetary properties of Bitcoin (which is what
> I'm interested in helping people work on).
>
> For example, would adding script opcodes whose only purpose is to better
> support moving BTC to/from sidechains like Liquid or WBTC on Eth, where
> they can be used as collateral in market makers for trading other tokens
> count as "supporting the bitcoin currency"? This might include such
> things like Drivechains (BIP 300, 301), eg. Is such a feature more about
> supporting asset trading, or is anything that involves buying/selling
> things with Bitcoin count as supporting bitcoin as a currency?
>
> Does it make a difference that a script opcode would be consensus
> critical? Another way of allowing trading between BTC and other assets is
> the "Taproot Assets" proposal (BIPs PR#1489), which anchor trades between
> BTC and tokenized assets on the Bitcoin blockchain, but don't require
> consensus changes. If the BIPS repo includes docs on Drivechains, is
> excluding proposals about Taproot Assets or RGB or similar that valuable?
>
> Those all seems arguable to me; but why force people to have those
> arguments over making up a number and hosting a document in a git repo?
>
> > > * The Comments-URI thing is outdated and everyone seems to ignore it.
> > > Comments-Summary is even weirder.
> > Agreed. It's unused, and sometimes misinterpreted. I think we should get 
> rid of it.
>
> For BINANA I added a "Discussion" header where the BIN author can point to
> locations where discussion has/can take place -- it seemed like a useful
> thing to have beyond just links in the "rationale", both for researching
> background into the proposals development, and as a pointer to somewhere
> people can leave additional feedback. I don't think there's much value in
> having a dedicated discussion area in the BINANA/BIP repo itself though.
>
> > > * "Informational BIPs do not necessarily represent a Bitcoin community
> > > consensus or recommendation". Aha, does this imply that Standards
> > > Track BIPs need to represent a Bitcoin community consensus or
> > > recommendation?
> > Indeed. I don't think BIPs should be representing community consensus or 
> recommendations. But perhaps they can document individual pieces of 
> evidence of acceptance; see further?
>
> Documenting consensus change activation seems useful if nothing else,
> eg as in BIP 90.
>
> > > * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
> > > more than annoying, believe me.
> > I'd like permitting BIPs to be written in markdown.
>
> This is already permitted, see https://github.com/bitcoin/bips/pull/1504
>
> > Some forms of Status are useful I think, but they ought to reflect the 
> author's intent, not the community's perception. E.g. "Draft", "Proposed", 
> and "Withdrawn" make sense to me for any kind of standard. In Draft stage 
> more substantial changes could be permitted, but would convey the idea 
> isn't yet intended for adoption. Of course, the BIP1 status fields weren't 
> really used, and the BIP2 status fields don't seem to be doing much better. 
> If we assume that BIP3 status fields aren't going to be used either this is 
> all for nought, but perhaps it's still worth trying with a significantly 
> simplified assortment of statuses.
> > 
> > Things like "Active / Final" and "Rejected" relate to community 
> acceptance, and I agree those don't belong in BIPs.
>
> I think "Proposed" is much more related to community acceptance than
> "Active" -- you can reasonably say something is "Active" once a single
> implementation has a released version that actively supports it, for
> example; but describing a standard as "Proposed" seems to be pretty
> clearly trying to achieve so form of community acceptance? Who else
> would you be proposing it to?
>
> I'd look at the lifecycle more as something like:
>
> * Draft: author expects further changes, don't deploy this
> * Proposed: author is hoping for multiple implementations to adopt this;
> author thinks it's complete, but there may be objections and it may
> need to go back to Draft state to resolve those objections
> * Active: one or more implementations have deployed this feature as
> specced. changes will usually be specified in a new proposal/standard.
> acceptable changes might be fixing ambiguities, adding extra rationale
> or test cases, etc.
> * Withdrawn: no current implementations support this, author doesn't
> think it should be adopted, author isn't planning on making further
> changes to it
>
> For comparison, BINANA currently has BINs marked Draft, Active and Info:
> https://github.com/bitcoin-inquisition/binana
>
> (Note that adding a consensus change in inquisition and doing a heretical
> activation of that change on signet would still leave the spec in "Draft"
> -- further changes are expected)
>
> (As far as BIP 2's list goes, I think Deferred should just be Draft;
> Rejected/Obsolete should just be Withdrawn; Final should just be Active;
> and Replaced should either be Withdrawn or Active depending on whether
> the replacement is backwards compatible, accompanied by Superseded-By)
>
> > As far as judging consensus goes, perhaps actual consensus changes are 
> an exception? I feel that for those, an "Accepted" status may actually make 
> sense, because they actually require the ecosystem to have agreement about.
>
> How about BIP 148 or BIP 91? I think it's fair to call both of those
> "Active" and would have been fair to mark them Active sometime in
> April-July 2017 -- that doesn't mean there was necessarily community
> consensus behind them: merely that there was software implementing
> those standards active on the network, and that if someone wanted to do
> something similar but different, that would warrant being a different
> standard. If it had turned out there wasn't consensus behind either
> proposal, and no one was mining a blockchain that those implementations
> would accept, at most that would warrant the author marking the BIPs as
> "Withdrawn" IMO.
>
> The same argument applies to BIP 343 I think. I believe only one
> implementation adopted it [0], and I don't believe any actively maintained
> software implements that BIP as written, but if you did implement it
> you'd continue to track the bitcoin blockchain, so I think it would
> be fair to have marked that BIP as "Active" once it was adopted by an
> implementation, and to have left it marked that way.
>
> [0] "Bitcoin Core-based Taproot Client" which doesn't even seem to exist
> in web.archive.org.
>
> https://github.com/BitcoinActivation/BitcoinTaproot.org/blob/master/taproot.html
>
> If the segwit2x fork had ever had a written spec, I likewise think it
> would have been appropriate for it to be a BIP, perhaps being marked as
> Proposed on 2017-07-01 [1], Active on 2017-07-22 [2], and Withdrawn on
> either 2017-11-08 [3] or 2019-10-09 (when the btc1/bitcoin github repo
> was marked as archived).
>
> [1] https://github.com/btc1/bitcoin/pull/50
> [2] https://github.com/btc1/bitcoin/releases/tag/v1.14.5
> [3] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html
>
> Cheers,
> aj
>

-- 
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/10ffcb51-9389-4127-800c-0b8f16ba0a10n%40googlegroups.com.

------=_Part_41529_1390850799.1712221772542
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,<br /><br />Assuming they are willing, I am supportive of Kanzure, Ruben=
, Laolu and Murch as BIP editors.<br /><div><br /></div><div>Best<br />Nikl=
as<br /></div><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"g=
mail_attr">Anthony Towns schrieb am Donnerstag, 4. April 2024 um 06:33:05 U=
TC+1:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Wed,=
 Apr 03, 2024 at 07:44:00PM +0000, Pieter Wuille wrote:
<br>&gt; - Scope: related to technology that supports the bitcoin currency.
<br>
<br>&gt; This last one may be controversial, but I feel that some of the di=
scussion the past months about the process has shown that there is unclarit=
y/disagreement here, and it would be good to have some guideline written ou=
t here. I think scope will inevitably be somewhat of a grey zone, but I fee=
l some limits (whether spelled out or not) will exist regardless (nobody wo=
uld consider including the HTTP spec in scope for a BIP, I think?).
<br>
<br>&gt; I also don&#39;t think scope should be tied to specific technologi=
es (e.g. it shouldn&#39;t just be about on-chain transactions, as e.g. that=
 would exclude address formats), but if not that, what scoping is useful? A=
nd to me, restricting to technology that supports the bitcoin currency is f=
airly clear, reasonable, and avoids a circular definition. As an example, t=
hat would exclude OpenTimestamps from scope (which was suggested in <a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/02=
2077.html" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Dde&amp;q=3Dhttps://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2023-October/022077.html&amp;source=3Dgmail&amp;ust=3D17=
12307364203000&amp;usg=3DAOvVaw2SE_i0-A69hvOJSaUY5a14">https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2023-October/022077.html</a>). I see th=
at as an unrelated application which happens to make use of the Bitcoin blo=
ckchain, which on itself is one of the technologies that supports bitcoin -=
 but is an indirection too far to be in scope.
<br>
<br>For BINANA I phrased that as &quot;proposals only being rejected if the=
y are
<br>... unrelated to Bitcoin&quot;, on the basis that deciding some BIP/BIN=
 is
<br>dumb and ignoring it wastes a lot less time than arguing about whether
<br>it&#39;s a good thing for the monetary properties of Bitcoin (which is =
what
<br>I&#39;m interested in helping people work on).
<br>
<br>For example, would adding script opcodes whose only purpose is to bette=
r
<br>support moving BTC to/from sidechains like Liquid or WBTC on Eth, where
<br>they can be used as collateral in market makers for trading other token=
s
<br>count as &quot;supporting the bitcoin currency&quot;? This might includ=
e such
<br>things like Drivechains (BIP 300, 301), eg. Is such a feature more abou=
t
<br>supporting asset trading, or is anything that involves buying/selling
<br>things with Bitcoin count as supporting bitcoin as a currency?
<br>
<br>Does it make a difference that a script opcode would be consensus
<br>critical? Another way of allowing trading between BTC and other assets =
is
<br>the &quot;Taproot Assets&quot; proposal (BIPs PR#1489), which anchor tr=
ades between
<br>BTC and tokenized assets on the Bitcoin blockchain, but don&#39;t requi=
re
<br>consensus changes. If the BIPS repo includes docs on Drivechains, is
<br>excluding proposals about Taproot Assets or RGB or similar that valuabl=
e?
<br>
<br>Those all seems arguable to me; but why force people to have those
<br>arguments over making up a number and hosting a document in a git repo?
<br>
<br>&gt; &gt; * The Comments-URI thing is outdated and everyone seems to ig=
nore it.
<br>&gt; &gt; Comments-Summary is even weirder.
<br>&gt; Agreed. It&#39;s unused, and sometimes misinterpreted. I think we =
should get rid of it.
<br>
<br>For BINANA I added a &quot;Discussion&quot; header where the BIN author=
 can point to
<br>locations where discussion has/can take place -- it seemed like a usefu=
l
<br>thing to have beyond just links in the &quot;rationale&quot;, both for =
researching
<br>background into the proposals development, and as a pointer to somewher=
e
<br>people can leave additional feedback. I don&#39;t think there&#39;s muc=
h value in
<br>having a dedicated discussion area in the BINANA/BIP repo itself though=
.
<br>
<br>&gt; &gt; * &quot;Informational BIPs do not necessarily represent a Bit=
coin community
<br>&gt; &gt; consensus or recommendation&quot;. Aha, does this imply that =
Standards
<br>&gt; &gt; Track BIPs need to represent a Bitcoin community consensus or
<br>&gt; &gt; recommendation?
<br>&gt; Indeed. I don&#39;t think BIPs should be representing community co=
nsensus or recommendations. But perhaps they can document individual pieces=
 of evidence of acceptance; see further?
<br>
<br>Documenting consensus change activation seems useful if nothing else,
<br>eg as in BIP 90.
<br>
<br>&gt; &gt; * Ever tried to write pseudocode or LaTeX in mediawiki format=
? It&#39;s
<br>&gt; &gt; more than annoying, believe me.
<br>&gt; I&#39;d like permitting BIPs to be written in markdown.
<br>
<br>This is already permitted, see <a href=3D"https://github.com/bitcoin/bi=
ps/pull/1504" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Dde&amp;q=3Dhttps://github.com/bitcoin/bips/pu=
ll/1504&amp;source=3Dgmail&amp;ust=3D1712307364204000&amp;usg=3DAOvVaw3Yka1=
Ufpx4yca-9t-NeSxD">https://github.com/bitcoin/bips/pull/1504</a>
<br>
<br>&gt; Some forms of Status are useful I think, but they ought to reflect=
 the author&#39;s intent, not the community&#39;s perception. E.g. &quot;Dr=
aft&quot;, &quot;Proposed&quot;, and &quot;Withdrawn&quot; make sense to me=
 for any kind of standard. In Draft stage more substantial changes could be=
 permitted, but would convey the idea isn&#39;t yet intended for adoption. =
Of course, the BIP1 status fields weren&#39;t really used, and the BIP2 sta=
tus fields don&#39;t seem to be doing much better. If we assume that BIP3 s=
tatus fields aren&#39;t going to be used either this is all for nought, but=
 perhaps it&#39;s still worth trying with a significantly simplified assort=
ment of statuses.
<br>&gt;=20
<br>&gt; Things like &quot;Active / Final&quot; and &quot;Rejected&quot; re=
late to community acceptance, and I agree those don&#39;t belong in BIPs.
<br>
<br>I think &quot;Proposed&quot; is much more related to community acceptan=
ce than
<br>&quot;Active&quot; -- you can reasonably say something is &quot;Active&=
quot; once a single
<br>implementation has a released version that actively supports it, for
<br>example; but describing a standard as &quot;Proposed&quot; seems to be =
pretty
<br>clearly trying to achieve so form of community acceptance? Who else
<br>would you be proposing it to?
<br>
<br>I&#39;d look at the lifecycle more as something like:
<br>
<br> * Draft: author expects further changes, don&#39;t deploy this
<br> * Proposed: author is hoping for multiple implementations to adopt thi=
s;
<br>    author thinks it&#39;s complete, but there may be objections and it=
 may
<br>    need to go back to Draft state to resolve those objections
<br> * Active: one or more implementations have deployed this feature as
<br>    specced. changes will usually be specified in a new proposal/standa=
rd.
<br>    acceptable changes might be fixing ambiguities, adding extra ration=
ale
<br>    or test cases, etc.
<br> * Withdrawn: no current implementations support this, author doesn&#39=
;t
<br>    think it should be adopted, author isn&#39;t planning on making fur=
ther
<br>    changes to it
<br>
<br>For comparison, BINANA currently has BINs marked Draft, Active and Info=
:
<br><a href=3D"https://github.com/bitcoin-inquisition/binana" target=3D"_bl=
ank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Dde&amp;q=3Dhttps://github.com/bitcoin-inquisition/binana&amp;source=3Dgm=
ail&amp;ust=3D1712307364204000&amp;usg=3DAOvVaw1TBEDRLX35TBS7Fz9j2BAo">http=
s://github.com/bitcoin-inquisition/binana</a>
<br>
<br>(Note that adding a consensus change in inquisition and doing a heretic=
al
<br>activation of that change on signet would still leave the spec in &quot=
;Draft&quot;
<br>-- further changes are expected)
<br>
<br>(As far as BIP 2&#39;s list goes, I think Deferred should just be Draft=
;
<br>Rejected/Obsolete should just be Withdrawn; Final should just be Active=
;
<br>and Replaced should either be Withdrawn or Active depending on whether
<br>the replacement is backwards compatible, accompanied by Superseded-By)
<br>
<br>&gt; As far as judging consensus goes, perhaps actual consensus changes=
 are an exception? I feel that for those, an &quot;Accepted&quot; status ma=
y actually make sense, because they actually require the ecosystem to have =
agreement about.
<br>
<br>How about BIP 148 or BIP 91? I think it&#39;s fair to call both of thos=
e
<br>&quot;Active&quot; and would have been fair to mark them Active sometim=
e in
<br>April-July 2017 -- that doesn&#39;t mean there was necessarily communit=
y
<br>consensus behind them: merely that there was software implementing
<br>those standards active on the network, and that if someone wanted to do
<br>something similar but different, that would warrant being a different
<br>standard. If it had turned out there wasn&#39;t consensus behind either
<br>proposal, and no one was mining a blockchain that those implementations
<br>would accept, at most that would warrant the author marking the BIPs as
<br>&quot;Withdrawn&quot; IMO.
<br>
<br>The same argument applies to BIP 343 I think. I believe only one
<br>implementation adopted it [0], and I don&#39;t believe any actively mai=
ntained
<br>software implements that BIP as written, but if you did implement it
<br>you&#39;d continue to track the bitcoin blockchain, so I think it would
<br>be fair to have marked that BIP as &quot;Active&quot; once it was adopt=
ed by an
<br>implementation, and to have left it marked that way.
<br>
<br>[0] &quot;Bitcoin Core-based Taproot Client&quot; which doesn&#39;t eve=
n seem to exist
<br>    in <a href=3D"http://web.archive.org" target=3D"_blank" rel=3D"nofo=
llow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dde&amp;q=3Dht=
tp://web.archive.org&amp;source=3Dgmail&amp;ust=3D1712307364204000&amp;usg=
=3DAOvVaw1KmzpoWhrxV9cU23t9Lsgm">web.archive.org</a>.
<br>    <a href=3D"https://github.com/BitcoinActivation/BitcoinTaproot.org/=
blob/master/taproot.html" target=3D"_blank" rel=3D"nofollow" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Dde&amp;q=3Dhttps://github.com/Bit=
coinActivation/BitcoinTaproot.org/blob/master/taproot.html&amp;source=3Dgma=
il&amp;ust=3D1712307364204000&amp;usg=3DAOvVaw0JDk2qIIEPanizXBiVdDs8">https=
://github.com/BitcoinActivation/BitcoinTaproot.org/blob/master/taproot.html=
</a>
<br>
<br>If the segwit2x fork had ever had a written spec, I likewise think it
<br>would have been appropriate for it to be a BIP, perhaps being marked as
<br>Proposed on 2017-07-01 [1], Active on 2017-07-22 [2], and Withdrawn on
<br>either 2017-11-08 [3] or 2019-10-09 (when the btc1/bitcoin github repo
<br>was marked as archived).
<br>
<br>[1] <a href=3D"https://github.com/btc1/bitcoin/pull/50" target=3D"_blan=
k" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Dde&amp;q=3Dhttps://github.com/btc1/bitcoin/pull/50&amp;source=3Dgmail&am=
p;ust=3D1712307364204000&amp;usg=3DAOvVaw3qknLApcm01UquJnWlpmW3">https://gi=
thub.com/btc1/bitcoin/pull/50</a>
<br>[2] <a href=3D"https://github.com/btc1/bitcoin/releases/tag/v1.14.5" ta=
rget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Dde&amp;q=3Dhttps://github.com/btc1/bitcoin/releases/tag/v1.14=
.5&amp;source=3Dgmail&amp;ust=3D1712307364204000&amp;usg=3DAOvVaw0bmmEHaU-h=
Cg0jDhuU_wlg">https://github.com/btc1/bitcoin/releases/tag/v1.14.5</a>
<br>[3] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-segw=
it2x/2017-November/000685.html" target=3D"_blank" rel=3D"nofollow" data-saf=
eredirecturl=3D"https://www.google.com/url?hl=3Dde&amp;q=3Dhttps://lists.li=
nuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html&amp;=
source=3Dgmail&amp;ust=3D1712307364204000&amp;usg=3DAOvVaw0QTFBQjpsS1Z6inSd=
yxwqp">https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-No=
vember/000685.html</a>
<br>
<br>Cheers,
<br>aj
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/10ffcb51-9389-4127-800c-0b8f16ba0a10n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/10ffcb51-9389-4127-800c-0b8f16ba0a10n%40googlegroups.com</a>.=
<br />

------=_Part_41529_1390850799.1712221772542--

------=_Part_41528_1273343625.1712221772542--