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

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

[Thomas Kerin]

[-- Attachment #1.1: Type: text/plain, Size: 9172 bytes --]


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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
- -------------------------

My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQJ8BAEBCgBmBQJU3R43XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVKwUP/3MS++5D+YJAPZG/a7PhY3hf
8UvBkaAp7YqCVvZkHhpQ3+7AF+c6nAfu9JRFSdGP5hNvApagbZoC2oeLQ5rHBfXC
MbkbqOSp0z7C4MvEqmncTSgqNykxanVfiypV2S7hU2fbiylVi2jIaGrjqQt32jT7
kdFw5wqAS3zVHJVZhnUufLj/VYC94vdfrgpL22WI9oNH/nOvO6uG3YwZ9rc63ZH/
cwTmUnjOqDUlJWtYsfcoDL41RkmeBtGqD+6gTe3BtVHJQqlsEWpB1hsucOv5XdEk
V0teRUQ8+hFnU86+S4VJ8+qy/QjYflHnfy7vcA3M6LhAkle3scCs7ZCpDb9EGFM+
yAZivS4vrcVaYgY+oBdSnMEyvudwDKHwdy/rNjTskCLsHzcZX5jAoIxT2XskAXMD
UcWRelpN7Wth5jnSXeB89Wg1DqBwyl0LF7ZXepglopfHbAIsZ1oms252f5G7cfFq
+11HR3JswvVN4otqNAZzYaN7wEBEZwlcD+a/VKoNE0uPVuBS08phhNGjHmidXCOZ
wC11biStwjt1tv1lUNcK0HkkNReuUrUDK1dNKxGGfUHk+Qcka+cQ1ap47lLx06+U
LskPwJKR1tvoHkVMLy4UutX8bIRtXE3WbSOQlV9Q/4/os3tTpVlH5AX47W+2CikV
t3pTmdJy0FubCrHSJ63C
=5H5A
-----END PGP SIGNATURE-----


[-- Attachment #1.2: Type: text/html, Size: 11707 bytes --]

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

[-- Attachment #3: 0xA2966155.asc.sig --]
[-- Type: application/pgp-signature, Size: 639 bytes --]

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

[Luke Dashjr]

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!

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

[Peter Todd]

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

On Thu, Feb 12, 2015 at 10:13:33PM +0000, Luke Dashjr wrote:
> Where is the Specification section?? Does this support arbitrary scripts, or 
> only the simplest CHECKMULTISIG case?

It might be enough to rewrite this BIP to basically say "all pubkeys
executed by all CHECKMULTISIG opcodes will be in the following canonical
order", followed by some explanatory examples of how to apply this
simple rule.

OTOH we don't yet have a standard way of even talking about arbitrary
scripts, so it may very well turn out to be the case that the above rule
is too restrictive in many cases - I certainly would not want to do a
soft-fork to enforce this, or even make it an IsStandard() rule.

-- 
'peter'[:-1]@petertodd.org
000000000000000013cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Ruben de Vries]

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

The idea is more like BIP44/45 to have a 'standard' that software can
comply by and express they do
so that it makes a step towards compatibility between (wallet) software.

On Fri, Feb 13, 2015 at 8:53 AM, Peter Todd <pete@petertodd.org> wrote:

> On Thu, Feb 12, 2015 at 10:13:33PM +0000, Luke Dashjr wrote:
> > Where is the Specification section?? Does this support arbitrary
> scripts, or
> > only the simplest CHECKMULTISIG case?
>
> It might be enough to rewrite this BIP to basically say "all pubkeys
> executed by all CHECKMULTISIG opcodes will be in the following canonical
> order", followed by some explanatory examples of how to apply this
> simple rule.
>
> OTOH we don't yet have a standard way of even talking about arbitrary
> scripts, so it may very well turn out to be the case that the above rule
> is too restrictive in many cases - I certainly would not want to do a
> soft-fork to enforce this, or even make it an IsStandard() rule.
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000013cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1
>



-- 
BlockTrail B.V.
Barbara Strozzilaan 201
1083HN Amsterdam
The Netherlands

Phone: +31 (0)612227277
E-mail: ruben@blocktrail.com
Web: www.blocktrail.com
Github: www.github.com/rubensayshi

BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in
Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01

[-- Attachment #2: Type: text/html, Size: 3174 bytes --]

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

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 1949 bytes --]

A few months back, William Swanson and I had worked on a more general script template format. Unfortunately, other work has prevented us from being able to fully complete it - but here’s the start:

https://docs.google.com/document/d/1nGF6LjGwhzuiJ9AQwKAhN1a1SXvGGHWxoKmDSkiIsPI <https://docs.google.com/document/d/1nGF6LjGwhzuiJ9AQwKAhN1a1SXvGGHWxoKmDSkiIsPI>/

- Eric Lombrozo

> On Feb 12, 2015, at 11:53 PM, Peter Todd <pete@petertodd.org> wrote:
> 
> On Thu, Feb 12, 2015 at 10:13:33PM +0000, Luke Dashjr wrote:
>> Where is the Specification section?? Does this support arbitrary scripts, or
>> only the simplest CHECKMULTISIG case?
> 
> It might be enough to rewrite this BIP to basically say "all pubkeys
> executed by all CHECKMULTISIG opcodes will be in the following canonical
> order", followed by some explanatory examples of how to apply this
> simple rule.
> 
> OTOH we don't yet have a standard way of even talking about arbitrary
> scripts, so it may very well turn out to be the case that the above rule
> is too restrictive in many cases - I certainly would not want to do a
> soft-fork to enforce this, or even make it an IsStandard() rule.
> 
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000013cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #1.2: Type: text/html, Size: 3001 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

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

[Thomas Kerin]

[-- Attachment #1.1: Type: text/plain, Size: 1672 bytes --]


On 12/02/15 22:13, Luke Dashjr wrote:
> Where is the Specification section?? Does this support arbitrary scripts, or 
> only the simplest CHECKMULTISIG case?

The BIP is a process for deriving only the type of scripts you would
encounter doing addmultisigaddress. More complicated scripts would
require more metadata to be shared, but the only case we describe is
when given public keys and the number of signatures required.

You're right, we're missing a Specification. I have tweaked the document
to cover this now.



On 13/02/15 07:53, Peter Todd wrote:
> It might be enough to rewrite this BIP to basically say "all pubkeys
> executed by all CHECKMULTISIG opcodes will be in the following
> canonical order", followed by some explanatory examples of how to
> apply this simple rule. OTOH we don't yet have a standard way of even
> talking about arbitrary scripts, so it may very well turn out to be
> the case that the above rule is too restrictive in many cases - I
> certainly would not want to do a soft-fork to enforce this, or even
> make it an IsStandard() rule.

It would be interesting, but I agree it should not be brought into these
validation rules - just a convention for people to follow for now. I
think it's fair that implementers are free to order them however they
please. But I think there is good reason for wallets to opt in to the
convention and declare this, for ease of recovery, and for
interoperability reasons. 


-- 
Thomas Kerin
------------------------------------------------------------------------

My PGP key can be found here <http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>


[-- Attachment #1.2: Type: text/html, Size: 2356 bytes --]

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

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

[Thomas Kerin]

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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I wonder are there any other blockers or modifications that need to be
made for this to be merged?

Latest version of the document:
https://github.com/afk11/bips/blob/213e8a27a3a2eaaf44f79221a9f9f888af002801/bip-0067.mediawiki



On 13/02/15 23:43, Thomas Kerin wrote:
>
> On 12/02/15 22:13, Luke Dashjr wrote:
>> Where is the Specification section?? Does this support arbitrary
scripts, or
>> only the simplest CHECKMULTISIG case?
>
> The BIP is a process for deriving only the type of scripts you would
encounter doing addmultisigaddress. More complicated scripts would
require more metadata to be shared, but the only case we describe is
when given public keys and the number of signatures required.
>
> You're right, we're missing a Specification. I have tweaked the
document to cover this now.
>
>
>
> On 13/02/15 07:53, Peter Todd wrote:
>> It might be enough to rewrite this BIP to basically say "all pubkeys
executed by all CHECKMULTISIG opcodes will be in the following canonical
order", followed by some explanatory examples of how to apply this
simple rule. OTOH we don't yet have a standard way of even talking about
arbitrary scripts, so it may very well turn out to be the case that the
above rule is too restrictive in many cases - I certainly would not want
to do a soft-fork to enforce this, or even make it an IsStandard() rule.
>
> It would be interesting, but I agree it should not be brought into
these validation rules - just a convention for people to follow for now.
I think it's fair that implementers are free to order them however they
please. But I think there is good reason for wallets to opt in to the
convention and declare this, for ease of recovery, and for
interoperability reasons.
>
>
> --
> Thomas Kerin
> -------------------------
> My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
>
>
>
------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

- -- 
Thomas Kerin
- -------------------------

My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQJ8BAEBCgBmBQJVX2ciXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVlOwP/1w/Omr/6jGyi7spqW22HQ7P
4+lNNzcsWp5/pv8e6YelUOSYiHuh/KxRoFfWL+wF+PNS2EtjRxSsXxg/R2nMft7B
JQLNmIG6zTzVg/lhVObeSslXaia7repZxZ1S4nyEcs8rDVt7kkNnNguFOeONF95O
3usCnrch+QbQacIt9StySAz155u1SuHeSmGmA/fRGLfArndXDdN0fYwE1KGyv5wm
LqZ1PQfmYaCc0TUKRvpDRuc/+KF7q1fDMzuP9mZ3WiPdvTDKCXSRxYfbQYJdxplg
AC0CFiOne+DXgiBdTOIcs9pcp1/6SyZs75Bkpv71AxBCmTlRTuYpsfH7O3VuZBGP
FrN/4BMYnzMbGnNmvZwerUKH59MmzZTAzLSwZlpvj7ZxRks6KOp1CHInFWQlHAXJ
O5c5McvqSdQ0rPHLcQ4DwB00Q1els18NRULjxdsTfLrT32birIXn3M1Hn/Q9d8Sa
N+Y/cfXkojf4rJt75+XwjLyHECwS378ZFC8lfs1m/B3VSQxTtTZWA8905a1IRv/F
nPQ2eaxBrFjm4OatE5lx+I/xmVAQuybG54UdcZGaKVXJbMg3sOslcYg7eA77pmR5
7jRoRU+q7GhiRsUmxSkD+57FfhaMzX7iUl4xe3YK14KUS/pONuv0USC9to8a62kA
gz9kb4pJMEhTtZNv7z9C
=iq37
-----END PGP SIGNATURE-----


[-- Attachment #2: Type: text/html, Size: 5468 bytes --]