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
Precedence: list


--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--