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
156
157
158
159
160
161
|
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 4C58615CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 22:52:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f173.google.com (mail-io0-f173.google.com
[209.85.223.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2987725A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 22:52:05 +0000 (UTC)
Received: by ioiz6 with SMTP id z6so3768888ioi.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 15:52:04 -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=DhGqm4BrrDyEFhPCSDLBIFz7b9PG5yCDYrn0/BMLcEU=;
b=PTJjgg+7NnIfBl7Ztw20Vn/j0dHRSI4V/pBicGPFhYTjFkwsnIm+PMLAJFqODqh2fd
E/peQfhkYmkuOWEow2FYJPbghsCC5olcI0s7GAfCRXtblVLtvZolvmf1KnvJwbhqfuBy
6VEu05jYhujGKCjy1nU6sIYqquvzjH9rpFX6V1fVBQjZsny39cMSkUJvjAbVDT2cAwAQ
FPvbtvTpEN7NNGgUqF/O7Cf5HSnMOxHBc6IxdOfutX109vYtIVV5ePW0XkiPKlXwYbpz
0+5mBUfF1+8++LGnf1pwUjXlIVxPk4QnYn1QSYwn6HDzDKdcC7qwV2RpCVB4uPXCh0vL
nwaQ==
X-Received: by 10.107.26.138 with SMTP id a132mr976294ioa.5.1442443924617;
Wed, 16 Sep 2015 15:52:04 -0700 (PDT)
Received: from android-497033634a7205c7 ([24.114.98.80])
by smtp.gmail.com with ESMTPSA id m25sm34996iod.32.2015.09.16.15.52.03
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 16 Sep 2015 15:52:04 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <CABm2gDphLRQ6huhxvcx1YvbsmaBHA_sk6MEZF+hgdxoC472P+w@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>
<CABm2gDphLRQ6huhxvcx1YvbsmaBHA_sk6MEZF+hgdxoC472P+w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----JNDJW5AOVC5NQ6GC1NHQQCU6O162PO"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Wed, 16 Sep 2015 18:52:09 -0400
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@jtimon.cc>,
=?ISO-8859-1?Q?Jorge_Tim=F3n_via_bitcoin-dev?=
<bitcoin-dev@lists.linuxfoundation.org>, Tier Nolan <tier.nolan@gmail.com>
Message-ID: <CDB1F26E-FE26-44F3-9A86-CDAE33A51B8B@gmail.com>
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 22:52:06 -0000
------JNDJW5AOVC5NQ6GC1NHQQCU6O162PO
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
The exact numbers (95% vs. 75% etc) don't need to be completely specified to start working on an implementation. What really matters for now is defining the states and trigger mechanisms. I'd rather we not argue over the optimal values for supermajority requirement at this point.
On September 16, 2015 5:03:43 PM EDT, "Jorge Timón via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>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ón <jtimon@jtimon.cc>
>wrote:
>>
>>>
>>> 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
>consensus
>>> rule it is just part of the standard policy (and we shouldn't rely
>on nodes
>>> 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
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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.
------JNDJW5AOVC5NQ6GC1NHQQCU6O162PO
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>The exact numbers (95% vs. 75% etc) don't need to be completely specified to start working on an implementation. What really matters for now is defining the states and trigger mechanisms. I'd rather we not argue over the optimal values for supermajority requirement at this point.<br><br><div class="gmail_quote">On September 16, 2015 5:03:43 PM EDT, "Jorge Timón 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;">
<p dir="ltr">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).<br />
What are the disadvantages of my approach? What are the advantages of yours?</p>
<div class="gmail_quote">On Sep 16, 2015 4:57 PM, "Tier Nolan via bitcoin-dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type="attribution" /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Sep 16, 2015 at 9:54 PM, Jorge Timón <span dir="ltr"><<a href="mailto:jtimon@jtimon.cc" target="_blank">jtimon@jtimon.cc</a>></span> wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><p dir="ltr"><br />
On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br />
> At 75%, if someone sets the bit, then they should be creating valid blocks (under the rule).</p>
</div></div><p dir="ltr">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 consensus rule it is just part of the standard policy (and 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. 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.<br /></div></div><br /></div></div>
<br />_______________________________________________<br />
bitcoin-dev mailing list<br />
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br />
<br /></blockquote></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>
------JNDJW5AOVC5NQ6GC1NHQQCU6O162PO--
|
