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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1RsHlg-00058z-Hl
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 17:45:20 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=gmaxwell@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RsHlf-0003dy-Ka
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 17:45:20 +0000
Received: by vbbff1 with SMTP id ff1so335701vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 31 Jan 2012 09:45:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.67.229 with SMTP id q5mr11196070vdt.14.1328031914231; Tue,
31 Jan 2012 09:45:14 -0800 (PST)
Received: by 10.220.151.200 with HTTP; Tue, 31 Jan 2012 09:45:14 -0800 (PST)
In-Reply-To: <201201311651.02726.andyparkins@gmail.com>
References: <201201311651.02726.andyparkins@gmail.com>
Date: Tue, 31 Jan 2012 12:45:14 -0500
Message-ID: <CAAS2fgTvvDT+acJQfwAGpVNeA2PAQ7wip9xXc-__V2oz-=Kk6Q@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.3 (-)
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
(gmaxwell[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.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RsHlf-0003dy-Ka
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: Tue, 31 Jan 2012 17:45:20 -0000
On Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins <andyparkins@gmail.com> wrot=
e:
> Hello,
>
> Gulp. =C2=A0Am a little nervous about wading into this swamp. =C2=A0Howev=
er, it seems
> to me that the debate has veered into the personal and away from the
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.
The differences between BIP16/BIP17 are technically obscure, everyone
who is well versed in the issue (with the potential exception of
Luke). There is broad consensus among the involved technically minded
parties over just about all of it.
Luke has been maintaining an opinion tracker page:
https://en.bitcoin.it/wiki/P2SH_Votes
reflecting the views of core developers and people who've been
technically involved enough to have an informed opinion.
>=C2=A0Surely if there are objections to both suggestions, that another
> solution might be better?
There is always a different color that the shed could be painted.
Expecting absolute consensus on the _best_ way forward is an
unreasonable standard, especially if you're going to invite the
opinions of many people.
Depending on how you count we have considered a good two dozen options
in this space=E2=80=94 Starting with the OP_CAT key combinations many mont=
hs
back, and including many variants of the current ideas. The BIPs only
represent the "final" surviving ideas.
In particular, BIP16 was the isolated consensus path forward that came
out of the discussions about the concerns that BIP12 was too
computationally powerful=E2=80=94 I don't think I can identify any particul=
ar
person as the author of the BIP16 idea. At the the time BIP16 became
a BIP only Luke was actively objecting to it.
Though his hard work and tireless (...unstoppable dogmatic) promotion
he's managed to build a workable alternative, and it now has some
support other than himself. This, however, doesn't constitute a
material schism.
> this idea up for my traditional mailing-list roasting but with the hope t=
hat
As always, asbestos underwear is required.
> If the change is going to be a big one anyway and will require a client
> upgrade why not...
It does not, in fact=E2=80=94 Yes, it requires a client update to make use =
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.
A breaking change of the kind you suggest is not something that would
be considered lightly, and this is certainly not justified for this.
> =C2=A0- Increase the version number in transactions to make a new transac=
tion
> =C2=A0 structure
> =C2=A0- Dump the "scriptPubKey" field completely. =C2=A0Everything will b=
e pay-to-
> =C2=A0 script-hash in version2 transactions
> =C2=A0- Replace it with "hashOfClaimingScript"
> =C2=A0- Add an "unsignedParameters" array.
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:
https://en.bitcoin.it/wiki/Hardfork_Wishlist
(see "Elimination of output scripts")
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
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 tim=
e
that the system is simply too big to make that kind of change.
|
