Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses

[Luke Dashjr <luke@dashjr.org>]

Where is the Specification section?? Does this support arbitrary scripts, or 
only the simplest CHECKMULTISIG case?

On Thursday, February 12, 2015 9:42:23 PM Thomas Kerin wrote:
> Hi all,
> 
> I have drafted a BIP with Jean Pierre and Ruben after the last
> discussion, related to a standard for deriving a canonical
> pay-to-script-hash address given a set of public keys and the number of
> signatures required. There have been two or three discussions about it
> on the mailing list to date, and various services already carry out this
> process. I hope a BIP to describe this process will 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.
> 
> 
>   BIP: XX
>   Title: Deterministic Pay-to-script-hash multi-signature addresses
> through public key sorting
>   Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries
>   Status: Draft
>   Type: Standards Track
>   Created: 8 February 2015
> 
> ==Abstract==
> 
> This BIP describes a method to deterministically generate
> multi-signature transaction scripts.  It focuses on defining how the
> 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 number of required signatures.
> 
> ==Motivation==
> 
> Most multi-signature transactions are addressed to P2SH
> (pay-to-script-hash) addresses, as defined in BIP-0016.
> 
> Multi-signature redeem scripts do not require a particular ordering or
> encoding for public keys.  This means that for a given set of keys and
> number of required signatures, there are as many as 2(n!) possible
> standard redeem scripts, each with its separate P2SH address.  Adhering
> to a an ordering scheme and key encoding would ensure that a
> multi-signature “account” (set of public keys and required signature
> count) has a canonical P2SH address.
> 
> By adopting a sorting and encoding standard, compliant wallets will
> always produce the same P2SH address for the same given set of keys and
> required signature count, making it easier to recognize transactions
> involving that multi-signature account.  This is particularly attractive
> for multisignature hierarchical-deterministic wallets, as less state is
> required to setup multi-signature accounts:  only the number of required
> signatures and master public keys of participants need to be shared, and
> all wallets will generate the same addresses.
> 
> While most web wallets do not presently facilitate the setup of
> multisignature accounts with users of a different service, conventions
> which ensure cross-compatibility should make it easier to achieve this.
> 
> Many wallet as a service providers use a 2of3 multi-signature schema
> where the user stores 1 of the keys (offline) as backup while using the
> other key for daily use and letting the service cosign his transactions.
> This standard will help in enabling a party other than the service
> provider to recover the wallet without any help from the service provider.
> 
> ==Implementation==
> 
> For a set of public keys, ensure that they have been received in
> compressed form, sort them lexicographically according to their binary
> representation before using the resulting list of keys in a standard
> multisig redeem script.  Hash the redeem script according to BIP-0016 to
> get the P2SH address.
> 
> ==Compatibility==
> 
> * Uncompressed keys are incompatible with this specificiation. A
> compatible implementation should not automatically compress keys.
> Receiving an uncompressed key from a multisig participant should be
> interpreted as a sign that the user has an incompatible implementation.
> * P2SH addressses do not reveal information about the script that is
> receiving the funds. For this reason it is not technically possible to
> enforce this BIP as a rule on the network.  Also, it would cause a hard
> fork.
> * Implementations that do not conform with this BIP will have
> compatibility issues with strictly-compliant wallets.
> * Implementations which do adopt this standard will be cross-compatible
> when choosing multisig addressses.
> * If a group of users were not entirely compliant, there is the
> possibility that a participant will derive an address that the others
> will not recognize as part of the common multisig account.
> 
> ==Test vectors==
> The required number of signatures in each case is 2.
> 
> Vector 1
> * List
> ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
> ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
> * Sorted
> ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
> ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
> * Script
> **
> 522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102f
> f12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae *
> Address
> ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
> 
> Vector 2 (Already sorted, no action required)
> * List:
> ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
> ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
> ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
> * Sorted:
> ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
> ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
> ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
> * Script
> **
> 522102632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed021027
> 735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e772102e2cc6bd5
> f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b40453ae * Address
> ** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
> 
> Vector 3:
> * List:
> ** 030000000000000000000000000000000000004141414141414141414141414141
> ** 020000000000000000000000000000000000004141414141414141414141414141
> ** 020000000000000000000000000000000000004141414141414141414141414140
> ** 030000000000000000000000000000000000004141414141414141414141414140
> * Sorted:
> ** 020000000000000000000000000000000000004141414141414141414141414140
> ** 020000000000000000000000000000000000004141414141414141414141414141
> ** 030000000000000000000000000000000000004141414141414141414141414140
> ** 030000000000000000000000000000000000004141414141414141414141414141
> * Script
> **
> 522102000000000000000000000000000000000000414141414141414141414141414021020
> 000000000000000000000000000000000004141414141414141414141414141210300000000
> 000000000000000000000000000041414141414141414141414141402103000000000000000
> 000000000000000000000414141414141414141414141414154ae * Address
> ** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
> 
> Vector 4: (from bitcore)
> * List:
> ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
> ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
> ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
> * Sorted:
> ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
> ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
> ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
> * Script
> **
> 5221021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc1821022
> df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da2103e3818b65
> bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e953ae * Address
> ** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
> 
> ==Usage & Implementations==
> * BIP45 - Structure for Deterministic P2SH Multisignature Wallets -
> https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-gene
> ration-procedure * Bitcore -
> https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f
> 5888/lib/script/script.js#L541 * Haskoin -
> https://github.com/haskoin/haskoin/blob/master/Network/Haskoin/Script/Parse
> r.hs#L112-122 * Armory -
> https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a
> 43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441 * Multisignature
> Brainwallet - http://ms-brainwallet.org/
> 
> For now, the BIP will live here:
> https://github.com/afk11/bips/blob/bip0090/bip-0090.mediawiki/
> 
> Looking forward to any feedback and discussions that arise!