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 299A52F for ; Sat, 29 Jun 2019 04:29:46 +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 926362C6 for ; Sat, 29 Jun 2019 04:29:45 +0000 (UTC) Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) by mail.ruggedbytes.com (Postfix) with ESMTPS id CF29E2600550; Sat, 29 Jun 2019 04:29:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; s=mail; t=1561782583; bh=sNSqBve/Y7+n0aSJqblV7YsSaH5MCqeobpL9KRwGDcQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Dazle+Y7IXWuuoGBddNknGzbZ12VTDrHzYbUdJgN8R8l+w5a/GiAb3lfBz3si/X+u P33O4ZwOSMEecEQeWG/1sEud/vVL740sTRaNntVsGVSv9QDl5q3jIt4UXPUS+jP5ql 3MH4fyyv0RAmRcLcoVm5Z2VKAHkokxB8T1XOF1rI= Date: Sat, 29 Jun 2019 09:31:04 +0500 From: Dmitry Petukhov To: Jonathan Underwood Message-ID: <20190629093104.52f7a262@simplexum.com> In-Reply-To: References: <20190627095031.4d5817b8@simplexum.com> <20190627122916.3b6c2c32@simplexum.com> <20190627181429.15dda570@simplexum.com> <20190627202932.1cb4d727@simplexum.com> <20190629024816.2193363e@simplexum.com> Organization: simplexum.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Sat, 29 Jun 2019 06:20:23 +0000 Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE) 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: Sat, 29 Jun 2019 04:29:46 -0000 =D0=92 Sat, 29 Jun 2019 09:19:41 +0900 Jonathan Underwood wrote: > Though outside the scope of this BIP, one difficulty of a whitelist > feature would be revocation of signatures. If we pre-sign a > revocation cert and somehow make the wallet blacklist if seen... then > the question is "if your signer has a trustworthy store of state, why > not store the whitelist pubkeys?" In principle, if the hardware wallet can permanently store at least one counter, it can have rich state, stored externally. It would sign a state stored in RAM, and give out the state + signature to the supporting app. The state will include a serial number, corresponding to the internal counter stored in the hardware wallet. Next time, the app will give the signed state to the hardware wallet along with transaction data. Hardware wallet checks its signature over the state, checks that serial matches its internal counter, uses and modifies the state, then updates the internal counter and the serial number of the state, and gives out the signed new state to the app. If the app loses the state blob, though, there should be some mechanism to securely override the hw wallet internal state. This approach might have other limitations, as processing and storing big enough state in the RAM of a resource-constrained device might present a problem in itself. The 'add serial to xpub-package' idea is in the same vein: you can store this xpub-package serial inside the hw wallet directly, or inside its 'external rich state blob', but it can take only one byte (unlikely to need more than 255 xpub-package 'revocations', at that point you are probably OK to change your cold keys already)