summaryrefslogtreecommitdiff
path: root/76/6228c051c60e39c6064000e0cadb733cb7a1c4
blob: db0297eee76debd983bfcf2364e37eb5acb89a5b (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
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1XljXO-0001QX-Q3
	for bitcoin-development@lists.sourceforge.net;
	Tue, 04 Nov 2014 19:13:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.102 as permitted sender)
	client-ip=62.13.148.102; envelope-from=pete@petertodd.org;
	helo=outmail148102.authsmtp.net; 
Received: from outmail148102.authsmtp.net ([62.13.148.102])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1XljXN-0005Nm-CA for bitcoin-development@lists.sourceforge.net;
	Tue, 04 Nov 2014 19:13:06 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id sA4JCwbT016762; 
	Tue, 4 Nov 2014 19:12:58 GMT
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
	[75.119.251.161]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA4JCrXe069313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Tue, 4 Nov 2014 19:12:56 GMT
Date: Tue, 4 Nov 2014 14:13:13 -0500
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20141104191313.GA5493@savin.petertodd.org>
References: <CAPg+sBjygohgFf2hE9cGH3ZmV0MaeniZDDNO+hFxOxo-s_d81A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO"
Content-Disposition: inline
In-Reply-To: <CAPg+sBjygohgFf2hE9cGH3ZmV0MaeniZDDNO+hFxOxo-s_d81A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 957dcbc0-6456-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdgYUFloCAgsB AmIbWl1eUV97XGU7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmQm0F fG1cOkxycQxFeX0+ ZEZlVngVVUF9IRUv
	EU5JE2kDY3phaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNB8E GUpKFDMjVUMYWzgp
	IlQ9IUQdBFpZL109 K1ItVElw
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1XljXN-0005Nm-CA
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP62 and future script upgrades
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: Tue, 04 Nov 2014 19:13:07 -0000


--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 04, 2014 at 05:29:46AM -0800, Pieter Wuille wrote:
> one of the rules in BIP62 is the "clean stack" requirement, which
> makes passing more inputs to a script than necessary illegal.
>=20
> Unfortunately, this rule needs an exception for P2SH scripts: the test
> can only be done after (and not before) the second stage evaluation.
> Otherwise it would reject all spends from P2SH (which rely on
> "superfluous" inputs to pass data to the second stage).
>=20
> I submitted a Pull Request to clarify this in BIP62:
> https://github.com/bitcoin/bips/pull/115
>=20
> However, this also leads to the interesting observation that the
> clean-stack rule is incompatible with future P2SH-like constructs -
> which would be very useful if we'd ever want to deploy a "Script 2.0".
> Any such upgrade would suffer from the same problem as P2SH, and
> require an exception in the clean-stack rule, which - once deployed -
> is no longer a softfork.
>=20
> Luke suggested on the pull request to not apply this rule on every
> transaction with nVersion >=3D 3, which indeed solves the problem. I
> believe this can easily be generalized: make the (non mandatory) BIP62
> rules only apply to transaction with strict nVersion=3D=3D3, and not to
> higher ones. The higher ones are non-standard anyway, and shouldn't be
> used before there is a rule that applies to them anyway - which could
> include some or all of BIP62 if wanted at that point still.
>=20
> Opinions?

I agree with Luke: make the rules only apply to transactions with a
strict nVersion=3D=3D3. If we want to extend that later we can do so in
another soft-fork.


On another topic, I'm skeptical of the choice of nVersion=3D=3D3 - we'll
likely end up doing more block.nVersion increases in the future, and
there's no reason to think they'll have anything to do with
transactions. No sense creating a rule that'll be so quickly broken.

--=20
'peter'[:-1]@petertodd.org
000000000000000002986604739bc94cc42d5c6adf75186e80ba3dbb501a076d

--2oS5YaxWCcQjTEyO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJUWSVEXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZTVhMjcwMTMyOTRhNDg4ZGRiNTQyNmE1YzYzZDZmN2E4
ZmVlMDg1YTQxZWZlM2QvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfthWgf+J9UtIQkRs+kxo3z92oubS33j
RT2AFDvhgNSdMtoF3uu3b3bg86rptRQgz1hnZLFn99yOAcnh7jiO9hptT5nC5RTx
4LO8C5ZvXnrDs92grVqJB/9KGjZbDX5EZuKS1Bh9Pejy7dhinoBazuvFojDYjSLc
g4oef04RIaVox+QOQ7mjWOsg6TFfc0nH4aK/8pz6gL9nItqAElEENrbpGfWimz9O
Ez9XeYaTjrFaioC6Un6BJmsvSe/tHPBqZMjU7rz7TnAH0qcRMMXT8WauEEkH+n1g
kO6fJwv3R4GuKS4aamu/QnI3Apcau++s4WdmdJ8CnhK1bPXbcXgC1qO+pPGadQ==
=eR2j
-----END PGP SIGNATURE-----

--2oS5YaxWCcQjTEyO--