Published on: 2015-02-06T21:38:40+00:00
In January 2015, Gregory Maxwell requested a BIP number and Pieter Wuille suggested BIP0066 as the response. There are currently four implementations of BIP0066 available, including one for the master and 0.10.0 versions, which have been merged and can be found on GitHub. The implementations for versions 0.9.4 and 0.8.6 can also be located on GitHub. It is important to note that the 0.8 and 0.9 versions have reduced test code due to reliance on new test framework codes in later versions, but the implementation code remains the same.On February 3, 2015, Pieter Wuille proposed a one-line change to BIP66's DERSIG that would softfork. However, he later retracted the proposal after Suhar Daftuas pointed out some uncovered edge-cases. The goal was to separate signature validation and parsing, and to avoid requiring a third return value for signature checking. A cleaner solution was proposed, which only allows an empty byte vector as an invalid signature, aligning signature validity with decoding and simplifying the implementation.In the same email thread on February 3, Gavin Andresen suggested including a change for DERSIG with other changes for version 0.10. Pieter Wuille acknowledged that it may be late for version 0.10, but releasing without the change would require additional work in future releases. The change was just two lines of code and Gavin Andresen agreed with the proposal.Wladimir suggested adding a patch to make non-standard transactions invalid in Bitcoin's 0.10 version. Pieter Wuille proposed a simpler alternative by modifying BIP66's DERSIG with a one-line change that would softfork. Implementing this change before the release of version 0.10 would prevent the need for a second softfork. The change was considered to be just two lines of code.A discussion was held regarding the implementation of a patch to make non-standard transactions invalid in BIP66. It was suggested to add the patch to BIP66's DERSIG as a simple one-line change that would softfork. However, it was deemed late for version 0.10 and hoped to tag rc4 soon. The discussion also included a sponsor from Intel and their Go Parallel Website, which offers resources for parallel software development.Pieter Wuille proposed a softfork to make non-DER signatures illegal. The draft BIP text for this proposal can be found on GitHub. Positive feedback was received from several implementers, including Amir Taak. One concern raised was the possibility of an unlocked spend with an invalidly encoded signature. In those cases, the signature could be mutated to get it mined, but it would need to already pass IsStandard rules. This issue does not cover cases where there is a chain of transactions after the unlocked transaction.In January 2015, Pieter Wuille proposed a softfork to make non-DER signatures illegal. Non-DER signatures have been non-standard since v0.8.0. Wuille provided a draft BIP text on GitHub for the proposal. He requested a BIP number for the proposal.In the email correspondence, Pieter Wuille responded to Zooko Wilcox-OHearn regarding updates made to the BIP text and code for handling invalid signatures in Bitcoin transactions. The changes were synced up with the repository code, and comments were added to the BIP text. There are still multiple ways to encode a correctly encoded but invalid signature, including the 0-length string. Pieter confirms that all branches of the new IsDERSignature() function have been tested and extra test cases have been added. However, there are still TODOs remaining for testing upgrade behavior. Lastly, Pieter fixes a missing comment in the code.In a discussion on January 25, 2015, Matt Whitlock suggested a change to the C++ code used in Bitcoin Core releases. He proposed changing the parameters of functions to be more in line with the spirit of C++. Pieter agreed with the suggestion but noted that one of the motivations for including C++ code was to match the exact code used in previous Bitcoin Core releases.On January 21, 2015, Rusty Russell sent an email addressing the issue of relying on OpenSSL for consensus rules as part of BIP 62. The plan to get rid of this risk was postponed due to unforeseen complexities. However, recent events have made it clear that a fundamental solution is necessary. Russell provided a C++ code snippet to validate signature encoding and several test cases to ensure its validity. Pieter Wuille, a Bitcoin Core developer, has proposed an improvement to the Bitcoin protocol that would replace OpenSSL with libsecp256k1.
Updated on: 2023-08-01T11:12:49.211700+00:00