From: "David A. Harding" <dave@dtrt•org>
To: Andrew Kozlik <andrew.kozlik@satoshilabs•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message
Date: Sat, 2 May 2020 08:53:12 -0400 [thread overview]
Message-ID: <20200502125312.y7y654uc4zdjh7m7@ganymede> (raw)
In-Reply-To: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-05-02 12:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 14:57 Andrew Kozlik
2020-05-01 6:57 ` Jeremy
2020-05-01 8:48 ` Andrew Kozlik
2020-05-01 12:23 ` Russell O'Connor
2020-05-01 12:25 ` Greg Sanders
2020-05-02 4:35 ` Jeremy
2020-05-02 14:26 ` Anthony Towns
2020-05-02 14:43 ` Russell O'Connor
2020-05-02 21:15 ` Russell O'Connor
2020-05-04 15:48 ` Andrew Kozlik
2020-05-02 12:53 ` David A. Harding [this message]
2020-05-05 10:20 ` Jonas Nick
2020-05-11 22:12 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200502125312.y7y654uc4zdjh7m7@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=andrew.kozlik@satoshilabs$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox