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
140
141
142
143
144
|
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 1XlkO9-0004Sq-Mc
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Nov 2014 20:07:37 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.101 as permitted sender)
client-ip=62.13.149.101; envelope-from=pete@petertodd.org;
helo=outmail149101.authsmtp.com;
Received: from outmail149101.authsmtp.com ([62.13.149.101])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XlkO8-0007O2-EF for bitcoin-development@lists.sourceforge.net;
Tue, 04 Nov 2014 20:07:37 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA4K7Tdx095814;
Tue, 4 Nov 2014 20:07:29 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 sA4K7Nn8065000
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 4 Nov 2014 20:07:26 GMT
Date: Tue, 4 Nov 2014 15:07:44 -0500
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20141104200744.GA16945@savin.petertodd.org>
References: <CAPg+sBjygohgFf2hE9cGH3ZmV0MaeniZDDNO+hFxOxo-s_d81A@mail.gmail.com>
<20141104191313.GA5493@savin.petertodd.org>
<CAJHLa0NiWJtb0aSRddZmBtQRkfMyQ957jnZi=qGfL6eOb76gFg@mail.gmail.com>
<CAPg+sBh=YDQhwNRWjhOQtWVPMZ0+D0MnprZK+vMjsuC-=RxAQA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd"
Content-Disposition: inline
In-Reply-To: <CAPg+sBh=YDQhwNRWjhOQtWVPMZ0+D0MnprZK+vMjsuC-=RxAQA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 32ac03b9-645e-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgYUFloCAgsB AmIbWVReUFp7W2U7 bA9PbARUfEhLXhtr
VklWR1pVCwQmQm0F fRlgDBFycQBGeH4+ ZENkVngVX0YrJkZ+
EEdJE2kDMHphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNB8E GUpKFDMjVUMYWzgp
IlQ9IUQdBFpZL109 K1ItVElw
X-Authentic-SMTP: 61633532353630.1024: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: 1XlkO8-0007O2-EF
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 20:07:37 -0000
--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 04, 2014 at 12:00:43PM -0800, Pieter Wuille wrote:
> On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> > On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd <pete@petertodd.org> wrote:
> >> 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.
> >
> > Moderately agreed.
> >
> > Earlier in BIP 62 lifetime, I had commented on ambiguity that arose
> > from bumping tx version simply because we were bumping block version.
> > The ambiguity was corrected, but IMO remains symptomatic of potential
> > problems and confusion down the road.
> >
> > Though I ACK'd the change, my general preference remains to disconnect
> > TX and block version.
>=20
> I prefer to see consensus rules as one set of rules (especially
> because they only really apply to blocks - the part for lone
> transactions is just policy), and thus have a single numbering. Still,
> I have no strong opinion about it and have now heard 3 'moderately
> against' comments. I'm fine with using nVersion=3D=3D2 for transactions.
Keep in mind that we may even have a circumstance where we need to
introduce *two* different new tx version numbers in a single soft-fork,
say because we find an exploit that has two different fixes, each of
which breaks something.
I don't think we have any certainty how new features will be added in
the future - just look at how we only recently realised new opcodes
won't be associated with tx version number bumps - so I'm loath to setup
expectations.
Besides, transactions can certainly be verified for correctness in a
stand-alone fashion outside a block; CHECKLOCKTIMEVERIFY was
specifically designed so that verifying scripts containing it could be
done in a self-contained manner only referencing the transaction the
script was within.
--=20
'peter'[:-1]@petertodd.org
0000000000000000036655c955dd94ba7f9856814f3cb87f003e311566921807
--ZPt4rx8FFjLCG7dd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUWTIMXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMzY2NTVjOTU1ZGQ5NGJhN2Y5ODU2ODE0ZjNjYjg3ZjAw
M2UzMTE1NjY5MjE4MDcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuICwgAvuEfpenuD9sBC+/+RTXb/8tm
B3RCU6ioiLcTqXXGW+3eqh/ZT0igtLXKOeRl2LPEccmXR3vj9BHS/hLlsHsbXa4v
oW1/O97yHovdsaR5tPeDdHK+YBeaz1/OmKfvAnpthuYjo+D0und6PgAqYxYixebI
nhm4XUaoZD1JZojFSaJgfbKPlLRbF1+JUTrUuGANeKeLqb+2q8e1MiNtHDZ7C/pb
qoAyweCJK1Ypcy8xdasrXblNmTHd/y5U2oaWS9k491I7nD9l7i5mQ3Dzjtz+YBU8
Hkzej6vdcLzEJwl9Dtr8xmOxlNp+iz/YG6Es47dgi8yURiTsy2ehtk3NswLg0Q==
=gyna
-----END PGP SIGNATURE-----
--ZPt4rx8FFjLCG7dd--
|
