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
162
163
164
165
166
167
168
169
|
Return-Path: <james.hilliard1@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 309A2902
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Dec 2015 02:47:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
[209.85.217.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32D8614E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Dec 2015 02:47:03 +0000 (UTC)
Received: by lbbkw15 with SMTP id kw15so39300995lbb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 05 Dec 2015 18:47:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=BHW8xhm43yzL6++kzUvFZeHvP3sg3x50+xOgfRkWcwk=;
b=JfF+nAUu/zSqNGIJ9y9bARTHjju1xbSiGbzIrXIiRX450kKxjEgTLQExl/juNbiNC3
YlANHimhw57pryIeIw+sNu/OKNCq2lKqRHBCql28jVX9egO8BSjNWF6qnExRWXB4jMDP
ANkqWLM82k6R+yiiV/XjRL0GO2PvjqTJQ10eKX0KaH7xwFHt/TWc169dowkY0KjYplHv
ANTqfhxa6k3j3C4anjiP4ar1/5t+I2WjrMbVIifl+/6AwZEjN+zZrGOVyEWQcaHewAxp
GB+gQLyyh2v1hvaEJNK3ppEyU+xk1F20KqAK5BHkGG3ZWyTEfrfunxV4jyGPyV8WbYxH
Pfsg==
MIME-Version: 1.0
X-Received: by 10.112.171.99 with SMTP id at3mr11440764lbc.108.1449370021637;
Sat, 05 Dec 2015 18:47:01 -0800 (PST)
Received: by 10.112.183.169 with HTTP; Sat, 5 Dec 2015 18:47:01 -0800 (PST)
In-Reply-To: <871tb16diz.fsf@rustcorp.com.au>
References: <CAAS2fgRwfQNYxCmDPAnVudyAti9v8PPXQjxe9M13pmrFxKcSCQ@mail.gmail.com>
<CABsx9T1vBRMYm6rLuqzvOxD0eABE4saF44JzZjMF3iUU==Nz0Q@mail.gmail.com>
<871tb16diz.fsf@rustcorp.com.au>
Date: Sat, 5 Dec 2015 20:47:01 -0600
Message-ID: <CADvTj4q_Ubrk6a15Q4uB3MT0PHGnvZt3yPMOWCdPhWf_WGH-tA@mail.gmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c2676649b89c052631c1e5
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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
X-Mailman-Approved-At: Sun, 06 Dec 2015 06:14:59 +0000
Subject: Re: [bitcoin-dev] Blockchain verification flag (BIP draft)
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: Sun, 06 Dec 2015 02:47:04 -0000
--001a11c2676649b89c052631c1e5
Content-Type: text/plain; charset=UTF-8
I think something that anyone who isn't validating should be aware of is
that cgminer(which powers the vast majority of the current mining network)
doesn't allow for a pool to revert to mining on the previous block due to
the way chain tracking is implemented.
https://github.com/ckolivas/cgminer/blob/master/cgminer.c#L4727
On Fri, Dec 4, 2015 at 4:43 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > Overall, good idea.
> >
> > Is there a write-up somewhere describing in detail the 'accidental
> selfish
> > mining' problem that this mitigates? I think a link in the BIP to a
> fuller
> > description of the problem and how validation-skipping makes it go away
> > would be helpful.
> >
> > RE: which bit to use: the draft versionbits BIP and BIP101 use bit 30;
> to
> > avoid confusion, I think it would be better to use bit 0.
>
> Yes, BIP9 need to be adjusted (setting bit 30 means BIP9 counts it as a
> vote against all softforks). BIP101 uses bits 0,1,2 AFAICT, so perhaps
> start from the other end and use bit 29? We can bikeshed that later
> though...
>
> > I agree with Jannes Faber, behavior with respect to SPV clients should be
> > to only tell them about fully validated headers.
>
> A delicate balance. If we penalize these blocks too much, it's
> disincentive to set the bit. Fortunately it's easy for SPV clients to
> decide for themselves, I think?
>
> Cheers,
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11c2676649b89c052631c1e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think something that anyone who isn't validating sho=
uld be aware of is that cgminer(which powers the vast majority of the curre=
nt mining network) doesn't allow for a pool to revert to mining on the =
previous block due to the way chain tracking is implemented.<br><br><a href=
=3D"https://github.com/ckolivas/cgminer/blob/master/cgminer.c#L4727">https:=
//github.com/ckolivas/cgminer/blob/master/cgminer.c#L4727</a><br></div><div=
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Dec 4, 2015 a=
t 4:43 PM, Rusty Russell via bitcoin-dev <span dir=3D"ltr"><<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">Gavin Andresen via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>><br>
writes:<br>
<span class=3D"">> Overall, good idea.<br>
><br>
> Is there a write-up somewhere describing in detail the 'accidental=
selfish<br>
> mining' problem that this mitigates? I think a link in the BIP to =
a fuller<br>
> description of the problem and how validation-skipping makes it go awa=
y<br>
> would be helpful.<br>
><br>
> RE: which bit to use:=C2=A0 the draft versionbits BIP and BIP101 use b=
it 30; to<br>
> avoid confusion, I think it would be better to use bit 0.<br>
<br>
</span>Yes, BIP9 need to be adjusted (setting bit 30 means BIP9 counts it a=
s a<br>
vote against all softforks).=C2=A0 BIP101 uses bits 0,1,2 AFAICT, so perhap=
s<br>
start from the other end and use bit 29?=C2=A0 We can bikeshed that later<b=
r>
though...<br>
<span class=3D""><br>
> I agree with Jannes Faber, behavior with respect to SPV clients should=
be<br>
> to only tell them about fully validated headers.<br>
<br>
</span>A delicate balance.=C2=A0 If we penalize these blocks too much, it&#=
39;s<br>
disincentive to set the bit.=C2=A0 Fortunately it's easy for SPV client=
s to<br>
decide for themselves, I think?<br>
<br>
Cheers,<br>
Rusty.<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<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>
</div></div></blockquote></div><br></div>
--001a11c2676649b89c052631c1e5--
|
