summaryrefslogtreecommitdiff
path: root/e3/122209360df0b9de43694717f3a87f7aacfbe5
blob: 756b12307182f0f37fff30913071a27f9a4770ef (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pieter.wuille@gmail.com>) id 1XmKev-0005Ie-HR
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Nov 2014 10:51:21 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.179 as permitted sender)
	client-ip=209.85.213.179; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ig0-f179.google.com; 
Received: from mail-ig0-f179.google.com ([209.85.213.179])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XmKet-0000tE-Lp
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Nov 2014 10:51:21 +0000
Received: by mail-ig0-f179.google.com with SMTP id r10so3153409igi.6
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 06 Nov 2014 02:51:14 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.137.91 with SMTP id l88mr3541220iod.61.1415271074318;
	Thu, 06 Nov 2014 02:51:14 -0800 (PST)
Received: by 10.50.98.40 with HTTP; Thu, 6 Nov 2014 02:51:14 -0800 (PST)
In-Reply-To: <CAPg+sBgBhemhPid0LcB9NAHckSmwPuQRRp-6CBVOe5CcOUH8NA@mail.gmail.com>
References: <20141106103820.GA17096@savin.petertodd.org>
	<CAPg+sBgBhemhPid0LcB9NAHckSmwPuQRRp-6CBVOe5CcOUH8NA@mail.gmail.com>
Date: Thu, 6 Nov 2014 02:51:14 -0800
Message-ID: <CAPg+sBhJrbV5+5M5q_E5hs18YVBG8wP=tTZEzVfn0u+UdrK1cw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(pieter.wuille[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XmKet-0000tE-Lp
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 06 Nov 2014 10:51:21 -0000

On Thu, Nov 6, 2014 at 2:47 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
>> I suggest we either change STRICTENC to simply fail unrecognized pubkeys
>> immediately - similar to how non-standard signatures are treated - or
>> fail the script if the pubkey is non-standard and signature verification
>> succeeds.
>
> Sounds good to me, I disliked those semantics too.

Of course: do we apply this rule to all pubkeys passed to
CHECKMULTISIG (my preference...), or just the ones that are otherwise
checked?

This will likely make existing outputs hard to spend as well (I don't
have numbers), are we okay with that? We probably can't make this a
consensus rule, as it may make existing P2SH outputs/addresses
unspendable.

-- 
Pieter