From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)
Date: Thu, 27 Jun 2019 11:11:23 +0900 [thread overview]
Message-ID: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]
Hello all,
Just wanted to pick your brains about an idea for PSBT extension.
One problem we try to solve with cold -> warm and warm -> hot sends for our
exchange wallet is "How do I know that the address I am sending to is not a
hacker's address that was swapped in between unsigned tx creation and first
signature?"
We have a proprietary JSON based encoding system which we are looking to
move towards PSBT, but PSBT is missing this key functionality.
BIP32_DERIVATION does allow us to verify the address is from a certain
XPUB, but, for example, it can not allow us to verify a signature of that
xpub.
I have made a rough draft of the proposed key value specification.
https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
The signing key path used in the spec is just randomly chosen 31 x 4 bits
shown as numbers with hardened paths.
Since this issue seems similar to the change address issue, I started from
that as a base. With the HW wallet case, I can verify the xpub by just
deriving it locally and comparing equality, however, in our case, we need
to verify an xpub that we do not have access to via derivation from our
cold key(s) (since we don't want to import our warm private key into our
cold signer)
So the flow would be:
1. Securely verify the xpub of the warm / hot wallet.
2. Using the airgap signing tool, sign the xpub with all cold keys.
3. Upload the signature/xpub pairs to the online unsigned transaction
generator.
4. Include one keyval pair per coldkey/xpub pairing.
5. When offline signing, if the wallet detects there is a global keyval
XPUB_SIGNATURE with its pubkey in the key, it must verify that all outputs
have BIP32_DERIVATION and that it can verify the outputs through the
derivation, to the xpub, and to the signature.
In my attempt to fitting this into PSBT, I am slightly altering our current
system, so don't take this as an indication 100% of how we work in the
backend.
However, I would like to hear any feedback on this proposal.
Thanks,
Jonathan
--
-----------------
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-----------------
暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
[-- Attachment #2: Type: text/html, Size: 3000 bytes --]
next reply other threads:[~2019-06-27 2:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 2:11 Jonathan Underwood [this message]
[not found] ` <20190627095031.4d5817b8@simplexum.com>
2019-06-27 5:07 ` [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE) Jonathan Underwood
[not found] ` <20190627122916.3b6c2c32@simplexum.com>
2019-06-27 8:16 ` Jonathan Underwood
[not found] ` <20190627134628.4d131264@simplexum.com>
[not found] ` <CAMpN3m+LiSW=kRCQio+C_2To66o_SEq-d_0Z122j+BUxvh=LDQ@mail.gmail.com>
2019-06-27 8:59 ` Jonathan Underwood
[not found] ` <20190627142120.2c24fddb@simplexum.com>
2019-06-27 9:32 ` Jonathan Underwood
2019-06-27 15:07 ` Peter D. Gray
2019-06-28 2:44 ` Jonathan Underwood
2019-06-28 14:37 ` Peter D. Gray
2019-06-28 15:00 ` Jonathan Underwood
[not found] ` <20190627144852.52c6d9e1@simplexum.com>
2019-06-27 9:52 ` Jonathan Underwood
[not found] ` <20190627181429.15dda570@simplexum.com>
2019-06-27 15:29 ` Dmitry Petukhov
2019-06-28 21:48 ` Dmitry Petukhov
2019-06-29 0:19 ` Jonathan Underwood
2019-06-29 4:31 ` Dmitry Petukhov
2019-06-29 4:46 ` Dmitry Petukhov
[not found] ` <20190629094512.558ce181@simplexum.com>
2019-06-29 8:11 ` Jonathan Underwood
2019-07-23 5:03 ` Jonathan Underwood
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='CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com' \
--to=junderwood@bitcoinbank.co.jp \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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