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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
Return-Path: <dave@dtrt.org>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D811FC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 12:54:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id C3A7C8715A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 12:54:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ddfVlBUKmUWa
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 12:54:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by fraxinus.osuosl.org (Postfix) with ESMTPS id C68F687154
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 12:54:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1jUrf6-0001pL-0F; Sat, 02 May 2020 08:54:32 -0400
Date: Sat, 2 May 2020 08:53:12 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Andrew Kozlik <andrew.kozlik@satoshilabs.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200502125312.y7y654uc4zdjh7m7@ganymede>
References: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="6v2lz22qxs5olpkq"
Content-Disposition: inline
In-Reply-To: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the
signature message
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 02 May 2020 12:54:36 -0000
--6v2lz22qxs5olpkq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Apr 29, 2020 at 04:57:46PM +0200, Andrew Kozlik via bitcoin-dev wrote:
> In order to ascertain non-ownership of an input which is claimed to be
> external, the wallet needs the scriptPubKey of the previous output spent by
> this input.
A wallet can easily check whether a scriptPubKey contais a specific
pubkey (as in P2PK/P2TR), but I think it's impractical for most wallets
to check whether a scriptPubKey contains any of the possible ~two
billion keys available in a specific BIP32 derivation path (and many
wallets natively support multiple paths).
It would seem to me that checking a list of scriptPubKeys for wallet
matches would require obtaining the BIP32 derivation paths for the
corresponding keys, which would have to be provided by a trusted data
source. If you trust that source, you could just trust them to tell you
that none of the other inputs belong to your wallet.
Alternatively, there's the scheme described in the email you linked by
Greg Saunders (with the scheme co-attributed to Andrew Poelstra), which
seems reasonable to me.[1] It's only downside (AFAICT) is that it
requires an extra one-way communication from a signing device to a
coordinator. For a true offline signer, that can be annoying, but for
an automated hardware wallet participating in coinjoins or LN, that
doesn't seem too burdensome to me.
-Dave
[1] The scheme could be trivially tweaked to be compatible with BIP322
generic signed messages, which is something that could become widely
adopted (I hope) and so make supporting the scheme easier.
--6v2lz22qxs5olpkq
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl6tbTgACgkQ2dtBqWwi
adMbDw//ZUVp7LfNFADyrIc2MjB9kzwdW2kL9ZWJdJuoFO6HWLZLs3TAyX6I/zob
70MvEv5ysi5pp6MNwcErJ+GBlhbLtqudR0SwQegMgeEVBvqKqighfL88TQcZZPnw
FLDBpAFI31MTX+BzISI+6F2J5ituyOrDgooVfx+39MNabDRr+/nRRrIC64CEZSwa
wPvaF4hUQmsd/O3IuX1lJQyGO0QZviOGP9C8emf3gFWU7cRN9tq+g37UQe8QwW8m
kr++oSrHh620iNAO+8kvj+FOGirN8pRo32YNui5Gni0UYE6aiDeeX2pPs7zH0/iO
WdznDpUvBavQsko6umohKe0paQn0MIFuBtegxaKfLfM+UN4i06ZNu35fRzAU3O7V
qQKj+H4IZhdwewOGdzShZeag7kedudOqL84/8L+gK/ceVuh2uyXBGO4t3XQlYHV9
b/JoToaACRFXc3BTu6ghAtfRAw4Ywtk4iQ8O+pdOWQSDo7jexUONziRMgqPbrPi5
HNKrZRXnFnKtn0DgyYBculxd2U2++QPpATHtfNXkMLEEWHOmeYSMCduh/AwtWm7V
KmwpfYN4q9yj5KHUDSIvX958v9zl4GElxF/oAOX72iTJvnTqQnjn4w680w1H21Gk
LrWc8/mbogOXhQ5dVG1zHDZdHwmraov815Bkia3aNbt6zcYYmiA=
=ycko
-----END PGP SIGNATURE-----
--6v2lz22qxs5olpkq--
|
