BIP numbering and status mess

[tiagocs]

There is BIP 199 and then the next BIP number is 300. why? These BIP numbers seem so random.

Also, the status of the BIPs could seem a bit outdated, no? For example, BIP 174 says "proposed" but it should be "final", no? It has been merged about two years ago...

https://github.com/bitcoin/bips

[1714762151]

1714762151

[BrewMaster]

some of the gaps between numbers is because they wanted to leave room for similar BIPs to be together. for example BIP n be about a certain topic and n+1 be about the same topic too. like how BIP-32, 39, 42 are all in the same range and close and are about HD wallets.

as for status, sometimes BIPs aren't accepted by the community or remain unused so they never reach "final" even if a long time has passed.

[ABCbits]

as for status, sometimes BIPs aren't accepted by the community or remain unused so they never reach "final" even if a long time has passed.

And not all BIPs are good BIP or relevant with today's condition.

[tiagocs]

But BIP 174 was merged like two years. It's about PSBT. There are a bunch of RPC commands to make PSBTs and all. For a reader interested in informing himself on what BIPs made it to the bitcoin core code, he would just ignore BIP 174. Even if there are some details that are left to be implemented, there should be a status like "Partially merged" or some indication that the BIP has made it into the codebase.

[BrewMaster]

if you feel like the status of any of the BIPs is wrong (or find any other mistakes for that matter) you should open a pull request on the same github repository about that mistake.

for BIP-174 you may also wait for achow101 to come around and make a comment since he is the creator of that proposal.

[achow101]

The status changes are largely up to the author. At a certain point in the lifetime of a BIP, the author stops caring to update the status or just forgets that that's a thing to do.

w.r.t BIP 174, it could probably be changed to final status. But Final also implies a finality and that the BIP won't change. However BIP 174 does change from time to time, especially as new fields get added to it. It makes me a little uncomfortable to have it be Final but then still add things and change things in it.

[DaveF]

The status changes are largely up to the author. At a certain point in the lifetime of a BIP, the author stops caring to update the status or just forgets that that's a thing to do.

w.r.t BIP 174, it could probably be changed to final status. But Final also implies a finality and that the BIP won't change. However BIP 174 does change from time to time, especially as new fields get added to it. It makes me a little uncomfortable to have it be Final but then still add things and change things in it.

Bit of a rant here targeted at you achow101 and I would like to apologize before I begin.
So sorry if I come off a bit snarky about it.

I am not a programmer I am a hardware guy / operations / network guy.

I do a ton of diagnostics on stuff, and am usually the person that gets called when nobody else can figure it out. I then spend hours going through tech docs to figure out why this one oddball thing is not doing what it is supposed to be doing. And there have been countless times when digging into obscure tech manuals that something has gone from proposed -> implemented -> used -> deprecated -> removed and the last notes in github / gitlab / SVN are "will be in next release"

Throw those of us out there some sort of signal. Please. Yeah, this is not exactly the same, but it snowballs. I have to do a call to something that is not what is documented and it all goes to shit.

Sorry, touched a nerve, I was working on a Ubiquiti setup and something stopped working because some things were removed from an upstream app that was never documented. Cost me days and the client a ton of money. Finally got an answer from the other vendor that yeah, we took that out nobody seemed to use it.

-Dave

[gmaxwell]

I can't figure out what, concretely, davef is asking for.

Would you prefer a spec which changes from time to time to falsely claim that it is final?  You would prefer that the spec not change even when demands mean the implementation must, so then the spec will just not match?   Or would you prefer the BIP have never been written in the first place, saving an epic boatload of time for the authors? Something else?


I don't intend to snark either, but your generalized complaint is totally opaque to me-- to the point that I can't even discuss it with you because I just can't tell what you expect.

[HeRetiK]

I can't figure out what, concretely, davef is asking for.

Would you prefer a spec which changes from time to time to falsely claim that it is final?  You would prefer that the spec not change even when demands mean the implementation must, so then the spec will just not match?   Or would you prefer the BIP have never been written in the first place, saving an epic boatload of time for the authors? Something else?


