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
|
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 <pieter.wuille@gmail.com>) id 1RsX1A-0000VC-AS
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Feb 2012 10:02:20 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=pieter.wuille@gmail.com;
helo=mail-ww0-f53.google.com;
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RsX14-0000Kh-R0
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Feb 2012 10:02:20 +0000
Received: by wgbdr12 with SMTP id dr12so1018218wgb.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 01 Feb 2012 02:02:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.100.234 with SMTP id fb10mr40383795wib.8.1328090528617;
Wed, 01 Feb 2012 02:02:08 -0800 (PST)
Received: by 10.223.68.211 with HTTP; Wed, 1 Feb 2012 02:02:08 -0800 (PST)
Received: by 10.223.68.211 with HTTP; Wed, 1 Feb 2012 02:02:08 -0800 (PST)
In-Reply-To: <201202010948.13169.andyparkins@gmail.com>
References: <201201311651.02726.andyparkins@gmail.com>
<201201311158.50801.luke@dashjr.org>
<201202010948.13169.andyparkins@gmail.com>
Date: Wed, 1 Feb 2012 11:02:08 +0100
Message-ID: <CAPg+sBgkEd71CUGHooymeVwGkz5axZMOck5o-nic8TM706T8OQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043748f33015fe04b7e42ccc
X-Spam-Score: -1.1 (-)
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
1.0 HTML_MESSAGE BODY: HTML included in message
-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
-0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RsX14-0000Kh-R0
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP16/17 replacement
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: Wed, 01 Feb 2012 10:02:20 -0000
--f46d043748f33015fe04b7e42ccc
Content-Type: text/plain; charset=ISO-8859-1
Op 1 feb. 2012 10:48 schreef "Andy Parkins" <andyparkins@gmail.com> het
volgende:
>
> On 2012 January 31 Tuesday, Luke-Jr wrote:
>
> > Both BIP 16 and 17 are backward compatible enough that people can
continue
> > to use the old clients with each other. An upgrade is only required to
> > send to (or create/receive on) the new 3...-form addresses. That being
>
> Is that true? (I'm happy to be called wrong)
>
> It doesn't seem like it to me. The new transaction types will be
rejected by
> old clients won't they? They don't pass IsStandard().
IsStandard() is for accepting transactions into the memory pool.
Non-standard transactions are verified just fine when they are in the block
chain.
BIP16/17 both create transactions that, when interpreted as old scripts,
are valid. The only change to the protocol is that previously-valid
transactions become invalid. As long as a supermajority of miners enforce
the new rules, everyone can happily keep using their old bitcoin client.
They won't create the new transaction type, and don't accept them as
payment, but they will accept the new block chain.
If we do a breaking change to the protocol - such as adding a new
transaction type - ALL users must upgrade. Those who don't will see a fork
of the chain from before the first new-style transaction. That is not the
case now.
--
Pieter
--f46d043748f33015fe04b7e42ccc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p><br>
Op 1 feb. 2012 10:48 schreef "Andy Parkins" <<a href=3D"mailto=
:andyparkins@gmail.com">andyparkins@gmail.com</a>> het volgende:<br>
><br>
> On 2012 January 31 Tuesday, Luke-Jr wrote:<br>
><br>
> > Both BIP 16 and 17 are backward compatible enough that people can=
continue<br>
> > to use the old clients with each other. An upgrade is only requir=
ed to<br>
> > send to (or create/receive on) the new 3...-form addresses. That =
being<br>
><br>
> Is that true? =A0(I'm happy to be called wrong)<br>
><br>
> It doesn't seem like it to me. =A0The new transaction types will b=
e rejected by<br>
> old clients won't they? =A0They don't pass IsStandard().</p>
<p>IsStandard() is for accepting transactions into the memory pool. Non-sta=
ndard transactions are verified just fine when they are in the block chain.=
</p>
<p>BIP16/17 both create transactions that, when interpreted as old scripts,=
are valid. The only change to the protocol is that previously-valid transa=
ctions become invalid. As long as a supermajority of miners enforce the new=
rules, everyone can happily keep using their old bitcoin client. They won&=
#39;t create the new transaction type, and don't accept them as payment=
, but they will accept the new block chain.</p>
<p>If we do a breaking change to the protocol - such as adding a new transa=
ction type - ALL users must upgrade. Those who don't will see a fork of=
the chain from before the first new-style transaction. That is not the cas=
e now.</p>
<p>-- <br>
Pieter<br>
</p>
--f46d043748f33015fe04b7e42ccc--
|
