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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1XYTc0-0004e8-N1
for bitcoin-development@lists.sourceforge.net;
Mon, 29 Sep 2014 05:35:04 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.106 as permitted sender)
client-ip=62.13.148.106; envelope-from=pete@petertodd.org;
helo=outmail148106.authsmtp.co.uk;
Received: from outmail148106.authsmtp.co.uk ([62.13.148.106])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XYTby-0007kf-UD for bitcoin-development@lists.sourceforge.net;
Mon, 29 Sep 2014 05:35:04 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s8T5YtbO052478;
Mon, 29 Sep 2014 06:34:55 +0100 (BST)
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 s8T5YqNl010220
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 29 Sep 2014 06:34:54 +0100 (BST)
Date: Mon, 29 Sep 2014 01:35:26 -0400
From: Peter Todd <pete@petertodd.org>
To: Alan Reiner <etotheipi@gmail.com>
Message-ID: <20140929053526.GA21446@savin.petertodd.org>
References: <CABsx9T2+_tLOPELm+K54D=6SNkHg1ZeO_T1jSM=CQZYJKGODFw@mail.gmail.com>
<20140618001503.GA8360@savin>
<CABsx9T2O42pER0b1v9oeU14_K=KVWVqHzcfFmWAhSxoYAn12vg@mail.gmail.com>
<20140619100909.GA3544@savin>
<CABsx9T1uC9sMzbPJa4MGpBNoQ4S255Tfo66+wwCoND_bQtvT7Q@mail.gmail.com>
<20140929023553.GA11877@savin.petertodd.org>
<5428E053.7070601@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5"
Content-Disposition: inline
In-Reply-To: <5428E053.7070601@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 57c24b54-479a-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAsUC1AEAgsB AmIbW1JeU1l7XGY7 bA9PbARUfEhLXhtr
VklWR1pVCwQmQhRl A3dfLEVydgVEen4+ ZEJrWnYVWUMpd0Iv
R0pJEWoPNHphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDODMj DxcaFjIjEFZNTiM/
ZwA8I1gHFU0NM0I0 eUUsQ0kZNBlwQgtD GktAGjQRZ0YIXGJk
Fw5eVF5WDD1QCQZH OQEhJBNBGDAaQDdc CVANRRYVQxsfawkA
VCxUVDYkB0QoIEQx fWV3
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [62.13.148.106 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1XYTby-0007kf-UD
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] New opcodes and transaction version
numbers (was 'relax the IsStandard rules for P2SH transactions')
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: Mon, 29 Sep 2014 05:35:04 -0000
--bg08WKrSYDhXBjb5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Sep 29, 2014 at 12:30:11AM -0400, Alan Reiner wrote:
> On 09/28/2014 10:35 PM, Peter Todd wrote:
> > This can be solved by upgrading the address format at
> > the same time to let senders know they must send the funds in a
> > transaction with an increased version number, but obviously needing new
> > addresses for every new opcode defeats the purpose of P2SH.
>=20
> Can't this be solved with a single update to the address format,
> allowing a tx version number to be part of the address serialization?=20
> Then the sending software will apply that version to the payment tx. =20
> Of course, I'm not sure if allowing nodes to create transactions with
> version numbers outside of their programming is safe. It seems like it
> should be since we're talking about soft forks anyway, but there's
> probably some subtleties I'm overlooking.
Keep in mind that when a *wallet* - not a node - creates a transaction
the scriptPubKeys in the transaction outputs have been specified by the
receiver(s) and aren't executed until they are spent. Modulo sigops(1)
there is absolutely no reason why the wallet should care what the
contents of those scriptPubKeys are at all.
This is particularly apparent when you remember that there may be
multiple recipients of a transaction. If I'm paying Alice and Bob, who
have specified that they want the transaction to have version number 2
and 3 respectively, now what? Do we take the highest of the two and
constrain ourselves for how scripts are interpreted for all eternity? It
just doesn't make very much sense.
Meanwhile the man-hours of effort that would be required to implement
that "one-time" address format change is huge - it took literally years
for everyone to update their software to just support P2SH addresses.
I'm working on a CHECKLOCKTIMEVERIFY implementation right now, and know
of exchanges who would like to use it ASAP. Why make them wait years for
everyone to upgrade?
On that basis alone I think the question ought to be why should we use
transaction version numbers to enable new opcodes rather than just
enabling them globally based on block version numbers.
1) Satoshi implemented a per-block sigop limit to prevent blocks from
causing an unreasonable number of signature checking operations, but
rather than computing that limit based on the scripts actually executed,
the limit is computed based on the contents of all scriptSigs and
scriptPubKeys in the block. This is bizzare given that the contents of
the latter are *not* executed, and the former misses the prevout
scriptPubKeys that *are* executed. In short this means you can create a
block that passes the sigop limit, yet executes millions of expensive
signature operations by being filled with scriptSigs spending txouts
with large numbers of sigops in their scriptPubKeys. P2SH improves on
this situation somewhat by counting the sigops in redeemScripts towards
the limit, but missed the opportunity to just count all sigops in all
scriptSigs directly.
--=20
'peter'[:-1]@petertodd.org
0000000000000000092e056ab9c5a3242bfa911ba9a0a8a3836bcd4b5fcab2f8
--bg08WKrSYDhXBjb5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUKO+ZXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxNGJiNDc0ZTZhYTFhN2M2ZDFiNzUyOTdjOGIxOTliMzA0
NDMzNjdiZDUyMjc0OWQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfui0wf8CzOlnJHMAyriZWnMdwRc3aqd
MBIPbRAq2JTICV1HKl4WgXKFMMyrMtBFD1wEQ9/K9EsK4KyjJTp0BoJgUn46+RBG
3QBywQzx1llzraWMbHVMKoC12H1tNeLgr0cXmiApvxrsSsT5oDoE2ructNCBP9zd
OHKT1aSWcVoLj1AbsmY90qHOjCbfcePHB+SzNiteZkoXmCAmHVogDs6C+drwACdC
HYxLaYvEA81weMOOMZsl4wAaU4s8j3l2rg65v/S9rCqxiRJ8se8CL+sST6w9QCWQ
VkKVbEtuKoc1rW1m74+lJ8pjW4wr6bEKqL+DcFESBsofBIWVt6xM23XBDcZ9lQ==
=lY8i
-----END PGP SIGNATURE-----
--bg08WKrSYDhXBjb5--
|
