[Bitcoin-development] BIP for deterministic multisig addresses

[Thomas Kerin <me@thomaskerin.io>]

[-- Attachment #1: Type: text/plain, Size: 8078 bytes --]

Not sure what happened there - I'll drop the PGP.


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
**
522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae
* Address
** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z

Vector 2 (Already sorted, no action required)
* List:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Sorted:
** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
* Script
**
522102632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed021027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e772102e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b40453ae
* Address
** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH

Vector 3:
* List:   
** 030000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414141
** 020000000000000000000000000000000000004141414141414141414141414140
** 030000000000000000000000000000000000004141414141414141414141414140
* Sorted:
** 020000000000000000000000000000000000004141414141414141414141414140
** 020000000000000000000000000000000000004141414141414141414141414141
** 030000000000000000000000000000000000004141414141414141414141414140
** 030000000000000000000000000000000000004141414141414141414141414141
* Script
**
522102000000000000000000000000000000000000414141414141414141414141414021020000000000000000000000000000000000004141414141414141414141414141210300000000000000000000000000000000000041414141414141414141414141402103000000000000000000000000000000000000414141414141414141414141414154ae
* Address
** 32V85igBri9zcfBRVupVvwK18NFtS37FuD

Vector 4: (from bitcore)
* List:
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
* Sorted:
** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
* Script
**
5221021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc1821022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da2103e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e953ae
* Address
** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba

==Usage & Implementations==
* BIP45 - Structure for Deterministic P2SH Multisignature Wallets -
https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-generation-procedure
* Bitcore -
https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc06f5888/lib/script/script.js#L541
* Haskoin -
https://github.com/haskoin/haskoin/blob/master/Network/Haskoin/Script/Parser.hs#L112-122
* Armory -
https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd43343a43b2edbe89aeb/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!


- -- 
Thomas Kerin


[-- Attachment #2: 0xA2966155.asc --]
[-- Type: application/pgp-keys, Size: 5712 bytes --]