Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of dashjr.org
	designates 85.234.147.28 as permitted sender)
	client-ip=85.234.147.28; envelope-from=luke@dashjr.org;
	helo=zinan.dashjr.org; 
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 12 Feb 2015 22:13:33 +0000
User-Agent: KMail/1.13.7 (Linux/3.14.27-gentoo; KDE/4.12.5; x86_64; ; )
References: <54DD1E3F.60006@thomaskerin.io>
In-Reply-To: <54DD1E3F.60006@thomaskerin.io>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201502122213.34765.luke@dashjr.org>
Cc: ruben@blocktrail.com
Subject: Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash
	multi-signature addresses
Precedence: list

Where is the Specification section?? Does this support arbitrary scripts, o=
r=20
only the simplest CHECKMULTISIG case?

On Thursday, February 12, 2015 9:42:23 PM Thomas Kerin wrote:
> Hi all,
>=20
> 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.
>=20
>=20
>   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
>=20
> =3D=3DAbstract=3D=3D
>=20
> 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.
>=20
> =3D=3DMotivation=3D=3D
>=20
> Most multi-signature transactions are addressed to P2SH
> (pay-to-script-hash) addresses, as defined in BIP-0016.
>=20
> 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 =E2=80=9Caccount=E2=80=9D (set of public keys and require=
d signature
> count) has a canonical P2SH address.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> =3D=3DImplementation=3D=3D
>=20
> 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.
>=20
> =3D=3DCompatibility=3D=3D
>=20
> * 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.
>=20
> =3D=3DTest vectors=3D=3D
> The required number of signatures in each case is 2.
>=20
> Vector 1
> * List
> ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
> ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
> * Sorted
> ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f
> ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8
> * Script
> **
> 522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f210=
2f
> f12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae *
> Address
> ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z
>=20
> Vector 2 (Already sorted, no action required)
> * List:
> ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
> ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
> ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
> * Sorted:
> ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0
> ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77
> ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404
> * Script
> **
> 522102632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0210=
27
> 735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e772102e2cc6b=
d5
> f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b40453ae * Address
> ** 3CKHTjBKxCARLzwABMu9yD85kvtm7WnMfH
>=20
> Vector 3:
> * List:
> ** 030000000000000000000000000000000000004141414141414141414141414141
> ** 020000000000000000000000000000000000004141414141414141414141414141
> ** 020000000000000000000000000000000000004141414141414141414141414140
> ** 030000000000000000000000000000000000004141414141414141414141414140
> * Sorted:
> ** 020000000000000000000000000000000000004141414141414141414141414140
> ** 020000000000000000000000000000000000004141414141414141414141414141
> ** 030000000000000000000000000000000000004141414141414141414141414140
> ** 030000000000000000000000000000000000004141414141414141414141414141
> * Script
> **
> 5221020000000000000000000000000000000000004141414141414141414141414140210=
20
> 0000000000000000000000000000000000041414141414141414141414141412103000000=
00
> 0000000000000000000000000000414141414141414141414141414021030000000000000=
00
> 000000000000000000000414141414141414141414141414154ae * Address
> ** 32V85igBri9zcfBRVupVvwK18NFtS37FuD
>=20
> Vector 4: (from bitcore)
> * List:
> ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
> ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
> ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
> * Sorted:
> ** 021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18
> ** 022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da
> ** 03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9
> * Script
> **
> 5221021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18210=
22
> df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da2103e3818b=
65
> bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e953ae * Address
> ** 3Q4sF6tv9wsdqu2NtARzNCpQgwifm2rAba
>=20
> =3D=3DUsage & Implementations=3D=3D
> * BIP45 - Structure for Deterministic P2SH Multisignature Wallets -
> https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#address-ge=
ne
> ration-procedure * Bitcore -
> https://github.com/bitpay/bitcore/blob/50a868cb8cdf2be04bb1c5bf4bcc064cc0=
6f
> 5888/lib/script/script.js#L541 * Haskoin -
> https://github.com/haskoin/haskoin/blob/master/Network/Haskoin/Script/Par=
se
> r.hs#L112-122 * Armory -
> https://github.com/etotheipi/BitcoinArmory/blob/268db0f3fa20c989057bd4334=
3a
> 43b2edbe89aeb/armoryengine/ArmoryUtils.py#L1441 * Multisignature
> Brainwallet - http://ms-brainwallet.org/
>=20
> For now, the BIP will live here:
> https://github.com/afk11/bips/blob/bip0090/bip-0090.mediawiki/
>=20
> Looking forward to any feedback and discussions that arise!