The previous BIP1 text was ambiguous regarding early steps for taking an
idea from concept and eventually into a BIP. The new text is intended to
make it more clear that the initial email to the bitcoin-dev mailing
list should not be a fully-formed BIP. There have been exceptions to
this in the past for ideas already widely known and implementation in
progress, but "you know it when you see it". Hopefully this will add
clarity to the BIP authoring process and work flow for new authors.
This switches from specifying "Bitcoin issue tracker" to specifying
"Bitcoin Core issue tracker". Other issue trackers are useful for other
client development activities, although this does not seem necessary to
mention.
Previously BIP-0001 listed in its header preamble that is was a "Standards Track"
type proposal. This conflicts with both its own definition of "Standards Track"
proposal as well as the type listed in PEP-0001 of which BIP-0001 is based on.
Defitions of each type of proposal:
A Standards Track BIP describes any change that affects most or all Bitcoin implementations.
An Informational BIP describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature.
A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process.
Specifically: "Any meta-BIP is also considered a Process BIP."
Based on these definitions BIP-0001 should have always been labeled as a "Process" BIP and this patch corrects this.
From the text: "Some Informational and Process BIPs may also have a
status of "Active" if they are never meant to be completed. E.g. BIP 1
(this BIP)."
All of BIP62's (including the only-new-transactions) are currently enforced
as standardness rules, but it seems hard to push it further. Every new type
of complex transaction may require new extra rules, and some important types
of malleability cannot be addressed by it (for example, a single participant
in a multisig spend creating a new signature with a different nonce).
It seems wiser to pursue normalized txid or segregated witness-based
solutions, which do solve this problem more fundamentally.
