public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Murch <murch@murch.one>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] BIP 3 and issues on BIPs
Date: Thu, 28 May 2026 11:28:49 -0700	[thread overview]
Message-ID: <db744821-940e-4f76-9a54-9c763ce7ce1e@murch.one> (raw)
In-Reply-To: <ahZOIkGfmJBbCffy@erisian.com.au>

Hi AJ,

AJ wrote: > 1) feedback that the BIP author(s) agree is a concern, but 
haven't figured out how to address > 2) feedback that the BIP author(s) 
strongly disagree with, but that is considered a reasonable concern more 
broadly > 3) feedback that is mostly dismissed as trolling and not taken 
seriously outside of a very small group > I wonder if it would be 
feasible to include the first two sorts of feedback directly in the BIPs 
repo, making it much easier to find.

We removed the Comment system, because it had vanishing adoption and 
resulted in the few submitted comments having an overstated 
representation in the criticized document’s preamble. Due to the lack 
of  authentication, wiki content was also often low quality and 
occasionally defaced. BIP3 already recommends that the Rationale should 
record relevant objections or important concerns that were raised and 
addressed as this proposal was developed. Open issues are also already 
often recorded in Draft BIPs. We now allow linking to multiple relevant 
discussions—new threads should be added as a document matures. In an 
ideal world this would already cover at least the first two classes of 
feedback.

In principle I am open to the idea to collect a summary of the 
discussion and dissent in a dedicated space, but there was hardly any 
commentary even when anyone could post it without any friction. Why 
should we expect this more arduous approach to have more adoption than 
the comment system? My expectation would be that going via pull requests 
and curation would not create more commentary, but the same amount of 
commentary would increase work and decision making for the BIP Editors, 
especially if the expectation is that BIP Editors collect such feedback 
for BIPs when the authors or dissenters do not submit it.

The mailing list seems like a fine place for these discussions. It seems 
to me that they receive a good amount of visibility there. If someone 
observes that BIP authors have insufficiently documented issues and 
concerns in their documents, this should be raised in relevant PRs or on 
the mailing list—just as it e.g., was recently done for BIP54 which led 
to improvements of Motivation and Rationale of BIP54.

 > I think this would be a substantial improvement on the state of the 
art for things like BIP 39 and its "Unanimously discourage for 
implementation" criticisms,[…]

This issue has already been addressed. When BIP3 was deployed, I removed 
all Comment URL headers that linked to empty wikis, and only left those 
that had content. BIP3 empowers¹ BIP Owners to decide whether to remove 
or keep Comment Summary and Comment URL from their BIPs. To be fair, 
this information may need to be spread more broadly.

> […] or, eg, creating issues against bitcoin-inquisition/bitcoin [0], or commenting on old, closed PRs [1].

The latter was my mistake. I should have just emailed BIP authors 
directly instead of commenting on the ancient PRs that submitted the 
corresponding documents, or opened up a PR to propose the changes to get 
the authors’ input on them.

¹ https://github.com/bitcoin/bips/blob/master/bip-0003.md#comments

Cheers,
Murch

On 2026-05-26 18:51, Anthony Towns wrote:
>  From bips#2175: https://github.com/bitcoin/bips/pull/2175#issuecomment-4550089883
>
>>> Lastly, the BIPs repo does not have an Issues tab. An Issues tab would
>>> allow for discussion of such things without opening a demonstrative PR.
>> (There may be other reasons, but one hypothesis amongst the BIP editors
>> as to why there is no Issues tab, was that the idea was to have those
>> discussions take place on the mailing list.)
> (Presumably, there was also the BIPs wiki for comments about BIPs,
> though that's no longer encouraged as of BIP 3)
>
> I think not having some "centralised" place for finding previous
> discussions/feedback about a BIP is a flaw in BIP 3 as it stands --
> searching across bitcoin-dev, delving, stacker.news, twitter, nostr,
> random blogs, etc is certainly possible, but it would be nicer if that
> were a fallback, rather than the only option.
>
> I think there's basically three classes of feedback:
>
>   1) feedback that the BIP author(s) agree is a concern, but haven't
>      figured out how to address
>
>   2) feedback that the BIP author(s) strongly disagree with, but that
>      is considered a reasonable concern more broadly
>
>   3) feedback that is mostly dismissed as trolling and not taken seriously
>      outside of a very small group
>
> I wonder if it would be feasible to include the first two sorts of
> feedback directly in the BIPs repo, making it much easier to find.
>
> For example, class 1 feedback could be added directly to the affected BIP
> with the agreement of the author(s), under a new top-level "Unresolved
> issues" section or similar. (Issues that are "resolved" can presumably
> be addressed more directly in the BIP, eg under the "Rationale" section)
>
> Presumably, BIPs that have an "Unresolved issues" section would not
> progress to "Complete".
>
> Class 2 feedback, where the BIP *editors* agree it's a reasonable concern,
> despite the *author(s)* NACKing it, could be placed under a dedicated
> BIP for class-2 feedback across the repo that's maintained by the BIP
> editors, perhaps as bip-xxxx/feedback-bip-yyyy.md. I guess bip-xxxx
> could actually just be bip-0003.
>
> Hopefully editors would be able to do a fairly quick/easy private vote to
> make decisions here, just a call on "is this worth surfacing to everyone
> or is it better left on whoever's blog?" rather than "do I agree with
> this criticism or not?".
>
> Both these types of feedback could then be refined over time to their
> best version by filing PRs on the bips repo. And just as bips themselves
> can have "Discussion" links, feedback items (whether class 1 or 2) could
> also have links to broader/more-detailed discussion of the feedback on
> mailing lists / blog posts / etc.
>
> I think this would be a substantial improvement on the state of the art
> for things like BIP 39 and its "Unanimously discourage for implementation"
> criticisms, or, eg, creating issues against bitcoin-inquisition/bitcoin
> [0], or commenting on old, closed PRs [1].
>
> [0] https://github.com/bitcoin-inquisition/bitcoin/issues/74
> [1] https://github.com/bitcoin/bips/pull/682#issuecomment-4503369974
>
> Class 3 feedback, where both the BIP authors and the BIP editor group
> don't think it's valuable to surface, would still have to be raised
> externally and found by web searches.
>
> (For class 2 feedback where the people complaining also have a solution
> in mind that the BIP authors have rejected, the obvious solution is to
> create a new BIP aimed at replacing the existing BIP)
>
> 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 visit https://groups.google.com/d/msgid/bitcoindev/db744821-940e-4f76-9a54-9c763ce7ce1e%40murch.one.


  reply	other threads:[~2026-05-28 18:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27  1:51 [bitcoindev] BIP 3 and issues on BIPs Anthony Towns
2026-05-28 18:28 ` Murch [this message]
2026-05-31  7:12   ` Anthony Towns
2026-06-01 21:24     ` Murch
2026-06-01 22:54       ` Murch
2026-06-05 11:41       ` Anthony Towns

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=db744821-940e-4f76-9a54-9c763ce7ce1e@murch.one \
    --to=murch@murch.one \
    --cc=bitcoindev@googlegroups.com \
    /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