Message-ID: <561160EB.30505@gmail.com>
Date: Sun, 04 Oct 2015 18:24:59 +0100
From: Thomas Kerin <thomas.kerin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org, root@haskoin.com
References: <CABQSq2Q98K5zbUbQAqSE4OYez2QuOaWTt+9n5iZmSR2boynf_Q@mail.gmail.com>	<560FCD30.9020902@haskoin.com>
	<5611432F.5070209@haskoin.com>
In-Reply-To: <5611432F.5070209@haskoin.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] [Bitcoin-development] New BIP32 structure for
 P2SH multisig wallets [BIP-45]
Precedence: list


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

Hi Jean Pierre,

This is a problem I've considered before, though I have to say I prefer
your solution.

The problem is, how can a person who restores his wallet from just a
seed restore
all his multi-signature addresses with other parties?

Your proposal is nice because all participants are equal, and it
minimalizes the data
required for recovery because it's deterministic, and the (extended)
public key is the first
piece of metadata you'll ask for from others.. Let it be the only thing
we need!

Regards amending BIP45 - BIP's are not amended after the fact, however
bad it may be
in retrospect. It might be best to write a BIP specifying a
"pseudorandom & deterministic
path generation for HD/multi-signature accounts"

TK

On 04/10/15 16:18, Jean-Pierre Rupp via bitcoin-dev wrote:
> I have a possible solution:
>
> Take all public keys encoded in the purpose-specific extended public
> keys (m/45') of all cosigners and sort them lexicographically, according
> to BIP-45.  Serialize this information and calculate its HASH160
> (RIPEMD160 ∘ HASH256).  Split the output in five 32-bit chunks, setting
> the MSB on all of them to 0. Use these 32-bit chunks to build a
> derivation path from the purpose-specific extended public keys.  Treat
> this derivation path as if it was the purpose-specific extended public
> key in BIP-45.
>
> This scheme will avoid public key sharing, and as long as you share your
> purpose-specific extended public key only with your cosigners, it should
> be relatively hard for a passive observer to link activity between
> different cosigning accounts.
>
> On 03/10/15 13:42, Jean-Pierre Rupp via bitcoin-dev wrote:
>> Hello,
>>
>> I have been reviewing BIP-45 today.  There is a privacy problem with it
>> that should at least be mentioned in the document.
>>
>> When using the same extended public key for all multisig activity, and
>> dealing with different cosigners in separate multisig accounts, reuse of
>> the same set of public keys means that all cosigners from all accounts
>> will be able to monitor multisig activity from every other cosigner, in
>> every other account.
>>
>> Besides privacy considerations, HD wallet's non-reuse of public keys
>> provide some defence against wallets that do not implement deterministic
>> signing, and use poor entropy for signature nonces.
>>
>> Unless users are expected to establish a single cosigning account, this
>> scheme will result in reuse of public keys, and degradation of privacy.
>>
>> I understand that for convenience it is useful to have a single extended
>> public key that can be handed to every cosigner.  This makes setting up
>> accounts or recovering from data loss a easier.
>>
>> I suggest that privacy & potential security degradation due to increased
>> public key reuse in the case of users with multiple multisig accounts
>> should get a mention in the BIP-45 document.
>>
>> Greetings
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

- -- 
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWEWDlAAoJEAiDZR291eTlFAkQALgiiKX+VzLOwLK13S0EcE0v
RZeC8hqS5AEi/wpOYC2H0TFaHhDqDgy7Pt7nTt/vfOr9QFbJm076I/iFIhLPPAWf
rRg5kzL6ebOyX1NLmALcNgE9L+Jwz09kdzLUj+xZesJfu1AiSMgND38vFq4CmRfg
YSnWI4iMSP3OoMO5Akjq7m9Ww/lENPDmxTrz2ET9KwKPEkjrdt3c0ipQcs+/vGuU
RfRCUwxcdu/0nl5JhltxMV6wUMjdJ3AGbamWZpL+vA+jT5paOd4ORjc64huQGtFQ
W7l8ynbbVqtXlYYs9mXCMm70316sdo5ZpOXzQmplwtuHWVYt9ssS1aLkBoLYCBtU
i95Ki79S2ooeIjDEqI6FKpgVnLTmUbhudg/vk7eA0+RoNh3SBEHV2HmZ5yTBNtjk
P2a2tRmrbe3CmrdogbJzaweZenzoR82PziF7DAb/2JqtccPSdTW/GrAGyCoe0O5B
PId/iELHKpQepvybp+5PI6q2Atgzut4ze+a2vBiXjbiU3j0sX0XWg5fu9R9Ea1Bw
5+BY71GSa20OTDYEsp5esrl5/AUFj4ivB2OWFok77nGi2rTK+rKL3qMvbmYjAKUV
rWN4m6r8pU2hdhBCEJkXjg57whiMYn5w7ILlrbK5lLEu5qo0txoRtBPaid+y4mkK
moZU0LtvSQSX6ZaojQ/v
=Vs6z
-----END PGP SIGNATURE-----