From: Anthony Towns <aj@erisian•com.au>
To: Pieter Wuille <bitcoin-dev@wuille•net>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Time for an update to BIP2?
Date: Thu, 4 Apr 2024 15:00:28 +1000 [thread overview]
Message-ID: <Zg4z7P+MKzEfCkdM@erisian.com.au> (raw)
In-Reply-To: <4pVUOTuyyAbTJB_rTGNWS_TuR39NS5OoJvaSCyqjezAg265kPnCjXvqohFmWQ5ITb7XFZCJie-uV1AG3pVCI5H54dDuFP4OyomC9yiWDot0=@wuille.net>
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/Zg4z7P%2BMKzEfCkdM%40erisian.com.au.
next prev parent reply other threads:[~2024-04-04 5:33 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 18:53 [bitcoindev] Adding New BIP Editors 'Ava Chow' via Bitcoin Development Mailing List
2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List
2024-02-27 22:40 ` Luke Dashjr
2024-02-27 22:57 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-02-27 23:26 ` Steve Lee
2024-02-28 11:12 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2024-02-28 16:31 ` Tim Ruffing
2024-03-07 20:56 ` Antoine Riard
2024-03-14 11:56 ` Chris Stewart
2024-03-27 21:25 ` Murch
2024-03-27 23:36 ` Keagan McClelland
2024-03-27 23:39 ` John C. Vernaleo
2024-03-28 13:02 ` Murch
2024-03-28 16:09 ` /dev /fd0
2024-03-28 20:04 ` Matt Corallo
2024-03-28 20:31 ` Antoine Riard
2024-03-28 20:59 ` John C. Vernaleo
2024-03-28 21:19 ` Matt Corallo
2024-03-29 2:34 ` Michael Folkson
2024-03-29 5:24 ` /dev /fd0
2024-03-29 21:08 ` Antoine Riard
2024-03-30 11:51 ` Michael Folkson
2024-03-30 20:01 ` Antoine Riard
2024-03-31 16:01 ` Michael Folkson
2024-04-01 20:14 ` Antoine Riard
2024-04-07 10:11 ` Ali Sherief
2024-04-01 21:13 ` David A. Harding
2024-04-01 23:55 ` /dev /fd0
2024-04-02 0:37 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-02 13:49 ` /dev /fd0
2024-04-02 14:28 ` Luke Dashjr
2024-04-02 15:13 ` Gloria Zhao
2024-04-02 15:39 ` Luke Dashjr
2024-04-03 15:03 ` Murch
2024-04-02 8:18 ` Michael Folkson
2024-04-02 14:24 ` nvk
2024-04-11 14:22 ` Sergi Delgado Segura
2024-04-15 17:50 ` Matt Corallo
2024-04-16 12:34 ` Tim Ruffing
2024-04-16 13:32 ` NVK
2024-04-16 17:08 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-17 23:58 ` 'nsvrn' via Bitcoin Development Mailing List
2024-04-19 22:32 ` Olaoluwa Osuntokun
2024-04-20 19:14 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 19:48 ` NVK
2024-04-20 19:59 ` Michael Folkson
2024-04-20 20:59 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 20:46 ` Steve Lee
2024-04-20 21:08 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 21:11 ` Steve Lee
2024-04-20 21:37 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 22:03 ` Steve Lee
2024-04-20 22:47 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-22 2:44 ` Steve Lee
2024-04-20 22:21 ` Michael Folkson
2024-04-20 23:05 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 11:43 ` Michael Folkson
2024-04-21 16:39 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 17:57 ` Michael Folkson
2024-04-21 18:47 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 19:18 ` Michael Folkson
2024-04-21 20:48 ` Antoine Riard
2024-04-21 23:01 ` Matt Corallo
2024-04-22 0:06 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-22 4:28 ` Ali Sherief
2024-04-23 22:15 ` Anthony Towns
2024-04-25 6:42 ` Antoine Riard
2024-03-29 22:17 ` Keagan McClelland
2024-03-30 4:04 ` Peter Todd
2024-04-01 18:42 ` Jonas Nick
2024-03-27 23:54 ` Matt Corallo
2024-03-28 15:50 ` Brandon Black
2024-03-28 19:42 ` Antoine Riard
2024-03-28 20:04 ` Matt Corallo
2024-04-02 13:17 ` [bitcoindev] Time for an update to BIP2? Tim Ruffing
2024-04-03 19:44 ` Pieter Wuille
2024-04-04 5:00 ` Anthony Towns [this message]
2024-04-04 9:09 ` Niklas Goegge
2024-04-04 12:58 ` [bitcoindev] Adding New BIP Editors 0xB10C
2024-05-13 18:33 ` [bitcoindev] Time for an update to BIP2? Murch
2024-04-01 18:41 ` [bitcoindev] Re: Adding New BIP Editors Murch
2024-03-31 17:01 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-01 6:21 ` /dev /fd0
2024-04-01 11:58 ` Michael Folkson
2024-04-03 16:58 ` Juan Galt
2024-04-03 17:24 ` Vasil Dimov
2024-04-03 18:34 ` 'Fabian' via Bitcoin Development Mailing List
2024-03-07 22:39 ` Keagan McClelland
2024-02-27 21:33 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-02-27 21:48 ` Greg Tonoski
2024-02-27 23:10 ` [bitcoindev] " /dev /fd0
2024-02-28 4:22 ` /dev /fd0
2024-03-09 10:46 ` Michael Folkson
2024-03-10 17:27 ` Bitcoin Error Log
2024-03-11 16:48 ` Jon A
2024-04-05 19:18 ` Larry Ruane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zg4z7P+MKzEfCkdM@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox