public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jonathan Underwood <junderwood@bitcoinbank•co.jp>
To: Peter Gray <peter@coinkite•com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type: PSBT_GLOBAL_XPUB_SIGNATURE)
Date: Fri, 28 Jun 2019 11:44:15 +0900	[thread overview]
Message-ID: <CAMpN3mKyKjSPs2SgC0pUbFMNXFZt7UOu4ktnbfBSDmLrDbafFA@mail.gmail.com> (raw)
In-Reply-To: <20190627150745.GA1897@coinkite.com>

[-- Attachment #1: Type: text/plain, Size: 2795 bytes --]

Hi Peter,

tl;dr The problem this solves is "How can a signer verify an address with
HD changing the address every time?"

As an aside: (This is sort of explaining the current PR for the 0x01 global
field (separate from mine))
The problem is more easily understood with change addresses: If someone can
alter my PSBT before signing, they could replace my change address with
their address, and my signer would not know unless the signer just guesses
all the path sets it knows, then derives thousands of change addresses and
searches (most likely a signer is offline, so gap limit doesn't work since
we can't tell which change addresses have tx history. So the 0x01 global
tag will tell the signer "here's how you get from your master private key
to the xpub used in the change output's output BIP32_DERIVATION tag... you
can then derive the same key and check it is yours before signing."

Back to my proposal, this problem extends across wallets, since,
for example, if I want to send from my cold wallet to my warm wallet, I
don't want to give my cold signer my warm master key just so it can derive
and check the key. That's what signatures are for. So this proposal says "A
signer can be built to only sign if it sees a signature that itself has
signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
outputs, and if the output doesn't match it will reject and not sign"

This creates a sort of "chain of trust" for the wallet.

Currently the best way to prevent this (hacker swapping the send to
address) without using signatures is to reuse the same address every time
you want to send to the warm wallet, since after a few times, the signers
(people) will be able to remember the address.

This is a huge HD drawback for high security requirement environments.
Having this data in the PSBT standard will allow Trezor etc. to create an
enforceable whitelist feature.

Let me know if you have feedback on the details.

Thanks,
Jon

2019年6月28日(金) 0:07 Peter D. Gray <peter@coinkite•com>:

> I haven't studied the new proposal in depth, but my first impression is:
>
> Wouldn't it just be easier and better to just sign the entire "outputs"
> section of the PSBT?
>
> The signature would cover every byte, and therefore would cover any
> future BIP additions to the outputs area, and also help non-multisig
> cases today.
>
> ---
> Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG:
> A3A31BAD 5A2A5B10
>
>

-- 
-----------------
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3

[-- Attachment #2: Type: text/html, Size: 3570 bytes --]

  reply	other threads:[~2019-06-28  2:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27  2:11 Jonathan Underwood
     [not found] ` <20190627095031.4d5817b8@simplexum.com>
2019-06-27  5:07   ` 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 [this message]
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=CAMpN3mKyKjSPs2SgC0pUbFMNXFZt7UOu4ktnbfBSDmLrDbafFA@mail.gmail.com \
    --to=junderwood@bitcoinbank$(echo .)co.jp \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=peter@coinkite$(echo .)com \
    /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