From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D59471D6A for ; Sun, 4 Oct 2015 17:25:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7DD242D2 for ; Sun, 4 Oct 2015 17:25:07 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so91142571wic.0 for ; Sun, 04 Oct 2015 10:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZCT4yG6DlNVHspWLZ8Os9Trn2WWJSIxkS+rNhk81RBo=; b=U1sm7HtaTvL4rGlrm1WLe0N+Ncu1Vyn+5MMQARPmMYTedUD483QDtS8yv9PTJqkH72 j7ZuQYC+oGjD6u8NcqClPxdIOGWYsg11ZHf/NgiOWpq8c4ipNsD9hQaLYXuxorptRH5r V1gRlzQNWydtpUJBAbEhd6Co6CBqBY6cv1bYofvqLNSV/igWB8OYrzs92MuQ4cguq/Ju LNn6Zm/AG3OiTQQx8DHaG/xYkOTUxoeWRoFm7ShMhGjbNVcYMW7i6mtpRiSCyfHhyNzC 6mIZOhcGsMpKv/V7y0PSfEG17SMl+NgqzmKZCyn4A3WpbWAaA5P1AotOZew4AmjXEGBg 5mSQ== X-Received: by 10.194.171.3 with SMTP id aq3mr26055881wjc.54.1443979505890; Sun, 04 Oct 2015 10:25:05 -0700 (PDT) Received: from [192.168.2.12] ([82.223.16.128]) by smtp.gmail.com with ESMTPSA id bf8sm22539695wjc.22.2015.10.04.10.25.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Oct 2015 10:25:04 -0700 (PDT) Message-ID: <561160EB.30505@gmail.com> Date: Sun, 04 Oct 2015 18:24:59 +0100 From: Thomas Kerin 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: <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 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] [Bitcoin-development] New BIP32 structure for P2SH multisig wallets [BIP-45] X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 17:25:08 -0000 -----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: -----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-----