Published on: 2020-12-23T15:55:42+00:00
Pieter Wuille and Andrew Poelstra had a discussion on the bitcoin-dev mailing list regarding the proposed text for consensus-only validation extension. Pieter Wuille was uncertain about whether this extension would replace the inconclusive-due-to-consensus-and-standardness-differ state. Andrew suggested a way to specify it, where every signature has a well-defined result of valid, invalid, or inconclusive. If validators do not understand anything, they may choose to report it as inconclusive.Andrew updated his PR at Github with four differences. These include compacting all the validation states into three categories, removing extensions sections, removing "to_sign" transaction from wire serialization, and not complicating the protocol for obscure things like bare public keys or multisigs.On December 22, 2020, Pieter Wuille made a proposal on the bitcoin-dev mailing list regarding the "consensus-only validation" extension. Andrew Poelstra responded with his thoughts on standardness vs consensus rules and his desire to enforce standardness rules for anti-malleability reasons. However, he acknowledged the difficulty of enforcing these rules as an implementer because libbitcoinconsensus does not expose them. He also agreed with Wuille's idea of allowing validators to signal when a signature appears to use future consensus rules and using the "inconclusive" state as an elegant way to achieve this.Both Pieter and Andrew agreed that confirming validators should never disagree on valid vs invalid. Poelstra added a commit to his PR at https://github.com/bitcoin/bips/pull/1048 which reflects their thoughts.Pieter Wuille responded to Karl-Johan Alm's request for feedback on changes to the BIP (Bitcoin Improvement Proposal) by suggesting a modification to the proposal. He agreed with the idea of allowing incomplete validators to return "inconclusive" results, making it more accessible to various software. However, he pointed out that this suggestion would break the original use of "inconclusive" as a way to detect future features used in the signature.Pieter suggested that whenever validation fails due to any of the standardness features listed in the BIP, validators should report "inconclusive" instead of "invalid". This ensures that every signature has a well-defined result of valid, invalid, or inconclusive. Validators may choose to report "inconclusive" for anything they don't understand. This modification ensures that no two validators will ever claim valid and invalid for the same signature, only valid+inconclusive or invalid+inconclusive.Karl-Johan Alm expressed his support for recent changes to the BIP in an email to bitcoin-dev. He agreed with the idea of allowing incomplete validators to return inconclusive results, considering it a clear improvement. However, he noted that this suggestion breaks the original use of inconclusive as a way to detect future features used in the signature. He suggested a fix by requiring reporting inconclusive instead of invalid whenever validation fails due to any standardness features unless something is actually invalid. Pieter also supported Karl-Johan's suggestion.A developer has rewritten the text of BIP-0322, a standard for interoperable signed messages based on the Bitcoin Script format, to simplify and clarify the protocol. The changes include merging "consensus" and "upgradeable" rules into one set of rules consisting of consensus checks plus additional restrictions. The BIP specifies three formats for signing messages: legacy, simple, and full. Validators must output one of four states: valid, valid at time t and age s, consensus-valid, or inconclusive. The BIP outlines additional states that can be output instead of "valid" or "invalid" to ease implementation.The author of BIP-0322 has rewritten the text to make it easier to follow and address objections regarding signmessage functionality. The consensus and upgradeable rules have been merged, and a new "Extensions" section allows validators to output the state "consensus-valid" if they don't want to check additional restrictions. The author welcomes comments on Github.In addition to BIP-0322, the document outlines a specification for a new message signing scheme called "signet." These signatures serve as proof of funds, indicating that a set of coins is under the control of a particular address. Validators require access to the current UTXO set and scriptPubKeys to confirm the claimed inputs exist on the blockchain. The specification includes detailed restrictions and requirements for all signature types except legacy. The validation process involves confirming message_hash, message_challenge, and more. If all conditions are met, the signature is considered valid; otherwise, it's invalid. The document also includes information on signing, extensions, compatibility, and references.
Updated on: 2023-08-02T02:58:52.043931+00:00