I don't intend to snark either, but your generalized complaint is totally opaque to me-- to the point that I can't even discuss it with you because I just can't tell what you expect.

I guess what DaveF and to some extend OP are asking for is an additional status like "Proposed" that indicates something has been merged and released but is still in a state of flux? Or is this what "Proposed" means anyway?

[DaveF]

I can't figure out what, concretely, davef is asking for.

Would you prefer a spec which changes from time to time to falsely claim that it is final?  You would prefer that the spec not change even when demands mean the implementation must, so then the spec will just not match?   Or would you prefer the BIP have never been written in the first place, saving an epic boatload of time for the authors? Something else?


I don't intend to snark either, but your generalized complaint is totally opaque to me-- to the point that I can't even discuss it with you because I just can't tell what you expect.

I guess what DaveF and to some extend OP are asking for is an additional status like "Proposed" that indicates something has been merged and released but is still in a state of flux? Or is this what "Proposed" means anyway?

How about in use but still regularly updated?

Or Active and still under development?

Or "Yes you can use it, it's in the current release but be aware that it will probably be changed in the future so if something stops working during an update this may or may not be the case."

OK, the last one is a bit long but you get the idea. But something, anything, that lets people who are not familiar with every function and every call of BTC (or any software for that matter) but does know some programming or is working with another app that deals with it that it's there and working this way today but might not be the same tomorrow.

Like @achow101 said above having it be "final" and still add  or still change things would not be good either. So I just think there needs to be something else there.

In a perfect world we would all have time to read every change-log of everything we are using but we can't.
As I said, it's not just BTC it's things that interact with it so tracking down things that stopped working can be long and painful.

But the best way to put it is what I tell some clients: If it's in the server room *in pencil* it might be wrong.
If it's in the operations manual as a printout it's correct as of the date on the printout.
If after that there were changes made, they will be noted, even if the exact changes are not listed, you at least know stuff was changed.

-Dave

[BrewMaster]

OK, the last one is a bit long but you get the idea. But something, anything, that lets people who are not familiar with every function and every call of BTC (or any software for that matter) but does know some programming or is working with another app that deals with it that it's there and working this way today but might not be the same tomorrow.

In a perfect world we would all have time to read every change-log of everything we are using but we can't.

but do we really need to be aware of all changes and keep track of them?
most regular users won't even know about most changes ever. for example they may not even know they are using PSBT, the wallet does that all for them.
as a developer it may be needed but keeping track of changes isn't that hard specially if it is a popular project and has many contributors.

[DaveF]

OK, the last one is a bit long but you get the idea. But something, anything, that lets people who are not familiar with every function and every call of BTC (or any software for that matter) but does know some programming or is working with another app that deals with it that it's there and working this way today but might not be the same tomorrow.

In a perfect world we would all have time to read every change-log of everything we are using but we can't.

but do we really need to be aware of all changes and keep track of them?
most regular users won't even know about most changes ever. for example they may not even know they are using PSBT, the wallet does that all for them.
as a developer it may be needed but keeping track of changes isn't that hard specially if it is a popular project and has many contributors.

If it involves money, yeah.
If this was an open source chess project and someone did not document a change and something stopped working then so be it.
With something that involves money, then yeah lots and lots of notes / comments / documentation.
It's not just PBST, it comes back to something achow101 said:

The status changes are largely up to the author. At a certain point in the lifetime of a BIP, the author stops caring to update the status or just forgets that that's a thing to do.

w.r.t BIP 174, it could probably be changed to final status. But Final also implies a finality and that the BIP won't change. However BIP 174 does change from time to time, especially as new fields get added to it. It makes me a little uncomfortable to have it be Final but then still add things and change things in it.

If it's final and never touched again, it's one thing. If you make a change and I am doing something and don't notice what you posted that's on me.
If you make a change and don't tell people about it, that's on you.

-Dave