Published on: 2015-05-24T00:44:20+00:00
In February 2015, a discussion took place on the Bitcoin-development mailing list regarding the lack of a specification section in a script template format created by William Swanson and Eric Lombrozo. Luke Dashjr asked if the format supported arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested that all pubkeys executed by all CHECKMULTISIG opcodes should be in canonical order, with some examples provided. However, Todd expressed concern about the rule being too restrictive and not enforced as an IsStandard() rule.The email thread discussed modifications needed for a document to be merged. The BIP being discussed is meant to derive the type of scripts encountered while doing addmultisigaddress. There was a discussion about enforcing a convention for canonical ordering of pubkeys executed by all CHECKMULTISIG opcodes, but it should not be brought into validation rules. It was suggested that wallets could opt-in to this convention for ease of recovery and interoperability reasons.Luke Dashjr and Peter Todd discussed the BIP process for deriving scripts and the need for a Specification section. They agreed that there should be a convention for ordering pubkeys executed by all CHECKMULTISIG opcodes, but it should not be enforced as a soft-fork or IsStandard() rule. Wallets can choose to follow this convention for ease of recovery and interoperability.A proposed standard called BIP44/45 aims to allow software to comply and express compatibility, making it easier for wallet software to be compatible with each other. Questions were raised about whether the specification section supports arbitrary scripts or only the simplest CHECKMULTISIG case. Peter Todd suggested a rule stating that all pubkeys executed by all CHECKMULTISIG opcodes will be in canonical order, followed by some explanatory examples. However, he noted that there is currently no standard way of discussing arbitrary scripts, so the above rule may be too restrictive in some cases.In an email conversation, Luke Dashjr inquired about the specification section of a BIP. Peter Todd suggested rewriting the BIP to state that all public keys executed by all CHECKMULTISIG opcodes would be in canonical order, with some examples provided. However, he also noted that there is currently no standard way of discussing arbitrary scripts, so this rule may not be sufficient in many cases. Peter Todd further stated that he would not want to enforce this as a soft-fork or make it an IsStandard() rule.On February 12, 2015, Thomas Kerin drafted a Bitcoin Improvement Proposal (BIP) with Jean Pierre and Ruben, describing a method to deterministically generate multi-signature transaction scripts. The proposal aims to allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. The BIP focuses on defining how public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and required signatures. Implementations that do not conform with this BIP may have compatibility issues with strictly-compliant wallets.A new Bitcoin Improvement Proposal (BIP) has been drafted to enable deterministic pay-to-script-hash multi-signature addresses through public key sorting. The BIP proposes a standard method to generate multi-signature transaction scripts and defines how the public keys must be encoded and sorted to ensure that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. This will simplify the derivation of scripts and their addresses by all parties and enable services to declare themselves as BIP compliant, working towards interoperability of services.The adoption of a sorting and encoding standard will ensure that compliant wallets produce the same P2SH address for the same given set of keys and required signature count, which is particularly beneficial for multisignature hierarchical-deterministic wallets as less state is required to set up multi-signature accounts. The proposed method requires that public keys be received in compressed form, sorted lexicographically according to their binary representation, and used in a standard multisig redeem script before being hashed according to BIP-0016 to get the P2SH address.Although the BIP is compatible with compressed keys only, it will enable implementations that adopt this standard to be cross-compatible when choosing multisig addresses. However, a group of users that are not entirely compliant could result in one participant deriving an address that the others will not recognize.The context also includes a PGP signature for cryptographic authentication, an HTML attachment that has been scrubbed, and two non-text attachments in the form of PGP keys and signatures. The purpose or content of the message is not clear from the available information, but it appears to be related to secure communication and authentication using PGP encryption and signatures.
Updated on: 2023-08-01T11:34:38.505279+00:00