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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
Return-Path: <dan@osc.co.cr>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C5F7EB50
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Sep 2017 19:56:04 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.osc.co.cr (unknown [168.235.79.83])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 28D374B6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Sep 2017 19:56:03 +0000 (UTC)
Received: from [192.168.2.225] (miner1 [71.94.45.245])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested) (Authenticated sender: danda)
by mail.osc.co.cr (Postfix) with ESMTPSA id DD7AF1F00D;
Fri, 15 Sep 2017 12:56:02 -0700 (PDT)
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr>
<SU02clg--S4TtIK4TZIytgdnHE8SzXBwSEb_FN5edtPAaojLwCEd6OTNkBUrDiH1FwHPuD4D5yByE7r4Fz_-CVzzU9KK0xvmDGlWNxTp3aU=@protonmail.com>
From: Dan Libby <dan@osc.co.cr>
Message-ID: <9a541ba8-7c25-fdbb-505f-6426f61bdc63@osc.co.cr>
Date: Fri, 15 Sep 2017 12:55:56 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <SU02clg--S4TtIK4TZIytgdnHE8SzXBwSEb_FN5edtPAaojLwCEd6OTNkBUrDiH1FwHPuD4D5yByE7r4Fz_-CVzzU9KK0xvmDGlWNxTp3aU=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=1.3 required=5.0 tests=RDNS_NONE autolearn=disabled
version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 15 Sep 2017 20:05:13 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 15 Sep 2017 19:56:04 -0000
Ok, this is good stuff. thanks for the thoughtful reply.
Regarding anyone-can-spend:
all of the examples you gave do not satisfy isStandard. So if our
hypothetical cryptocurrency were to restrict all transactions to
isStandard at the consensus layer, would that not effectively prevent
anyone-can-spend?
Or more generally and with our thinking caps on, what would be the best
way to prevent anyone-can-spend, if that is our goal?
Regarding soft-fork = restrict:
Your example of miners running secret soft-fork code that blacklists
satoshi's utxo's is intriguing and somewhat troubling.
I think the main takeaways are that:
1) there are other ways to soft-fork besides anyone-can-spend.
2) it is impossible to prevent hidden soft-forks.
Is that accurate?
Still, I would put forth the following question: If anyone-can-spend tx
were no longer allowed according to consensus rules (assuming that is
possible/practical), then could the network still be practically
"upgraded" with new features (eg opcodes) via soft-fork, and if so, what
would be the mechanism for backwards compatibility in this scenario?
or from another angle: even if it is impossible to prevent all
soft-forks, can you see any way at all to make it logistically
infeasible to use soft-forks as a network-wide consensus change mechanism?
and another thought: as I understand it, bitcoin is presently able to
add new opcodes via soft-fork because Satoshi added 10 unused opcodes
via hardfork. What will happen when these run out? Can new opcodes
still be added without a hard-fork?
note: I ask these questions with the goal/vision of creating an
immutable altcoin or sidechain, not necessarily restricting bitcoin's path.
On 09/14/2017 09:01 PM, ZmnSCPxj wrote:
> Good morning Dan,
>
> My understanding is that it is impossible for soft forks to be prevented.
>
> 1. Anyone-can-spend
>
> There are a very large number of anyone-can-spend scripts, and it would
> be very impractical to ban them all.
>
> For example, the below output script is anyone-can-spend
>
> <random number> OP_TRUE
>
> So is the below:
>
> OP_SIZE <random small number> OP_EQUAL
>
> Or:
>
> OP_1ADD <random number> OP_EQUAL
>
> Or:
>
> OP_BOOLAND
>
> Or:
>
> OP_BOOLOR
>
> And so on.
>
> So no, it is not practically possible to ban anyone-can-spend outputs,
> as there are too many potential scriptPubKey that anyone can spend.
>
> It is even possible to have an output that requires a proof-of-work,
> like so:
>
> OP_HASH256 <difficulty target> OP_LESSTHAN
>
> All the above outputs are disallowed from propagation by IsStandard, but
> a miner can put them validly in a block, and IsStandard is not consensus
> code and can be modified.
>
> 2. Soft fork = restrict
>
> It is possible (although unlikely) for a majority of miners to run soft
> forking code which the rest of us are not privy to.
>
> For example, for all we know, miners are already blacklisting spends on
> Satoshi's coins. We would not be able to detect this at all, since no
> transaction that spends Satoshi's coins have been broadcast, ever. It
> is thus indistinguishable from a world where Satoshi lost his private
> keys. Of course, the world where Satoshi never spent his coins and
> miners are blacklisting Satoshi's coins, is more complex than the world
> where Satoshi never spent his coins, so it is more likely that miners
> are not blacklisting.
>
> But the principle is there. We may already be in a softfork whose rules
> we do not know, and it just so happens that all our transactions today
> do not violate those rules. It is impossible for us to know this, but
> it is very unlikely.
>
> Soft forks apply further restrictions on Bitcoin. Hard forks do not.
> Thus, if everyone else is entering a soft fork and we are oblivious, we
> do not even know about it. Whereas, if everyone else is entering a hard
> fork, we will immediately see (and reject) invalid transactions and blocks.
>
> Thus the only way to prevent soft fork is to hard fork against the new
> soft fork, like Bcash did.
>
> Regards,
> ZmnSCPxj
>
> -------- Original Message --------
> Subject: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
> Local Time: September 13, 2017 5:50 PM
> UTC Time: September 13, 2017 9:50 AM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
>
> Hi, I am interested in the possibility of a cryptocurrency software
> (future bitcoin or a future altcoin) that strives to have immutable
> consensus rules.
>
> The goal of such a cryptocurrency would not be to have the latest and
> greatest tech, but rather to be a long-term store of value and to offer
> investors great certainty and predictability... something that markets
> tend to like. And of course, zero consensus rule changes also means
> less chance of new bugs and attack surface remains the same, which is
> good for security.
>
> Of course, hard-forks are always possible. But that is a clear split
> and something that people must opt into. Each party has to make a
> choice, and inertia is on the side of the status quo. Whereas
> soft-forks sort of drag people along with them, even those who oppose
> the changes and never upgrade. In my view, that is problematic,
> especially for a coin with permanent consensus rule immutability as a
> goal/ethic.
>
> As I understand it, bitcoin soft-forks always rely on anyone-can-spend
> transactions. If those were removed, would it effectively prevent
> soft-forks, or are there other possible mechanisms? How important are
> any-one-can spend tx for other uses?
>
> More generally, do you think it is possible to programmatically
> avoid/ban soft-forks, and if so, how would you go about it?
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
