Reject BIP-0060 (three years inactivity)

[ysangkok]

According to BIP-0002, any person can request this.

[luke-jr]

This is a confusing BIP. I guess it's proposing adding the relay-txs flag to all version messages. Current nodes do this.

[ysangkok]

OK, if the BIP is bad, why not Reject it then? Proper documentation can be written in a separate BIP or elsewhere.

[luke-jr]

It's unclear to me if it's Reject or Final.

[ysangkok]

@luke-jr it's silly to have a badly written BIP stuck in the Draft state... Can you explain the rationale for either Rejecting or marking as Final? Then those points could be discussed.

[maflcko]

side-note: There is a protocol-version-bump collision between BIP 60 and BIP 61.

It is up to implementations whether to implement BIP 60. If there are some implementations that implement it, it should be Final.

[luke-jr]

I wouldn't call it a collision - you could just as well argue BIP 61 and BIP 60 must be implemented together?

[maflcko]

The protocol version number can not be used as an indicator whether BIP 61 (or BIP 60) is implemented

[ysangkok]

@kallewoof Is there any chance that this can move ahead or should I close it?

[murchandamus]

It seems to me that BIP60 has not made progress in 11 years, and is not implemented by any software. According to BIP2, it should be moved to rejected. If it should rather be treated differently, this would require an amendment of our process.

ACK 3b6a929

[murchandamus]

After reading the discussion on #1012, it may be better to hold off on merging this PR, as there is currently an on-going discussion about revising the BIP process per a successor to BIP2.

[murchandamus]

It seems to me that this should be closed both per the BIP2 process or the BIP3 process, and the point that it might be implemented by some Bitcoin implementation has not been substantiated in 6 years, so I am going to merge this PR.