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: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1F94E1F0E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 1 Oct 2015 02:54:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com
[209.85.220.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A27E7FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 1 Oct 2015 02:54:25 +0000 (UTC)
Received: by pablk4 with SMTP id lk4so58525019pab.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 19:54: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=xStGdmfkc5SBlMDn9YV4bwzaoimGXJOJeaFY0Zy5A9A=;
b=HMAgX1xSmKROIorySKjKA4mUgCPMN0HwcKYZR3SpP5O5IO1xrPcFPrKcQua43V2erl
jqRSstkKRzlnXqNk6pqXBRqF3MufaCqSBWxpLK0MeM2wrw5VKhw9UQ2PMT8ja7/ybFF2
k1oG1xWuj1/lECWusWjrTEsyo+R2jheO0FY3YmK/q20dOOe+lFfRvHs1n6vZsINiN+SU
/6bTqIFe1gcZQcnxPPQ0yBH04drE6MDwPjKIshu5rTpajkXVccY4shtUqE1mrXFGLx10
mrKeBzzQpvSoKNTarFMfyxsKCPHuEhdn2K5jkD56I+VRS/MLjKFKbG7TpcswCDrpNCJn
zegw==
X-Received: by 10.66.159.201 with SMTP id xe9mr9086232pab.54.1443668065379;
Wed, 30 Sep 2015 19:54:25 -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
kv9sm3257947pab.39.2015.09.30.19.54.24
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 30 Sep 2015 19:54:24 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <87bncjph6c.fsf@rustcorp.com.au>
References: <87zj04fxkw.fsf@rustcorp.com.au>
<CAAS2fgTXP0j6K3sxp=HL9j2-xvO8y_VnpG+iZw9kaxmnxZQjSw@mail.gmail.com>
<87bncjph6c.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----IOGPRRM1JMEXHC69MOAJFU5LC1UZ14"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Wed, 30 Sep 2015 19:54:34 -0700
To: Rusty Russell <rusty@rustcorp.com.au>, Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <A0342136-AA7C-4355-BCDA-C6AE8D6BCCB4@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>,
Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.
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: Thu, 01 Oct 2015 02:54:27 -0000
------IOGPRRM1JMEXHC69MOAJFU5LC1UZ14
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
I can go along with making it optional but recommended for the first deployment and making it mandatory later on. It would be purely informational for now...but it will give us valuable data.
As has been said before, most of these BIP deployments will likely be accompanied by recommended default settings for miners. Assuming the BIP itself is not very controversial, the gravest dangers come not so much from miners (or pool operators, more accurately) deliberately choosing to lie...but more from either shortcuts taken in implementations and/or bugs. Collecting additional data will help spot faulty implementations and allow us to intervene.
Eventually, I imagine a much more sophisticated signaling mechanism where endusers can be given highly informative messages regarding changes and we can have a way of directing people to resources where they can learn more about the new features.
- Eric
On September 30, 2015 5:26:51 PM PDT, Rusty Russell <rusty@rustcorp.com.au> wrote:
>Gregory Maxwell <gmaxwell@gmail.com> writes:
>> I can, however, argue it the other way (and probably have in the
>> past): The bit is easily checked by thin clients, so thin clients
>> could use it to reject potentially ill-fated blocks from non-upgraded
>> miners post switch (which otherwise they couldn't reject without
>> inspecting the whole thing). This is an improvement over not forcing
>> the bit, and it's why I was previously in favor of the way the
>> versions were enforced. But, experience has played out other ways,
>> and thin clients have not done anything useful with the version
>> numbers.
>>
>> A middle ground might be to require setting the bit for a period of
>> time after rule enforcing begins, but don't enforce the bit, just
>> enforce validity of the block under new rules. Thus a thin client
>> could treat these blocks with increased skepticism.
>
>Introducing this later would trigger warnings on older clients, who
>would consider the bit to represent a new soft fork :(
>
>So if we want this middle ground, we should sew it in now, though it
>adds a other state. Simplest is to have miners keep setting the bit
>for
>another 2016 blocks. If we want to later, we can make this a consensus
>rule.
>
>"Bitcoin is hard, let's go shopping!" "With Bitcoin!" "..."
>Rusty.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------IOGPRRM1JMEXHC69MOAJFU5LC1UZ14
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>I can go along with making it optional but recommended for the first deployment and making it mandatory later on. It would be purely informational for now...but it will give us valuable data.<br>
<br>
As has been said before, most of these BIP deployments will likely be accompanied by recommended default settings for miners. Assuming the BIP itself is not very controversial, the gravest dangers come not so much from miners (or pool operators, more accurately) deliberately choosing to lie...but more from either shortcuts taken in implementations and/or bugs. Collecting additional data will help spot faulty implementations and allow us to intervene.<br>
<br>
Eventually, I imagine a much more sophisticated signaling mechanism where endusers can be given highly informative messages regarding changes and we can have a way of directing people to resources where they can learn more about the new features.<br>
<br>
- Eric<br><br><div class="gmail_quote">On September 30, 2015 5:26:51 PM PDT, Rusty Russell <rusty@rustcorp.com.au> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Gregory Maxwell <gmaxwell@gmail.com> writes:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> I can, however, argue it the other way (and probably have in the<br /> past): The bit is easily checked by thin clients, so thin clients<br /> could use it to reject potentially ill-fated blocks from non-upgraded<br /> miners post switch (which otherwise they couldn't reject without<br /> inspecting the whole thing). This is an improvement over not forcing<br /> the bit, and it's why I was previously in favor of the way the<br /> versions were enforced. But, experience has played out other ways,<br /> and thin clients have not done anything useful with the version<br /> numbers.<br /><br /> A middle ground might be to require setting the bit for a period of<br /> time after rule enforcing begins, but don't enforce the bit, just<br /> enforce validity of the block under new rules. T
hus a
thin client<br /> could treat these blocks with increased skepticism.<br /></blockquote><br />Introducing this later would trigger warnings on older clients, who<br />would consider the bit to represent a new soft fork :(<br /><br />So if we want this middle ground, we should sew it in now, though it<br />adds a other state. Simplest is to have miners keep setting the bit for<br />another 2016 blocks. If we want to later, we can make this a consensus<br />rule.<br /><br />"Bitcoin is hard, let's go shopping!" "With Bitcoin!" "..."<br />Rusty.<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
------IOGPRRM1JMEXHC69MOAJFU5LC1UZ14--
|
