From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YM21U-0005vr-AE for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 22:14:12 +0000 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; Received: from 85-234-147-28.static.as29550.net ([85.234.147.28] helo=zinan.dashjr.org) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YM212-0006uc-Pi for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 22:14:12 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 4D3F0108373F; Thu, 12 Feb 2015 22:13:36 +0000 (UTC) From: Luke Dashjr 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> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201502122213.34765.luke@dashjr.org> X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 TVD_RCVD_IP Message was received from an IP address -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1YM212-0006uc-Pi Cc: ruben@blocktrail.com Subject: Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 22:14:12 -0000 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!