1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
Return-Path: <dp@simplexum.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 299A52F
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <dp@simplexum.com>
To: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Message-ID: <20190629093104.52f7a262@simplexum.com>
In-Reply-To: <CAMpN3m+Oa6oPzAmhoioOkuf8__NSPPNoSEMHJwo9PhjXosMwhg@mail.gmail.com>
References: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
<20190627095031.4d5817b8@simplexum.com>
<CAMpN3mKPkCPtYkN-JVku1r217-aBK=Rh3UEhvRPS_Y6DixJ9Dw@mail.gmail.com>
<20190627122916.3b6c2c32@simplexum.com>
<CAMpN3mL8tyP-6-nwn6dorcq7-dad6wYz8_pXinqHhgzUnrr_tg@mail.gmail.com>
<20190627181429.15dda570@simplexum.com>
<20190627202932.1cb4d727@simplexum.com>
<20190629024816.2193363e@simplexum.com>
<CAMpN3m+Oa6oPzAmhoioOkuf8__NSPPNoSEMHJwo9PhjXosMwhg@mail.gmail.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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <junderwood@bitcoinbank.co.jp> 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)
|
