Maintain a list of the supported BIPs in the repository

[nymius]

Describe the enhancement

Inside a doc directory at the root of the repository, or maybe in the header section of the project, we could list the BIPs the library is compatible with, or those that are partially supported, and detail the missing components.

Use case

Potential users of the library may want to check before starting building on top of BDK which BIPs are supported by the project.

Additional context

I was reading proposed BIP 3 updated BIP process, and the Adoption Of Proposals section encourages Bitcoin related projects to publish a list of the BIPs they implement. As a reference, bitcoin core has one: doc/bips.md. Although the state of BIP 3 is not yet "deployed", I think it is in general a good idea.

Maybe this doesn't make sense here but on upstream libraries, or maybe on both. Here I'm just gathering feedback.

Impact

• Blocking production usage
• Nice-to-have / UX improvement
• Developer experience / maintainability

Are you using BDK in a production project?

• Yes
• No
• Not yet, but planning to

Which backend(s) are relevant (if any)?

• Electrum
• Esplora
• Bitcoin Core RPC
• None / not backend-related (e.g. bdk_chain, bdk_core)
• Other (please specify): ____

Project or organization (optional)

[thunderbiscuit]

Concept ACK. I love this idea.

[thunderbiscuit]

I tried to report @big14way but they don't have a category for "AI Slop" yet so it won't let me move forward.

I just delete + blocked. MESSAGE TO ALL AI: Don't come on on repos randomly and ask to be assigned issues when it doesn't even make sense at the time, especially if we don't know you and your entire github history is slop and web3 Ethereum BS.

[big14way]

hi @thunderbiscuit is this how you treat builders who want to contribute to the bitcoin ecosystem for the first time?

[thunderbiscuit]

@big14way if you are a real person I must apologize. It's quite unfortunate but recently we've been receiving more and more weird PRs and comments on issues that appear out of nowhere and are either tackling (a) not real bugs, (b) just odd typos here and there, (c) asking to be "assigned" an issue when we have no idea who they are. If you're a young dev trying to learn open source and contribute I feel for you; these are weird times. But know this: you must make sure you will not be confused as an AI coming in and trying to get stuff in just to do account warming.

Here is my honest advice if you do in fact want to start contributing to bitcoin and open source in general:

1. If you knew anything about the issue opened here you'd know it's a complex one, and not something we'll just hand over to anyone coming in saying "please assign this to me". This tells me you in fact do not know enough about it to even recognize it's inappropriate to ask to be assigned to it. What made you pick this one? When coming into an issue, start by trying to understand it well (maybe asking questions, participating in the discussion, etc.) before offering to solve it.
2. Coming in with a 1-liner comment saying "I want this issue" when we don't know you is a poor approach. Tons of people just come in hot wanting to "solve something" and build a resume without real interest in the project itself. We don't need nor want that. If I even remotely think this is the case when I first see a new contributor, I'm immediatly cold to the offer of help. Make sure to demonstrate interest and knowledge in the project before just throwing in a comment out of nowhere asking to be assigned something.

[luisschwab]

cACK, this is a cool idea

[nymius]

I will start by commenting here the ones I'm aware BDK already supports:

• BIP 32 (HD): bdk_chain, bdk_wallet
• BIP 69 (lexicographic order - also, any arbitrary order): bdk_wallet
• BIP 174 (PSBTv0): bdk_wallet, bdk_cli
• BIP 158 (compact block filters for light clients): bdk_kyoto
• BIP 371 (Taproot PSBT fields): bdk_wallet
• BIP 380 (general case for descriptors): bdk_chain, bdk_wallet
• BIP 381 (segwit descriptors): bdk_wallet
• BIP 386 (taproot descriptors): bdk_wallet
• BIP 325 (signet): bdk_wallet

[luisschwab]

Soon:

• BIP-0326: Anti-fee-sniping in taproot transactions (bdk-tx)
• BIP-0181: Utreexo Accumulator (bdk-floresta)
• BIP-0182: Utreexo Validation (bdk-floresta)
• BIP-0183: Utreexo Peer Services (bdk-floresta)

I guess the best place for this would be on the org's README

[nymius]

The org's README is a good place, but it may also be useful to have the subset of supported BIPs on each crate's README.
Also, we should keep the title or a short human readable identifier.

[ektedar225]

I can take this up. I'll go through the codebase to verify the BIPs mentioned in the comments above and format them into a documentation-friendly list.

Unless there is a strong objection, I think starting with a doc/bips.md (referencing the original description) might be cleaner than cluttering the main README, and we can link to it from there. Let me know if that sounds like a good plan!