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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F3648D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Nov 2015 01:30:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com
[209.85.192.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F1043150
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Nov 2015 01:30:51 +0000 (UTC)
Received: by qgeo38 with SMTP id o38so106386739qge.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 01 Nov 2015 17:30:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=6UtFUFitHim62nlOG7D370B9dDLGC8ET7Du4Rtk4130=;
b=rB2p9eBEYgWyCnCR+mYCLqYmQJqAPQuunbpBy8Bbt48nEMEMePwoQfmvsSohpkCFyn
UVSxe3SF+W7prX/tzK3+j3/UmYI+CmlOWzpZNmb5WQXrRdy2FIyOZJqd53DhFNg8qDiu
F60QI8+bn7P4oKi2C8fcHfIZGB2ePDFJ46xwAKRRAYQQxPMpHvrelVDAj99r1MKkE1FB
0KiNgDD4i5sadDrvcWVnOkfRUTtexncvsLG6qFw/epLtbgDL03BpkVGCZ7egNo9e04nE
e2GGp1uRpFy15CAvJYB4TECWQtPVCmyzzEN9gpKubTRcguGvjXvz8VJW3SLL/mgaYwWk
CgXA==
MIME-Version: 1.0
X-Received: by 10.140.181.197 with SMTP id c188mr11491753qha.4.1446427851149;
Sun, 01 Nov 2015 17:30:51 -0800 (PST)
Received: by 10.140.30.201 with HTTP; Sun, 1 Nov 2015 17:30:51 -0800 (PST)
In-Reply-To: <5636ACFF.5040908@openbitcoinprivacyproject.org>
References: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com>
<df48a2c44441f39c71579aa5e474ec38@xbt.hk>
<CAE-z3OWJ8YvXU5aGqgs9VJnW99va=0=FoObmpHS3irg4Kh6wrQ@mail.gmail.com>
<5636ACFF.5040908@openbitcoinprivacyproject.org>
Date: Mon, 2 Nov 2015 01:30:51 +0000
Message-ID: <CAE-z3OVDT-0cYq4Hh_OozWEp-UEj6yxbyon6YhOretgKPRLfFg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113a95be43058e052384ba20
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
MALFORMED_FREEMAIL,
MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Compatibility requirements for hard or soft forks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2015 01:30:52 -0000
--001a113a95be43058e052384ba20
Content-Type: text/plain; charset=UTF-8
On Mon, Nov 2, 2015 at 12:23 AM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Are there actually any OP_CAT scripts currently in the utxo set?
>
A locked transaction could pay to an OP_CAT script with the private key
being lost.
Even if it is only in theory, it is still worth trying to prevent rule
changes which permanently prevent outputs being spendable.
> It's a lot easier to justify the position: "nobody has the right to
> change the meaning of someone else's outputs", than it is to justify,
> "some small group of people gets to decide what's standard and what
> isn't, and if you choose to use the network in a valid but nonstandard
> way, that group of people might choose to deny you access to your money
> in the future"
>
If at least one year's notice was given, then people aren't going to lose
their money, since they have notice.
Locked transactions could have a difference expectation than non-locked
ones.
> In other words, how close to the shores of "administrators of a virtual
> currency" do Bitcoin developers want to sail?
>
Miners can collectively vote to disable specific UTXOs and change the
acceptance rules.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a113a95be43058e052384ba20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Nov 2, 2015 at 12:23 AM, Justus Ranvier via bitcoin-dev <span d=
ir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"">
</span>Are there actually any OP_CAT scripts currently in the utxo set?<br>=
</blockquote><div><br></div><div>A locked transaction could pay to an OP_CA=
T script with the private key being lost.<br></div><div><br>Even if it is o=
nly in theory, it is still worth trying to prevent rule=20
changes which permanently prevent outputs being spendable.<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
It's a lot easier to justify the position: "nobody has the right t=
o<br>
change the meaning of someone else's outputs", than it is to justi=
fy,<br>
"some small group of people gets to decide what's standard and wha=
t<br>
isn't, and if you choose to use the network in a valid but nonstandard<=
br>
way, that group of people might choose to deny you access to your money<br>
in the future"<br></blockquote><div><br></div><div>If at least one yea=
r's notice was given, then people aren't going to lose their money,=
since they have notice.<br><br></div><div>Locked transactions could have a=
difference expectation than non-locked ones.<br>=C2=A0<br></div><div></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
In other words, how close to the shores of "administrators of a virtua=
l<br>
currency" do Bitcoin developers want to sail?<br></blockquote><div><br=
></div><div>Miners can collectively vote to disable specific UTXOs and chan=
ge the acceptance rules.<br></div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
<br>
<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div>
--001a113a95be43058e052384ba20--
|
