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
|
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 231FBB63
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Sep 2017 20:15:40 +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 84D947C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Sep 2017 20:15:39 +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 A624A3D6A8;
Fri, 15 Sep 2017 13:15:38 -0700 (PDT)
To: Andrew Quentson <andrewquentson@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr>
<CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.com>
From: Dan Libby <dan@osc.co.cr>
Message-ID: <a4ed81de-68ed-1c72-2302-139a88ee886f@osc.co.cr>
Date: Fri, 15 Sep 2017 13:15:36 -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: <CADSvpf7sC-Rh0qoGKgagQV7Mo_BV6ymeadgfMzJ_oXPCTyJ6Mw@mail.gmail.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 21:00:22 +0000
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 20:15:40 -0000
Thanks for this link. From my reading though, it seems that only
soft-forks that attempt to freeze funds are problematic on ethereum.
From the article:
> The soft fork creates a new and fundamentally different class of
> transactions in contrast with those that currently exist within the
> protocol. Currently, transactions either complete successfully and
> cause a state transition, or run into an exception, in which case
> state is reverted but the maximum possible gas is still charged. With
> the soft fork, transactions which interact with a DAO will not fit
> within these two classes: they will fail execution but no gas will be
> charged. This must inevitably be the case in any soft fork that aims
> to freeze the stolen funds;
So in the general case ethereum can still soft-fork I think...
On 09/15/2017 04:19 AM, Andrew Quentson wrote:
> From my understanding, the blockchain can be designed in such a way as
> to make soft-forks be impossible or at least impractical due to attack
> vectors.
>
> http://hackingdistributed.com/2016/06/28/ethereum-soft-fork-dos-vector/
>
> Ethereum, for example, can't soft-fork. They have to always hardfork.
>
> On 13 September 2017 at 10:50, Dan Libby via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> 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
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
--
Dan Libby
Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359
|
