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
|
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 BE198102A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Jan 2018 12:40:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 659D1A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Jan 2018 12:40:36 +0000 (UTC)
Received: by mail-pg0-f50.google.com with SMTP id z20so5621965pgv.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 09 Jan 2018 04:40:36 -0800 (PST)
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=U3bD0coz2LWr7GuQTb9pdDHQpBBYQn8YNn39DIKQejU=;
b=P+Pss+Pq0mcf+pncjRr28WZ3BuFcEv86INI/GzxtbxmfidpS6ld4voJFnm9qnvpD9R
CQagCHBQMxf/V+kxSivj+o4FewQZzzMGmjuBIw4iPWeqeyidG5wZo9gzOp8XUwh/Eua6
dTWsOfX08VIVGpJ76TQeqlMqZ9knMKXSvqcZMaRNiOv/sqXmroyauVPKM1HIdG23XaR3
zrrrV491QahGX3hWAz1oKRT4rnI1+ZAco3fczLjAXHkXdThaBl0RSLsii8gk6Y9rCMuJ
1Gm9+apeb2JP3bWPHFh8zpBrg5tsXQhwEv/RfWMjH22VtckEWOFfJGN0Xk0yrdrCDj3+
p0eA==
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=U3bD0coz2LWr7GuQTb9pdDHQpBBYQn8YNn39DIKQejU=;
b=i+KQ++MdxIdk67kOHNbWzYKHvV5TIzKABOd7dJZXgKI4QR8er8YIqCR3FQtJ/YDyJw
0quWgxl1tZV4c+zNpc9ZzdSSlZJE6zXgaog1S4DZmH3wb6LP+aWpPXrzvlFwkDv7Jsbd
523OTTlDZg3SmanwfUoNkxahJglmxSw4QeshIuHh+Rl48T/gydl5/3PPPVdlehkWPbvC
z8ZwG4X8TXKg1dSx85246XFOTubFbWeD0f1vkgoPO491LdW3AeWgERv18RryeLOY+zLo
BDMJ9JwFYIL3tVqdnbQZvGigC83x1IbG9vmdJhs4aokhhwC9F2pyEcvfHmWAk0L0X7Pl
JkPw==
X-Gm-Message-State: AKGB3mLtOW6Y0WJvUpMskRkwQ2xGf/jdn+U57j4Hv48f9gjvarZM8yh/
1RWJilqjY0F9+V9s+CMZ9S9LrA==
X-Google-Smtp-Source: ACJfBosIe/qo4go4OD++F2EMpwgRwFvC5TnG9tgk0RL67XGfyC1BTFJBz/QcuguYh6zEUgZVciWm0w==
X-Received: by 10.99.126.86 with SMTP id o22mr8261910pgn.364.1515501635920;
Tue, 09 Jan 2018 04:40:35 -0800 (PST)
Received: from [26.253.30.111] (mf42736d0.tmodns.net. [208.54.39.244])
by smtp.gmail.com with ESMTPSA id
g2sm11033347pfh.62.2018.01.09.04.40.34
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 09 Jan 2018 04:40:34 -0800 (PST)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: iPhone Mail (15C153)
In-Reply-To: <87608btgyd.fsf@rustcorp.com.au>
Date: Tue, 9 Jan 2018 21:40:30 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB7E57AC-5588-4BBA-9ABC-B9B4F6BAECE2@friedenbach.org>
References: <87608btgyd.fsf@rustcorp.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Russell O'Connor <roconnor@blockstream.com>,
Kalle Alm <kalle.alm@gmail.com>
Subject: Re: [bitcoin-dev] BIP 117 Feedback
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, 09 Jan 2018 12:40:38 -0000
The use of the alt stack is a hack for segwit script version 0 which has the=
clean stack rule. Anticipated future improvements here are to switch to a w=
itness script version, and a new segwit output version which supports native=
MAST to save an additional 40 or so witness bytes. Either approach would al=
low getting rid of the alt stack hack. They are not part of the proposal now=
because it is better to do things incrementally, and because we anticipate u=
sage of MAST to better inform these less generic changes.
Your suggestion of =E2=80=9Csingle blob on the stack=E2=80=9D seems to be ex=
actly this proposal afaict? Note the witness data needs to be passed separat=
ely because signatures can=E2=80=99t be included in that single blob if that=
blob is hashed and compared against something in the scriptPubKey.
The sigop and opcode limit drop can be justified with some back of the envel=
ope calculations. Non-scriptPubKey scripts are fundamentally limited by bloc=
ksize/weight and the most damage you can do, as an adversary, is limited by s=
pace. The most expensive thing you can do check a signature. Our assumptions=
about block size safety are basically due to how much computation you can s=
tuff in a block with checksigs =E2=80=94 all the analysis there applies.
My suggestion is to limit the number of checksigs allowed in a script to siz=
e(script+witness)/64, but I wanted this to come up in review rather than com=
plicate the code right off the bat.
I will make a strong assertion: static analyzing the number of opcodes and s=
igops gets us absolutely nothing. It is cargo cult safety engineering. No ne=
ed to perpetuate it when it is now in the way.
Sent from my iPhone
> On Jan 9, 2018, at 8:22 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>=20
> I've just re-read BIP 117, and I'm concerned about its flexibility. It
> seems to be doing too much.
>=20
> The use of altstack is awkward, and makes me query this entire approach.
> I understand that CLEANSTACK painted us into a corner here :(
>=20
> The simplest implementation of tail recursion would be a single blob: if
> a single element is left on the altstack, pop and execute it. That
> seems trivial to specify. The treatment of concatenation seems like
> trying to run before we can walk.
>=20
> Note that if we restrict this for a specific tx version, we can gain
> experience first and get fancier later.
>=20
> BIP 117 also drops SIGOP and opcode limits. This requires more
> justification, in particular, measurements and bounds on execution
> times. If this analysis has been done, I'm not aware of it.
>=20
> We could restore statically analyzability by rules like so:
> 1. Only applied for tx version 3 segwit txs.
> 2. For version 3, top element of stack is counted for limits (perhaps
> with discount).
> 3. The blob popped off for tail recursion must be identical to that top
> element of the stack (ie. the one counted above).
>=20
> Again, future tx versions could drop such restrictions.
>=20
> Cheers,
> Rusty.
|
