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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 796D0C22
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 21:03:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
[209.85.212.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CF1011A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 21:03:44 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so2208176wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 14:03:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=QL/RxPpc3bkOBjweHzGfIfYnz71p/o/afVbnNF2fAvg=;
b=Z7lzJYWom5OqjpnJZSC+JMbriLOb0n7HCsxa1ueCaLkuzu3dAynjWbhX5TNwiYTtwq
6mD38biXWKTCiEmjWyrEnbE1+Eqm2HpgXyAjckQ7muxagJMAqhE/65Nk5PIX9bRvnJpQ
PkNA+Q2UppA+SSNwKyrXoz7zqLSKXZvA8TRAxtXCkHlGxoiUFpaOcbDPSLgB19JSEY7w
/jPq1/S3YRrzSKaxuInsyqlelb0cqlurh8dQK4pF7RT817UDKe+30Qk1VepetgX3IMxu
K5HkGfMmw2NL7tRY/gmYmdYgocePfxAKl3yF1c5CvZ1c416v0O8QUSxFDAWUZdMwL2wp
i4Fw==
X-Gm-Message-State: ALoCoQlDJZnnYsIZEXlsGydPAqT71YSZ2fwXZJ3VEPtFQuBe1lwO/hIy9bhYm3Rbe7apkCETnac1
MIME-Version: 1.0
X-Received: by 10.180.84.225 with SMTP id c1mr460301wiz.92.1442437423534; Wed,
16 Sep 2015 14:03:43 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 14:03:43 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 14:03:43 -0700 (PDT)
In-Reply-To: <CAE-z3OUyNpmG5uhSCExf39zmmB-b9xDrn+gkp3UFeg7M3G8E5g@mail.gmail.com>
References: <87mvwqb132.fsf@rustcorp.com.au>
<CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
<87r3lyjewl.fsf@rustcorp.com.au>
<CABm2gDqh=Dv2Ygctg+jEt61N_nJDRBMqdZypSPtmfM2QrY4AYQ@mail.gmail.com>
<CAE-z3OXATJ6HGKqU=vxc8k-yCMAMwXiWQJxvO3D_O256_ZODtw@mail.gmail.com>
<CABm2gDppFsTbh3JtdJkAkV_GzKFYAOLiEmtQPCgS9O6b7eWFuw@mail.gmail.com>
<CAE-z3OXbUhsyzd=8hxzFAST9rEQyTg9whn+CMh92S0FMdLH4ug@mail.gmail.com>
<CABm2gDo4f6bpJeobwRyoukKw9t=ApuRtHMYWpWFXjv9=K7aFyA@mail.gmail.com>
<CAE-z3OUyNpmG5uhSCExf39zmmB-b9xDrn+gkp3UFeg7M3G8E5g@mail.gmail.com>
Date: Wed, 16 Sep 2015 23:03:43 +0200
Message-ID: <CABm2gDphLRQ6huhxvcx1YvbsmaBHA_sk6MEZF+hgdxoC472P+w@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0418282e3da8bd051fe3a2e3
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no 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] [BIP Proposal] Version bits with timeout and
delay.
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: Wed, 16 Sep 2015 21:03:45 -0000
--f46d0418282e3da8bd051fe3a2e3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I understand your proposal, but I don't see what it accomplishes compared
to applying the new rule from the start (in your own blocks) and wait for
95% for consensus activation (which is my preference and it's much simpler
to implement).
What are the disadvantages of my approach? What are the advantages of yours=
?
On Sep 16, 2015 4:57 PM, "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> On Wed, Sep 16, 2015 at 9:54 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrot=
e:
>
>>
>> On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > At 75%, if someone sets the bit, then they should be creating valid
>> blocks (under the rule).
>>
>> You shouldn't rely on that, some may start applying the restrictions in
>> their own blocks at 0% and others only at 90%. Until it becomes a consen=
sus
>> rule it is just part of the standard policy (and we shouldn't rely on no=
des
>> following the standard policy).
>>
>
> It would be a consensus rule. If >75% of the blocks in the last 2016
> window have the bit set, then reject all blocks that have the bit set and
> fail to meet the rule.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--f46d0418282e3da8bd051fe3a2e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I understand your proposal, but I don't see what it acco=
mplishes compared to applying the new rule from the start (in your own bloc=
ks) and wait for 95% for consensus activation (which is my preference and i=
t's much simpler to implement).<br>
What are the disadvantages of my approach? What are the advantages of yours=
?</p>
<div class=3D"gmail_quote">On Sep 16, 2015 4:57 PM, "Tier Nolan via bi=
tcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attributi=
on"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Wed, Sep 16, 2015 at 9:54 PM, Jor=
ge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D"mailto:jtimon@jtimon.cc" tar=
get=3D"_blank">jtimon@jtimon.cc</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div><p dir=3D"ltr"><br>
On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>> wrote:<br>
> At 75%, if someone sets the bit, then they should be creating valid bl=
ocks (under the rule).</p>
</div></div><p dir=3D"ltr">You shouldn't rely on that, some may start a=
pplying the restrictions in their own blocks at 0% and others only at 90%. =
Until it becomes a consensus rule it is just part of the standard policy (a=
nd we shouldn't rely on nodes following the standard policy).<span><br>=
</span></p></blockquote><div><br></div><div>It would be a consensus rule.=
=C2=A0 If >75% of the blocks in the last 2016 window have the bit set, t=
hen reject all blocks that have the bit set and fail to meet the rule.<br><=
/div></div><br></div></div>
<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>
--f46d0418282e3da8bd051fe3a2e3--
|
