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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2EDF8499
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 19:27:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com
[209.85.192.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9BCF8204
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 19:27:23 +0000 (UTC)
Received: by mail-pf0-f177.google.com with SMTP id l188so1951172pfc.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 01 Oct 2017 12:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=x/R1OyVGX9++bvVhAXTAbbjznB19Qk2r82Kihd8rEW8=;
b=wjAf0Vu2ZdvM0tg6prFs+/rAi0qNyxWC7wASiDnuQUhWUjS7cCd5TpC9njDR7a1h/Q
jU7XMG7djjxzddG7ZksygTfGiGLomQRuitXm4LnzDqhLYW7vfQq+sImY8izyOGsR6CNz
KItydwx592KJPX1LdefySG79tENSTSU6YMoM7oOXXsET93h91akaDfdWA7l+1Y+ozsQu
MHsWxtn006m4OLHmNwdmM4OR/zh5R1tuV/SlYC0WR7Axd1YN0RHQ6IKOZs7TYNj24IYP
RWltIksxdBQRnUOHdMQ/7k5oGRFvREvJ1ETIlsVx8vH+2Uw7Zlp2MgKLZndT38zpkIEe
fy5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=x/R1OyVGX9++bvVhAXTAbbjznB19Qk2r82Kihd8rEW8=;
b=gHAZpvtOUK97Pyau5Rw/fxZ0Nu4NRVe7jCitDwrlpC6JdNvxOrltCokOPZUE51d+WV
V1fi8AlqxzeFJa/EXwjo+pQIvkyrdheBOubMsxn6Xt7OwniHvVM3Uh3f316dcGVQiuNq
p4IrWht9rW5g/0xTO6u2D4L4NdcC1Xys2jwe2fddtHmrhEN4w5jfxKUjWysSXVXZVcy9
iBlJ5t60g8d/ef3gYxLdE1M4NszcrMnmD521LStLqsHUea2saQ/O4VsfsofzaKMAJ7LD
Ml0A08bhpaoCNA+N9YugCryiGvHrCmpGb1w/HxDodW0mKFIl/Jfm2ZgoXdqJzB1TgdxZ
D5Uw==
X-Gm-Message-State: AHPjjUglm/gIREqf3ybWn5RX5CS8nV2+UV5miTwhibdvYXYjSSBHTPhQ
6weDcPNcm+TILgon73Y8kWl50EmshFE=
X-Google-Smtp-Source: AOwi7QBcNZmZxUUi1G4gW2kysfopfdqmDb34OMDfcOrn49s+akTA/jSnuUeT/A8Ztk61TrwBLS5FpA==
X-Received: by 10.99.121.77 with SMTP id u74mr10482062pgc.180.1506886043141;
Sun, 01 Oct 2017 12:27:23 -0700 (PDT)
Received: from ?IPv6:2601:646:8080:1291:39e7:3724:6f96:6f4b?
([2601:646:8080:1291:39e7:3724:6f96:6f4b])
by smtp.gmail.com with ESMTPSA id
77sm14623980pfi.103.2017.10.01.12.27.21
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 01 Oct 2017 12:27:22 -0700 (PDT)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
From: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <CAMZUoK=1fZUeKkA6V2pFwqj-Fd-YnZD4sffP9yc0Y7vv8-XvhQ@mail.gmail.com>
Date: Sun, 1 Oct 2017 12:27:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <460EDF1F-2BFD-4DBE-A921-73469C2EA9B9@friedenbach.org>
References: <201710010113.30518.luke@dashjr.org>
<5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org>
<201710010247.42180.luke@dashjr.org>
<D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
<CAMZUoK=1fZUeKkA6V2pFwqj-Fd-YnZD4sffP9yc0Y7vv8-XvhQ@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>
X-Mailer: Apple Mail (2.3445.1.6)
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
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: Sun, 01 Oct 2017 19:27:24 -0000
> On Oct 1, 2017, at 12:05 PM, Russell O'Connor =
<roconnor@blockstream.io> wrote:
>=20
> Given the proposed fixed signature size, It seems better to me that we =
create a SIGHASH_WITNESS_WEIGHT flag as opposed to =
SIGHASH_WITNESS_DEPTH.
For what benefit? If your script actually uses all the items on the =
stack, and if your script is not written in such a way as to allow =
malleability (which cannot be prevented in general), then they=E2=80=99re =
equivalent. Using weight instead of depth only needlessly restricts =
other parties to select a witness size up-front.
And to be clear, signing witness weight doesn=E2=80=99t mean the witness =
is not malleable. The signer could sign again with a different ECDSA =
nonce. Or if the signer is signing from a 2-of-3 wallet, a common =
scenario I hope, there are 3 possible key combinations that could be =
used. If using MBV, a 3-element tree is inherently unbalanced and the =
common use case can have a smaller proof size.
Witnesses are not 3rd party malleable and we will maintain that property =
going forward with future opcodes.
> Mark, you seem to be arguing that in general we still want weight =
malleability even with witness depth fixed, but I don't understand in =
what scenario we would want that.
Any time all parties are not online at the same time in an interactive =
signing protocol, or for which individual parties have to reconfigure =
their signing choices due to failures. We should not restrict our script =
signature system to such a degree that it becomes difficult to create =
realistic signing setups for people using best practices (multi-key, =
2FA, etc.) to sign. If I am a participant in a signing protocol, it =
would be layer violating to treat me as anything other than a black box, =
such that internal errors and timeouts in my signing setup don=E2=80=99t =
propagate upwards to the multi-party protocol.
For example, I should be able to try to 2FA sign, and if that fails go =
fetch my backup key and sign with that. But because it=E2=80=99s my =
infrequently used backup key, it might be placed deeper in the key tree =
and therefore signatures using it are larger. All the other signers need =
care is that slot #3 in the witness is where my Merkle proof goes. They =
shouldn=E2=80=99t have to restart and resign because my proof was a =
little larger than anticipated =E2=80=94 and maybe they can=E2=80=99t =
resign because double-spend protections!
|
