Promote Draft->Final BIPs: 60 and 64

luke-jr commented at 5:36 am on February 24, 2016: member

Follow-up from #315

The following BIPs appear to meet the criteria for Final status, but have not been promoted to Accepted by their author yet, so theoretically need ACKs from the authors. Since @genjix is MIA, and @mikehearn ignores Bitcoin, we need to discuss how to handle such actions when BIP champions disappear - BIP 1 allows for me to assign an additional champion to take over, but I’m not sure anyone would necessarily want to do so in these cases.

BIP 60: BIP 37 was apparently not clear on whether the new “relay transactions” flag was mandatory or optional. BIP 60 sought to explicitly make it mandatory. In parallel, Jeff Garzik interpreted BIP 37’s field as mandatory in bitcoin/bitcoin#2534 and Pieter Wuille implemented the changes required for that (and BIP 60) in bitcoin/bitcoin#2763 . Numerous forks of Bitcoin Core since then have also picked up this change.

BIP 64: The getutxo message was implemented for use between (pre-contentious hardforks) Bitcoin XT and Lighthouse. Both of these are unmaintained now, but this does not seem relevant.

Promote Draft->Final BIPs: 50, 60, 64, 66, and 73

BIP 50: Proposed action items, including the hardfork, are completed.

BIP 60: BIP 37 was apparently not clear on whether the new "relay transactions" flag was mandatory or optional. BIP 60 sought to explicitly make it mandatory. In parallel, Jeff Garzik interpreted BIP 37's field as mandatory in https://github.com/bitcoin/bitcoin/issues/2534 and Pieter Wuille implemented the changes required for that (and BIP 60) in https://github.com/bitcoin/bitcoin/pull/2763 . Numerous forks of Bitcoin Core since then have also picked up this change.

BIP 64: The getutxo message was implemented for use between (pre-contentious hardforks) Bitcoin XT and Lighthouse. Both of these are unmaintained now, but this does not seem relevant.

BIP 66: Softfork accepted by a supermajority of miners.

BIP 73: Implemented by at least Bitcoin Core and BitPay.

4ca705ac04

Merge branch 'master' into 20160201_status_updates_d2f 50aa85ee73

Bugfix: README.mediawiki colours 0bba14f2ae

luke-jr added the label question on Feb 24, 2016

luke-jr added the label Pending acceptance on Feb 24, 2016

evoskuil commented at 8:53 am on March 26, 2017: contributor

It’s worth noting that the change to version.relay behavior in the satoshi client spanned release and protocol versions. And as you say, this difference was also picked up by forks. From libbitcoin comments:

0    // The /Satoshi:0.8.x/ node (70001) reads (but does not send) relay byte.
1    // The /Satoshi:0.9.x/ node (70002) sends (and reads) the relay byte.

In order to not fail a high number of connections it’s necessary to allow peers reporting 70001 to not set the byte. Failing connections above 70001 results in a very small number of dropped connections, such as the following:

0// "/Satoshi:1.1.1/" (70006) no relay
1//     anarchistprime: bitcointalk.org/index.php?topic=1001407
2//     This node is identifiable by a different genesis block.
3// "/Cornell-Falcon-Network:0.1.0/" (70014) no relay
4// "/therealbitcoin.org:0.9.99.99/" (99999) no relay

So it seems that the BIP60 treatment of relay as optional in 70001 and mandatory in 70002 is reasonably consistent on the network. Variations are likely forks of version 70001 or prior that failed to track protocol changes.

jonathancross commented at 2:04 am on November 7, 2017: contributor

@evoskuil is this ACK / NACK or did you want to see something changed?

Also, needs to be rebased.

ysangkok commented at 5:57 pm on July 25, 2019: contributor

Isn’t it a bit silly to require ACK from the authors if it has been implemented and is used? I guess you (@luke-jr) see the damage of “breaking protocol” as worse than PR’s floating around and the “Status” field losing value? But you also do not seem to want to reject them as Expired. If you don’t want to follow BIP-0002 (and expire according to protocol), we need a new BIP that explains the actual new process. The current process seems to be to let PR’s linger about if they are controversial, that bloats the issue list.

luke-jr commented at 2:32 am on July 26, 2019: member

Implementation is clearly progress, so to say it hasn’t made progress in 3 years is incorrect…

BIP 2 is what guides my decisions here.

katesalazar commented at 6:47 pm on April 24, 2024: contributor

genjix, mikehearn, evoskuil, have all had plenty of time to comment

maybe just interpret and apply process

evoskuil commented at 9:53 pm on April 24, 2024: contributor

My comments above on bip60 were just to provide additional information. I suppose however I can speak for @genjix in this case. I ACK bip60 and can offer the following comments in support.

The bip37 implementation broke the network protocol. Any peer that fully validated the version message would have simply dropped the connection with the new longer message. Otherwise the assumption had to be that any amount of trailing garbage at the end of that message was ok. I don’t believe this is/was allowed for any other message type.

Also, bip60 requires that no other messages may be sent between version and verack. The reason for this is also preservation of the ability to validate received messages, as opposed to being forced to accept any garbage. However I believe this has, more recently also been violated by certain proposals. There is at least one node that has implemented sendaddrv2 in this manner, as we sometimes see Libbitcoin dropping a peer for this, but I believe Core avoided this break by deviating from that proposal in compliance with bip60.

I wholeheartedly support the objective of this proposal, though I don’t believe the case was made as clearly as it could have been. Also, regarding the relay flag, it’s too late. All nodes have already had to adapt to the protocol break. Clarifying the specific intended behavior is worthwhile, but it is probably the case that many nodes just treat the byte as optional at independent of version level (since it precedes version negotiation).

It would however still be with documenting so that the version message is not extended again, beyond this break, as it will break protocol again. And I strongly recommend acceptance of the additional requirement for no other message traffic between version and verack, and also prior to version (the latter was previously proposed by an obsolete bip).

murchandamus removed the label question on May 8, 2024

murchandamus added the label Proposed BIP modification on May 8, 2024

murchandamus added the label Process on May 9, 2024

5twelve approved

murchandamus removed the label Pending acceptance on Jul 17, 2024

murchandamus added the label PR Author action required on Jul 17, 2024

murchandamus changes_requested

murchandamus commented at 2:23 pm on July 17, 2024: contributor

This PR is in conflict with #913 which updated BIP 64 to Obsolete.

The way I understand BIP 60 and the concurrent PR, Bitcoin Core interprets the field as optional as a receiver, but always sets it as a sender. BIP 60 also required incrementing the version, but that did not happen in the mentioned PR, even while it was implemented months later to comply with BIP 61. So, it looks like Bitcoin Core never explicitly implemented BIP 60, even though Bitcoin Core complies with BIP 60’s sender-only specification today. Regardless of whether BIP 60 was implemented at some point, it’s not clear to me whether it is actually relevant today. It seems to me that one could argue for either Rejected, Final, or Obsolete.

Given that this PR to update BIP 60 and BIP 64 has had a merge conflict for over six years and was not updated, even after there were new comments here almost three months ago, it does not seem to be actively developed anymore. I would recommend that this PR is updated to drop the changes to BIP 64.

Promote Draft->Final BIPs: 60 and 64 #339