2021-09-29-bips-meeting-log

[00:00:27]  <michaelfolkson> #startmeeting
[00:01:08]  <michaelfolkson> Feel free to say hi if you will participate (or just watching, fine too)
[00:01:16]  <rgrant> hi
[00:01:21]  <Alexandre_Chery> Hi.
[00:01:23]  <ChristopherA> Hello!
[00:01:31]  <prayank> hi
[00:02:13]  <michaelfolkson> So a summary of the first meeting is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html
[00:02:47]  <michaelfolkson> Is there anything in particular you'd like to discuss? I have a couple of items I'd like to cover
[00:03:39]  <michaelfolkson> If no, we can get started with BIP extensions
[00:03:44]  <ChristopherA> I had a few minor items for agenda.
[00:03:53]  <prayank> I would like to know what people think about things suggested by few devs to decentralize BIP process
[00:04:46]  <rgrant> prayank: bip numbering?
[00:05:01]  <rgrant> prayank: can you recap if other issues?
[00:05:38]  <prayank> rgrant: Mainly mirroring the repository at multiple places and not depend on one or treat as some authority approving things
[00:05:46]  <michaelfolkson> ChristopherA: Ok cool, if only minor let's cover them later 
[00:05:49]  <sgiath> prayank: I think that it is the right move
[00:06:11]  <ChristopherA> I value that BIPs have some minimal filtering, but desire both greater decentralization of efforts and inclusion of non-bitcoin-core documents. For instance, we have a number at https://github.com/blockchainCommons/research/
[00:06:33]  <michaelfolkson> So we covered this "decentralize the BIP process" partly at the last meeting
[00:06:44]  <ChristopherA> (minor stuff depends more on if we choose naming schemes)
[00:07:41]  <ChristopherA> Was there sufficient consensus from that meeting on it? What was it?
[00:07:48]  <michaelfolkson> If you have multiple repos with some version of the Taproot BIPs in them which repo should you refer to?
[00:08:02]  <michaelfolkson> It is nonsensical to me to not have one central repo
[00:08:14]  <michaelfolkson> I don't know how it can work
[00:08:33]  <ChristopherA> I'm fine with a registry. That is what we do with the W3C Credentials Community Group and with some different W3C standards.
[00:08:53]  <ChristopherA> It works for registering DID methods for instance:
[00:09:13]  <ChristopherA> https://github.com/w3c-ccg/did-method-registry
[00:09:16]  <prayank> michaelfolkson: I will refer to repo which is mentioned in implementation. BIP must be implemented somewhere if it had consensus so it's not difficult to document what directory is used for it.
[00:09:31]  <ChristopherA> (oops, updated to https://w3c.github.io/did-spec-registries/#did-methods )
[00:09:49]  <michaelfolkson> prayank: But what if the BIPs have differences between repos and directories? Which is the "correct" one?
[00:10:03]  <rgrant> ChristopherA: DID registry has an "editor" who is supposed to approve patches.  same problem BIPS are trying to get past.
[00:10:23]  <michaelfolkson> Not to mention it ramps up levels of confusion because there are infinite possible locations for BIPs
[00:10:47]  <ChristopherA> I'm not against an editor(s) who primarily makes sure collisions don't happen. But not a single repo for content.
[00:11:02]  <ChristopherA> I'm against a single repo for content.
[00:11:09]  <prayank> michaelfolkson: There is no correct BIP. BIP is a proposal which can be implemented. Implementation is correct thing that needs to be followed and it will obviously be based on one of the repository.
[00:12:12]  <ChristopherA> I'm mostly interested in things like naming convention to assist in naming collisions. For instance, we use year in our file names.
[00:12:36]  <rgrant> ChristopherA: i agree that a more mechanical coordination process, even if it uses the same number of humans, is an improvement.  however, the definition of spam will always be necessary.  that's almost all the Bitcoin BIP editor is doing now.
[00:12:41]  <ChristopherA> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md
[00:13:08]  <ChristopherA> I got the feeling in was more than spam.
[00:13:21]  <ChristopherA> …in the past…
[00:13:45]  <ChristopherA> Plus, updates, changes had to also be approved.
[00:13:52]  <michaelfolkson> rgrant: Agreed. There is always an authority. Generally the BIP champion is the authority over the BIP but with some limited, moderate oversight from BIP editors
[00:14:09]  <michaelfolkson> You can try to magic away the authority but there will always be one
[00:14:23]  <michaelfolkson> An authority who says where the location of the BIP content is
[00:14:42]  <ChristopherA> My ideal (and I'll push strongly for it, but will support consensus if there is one) is that once you have registered it and a location, the author controls that location.
[00:15:16]  <michaelfolkson> ChristopherA: What is the benefit of that? It makes things more complicated, that's one downside
[00:15:25]  <ChristopherA> michealfolkson: The problem with that is "authority for what". There is a lot of work happening outside of bitcoin-core
[00:15:27]  <rgrant> ChristopherA: agree on approvals to change things.  however, the current process is meant to prevent a bait-and-switch attack, where people point to authoritative documents that are later changed to say somthing else.
[00:15:44]  <ChristopherA> I'm fine with bitcoin-core having a subset of items that are specific to core implementation.
[00:15:52]  <michaelfolkson> ChristopherA: But BIPs don't have to implemented in Core? 
[00:16:02]  <ChristopherA> But look at SLIPs, lighting bips, etc.
[00:16:28]  <ChristopherA> If you define a BIP that way, maybe. But core still doesn't do BIP39 and almost every wallet does.
[00:16:55]  <michaelfolkson> ChristopherA: I don't know the history of SLIPs but Lightning devs appeared to want to start a new process (BOLTs)
[00:16:57]  <ChristopherA> There are a number of important wallet related things that are found in SLIPs for instance.
[00:17:20]  <ChristopherA> Similarly, there are lighting topics that should be referenced in core.
[00:18:02]  <michaelfolkson> Lightning topics should be referenced in Core? You mean should be referenced in the BIPs?
[00:18:11]  <ChristopherA> I'd like to see a single "bitcoin family" registry, that can point to core proposals, BOLTs, airgapped community proposals, etc.
[00:18:51]  <ChristopherA> I'd like to seperate the "registry" with name and locations, from the process of core proposals.
[00:18:54]  <michaelfolkson> I'm not sure if luke-jr is here but he has said in the past he'd like Lightning BOLTs to be BIPs. I don't know what his view is of SLIPs
[00:18:57]  <rgrant> ChristopherA: i think you're describing a more open system that includes a broader ecosystem.  one non-controversial way to do this would be to make an informative BIP.  it could link to currently known other repositories, and they can link to whatever they want to.
[00:19:17]  <michaelfolkson> rgrant: Right and you can already make informational BIPs
[00:19:37]  <ChristopherA> In the past they've been pretty roughly filtered.
[00:19:45]  <michaelfolkson> I don't see how moving the location of the content makes a difference here. People should just propose more BIPs :)
[00:19:48]  <rgrant> ahh.
[00:19:54]  <ChristopherA> Part of the reason why BOLTs happened was because of that.
[00:20:51]  <michaelfolkson> But then some people now want bLIPs. Just repeated splintering :)
[00:21:18]  <ChristopherA> I know I'd appreciate it if I contacted the registry team, asked for 2021-NBIP-MyUniqueName, and gave them a repo and an abstract, and they listed it.
[00:22:12]  <michaelfolkson> ChristopherA: But you don't want any oversight? Someone else could come along with rubbish and be able to do the same thing?
[00:22:17]  <ChristopherA> And that repo could also be a SLIP, a W3C community document, a IANA proposal, etc. But one unified place for the bitcoin community to share where to find "the definitive taproot proposal"
[00:22:43]  <michaelfolkson> ChristopherA: In your case I'm sure it would be high quality but that won't be the case if open to everyone with no oversight
[00:22:43]  <rgrant> it's not going to be definitive if there's no review on changing it.
[00:22:49]  <ChristopherA> I'm saying the oversight should be minimal. A small team, and they largely are trying to avoid collisions.
[00:23:15]  <michaelfolkson> ChristopherA: We are pretty close to that now. We only have 2 BIP editors
[00:23:48]  <ChristopherA> You can have some minimal standards. The DID method registry says you have to have sections XY&Z. The Rebooting Web of Trust repo says you must have 2 authors. The W3C CCG requires to different non-affiliated companies. All are minimal oversight.
[00:24:17]  <ChristopherA> We can come up wth something that makes scens for a new bip registry (NBIP?)
[00:24:33]  <rgrant> (wouldn't be definitive because versions would be a bit unclear.  you'd always have to check the history, and cross reference it with other people's histories.)
[00:24:51]  <ChristopherA> "> we have 2 BIP editors" and one repo.
[00:24:56]  <michaelfolkson> Right but respectfully BIPs see a number of rubbish proposals seeking a BIP number to give themselves or their idea credibility
[00:25:23]  <ChristopherA> It happens anyhow. Make them stake some bitcoin ;-)
[00:25:54]  <michaelfolkson> Rebooting Web of Trust etc doesn't necessarily encounter that same challenge. Problems of scale
[00:26:20]  <ChristopherA> True, but I think I've made my point we could do better.
[00:26:29]  <rgrant> IDK, separate registries sounds pretty good for letting reputation follow work that people seek out, and letting everyone figure out spam for themselves.
[00:26:51]  <michaelfolkson> Ok let's move on, 30 mins in and only one topic covered
[00:27:27]  <michaelfolkson> Let's do BIP extensions next
[00:27:35]  <ChristopherA> <nod>
[00:27:43]  <michaelfolkson> Did people read kallewoof mailing list post?
[00:27:52]  <rgrant> yeah
[00:27:55]  <michaelfolkson> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019457.html
[00:28:01]  <michaelfolkson> Thoughts?
[00:28:27]  <michaelfolkson> I'm generally supportive but it is hard to know without examples when they would be used
[00:28:58]  <michaelfolkson> _aj_ brought up bech32. That seems like a good example when it could be used
[00:29:14]  <ChristopherA> My main comment is that -1 -2 etc. doesn't feel quite right, as there is an ordering there.
[00:29:35]  <michaelfolkson> bech32 was considered FINAL/ACTIVE but then a problem was found so in the end bech32m got a new BIP number
[00:29:57]  <rgrant> i think this has a mild tip-following problem.  someone forks and says they have the new-BIP.  who is to say?
[00:29:58]  <ChristopherA> I'd prefer someting more like BIP-XXX-2020-ShortExtensionName
[00:30:05]  <rgrant> usually good work is easy to spot.
[00:30:38]  <michaelfolkson> rgrant: The extension still has to be merged into the BIPs repo (under current procedures)
[00:30:48]  <michaelfolkson> If it was total nonsense it wouldn't get merged
[00:30:50]  <rgrant> michaelfolkson: ahh, okay
[00:31:07]  <ChristopherA> (too late now, but retrospectively I'd prefer BIP-2019-XXX-2021-Extenstion)
[00:31:16]  <ChristopherA> I hate the infiniately increasing numbers.
[00:31:38]  <michaelfolkson> [00:29:58]  <ChristopherA> I'd prefer someting more like BIP-XXX-2020-ShortExtensionName
[00:31:40]  <ChristopherA> In the Ethereum community they are in the thousands now, and i'm constantly getting confused
[00:31:55]  <michaelfolkson> Yeah I think that naming suggestion seems reasonable
[00:32:45]  <michaelfolkson> ChristopherA: Presumably Ethereum has no filter for their BIP equivalents :)
[00:33:11]  <michaelfolkson> Be careful what you wish for on the relaxed/no filter lol
[00:34:00]  <michaelfolkson> So sounds like you are supportive of the extensions idea
[00:34:02]  <ChristopherA> So bech32 is BIP-173, bech32n would be BIP-173-2020-bech32n
[00:34:19]  <ChristopherA> which might be different than another BIP-173-2020-differentissue
[00:34:38]  <ChristopherA> michaelfolkson: yes.
[00:34:58]  <michaelfolkson> Feel free to post a response to kallewoof to the mailing list, it is hard to gauge what people think of an idea if only 2 people respond. But I'll summarize this conversation for the mailing list afterwards
[00:35:08]  <ChristopherA> And in fact, there was a BIP-173-2019-bech32bis
[00:35:41]  <ChristopherA> As many of us (including rxgrant here) implemented the interim "fixed" bech32 before bech32n
[00:36:02]  <michaelfolkson> The ordering point 1, 2, 3 etc is a good one I think
[00:36:46]  <michaelfolkson> People might think 2 replaces 1 or 2 is attempting to supplant 1 etc
[00:36:59]  <michaelfolkson> When they might be two competing proposals
[00:37:12]  <ChristopherA> Just be aware that ordering past the first isn't always linear. I certainly see that with IETF standards, where there might be completely unrelated fixes.
[00:37:36]  <michaelfolkson> Hmm ok interesting
[00:37:57]  <ChristopherA> I not particularly a fan of ordering -1 -2 (or -a -b, etc.)
[00:38:28]  <rgrant> again, i'd support an informational BIP that suggests new names.  i think, however, at the point that it matters you will also want a good toplevel readme with nice links, so they aren't that big a deal.
[00:38:29]  <michaelfolkson> I'm kind of of the view that extensions wouldn't be used that much. Generally you want to wait as long as possible before it is FINAL/ACTIVE anyway giving time for edits,changes, improvements
[00:38:58]  <michaelfolkson> And a competing proposal at odds with an existing draft BIP can still get a new BIP number
[00:39:48]  <rgrant> michaelfolkson: i'd say competing ideas should be sorted out as such by the BIP editors.
[00:39:55]  <ChristopherA> (don't want to stop discussion if this is active, but what is next agenda item)
[00:40:14]  <michaelfolkson> ChristopherA: We can go to yours next
[00:40:36]  <ChristopherA> I think we've covered my issues enough ;-)
[00:41:40]  <michaelfolkson> rgrant: There have in the past been competing proposals that have got BIP numbers. I think it is fine. You don't want the BIP editors deciding which competing proposal wins
[00:41:53]  <ChristopherA> (long term I'm worried about things why BIP-48 didn't happen as it was a wallet community proposal and not a core proposal, but can save that for another day)
[00:42:31]  <michaelfolkson> ChristopherA: Why do you think BIP 48 didn't happen? I don't know the context
[00:43:04]  <rgrant> michaelfolkson: agree, i just meant that 123-mything should not compete with 123-yourthing.  BIP editors should do some work to make sure that (within the same repository) competing ideas get different numbers.
[00:43:48]  <michaelfolkson> rgrant: Agreed. And even if extensions were included in say BIP 3 that doesn't mean competing proposals can't still get different BIP numbers
[00:44:04]  <michaelfolkson> Extensions is just another tool in the toolkit
[00:45:01]  <michaelfolkson> I think they would have reduced the noise around Taproot activation params for instance. Two extensions with the slightly different activation params
[00:45:11]  <ChristopherA> (a number of wallet vendors started using the BIP-32 48 derivation for multisig. But someone couldn't get a BIP number for it (even though it was open) so it became wallet community esoterica. Every multisig wallet that works with Trezor and other hardware has to deal with that it is wonky)
[00:45:45]  <ChristopherA> (We've been pushing for getting it fully documented, but is is reverse engineering)
[00:46:19]  <michaelfolkson> ChristopherA: Hmm would be interesting to get luke-jr and kallewoof's take on that
[00:46:51]  <ChristopherA> (it finally got accepted a few years late for getting good advice on it. https://github.com/bitcoin/bips/blob/master/bip-0048.mediawiki)
[00:46:52]  <michaelfolkson> That seems like something we could resolve today though my understanding of the issue is limited
[00:47:52]  <ChristopherA> It's documented now, and not worth fixing itself. But preventing a fragment of the community engineering something without others knowing it existed was problematic.
[00:48:25]  <michaelfolkson> So it is a "We shouldn't do that again" comment rather than a "We need to fix this" comment?
[00:48:33]  <rgrant> so one way to proceed from here would be for ChristopherA to write a short informative BIP that lists different BIP repos, and we support the idea that this isn't spam this time.  and then a BIP that suggests a numbering that does BIP extensions.
[00:48:39]  <ChristopherA> (I still have some gripes with it, but it ACTIVE in Trezor, Cold Card, Sparrow, etc. now, but everyone had to figure it out themselves)
[00:49:18]  <michaelfolkson> I would NACK different BIP repos, I don't know what Luke, Kalle would say
[00:50:01]  <michaelfolkson> The BIP 48 thing if as described here doesn't need to repeated in future
[00:50:02]  <rgrant> okay, i'm not highly motivated there.  i think the information could be sent as a periodic mailing list reminder.
[00:50:30]  <michaelfolkson> BIPs are definitely not supposed to just be documenting Core
[00:50:51]  <michaelfolkson> There would be no need for them otherwise
[00:50:52]  <ChristopherA> michealfolkson: It isn't the technical problem of BIP-48 that I'm wanting to fix, it the process problem that caused it in the first place. At root of it is core doesn't really care as about about wallet interoperability as the wallet vendors do.
[00:51:29]  <ChristopherA> Both should be able to feel open to contribute. Maybe just the new team is enough.
[00:52:24]  <michaelfolkson> ChristopherA: Yeah I'm unsure that a process problem caused it. Or that different locations other than one repo would solve it
[00:52:43]  <michaelfolkson> But the thinking seems reasonable to me and valuable feedback
[00:52:54]  <ChristopherA> <thumbs up>
[00:53:43]  <michaelfolkson> Ok is there anything else? I think after this the discussion will be focused around the BIP PR and we won't do any other meetings unless they are necessary for some reason
[00:54:09]  <rgrant> the least uncontroversial BIP that pointed to all the external BIPs would be a wallet implementation guide, which could take the form of a table of BIPS implemented by various wallets.
[00:54:23]  <rgrant> oops that would be controversial for which wallets to include.
[00:54:44]  <ChristopherA> A test will be as we move items from https://github.com/BlockchainCommons/Research that are adopted by more than one wallet vendor, we'll suggest BIPs out of them. But not every BIP proposal can be "pre-flighted" like those.
[00:56:22]  <michaelfolkson> ChristopherA: That sounds good to me. I think we'll only find more discussion points on the process with people proposing BIPs. And I'm sure there's some BIPable stuff in the Blockchain Commons stuff
[00:56:34]  <ChristopherA> Right now we have about 5 wallet companies (and 2 services) who have implemented airgapped PSBT & metadata interoperability from that research (though not every research item is worthy of a BIP)
[00:56:51]  <rgrant> aha, we could list BIPs in a table that "selected wallets" implement.  there's not much incentive to control the "Selected wallets" list, because there's no commercial benefit from being on it.
[00:57:12]  <ChristopherA> I wonder if part of the problem is that there isn't some kind of lower level thing than a BIP.
[00:57:46]  <ChristopherA> I can remember when RFC was "a draft request for comments". It since has become a big deal.
[00:57:53]  <michaelfolkson> There's nothing wrong with something being a resource under say Blockchain Commons and not being a BIP
[00:57:54]  <rgrant> that table could be a wallet implementation guide showing what BIPs to consider, ranked by popularity, based on real-world data
[00:58:07]  <michaelfolkson> It is still a valuable resource on Blockchain Commons
[00:58:11]  <ChristopherA> ;-)
[00:58:16]  <michaelfolkson> It isn't BIP or nothing :)
[00:58:52]  <michaelfolkson> But yeah it is very much case by case and Kalle, Luke will have a better idea than me on what can and should be BIPed
[00:59:08]  <ChristopherA> I've got run run. I appreciate you convening on this issue. Prayank came to last one and asked me to join this time.
[00:59:13]  <rgrant> okay, it's been good.  CU.
[00:59:27]  <ChristopherA> Ciao!
[00:59:34]  <michaelfolkson> Cool, let's wrap up then. Thanks for attending everyone.