From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-development@lists•sourceforge.net
Cc: ruben@blocktrail•com
Subject: Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
Date: Thu, 12 Feb 2015 22:13:33 +0000 [thread overview]
Message-ID: <201502122213.34765.luke@dashjr.org> (raw)
In-Reply-To: <54DD1E3F.60006@thomaskerin.io>
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!
next prev parent reply other threads:[~2015-02-12 22:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 21:42 Thomas Kerin
2015-02-12 22:13 ` Luke Dashjr [this message]
2015-02-13 7:53 ` Peter Todd
2015-02-13 9:01 ` Ruben de Vries
2015-05-24 0:44 ` Eric Lombrozo
2015-02-13 23:43 ` Thomas Kerin
2015-05-22 17:28 ` Thomas Kerin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201502122213.34765.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=ruben@blocktrail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox