Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 309A2902 for ; 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 ; Sun, 6 Dec 2015 02:47:03 +0000 (UTC) Received: by lbbkw15 with SMTP id kw15so39300995lbb.0 for ; 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: <871tb16diz.fsf@rustcorp.com.au> Date: Sat, 5 Dec 2015 20:47:01 -0600 Message-ID: From: James Hilliard 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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
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.

https:= //github.com/ckolivas/cgminer/blob/master/cgminer.c#L4727

On Fri, Dec 4, 2015 a= t 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 awa= y
> would be helpful.
>
> RE: which bit to use:=C2=A0 the draft versionbits BIP and BIP101 use b= it 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 a= s a
vote against all softforks).=C2=A0 BIP101 uses bits 0,1,2 AFAICT, so perhap= s
start from the other end and use bit 29?=C2=A0 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.=C2=A0 If we penalize these blocks too much, it&#= 39;s
disincentive to set the bit.=C2=A0 Fortunately it's easy for SPV client= s to
decide for themselves, I think?

Cheers,
Rusty.
___________________________________= ____________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a11c2676649b89c052631c1e5--