It remained unused and it is not compatible to BIP43 and the BIPs based on it. If it turns out worthy to keep as a standard, I suggest reviving it under a new BIP number.
As the removed part of the BIP was optional, this change of the standard does not change the compliance state of any BIP32 implementation.
It remained unused and it is not compatible to BIP43 and the BIPs based on it. If it turns out worthy to keep as a standard, I suggest reviving it under a new BIP number.
As the removed part of the BIP was optional, this change of the standard does not change the compliance state of any BIP32 implementation.
I'm fine with having BIP32 just describe the technical details and not prescribe how to use it.
I read one ACK and no NACKs. Can we get another ACK?
NAK.
BIPs are unique identifiers for ideas. If we're going to change them over time it becomes ambiguous, and we need identifying them through "bip x as it was on date x" or "bip y after section z was removed".
I'm fine with a notice "this section is obsolete because of bip z", but let's not retroactively modify them, apart from clarifications, examples, typo corrections, ...
@sipa Note your scenario is exactly what I want to prevent. If we leave BIP32 as is, we will always have to say "BIP32 first part" (accepted) and "BIP32 second part" (not accepted and obsoleted by BIP43). This is unnecessarly complex/puzzling for new devs in the Bitcoin space trying to catch up on standards with their products.
I think the mistake happened when starting this BIP: We tried to put too much into one document, rather than separating the concerns a bit.
@sipa Note your scenario is exactly what I want to prevent. If we leave BIP32 as is, we will always have to say "BIP32 first part" (accepted) and "BIP32 second part" (not accepted and obsoleted by BIP43).
I think the mistake happened when starting this BIP: We tried to put too much into one document, rather than separating the concerns a bit.
Fair enough. I fully agree BIP32 should have been 2 BIPs in the first place.
Still, I dislike the practice of retroactively changing them. I don't think we should encourage that.
Regarding the "Accepted" term, I think that should go away. Except for BIPs that actually modify a consensus rule or non-optional protocol change, there is no need for such a state. Any implementation of ecosystem infrastructure is free to independently choose to support it or not.
Maybe retroactively separating the two concerns into BIP32a and BIP32b is an option, with BIP32 being defined as the sum (concatenation) of all sub-BIPs?
So if removing is not possible, let's put a deprecation warning above the section, that would be equivalent and then we could finally close this issue.
Closing this as there is no consensus.