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
|
Return-Path: <junderwood@bitcoinbank.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 649D5BA0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Jun 2019 08:12:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com
[209.85.219.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE71A82F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Jun 2019 08:12:07 +0000 (UTC)
Received: by mail-yb1-f170.google.com with SMTP id k4so6288603ybo.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Jun 2019 01:12:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bitcoinbank.co.jp; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=py7h4d7Q0grB+DOcC+ciX4hwSHbnHVFbTw8i+5KQKHA=;
b=bIM1pa319XftmBTHGSFNQS0oDusL6keg41+S70A0JKxtt0POhrm/NkJe4e48LbGOb/
XKkDIRpJUR5p+Yx1L8EcupaPwN16dAHamHm+3elw0v8XMikyRnObKqgR2BO+ws5PThi9
FO+Ghs0/8grvT/eU0prSfGJrqZ2MCnSZQIXhqQN1rRRREDzLyFi2iSmJx/HmkN3ubNmq
n3kA6WSrDntTSiC5ZOm+LZFd/3/OuhIW+Hhujilw8EwmhtD+6YCgIOm5g4mADgjrivgV
SFU0keb7huxCma4NobQmRrTIPlAOwoXgCqntK1/zravOrY8B35hp6b6RDL5FjXmOpXul
i2iQ==
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=py7h4d7Q0grB+DOcC+ciX4hwSHbnHVFbTw8i+5KQKHA=;
b=R2OG3TY2WFNq3usqF/UIsFGqTM0im8wX/aB4ITye9TAYu1iHJT5dYf3HoZh4OrhSMU
eTEaue0Wuw4FHmaYWKxJLNBrhQqkhh3mMySM/4kayExL7rrmQUJF6WNhPiWvHF9Ry5aF
kWksHseCdta3WSUbCS0+t+9K0P6p643iVYdEfNnddVJdv0tLj8uvd5KFFtTx9WXNXTDe
6L0Ld0Lk504DUOMg9/RCmpb4LfnmZ8pjy0UgWj18Dxa2Xnbnk3nr219rwx6AMLGBgf3e
OTcVkXDi75y5+xkAUHhZe2N8KKj0tcZrSTiWwFAdZ8H+YpLnKRPYrjSaeiAozBUMPuTh
G+zQ==
X-Gm-Message-State: APjAAAWMYODygziVYTD7ixhJdOZxy4Dk6gK4JQOsfZhrAOC+zi383Fjh
2jRROScino04nIEs0+5I0HGBedkiIN1Fa0egI/cdDBs=
X-Google-Smtp-Source: APXvYqw4cUKTQWhQ/QrzzaDlwuV7WnPhM+6v/8Y5gKAcviqZoUwiyzLzZulMN7/LjbDg6pV8cgidrSNwkg/zm2PupAo=
X-Received: by 2002:a25:404:: with SMTP id 4mr1247755ybe.77.1561795926899;
Sat, 29 Jun 2019 01:12:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
<20190627095031.4d5817b8@simplexum.com>
<CAMpN3mKPkCPtYkN-JVku1r217-aBK=Rh3UEhvRPS_Y6DixJ9Dw@mail.gmail.com>
<20190627122916.3b6c2c32@simplexum.com>
<CAMpN3mL8tyP-6-nwn6dorcq7-dad6wYz8_pXinqHhgzUnrr_tg@mail.gmail.com>
<20190627181429.15dda570@simplexum.com>
<20190627202932.1cb4d727@simplexum.com>
<20190629024816.2193363e@simplexum.com>
<CAMpN3m+Oa6oPzAmhoioOkuf8__NSPPNoSEMHJwo9PhjXosMwhg@mail.gmail.com>
<20190629094512.558ce181@simplexum.com>
In-Reply-To: <20190629094512.558ce181@simplexum.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Sat, 29 Jun 2019 17:11:56 +0900
Message-ID: <CAMpN3mLmVwKwMwjjPGV3Z1JjeLmejMLkTN+3+c0Hu3K0-0GjyA@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="0000000000006f5046058c71f395"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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: Sat, 29 Jun 2019 21:07:15 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type:
PSBT_GLOBAL_XPUB_SIGNATURE)
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: Sat, 29 Jun 2019 08:12:08 -0000
--0000000000006f5046058c71f395
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Even if the difference is apparent outside the signed data (in the output).
Signing the data explicitly is more secure.
ie. if some sort of vulnerability / way to break this system for 1-of-1
multisig is found, someone who signed a single sig xpub whitelist will not
be exposed.
2019=E5=B9=B46=E6=9C=8829=E6=97=A5(=E5=9C=9F) 13:43 Dmitry Petukhov <dp@sim=
plexum.com>:
> =D0=92 Sat, 29 Jun 2019 09:19:41 +0900
> Jonathan Underwood <junderwood@bitcoinbank.co.jp> =D0=BF=D0=B8=D1=88=D0=
=B5=D1=82:
>
> > > Other note: you have 'unused' value of 1 for `m` in your scheme, why
> > > not require m=3D1 for single-sig case, and use 0 as indicator that
> > > there are a serlal number following it?
> > >
> >
> > 0x00 is single sig, aka, OP_CHECKSIG
> >
> > 0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG
>
> This informatin is available in per-output redeem/witness script,
> signer will be able to distinguish between multisig/single-sig by
> looking at this script. I think it only need to know the total number
> of keys participating in the signing, and check that this number
> matches the particulars of redeem/witness script.
>
--0000000000006f5046058c71f395
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Even if the difference is apparent outside the signed=
data (in the output). Signing the data explicitly is more secure.<br><br>i=
e. if some sort of vulnerability / way to break this system for 1-of-1 mult=
isig is found, someone who signed a single sig xpub whitelist will not be e=
xposed.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">2019=E5=B9=B46=E6=9C=8829=E6=97=A5(=E5=9C=9F) 13:43 Dmitry Petukhov =
<<a href=3D"mailto:dp@simplexum.com">dp@simplexum.com</a>>:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">=D0=92 Sat, 29 Jun 2019 0=
9:19:41 +0900<br>
Jonathan Underwood <<a href=3D"mailto:junderwood@bitcoinbank.co.jp" targ=
et=3D"_blank">junderwood@bitcoinbank.co.jp</a>> =D0=BF=D0=B8=D1=88=D0=B5=
=D1=82:<br>
<br>
> > Other note: you have 'unused' value of 1 for `m` in your =
scheme, why<br>
> > not require m=3D1 for single-sig case, and use 0 as indicator tha=
t<br>
> > there are a serlal number following it?<br>
> >=C2=A0 <br>
> <br>
> 0x00 is single sig, aka, OP_CHECKSIG<br>
> <br>
> 0x01 is multisig, aka, 1-of-3, 1-of-2 OP_CHECKMULTISIG<br>
<br>
This informatin is available in per-output redeem/witness script,<br>
signer will be able to distinguish between multisig/single-sig by<br>
looking at this script. I think it only need to know the total number<br>
of keys participating in the signing, and check that this number<br>
matches the particulars of redeem/witness script.<br>
</blockquote></div><br></div>
--0000000000006f5046058c71f395--
|
