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
|
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 D78BC95D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Sep 2017 07:33:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com [74.125.83.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6B23D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Sep 2017 07:33:56 +0000 (UTC)
Received: by mail-pg0-f46.google.com with SMTP id p5so1576398pgn.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 19 Sep 2017 00:33:56 -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=QktrbJjs9z3f0vDxaDxRsupvJpQLdQiYHq1S9yxnVZw=;
b=az9j3I92FoODI94ZVyexLEKc8cy0MRcA2ZiH8N1fMa0Ee0fRMphG5eSwfYcr/C8JWS
M4+PlZHZ3wvGVGck5HXeoC0Ms3oS9knQYM7hRYpuJgqSoih/NUVLoDZxARPM2dMQm8rS
y4fzUXprNMKXmgCBYNP5iqbQ4qdTOjtSWS0bhDGs4EdI62BRPzTJHZwg7QLiGBc6hMh1
sqaAOOFlVblf4WejLw6BMVM9vGIrdl7SBBLbGoNiC6EcZpWLSgNdkLFa1iP639flGnbW
nJR4LiWmd1mzX9SiRQKN5SevNxFYcOTouTTa4zIh2B+Vhj1gvo2fs8Cw2acwi1Zao8ai
BTvw==
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=QktrbJjs9z3f0vDxaDxRsupvJpQLdQiYHq1S9yxnVZw=;
b=QtGT1T/lggTx+mkKzGQUVYZMpTQGkI9G+dAL0lmEzbTHtVWyKB9AI8RTRN3TPN8Q13
UqYanjN3uo2HBIFTDm4ZGtmyH3zy9QoWk4MfLSzyMU9s/7MarhlRZHhPeWPeAR3aKuiv
F8MX8egb27IHc3+cYYx4KqZ8n3QV0+SCLaIV4OzykwwQDq4XbdLeKOaen5wZ/vMeCQQf
LMUb9ZqK0wknb/okPwmG4TuOCP0HszRL3/hp9uPgBszTSCKPfLnPQiqcAglN6szsOp9P
qH0zfvnaaip2Ylv5JSYNpK5dNUnmiB+x0EFOFuldTt+KjlO8BIi0jGCbj7tN72cbuEew
WZSw==
X-Gm-Message-State: AHPjjUhWL6no9JdytodkimNy1fth2H1E9/1uUw5j1mqCRvfvMn2oR7+6
hYSzZGXk2dL1XaBY+VajQUXJqtuUhsE=
X-Google-Smtp-Source: AOwi7QCU8ZrtW9O/mly3a9rdy/NZ93L4x+LDva65VyVdcMKsBoqR5SFOr2yaaKvQH/miGgIJVYTRyQ==
X-Received: by 10.99.109.71 with SMTP id i68mr505691pgc.252.1505806436422;
Tue, 19 Sep 2017 00:33:56 -0700 (PDT)
Received: from ?IPv6:2601:646:8080:1291:605f:f803:a49d:ae85?
([2601:646:8080:1291:605f:f803:a49d:ae85])
by smtp.gmail.com with ESMTPSA id k12sm2817116pgt.3.2017.09.19.00.33.54
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 19 Sep 2017 00:33:55 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <201709190309.08669.luke@dashjr.org>
Date: Tue, 19 Sep 2017 00:33:54 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <CAA2B000-6C54-4AD7-B931-43C99D615A61@friedenbach.org>
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
<C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org>
<201709190309.08669.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=2.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
RCVD_IN_DNSWL_NONE,URIBL_DBL_SPAM autolearn=disabled version=3.3.1
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 19 Sep 2017 09:57:36 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] cleanstack alt stack & softfork improvements
(Was: Merkle branch verification & tail-call semantics for generalized
MAST)
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, 19 Sep 2017 07:33:58 -0000
> On Sep 18, 2017, at 8:09 PM, Luke Dashjr <luke@dashjr.org> wrote:
>
> On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev
> wrote:
>> After the main discussion session it was observed that tail-call semantics
>> could still be maintained if the alt stack is used for transferring
>> arguments to the policy script.
>
> Isn't this a bug in the cleanstack rule?
Well in the sense that "cleanstack" doesn't do what it says, sure.
However cleanstack was introduced as a consensus rule to prevent a
possible denial of service vulnerability where a third party could
intercept any* transaction broadcast and arbitrarily add data to the
witness stack, since witness data is not covered by a checksig.
Cleanstack as-is accomplishes this because any extra items on the
stack would pass through all realistic scripts, remaining on the stack
and thereby violating the rule. There is no reason to prohibit extra
items on the altstack as those items can only arrive there
purposefully as an action of the script itself, not a third party
malleation of witness data. You could of course use DEPTH to write a
script that takes a variable number of parameters and sends them to
the altstack. Such a script would be malleable if those extra
parameters are not used. But that is predicated on the script being
specifically written in such a way as to be vulnerable; why protect
against that?
There are other solutions to this problem that could have been taken
instead, such as committing to the number of items or maximum size of
the stack as part of the sighash data, but cleanstack was the approach
taken. Arguably for a future script version upgrade one of these other
approaches should be taken to allow for shorter tail-call scripts.
Mark
* Well, almost any. You could end the script with DEPTH EQUAL and that
is a compact way of ensuring the stack is clean (assuming the script
finished with just "true" on the stack). Nobody does this however
and burning two witness bytes of every redeem script going forward
as a protective measure seems like an unnecessary ask.
|
