Reject 98 (expired) #1006
Reject 98 (expired) #1006
Conversation
|
What do you think @btcdrak @maaku @kallewoof ? |
|
This is a general purpose Merkle tree proposals that is in production use is a couple of different applications. I'm not sure why you think Taproot would supersede BIP-98. |
|
@ysangkok please don't go around marking BIPs as expired merely because some duration of time has passed. At least not any BIPs I'm involved with. I don't appreciate it. |
|
@maaku Has this been making any progress, even a little? You can always "re-open" it to Draft/Proposed later, even if we merge this... (Arguably Taproot's progress could be interpreted as MAST's progress?) |
|
BIP-98 is not MAST, that is just the context in which it was proposed. BIP-98 is a general purpose fast-Merkle tree. It is presently used for merge-mining Tradecraft/Freicoin with Bitcoin, among other things. (It is also used inside of Tradecraft for other purposes, and by Elements/Liquid.) |
|
I have no opinion on the conditions or process around closing old PRs, but I agree with @maaku that BIP 340-342 doesn't supersede this or otherwise relates to this. |
|
@luke-jr If something's rejected it's off the table. It's not something you drag back onto the table afterwards. That's not what the word 'rejected' means. At least that's my opinion. |
|
@kallewoof no one ever has the authority to take something perpetually off the table. BIP-0002 is explicit that a BIP can move from rejected to proposed or draft status, it is absolutely not final. Perhaps the word "rejected" conjures stronger meanings than it should, but then again it's just as easy to make the opposite error (e.g. witness the fact that RFCs are "drafts" have historically caused a lot of confusion). What I believe the process is trying to capture with "rejected" is that the proposal in question isn't currently a live proposal and isn't any clear plan or criteria for that to change (which would be a place for the deferred status), and could have just as well used a more neutral term like "inactive", "archived", or "expired". It's inconsiderate to users of the library of BIPs to not have a clear delineation between specs which are stuff they need to consider implementing vs stuff that is an amorphous future maybe (or, worse, something that someone with expertise would tell you doesn't have a chance in hell-- which has certainly been the case for at least a few documents people have proposed). BIPs library are ultimately documents for Bitcoin. The fact that a proposal is used outside of Bitcoin shouldn't much matter for status here-- if anything it's a reason that a BIP that isn't under active development should move to rejected or withdrawn: If it became an active proposal for Bitcoin again, it would probably undergo changes which would make it incompatible with the usage elsewhere. If that happened it would be extremely unfortunate for the revised version to have the same name, since then it would create confusion for people trying to implement the other thing. Where this has happened before (e.g. with the p2p encryption bip) when the work began it started under another document, which seems like a pretty useful thing for implementers, so they don't end up looking at the wrong spec. |
|
I think it's exceedingly rare that anyone implements draft BIP specifications without any other feedback/input, so I'm not sure if I agree with it being inconsiderate. Especially considering the fact there is also a
As a sidenote, BIP 2 also has this to say about rejected BIPs:
but in this and several other cases, there is no criticism to address. It's simply a proposal that is not currently moving forward. In my book, "rejected" is meant for BIPs for which flaws or errors have been pointed out, which have not been adequately addressed given a reasonable period of time during which to address them. For such a case, the above wording all makes 100% sense. To simply "reject" stuff because it's at a standstill without any criticism to address is not constructive. |
|
It can be difficult to tell if an inactive proposal isn't subject to criticism. Criticising proposals takes a lot of energy, particularly when the proposers are more difficult to communicate with-- so if a proposal is inactive you can expect that people will just bite their tongue and save their efforts for issues which are more pressing. Another ways to look at the text you quoted is to simply say that the proposal can go back to draft if it's actually active. I agree that the language of BIP-0002 isn't the clearest, but rejected is the one avenue in it for inactive proposals. Contrary to your position it is absolutely unambiguous that a "rejected" proposal can go back to draft or proposed if it meets the criteria: "A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status." and this doesn't require changes to criticism (assuming there isn't any!).
Usually they don't get that far, but people have been extremely irate about the lack of clarity on proposal status in all directions ( random example: https://bitcointalk.org/index.php?topic=5261920.msg54842557#msg54842557 ). (sometimes they do implement them, e.g. see "bcoin" implementing BIP151). |
|
@ysangkok Sorry I didn't mean to come off so harshly. It's just these recent PRs caused me to spend a couple of hours reviewing older expiration PRs for various other BIPs in which as I wasn't tagged, as this is not a repo I closely monitor. Now I'm still worried that should I let a notification slip by (and I receive far too many GitHub notifications), a BIP I use or maintain code for might get withdrawn or rejected for no reason other than the passage of time. That's anxiety-inducing. I can imagine circumstances in which it would be useful for a 3rd party to trigger a BIP's status to be withdrawn or rejected. For example, if the BIP describes a protocol for which there are outstanding unfixed security advisories, and the champion is unresponsive. I see at least one instance in the past where @ysangkok expired a BIP that had an outstanding security vulnerability, and I commend him for it. However for BIPs that do not have known vulnerabilities there shouldn't be an automatic expiration. This BIP is still in the "Draft" state because there is still potential for aspects of it to change as it is implemented in the service of various other protocols. It may never leave the "Draft" state, and that's okay. |
|
@maaku I agree that, at the very least if there are no outstanding circumstances and if the BIP author outright objects to the rejection (as is the case here), it should at the very least be postponed until it has clearly become obsolete or redundant or otherwise proven to be unusable in the Bitcoin context. @gmaxwell has a point though that it becomes unclear to implementers whether a BIP represents something they should implement or not. Edit: to clarify, I think BIP-2 requires an amendment (or replacement) to address this case. |
|
Giving this some thought, my primary objection is to the wording. I propose we rename "reject" to "Inactive" or "Inactive Draft" or something equally neutral. Taking something inactive and reactivating it is every-day. But taking something that was rejected and un-rejecting it is... unusual. |
|
While I read the link and I think I understand the objection, I'm a bit baffled by the general statement. A BIP existing by no means indicates that you need to implement it. Nobody would presume that to implement a networking server you need to implement every single RFC ever published, for example. |
|
NACK to rejecting this. BIP 340-342 doesn't supersede this and so the only rationale for rejecting this is the three year rule which may be clarified in #1016. |
This has expired according to BIP-0002 expiration rules, and I believe it has also been superseded by Taproot.