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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1RsWm9-0007w1-Lr
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Feb 2012 09:46:49 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RsWm8-0004cF-Kg
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Feb 2012 09:46:49 +0000
Received: by werc1 with SMTP id c1so1143813wer.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 01 Feb 2012 01:46:42 -0800 (PST)
Received: by 10.216.139.161 with SMTP id c33mr2445971wej.53.1328089602471;
Wed, 01 Feb 2012 01:46:42 -0800 (PST)
Received: from dvr.localnet (mail.360visiontechnology.com. [92.42.121.178])
by mx.google.com with ESMTPS id dw7sm28964391wib.4.2012.02.01.01.46.39
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 01 Feb 2012 01:46:40 -0800 (PST)
From: Andy Parkins <andyparkins@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Date: Wed, 1 Feb 2012 09:46:31 +0000
User-Agent: KMail/1.13.6 (Linux/3.0.0-1-686-pae; KDE/4.6.3; i686; ; )
References: <201201311651.02726.andyparkins@gmail.com>
<CAAS2fgTvvDT+acJQfwAGpVNeA2PAQ7wip9xXc-__V2oz-=Kk6Q@mail.gmail.com>
In-Reply-To: <CAAS2fgTvvDT+acJQfwAGpVNeA2PAQ7wip9xXc-__V2oz-=Kk6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1372095.UjJ9JDOvRM";
protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201202010946.37807.andyparkins@gmail.com>
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
(andyparkins[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
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RsWm8-0004cF-Kg
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 09:46:49 -0000
--nextPart1372095.UjJ9JDOvRM
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
On 2012 January 31 Tuesday, Gregory Maxwell wrote:
> I think you've been deceived by people who have some interest in
> promoting this as some sort of big controversy, or perhaps just
> confused by the general level of noise.
Well that's good that there is no real problem.
> It does not, in fact=E2=80=94 Yes, it requires a client update to make us=
e of
> the new functionality, but old nodes will happily continue to validate
> things. It's hard to express how critical this is distinctly.
> Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that
> things were done right, the validate them for themselves.
>=20
> A breaking change of the kind you suggest is not something that would
> be considered lightly, and this is certainly not justified for this.
To be brutally honest; I don't see how the BIP16/17 changes are any less=20
"breaking" than what I proposed (I'm not trying to push mine; forget it, th=
e=20
last thing bitcoin needs is another proposal if there is no real argument).=
=20
I will agree the changes are smaller for BIP16, since the transactions are=
=20
left as they are.
If BIP16/BIP17 were being honest they would too increase the version number=
=20
of the transaction structure. The new transaction type is not supported by=
=20
the old client... that's a break. My argument would be that once you're=20
going to break the old clients anyway, go the whole hog and fix some other=
=20
stuff as well.
> If we ever were to scrap the system, I think we very much would do
> something like what you describe here... and as much has been
> documented:
>=20
> https://en.bitcoin.it/wiki/Hardfork_Wishlist
> (see "Elimination of output scripts")
I'm glad I wasn't talking rubbish then.
=20
> But, to be clear, this stuff is pretty much fantasy. I'm doubtful that
> it will ever happen, doubtful that we can get the kind of development
Me too. Which is a shame; as it means we're locked into quite a fair numbe=
r=20
of earlier decisions that will now never be changed.
> resources required to pull off a true breaking change in a way that
> people would actually trust upgrading to=E2=80=94 at least not before a t=
ime
> that the system is simply too big to make that kind of change.
Again: I don't see how BIP16/17 aren't "breaking" as well; but perhaps I'm=
=20
just not familiar enough with the conventions. As far as I understand; no=
=20
pre-BIP16 miner is going to allow BIP16 into the blockchain because it's no=
t=20
going to pass the IsStandard() test.
I'd repeat: the reasonable thing to do is to increase the version number of=
=20
the transaction structure to indicate that they are being processed=20
differently from old transactions.
Andy
=2D-=20
Dr Andy Parkins
andyparkins@gmail.com
--nextPart1372095.UjJ9JDOvRM
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEABECAAYFAk8pCfgACgkQwQJ9gE9xL22nIQCfUxsxUhzm6f+K9sPpZUoQioba
Cw8An2bpp2CzDnIFnC6tjjdEsi3KL7Dk
=743B
-----END PGP SIGNATURE-----
--nextPart1372095.UjJ9JDOvRM--
|
