...BIP document
Please let me know if the status listed in each individual BIP document isn't the authoritative status, and this changed shouldn't be merged. Just wanted the README document to be up-to-date with current status of all BIPs.
...BIP document
Please let me know if the status listed in each individual BIP document isn't the authoritative status, and this changed shouldn't be merged. Just wanted the README document to be up-to-date with current status of all BIPs.
BIP72 isn't final.
Thanks for the catch schildbach.
Is there any common authoritative source on BIP statuses at the moment? Just because https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki refers to itself as Final, but I understand that this may not actually be the case.
Authorative and decentralized doesn't match well (-: Honestly, I don't know. I guess the BIP process itself is still heavy under construction.
Haha agreed.
Okay, hopefully this thread will spur some discussion about which BIPs are formalized and which aren't so that this README can get as close as possible to the authoritative source for the whole community.
BIP72 is final as far as I'm concerned.
I believe Andreas has an issue with a use-case that is not covered by BIP72, and should be in a separate BIP (see discussion in #106 )
@gavinandresen Well it's the "payment" usecase (-:
@soroushjp I'm a bit late, but your PR looks a lot lie PR #104 except for the small change to BIP1...
But I agree that it would be useful to understand (as someone who doesn't know any better) what is authoritative vs. what is simply normative. I assumed as (I believe?) you did that the individual BIPs were generally authoritative, whereas the README generally was not.
(This came about following @saivann's idea that wallets listed on bitcoin.org should support the "most basic BIPs", and I started wondering how to objectively specify that...)
If we can't agree on what should be in the "Status" column, it may be better to remove it completely. Or at least reduce the number of statuses to a set we can agree on (ie, at least Draft and Active/In Use).
You're right @gurnec, this is very similar to PR #104, I should have looked more carefully. One should be removed, honestly mine since it care after, but I would hate to see this discussion end without a resolution.
Could we go ahead and change all the statuses in the README for BIPs for which there are no disputes? I think that covers most BIPs except for BIP72 at this point.
It would be a huge boon to the ecosystem if people could look at the BIPs README, look at all the Final BIPs, without reading through extensive discussions, and just focus on implementing them. Would move the protocol faster and make bitcoin stronger.
Better is better, merging this.
BTW we need to have a discussion some time about this repository. At least who has to merge BIP changes, and when. I'm honestly not sure whose responsibility that is.
Moving the bips to github was good because it allows change control, in contrast to the wiki in which everyone could make changes. But it appears that this is the other extreme and it has become almost impossible to make changes here.
Would it make more sense for BIP authors to host each BIP on their own github repository, so they can merge PRs at will?
@voisine It makes sense but that'd make it harder to find a BIP, at least programmatically. There are some scripts that automatically link to a BIP given the number.
But I like the idea to decentralize the responsibility of reviewing and merging changes to BIPs.
Maybe we could roll something that authors submit a GPG key, and that for each BIP we have a list of author keys, and that commits signed by one of the authors to their BIP are automatically merged. Or alternatively we could forego the GPG signing and base it in github account.
This would assume that the authors are responsible enough to respect their BIP status - that they won't make technical changes after the BIP is Final. Then again, reverting is always possible. It's better than having everything go through the bottleneck of the Bitcoin Core team (which makes little sense in the first place)...