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
|
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 294461392
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 20:38:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com
[209.85.212.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98C93176
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 20:38:21 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so90003726wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 13:38:20 -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=ymBQCkpK1e9ibQC1DuwPEk7x7vtjp8O4yXpqAYuOrek=;
b=FcnVnnYAnrTDAj5/H08MAlvzqN9Y/ekmd4gB+801LT1U86l7F1UZJ1lNJjfu8Zy4q1
1TSO3/GcwVT2W1kU4Wr5pr6xhASCOW6yQJj5UN+svIxkvnj6PLLwc9Oor0rpDs+/g60D
sbfLCaz0iYBw5RHndZxkfdJ4HjeB9kaJ/wHB9maiGyU4//WBKml/lf8KQuxnqKL5H5Jt
wiZrJPIHUkb6mCwXoHHEuPPo8XnI3Scmg8yueYo59sdWGTPNPkzBpH7iupC4MZL6D52q
P0N0vAETxTgNq2OZNIQQPpqnleEHgUDlZTbbZ8cCmRq7sHzEmjGi9yfQg2Ch9ye+1+57
5pgg==
X-Gm-Message-State: ALoCoQk9XNDzDmxSdvbFoVxOTJZ+JwGxbkmSuLttCdGHNiBSz+l3bS2bUkwSzsZ0Xsn9a+v03/lo
MIME-Version: 1.0
X-Received: by 10.194.238.39 with SMTP id vh7mr54092509wjc.109.1442435900251;
Wed, 16 Sep 2015 13:38:20 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 13:38:20 -0700 (PDT)
Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 13:38:20 -0700 (PDT)
In-Reply-To: <CAE-z3OXATJ6HGKqU=vxc8k-yCMAMwXiWQJxvO3D_O256_ZODtw@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>
Date: Wed, 16 Sep 2015 22:38:20 +0200
Message-ID: <CABm2gDppFsTbh3JtdJkAkV_GzKFYAOLiEmtQPCgS9O6b7eWFuw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=089e0141aa1a7239ea051fe3474e
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] [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 20:38:22 -0000
--089e0141aa1a7239ea051fe3474e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
No, 95% is safer and will produce less orphaned blocks.
0%is fine to do it in your own blocks.
I agree on using height vs time. Rusty, what do you mean by being easier
for bip writers? How is writing "block x" any harder than writing "date y".
On Sep 16, 2015 4:32 PM, "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> On Wed, Sep 16, 2015 at 9:27 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrot=
e:
>
>> For enforcing new restrictions on your own blocks (thus at the policy
>> level, not consensus) you don't need to wait for 75%. You can do it from
>> the start (this way all miners setting the bit will enforce the new
>> restrictions.
>>
> At 75%, you have a pretty solid super-majority.
>
> You can safely reject blocks that have the bit set but are invalid
> according to the new rule (as long as everyone who sets the bit does it
> too).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--089e0141aa1a7239ea051fe3474e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">No, 95% is safer and will produce less orphaned blocks.<br>
0%is fine to do it in your own blocks.</p>
<p dir=3D"ltr">I agree on using height vs time. Rusty, what do you mean by =
being easier for bip writers? How is writing "block x" any harder=
than writing "date y".</p>
<div class=3D"gmail_quote">On Sep 16, 2015 4:32 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:27 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"><p dir=3D"ltr">For enforcing new restrictions on your own blo=
cks (thus at the policy level, not consensus) you don't need to wait fo=
r 75%. You can do it from the start (this way all miners setting the bit wi=
ll enforce the new restrictions.</p></blockquote><div>At 75%, you have a pr=
etty solid super-majority.=C2=A0 <br><br>You can safely reject blocks that =
have the bit set but are invalid according to the new rule (as long as ever=
yone who sets the bit does it too).<br></div></div></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>
--089e0141aa1a7239ea051fe3474e--
|
