summaryrefslogtreecommitdiff
path: root/4f/a3a440faf74b0b8f196e5b6d0fd6d340260908
blob: fa17ba177dd26969ce9e71be12e013166bb18cf1 (plain)
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
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2853096F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Sep 2017 03:09:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id DC510461
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Sep 2017 03:09:19 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 7E41A38A0075;
	Tue, 19 Sep 2017 03:09:09 +0000 (UTC)
X-Hashcash: 1:25:170919:bitcoin-dev@lists.linuxfoundation.org::woocaI=MteW9EV4u:MF1n
X-Hashcash: 1:25:170919:mark@friedenbach.org::Cp5miHJ6mWieAUBu:Zf4d
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Mark Friedenbach <mark@friedenbach.org>
Date: Tue, 19 Sep 2017 03:09:08 +0000
User-Agent: KMail/1.13.7 (Linux/4.12.5-gentoo; KDE/4.14.34; x86_64; ; )
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
	<C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org>
In-Reply-To: <C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201709190309.08669.luke@dashjr.org>
X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [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 03:09:20 -0000

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?

(Unrelated...)

Another thing that came up during the discussion was the idea of replacing all 
the NOPs and otherwise-unallocated opcodes with a new OP_RETURNTRUE 
implementation, in future versions of Script. This would immediately exit the 
program (perhaps performing some semantic checks on the remainder of the 
Script) with a successful outcome.

This is similar to CVE-2010-5141 in a sense, but since signatures are no 
longer Scripts themselves, it shouldn't be exploitable.

The benefit of this is that it allows softforking in ANY new opcode, not only 
the -VERIFY opcode variants we've been doing. That is, instead of merely 
terminating the Script with a failure, the new opcode can also remove or push 
stack items. This is because old nodes, upon encountering the undefined 
opcode, will always succeed immediately, allowing the new opcode to do 
literally anything from that point onward.

Luke