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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E29F51962
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 12:20:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com
[209.85.220.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4195E1C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 12:20:25 +0000 (UTC)
Received: by padhy16 with SMTP id hy16so173493967pad.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Sep 2015 05:20:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=user-agent:in-reply-to:references:mime-version:content-type
:content-transfer-encoding:subject:from:date:to:cc:message-id;
bh=ceEVpOOymSof8aHPvAC2WYbIaOL6xz4YfeE5kOwuFAg=;
b=d6D1Q+jLN3MdKY+CARqXnqI7Asl3Z5QrumxwRYufeumu/7ymPpSrlJeBxvQHzIKqdV
Ao/D/G92mAQKyfUhWqgfTwyq0MtzPSC/XKYjmJnkkzng6yEv3s6DfReb39aQjNBFjZdT
4iDIZWQCczHc6OidXt7IhZ/VKAMztTp5r+GkC6LkKRkhSfdAxgovYJiZWpfhg4pbbg3R
BbMjiVj2wCi9t/SQezz8lffOKsI1EvkGRgHVGbJ/QLqMB6iMjZA615z5u1J5hBPQxnQQ
+pTq5sOr6n9SJSosHfydJ9JOO8prVFhge3/SdVyR33aZyipbUzPZlc7Pk0I1S7E6NCmq
IFnQ==
X-Received: by 10.66.121.195 with SMTP id lm3mr22857270pab.84.1443442824979;
Mon, 28 Sep 2015 05:20:24 -0700 (PDT)
Received: from [192.168.1.100] (cpe-76-167-237-202.san.res.rr.com.
[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
fu4sm19138353pbb.59.2015.09.28.05.20.24
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 28 Sep 2015 05:20:24 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CALqxMTFEme9gYHTAVVLtFc4JCK4hoBLXEhMCRdEXK9cWso_pUA@mail.gmail.com>
<CA+w+GKQ8xos6S_BBMqZy6wieFCG=eNxahKXrx3mVKuZcxzjruw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----FDFLLDMMV4R1M3Y1PXVM8C9X38HAPL"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Mon, 28 Sep 2015 05:20:31 -0700
To: Mike Hearn <hearn@vinumeris.com>,
Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Adam Back <adam@cypherspace.org>
Message-ID: <4965E9A0-0FF1-4A3F-9165-A21AF976E229@gmail.com>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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, 28 Sep 2015 12:20:26 -0000
------FDFLLDMMV4R1M3Y1PXVM8C9X38HAPL
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
Perhaps Adam won't go into the rationale...but I think it is important we clarify this.
For better or worse, the only "voting" system available to Bitcoin that cannot be trivially attacked is hashing power. Soft forks are essentially miner-enforced rule changes...rules they could have decided to enforce without the consensus of anyone else. For instance, as far as old nodes are concerned, a p2sh output can be redeemed by a simple preimage of the hash...with no signatures. The point, however, is that as long as the majority of hashpower enforces the new rule, such attempts to redeem the output will never end up on the blockchain. Therefore, transactions that attempt to redeem the output with a simple preimage are as good as invalid...and effectively have become invalid.
I concede that this mechanism has some issues. Moreover, I agree that it is important that the Bitcoin community be aware of these things. I've been proposing making these rule changes explicit in the BIPs (https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki). I believe it is important that people weigh in on such rule changes. However, the above stated mechanism does not fall under the definition of "hard fork" we've come to accept.
Go ahead and object to soft forks...but at least try not to make arguments based on changing the definitions of terms we all generally agree upon.
- Eric
On September 28, 2015 4:40:35 AM PDT, Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> The rationale for soft vs hard-forks is well known, so I wont go over
>them.
>>
>
>The rationale of "backwards compatibility" is well known, yet wrong.
>I've
>gone over the arguments here and explained why the concept makes no
>sense:
>
>https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
>
>Eric - no, it's not sophisticated humour. I've been objecting to soft
>forks
>since this idea first appeared.
>
>There is no consensus. Now pick. Lose the requirement that everyone
>agree
>for consensus changes, and tell people you've done it. Change the spec.
>Or
>do nothing.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------FDFLLDMMV4R1M3Y1PXVM8C9X38HAPL
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>Perhaps Adam won't go into the rationale...but I think it is important we clarify this.<br>
<br>
For better or worse, the only "voting" system available to Bitcoin that cannot be trivially attacked is hashing power. Soft forks are essentially miner-enforced rule changes...rules they could have decided to enforce without the consensus of anyone else. For instance, as far as old nodes are concerned, a p2sh output can be redeemed by a simple preimage of the hash...with no signatures. The point, however, is that as long as the majority of hashpower enforces the new rule, such attempts to redeem the output will never end up on the blockchain. Therefore, transactions that attempt to redeem the output with a simple preimage are as good as invalid...and effectively have become invalid.<br>
<br>
I concede that this mechanism has some issues. Moreover, I agree that it is important that the Bitcoin community be aware of these things. I've been proposing making these rule changes explicit in the BIPs (<a href="https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki">https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki</a>). I believe it is important that people weigh in on such rule changes. However, the above stated mechanism does not fall under the definition of "hard fork" we've come to accept.<br>
<br>
Go ahead and object to soft forks...but at least try not to make arguments based on changing the definitions of terms we all generally agree upon.<br>
<br>
- Eric<br><br><div class="gmail_quote">On September 28, 2015 4:40:35 AM PDT, Mike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The rationale for soft vs hard-forks is well known, so I wont go over them.<br /></blockquote><div><br /></div><div>The rationale of "backwards compatibility" is well known, yet wrong. I've gone over the arguments here and explained why the concept makes no sense:</div><div><br /></div><div><a href="https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7">https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7</a><br /></div><div><br /></div><div>Eric - no, it's not sophisticated humour. I've been objecting to soft forks since this idea first appeared.</div><div><br /></div><div>There is no consensus. Now pick. Lose the requirement that everyone agree for consensus changes, and tell people you've done it.
Change
the spec. Or do nothing.</div></div></div></div>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
------FDFLLDMMV4R1M3Y1PXVM8C9X38HAPL--
|
