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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9897CF74
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Mar 2018 15:28:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 04D505D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Mar 2018 15:28:31 +0000 (UTC)
Received: from [172.29.7.32] (38.140.120.98 [38.140.120.98]) by mx.zohomail.com
with SMTPS id 1520263701974334.11387568882833;
Mon, 5 Mar 2018 07:28:21 -0800 (PST)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <87608btgyd.fsf@rustcorp.com.au>
Date: Mon, 5 Mar 2018 10:28:20 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A9BCC75-F116-4382-B4DE-2E69E79C1DDB@xbt.hk>
References: <87608btgyd.fsf@rustcorp.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Mark Friedenbach <mark@friedenbach.org>
X-Mailer: Apple Mail (2.3445.5.20)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: 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: Mon, 05 Mar 2018 15:28:32 -0000
Altstack in v0 P2WSH should be left untouched. If anyone is already =
using altstack, BIP117 would very likely confiscate those UTXOs because =
the altstack would unlikely be executable.
Even in v1 witness, I think altstack should remain be a temporary data =
storage.
The =E2=80=9C(many scripts) concatinated together in reverse order to =
form a serialized script=E2=80=9D in BIP117 is exactly the same security =
hole of Satoshi=E2=80=99s scriptSig + OP_CODESAPARATOR + scriptPubKey . =
That means it is possible to skip execution of scriptPubKey by using a =
scriptSig with an invalid push operation, so the whole concatenated =
script becomes a simple push.
For SigOp limit, I think it=E2=80=99d become more and more difficult to =
maintain the current statical analyzability model as we try to introduce =
more functions. I think we should just migrate to a model of limiting =
sigop per weight, and count the actual number of sigop during execution. =
( =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/0157=
64.html ) Actually, this approach is cheaper to analyse, as you only =
need to look at the witness size, and don=E2=80=99t need to look at the =
script at all.
> On 9 Jan 2018, at 6:22 AM, Rusty Russell via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
