From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinals BIP PR
Date: Mon, 23 Oct 2023 17:43:29 +0000 [thread overview]
Message-ID: <ZTawwRqGN4XUUu8C@camus> (raw)
In-Reply-To: <ZTaSwtvctmIiF74k@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]
On Mon, Oct 23, 2023 at 03:35:30PM +0000, Peter Todd via bitcoin-dev wrote:
>
> 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.
>
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.
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.
In fact, I would prefer that OpenTimestamps were a BIP :).
> 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.
>
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.
While it's technically true that BIPs need "approval of Core maintainers"
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.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-10-23 17:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-21 5:38 [bitcoin-dev] Ordinals BIP PR Casey Rodarmor
2023-10-23 13:45 ` Andrew Poelstra
2023-10-23 15:35 ` Peter Todd
2023-10-23 16:32 ` Tim Ruffing
2023-10-26 22:05 ` Peter Todd
2023-10-23 17:43 ` Andrew Poelstra [this message]
2023-10-23 18:29 ` Luke Dashjr
2023-10-24 1:28 ` alicexbt
2023-10-24 22:56 ` Olaoluwa Osuntokun
2023-10-24 23:08 ` Christopher Allen
2023-10-25 0:15 ` Luke Dashjr
2023-10-26 22:11 ` Peter Todd
2023-10-27 9:39 ` Alexander F. Moser
2023-10-27 17:05 ` alicexbt
2023-11-09 2:15 ` Casey Rodarmor
2023-11-09 22:32 ` Claus Ehrenberg
2023-10-23 14:57 Léo Haf
2023-10-23 17:26 ` Ryan Breen
2023-11-20 22:20 vjudeu
2023-11-21 12:13 ` Kostas Karasavvas
2023-11-21 23:10 vjudeu
2023-11-22 11:27 ` Kostas Karasavvas
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=ZTawwRqGN4XUUu8C@camus \
--to=apoelstra@wpsoftware.net \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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