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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Return-Path: <snigirev.stepan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 54A35D90
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 May 2019 10:43:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com
[209.85.222.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 615BC8D6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 May 2019 09:23:56 +0000 (UTC)
Received: by mail-qk1-f181.google.com with SMTP id k189so572634qkc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 07 May 2019 02:23:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=JTzL6DScP4RgcsbbVLYTXVQNfRya2xPmHFvchaaVId0=;
b=lzwNZyV0ZfPV4UOJjB4oRVisKyQhOMdst6SJmQV3WGrx1qEEySEj6tZFnL9ncpyXgc
JN+VxgdmwpjAaLHAyFy8p9qoNq8UjvH8wocJH5hiphBlBAksQoLVPbWT3c83vPg68SXF
PO+1LEMr91ZAl/W4PiXM1vI0UBTQuy6BefHt7DeZdX1rt88IsXevdCYH7EFE/CEOc5J5
pqwutvgnHuhguoliNekHZ5qelU1jv3EVy49K7sxQjOSDwRj4umpE4THUZemX34BUAlCf
E7UedgRJ6v28DJpQsVsKKO/NOWGQgrvIwy/MWtk/npqqvqAHtcrL6Gj9TOz/STrGCFZO
6opA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=JTzL6DScP4RgcsbbVLYTXVQNfRya2xPmHFvchaaVId0=;
b=TpEnIrYvSrIzk+c9jqkPQQHnujBOsyASM7mRLsVSnH+BbWgt0sWfPyvSaHqfD2CqMv
dKAQ/qg83q3CFLJb736bDiiIMBq/gy/NJ3HFTA9dYyUt2WDdxqtZcRtoplMBmzGfCsjv
pjB7MZ6Y189lVTWURCM+bBtnDmMTcJB7oWss/A8sEVPtq9CojWdBT4yLztDapyD8wXel
pYg9mbEuyqCceJk6j2WqDXHoNRebFupMCDF2qk9mOUqZcekcivzjfIu5IUS1Rxf/o8Pf
2w/TEqhY1U3eDaN7bs88XQD0okIwPnCz5qpRaMl7JevDnPvGfk2Bp1E4SqMhIlTlILXn
hwkg==
X-Gm-Message-State: APjAAAVjYMGAdv1qMZE8tW7JbCGJI+6so+TdB1e7ZBc+Ll7McWi0P+eV
Yae5Y8iMC1XPARctQajkf1zAxHia+nJI8FGxACw=
X-Google-Smtp-Source: APXvYqwnmnKXvLzQ8cEWqEn4OU0gxGLPu9rlRlNqURrcN4IVgixqYHnNFdedu2vOVL3u7CdBRAgJZeLQzR3JQkktnpU=
X-Received: by 2002:a37:4287:: with SMTP id
p129mr24715246qka.268.1557221035258;
Tue, 07 May 2019 02:23:55 -0700 (PDT)
MIME-Version: 1.0
References: <CACL8y1v9fpZ+gWLVHMx-bGUCaSd0=0ecHU-u4FF=LnhT7s1zTg@mail.gmail.com>
<20190503132945.GR810@coinkite.com>
In-Reply-To: <20190503132945.GR810@coinkite.com>
From: Stepan Snigirev <snigirev.stepan@gmail.com>
Date: Tue, 7 May 2019 11:23:44 +0200
Message-ID: <CACL8y1tesev2OLrkfYfvmkgbR2xuk-0JPqdmYGtrUcser9GPfg@mail.gmail.com>
To: Peter Gray <peter@coinkite.com>
Content-Type: multipart/alternative; boundary="000000000000a4b950058848c6a7"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 07 May 2019 12:18:24 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Adding xpub field to PSBT to make multisig more
secure
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 07 May 2019 10:43:31 -0000
--000000000000a4b950058848c6a7
Content-Type: text/plain; charset="UTF-8"
> I'd rather see the xpubs shared in the global section of the file,
> with the restriction that they must/should only include the hardened
> prefix of the path. The existing bip32 derivation path included in
> individual inputs and outputs be merged in as needed.
> After all in a typical PSBT, we would expect the same master keys
> to be used on all inputs, and at least one output, and there might
> be as many as 20 co-signers. No need to repeat all that information.
I agree that it makes sense to put xpubs to the global scope.
But I am not sure that restricting xpubs to have only hardened derivation
is necessary.
People may want to share non-hardened xpubs with co-signers and keep parent
xpub on there watch-only wallet.
For example, in bip45 cosigner_index is not hardened, and sharing top level
xpub is not necessary.
> Even with this additions to the PSBT format, I think PSBT-signing
> devices still need to store the xpubs of their co-signers. It's not
> possible to safely show an incoming address to the user without a
> full understanding of the other keys in a "multisig wallet". Also,
> it represents data that should not change between PSBT instances
> (ie. tomorrow's co-signers should match today's).
I would like to keep hardware wallets state-less, otherwise wiping and
recovering them would be problematic.
At the setup phase the user can verify a multisignature address (or xpub)
on the screens of all devices,
after that we just need to verify that xpubs in the inputs and in the
change output are the same.
Andrew, regarding your question:
> Just for clairty, by xpub, do you mean the extended serialization format
> defined in BIP 32 or the Base58 check encoded string of that
serialization?
As PSBT is a binary format I think it makes sense to use extension
serialization format without any encodings.
I am not sure if we need the whole xpub or keeping chain_code and
public_key is enough, but I would suggest to keep other data
just in case. For example, keeping prefix that defines if the key is used
for testnet or mainnet may be useful.
Best regards,
Stepan
--000000000000a4b950058848c6a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div>> I'd rather see the xpubs sh=
ared in the global section of the file,<br></div>> with the restriction =
that they must/should only include the hardened<br>> prefix of the path.=
The existing bip32 derivation path included in<br>> individual inputs a=
nd outputs be merged in as needed.<div>> After all in a typical PSBT, we=
would expect the same master keys<br>> to be used on all inputs, and at=
least one output, and there might<br>> be as many as 20 co-signers. No =
need to repeat all that information.<br></div><div><br></div><div>I agree t=
hat it makes sense to put xpubs to the global scope.</div><div>But I am not=
sure that restricting xpubs to have only hardened derivation is necessary.=
</div><div>People may want to share non-hardened xpubs with co-signers and =
keep parent xpub on there watch-only wallet.</div><div>For example, in bip4=
5 cosigner_index is not hardened, and sharing top level xpub is not necessa=
ry.</div><div><br>> Even with this additions to the PSBT format, I think=
PSBT-signing<br>> devices still need to store the xpubs of their co-sig=
ners. It's not<br>> possible to safely show an incoming address to t=
he user without a<br>> full understanding of the other keys in a "m=
ultisig wallet". Also,<br>> it represents data that should not chan=
ge between PSBT instances<br>> (ie. tomorrow's co-signers should mat=
ch today's).</div><div><br></div><div>I would like to keep hardware wal=
lets state-less, otherwise wiping=C2=A0and recovering=C2=A0them would be pr=
oblematic.</div><div>At the setup phase the user can verify a multisignatur=
e address (or xpub) on the screens of all devices,=C2=A0</div><div>after th=
at we just need to verify that xpubs in the inputs and in the change output=
are the same.</div><div><br>Andrew, regarding your question:=C2=A0</div><d=
iv><div>> Just for clairty, by xpub, do you mean the extended serializat=
ion format=C2=A0</div><div>> defined in BIP 32 or the Base58 check encod=
ed string of that serialization?</div></div><div><br></div><div>As PSBT is =
a binary format I think it makes sense to use extension serialization forma=
t without any encodings.=C2=A0</div><div>I am not sure if we need the whole=
xpub or keeping chain_code and public_key is enough, but I would suggest t=
o keep other data</div><div>just in case. For example, keeping prefix that =
defines if the key is used for testnet or mainnet may be useful.</div><div>=
<br></div><div>Best regards,</div><div>Stepan</div></div></div>
--000000000000a4b950058848c6a7--
|
