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 DC0FEE2C for ; Tue, 7 May 2019 13:39:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52B79FD for ; Tue, 7 May 2019 13:39:37 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id 8070826003D2; Tue, 7 May 2019 13:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1557236375; bh=wf+k5A6nNOK1Psm+PzvaMZLErAqcFAs4ItwB7o9sIaI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ai5TdeTic5eOa4d+x30IgbJ2zR5ZhRZk/+5j7im5pJAzsT/d8KEGUuTB3YIJb2Qou BMH9V45SAIxxsAeYXDjqYS2q92b71MsHqxl1+7pCgKVN/866aVQZVWk7S0p8bQmsG3 PFy3J4xaVM/ZXM4dxUa99cBeb+g6qXE15/9C8LJ0= Date: Tue, 7 May 2019 18:40:34 +0500 From: Dmitry Petukhov To: Stepan Snigirev via bitcoin-dev Message-ID: <20190507184034.0a72a9c7@simplexum.com> In-Reply-To: References: <20190503132945.GR810@coinkite.com> Organization: simplexum.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 07 May 2019 19:16:56 +0000 Cc: Stepan Snigirev , Peter Gray Subject: Re: [bitcoin-dev] Adding xpub field to PSBT to make multisig more secure X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 13:39:38 -0000 > > Even with this additions to the PSBT format, I think PSBT-signing > > devices still need to store the xpubs of their co-signers. It's not > > possible to safely show an incoming address to the user without a > > full understanding of the other keys in a "multisig wallet". Also, > > it represents data that should not change between PSBT instances > > (ie. tomorrow's co-signers should match today's). > > I would like to keep hardware wallets state-less, otherwise wiping and > recovering them would be problematic. > At the setup phase the user can verify a multisignature address (or > xpub) on the screens of all devices, > after that we just need to verify that xpubs in the inputs and in the > change output are the same. At the setup phase, hardware wallet can sign a message that consists of xpubs of participants, and some auxiliary text. It can use the key derived from the master key, with path chosen specifically for this purpose. Hardware wallet then gives out this signature to the software. The software will store the message and the signature (or maybe it can take xpubs from PSBT), and will send this 'trusted-xpub-package' to hardware wallet along with the transaction. Hardware wallet can then verify that the message is indeed signed by the key for that purpose, and then can mark the ouputs that use the pubkeys derived from 'verified' xpubs as 'trusted' outputs. It can also display the auxiliary text along with the information about the 'trusted' output. This way, hardware wallet does not need to store anything extra besides the master key. This would allow to distinguish the trusted output even if the inputs are not all derived from the same set of xpubs, that could happen in more complex scenarios (batching, key rotation, etc.), and can possibly be used to have several different types of 'trusted' outputs. If the user loses the signature for trusted-xpub-package, the signature can be re-created again - but maybe the procedure should be more involved than ordinary signing, because creating creating such 'trusted-xpub-package' with malicious keys can enable attackers to bypass these checks.