From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 432FBFD6 for ; Thu, 4 Feb 2016 22:15:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8DC08106 for ; Thu, 4 Feb 2016 22:15:43 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id cw1so39623524lbb.1 for ; Thu, 04 Feb 2016 14:15:43 -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 :cc:content-type; bh=FWOKokYgOdYyPyNBc/kmXXfL1puU0yPnCgnJ7r6pbTA=; b=QqugfeDVwWY67D8LrQUJCEwgW8wlrXTk5c+HiE94cr7fEsnEOhP3/IKdaHlvlgCTlt kSELA6YLYPvKfYjk1hxI+oyxJ26YbNy8tcLcQdLqKQwQR4asx0OwTggsSCIN8/X3XeaR he83KdaBeMHGCFIC/PhS3rAoFar42z24zqa6JE6h537wX37HocJTMSggs8UotepdyH26 pk/cg4D8WFLGngBc2YqS/UcoIuD8BPni2BKxieG1aRJPvPNRIk2Ffl0tuFdGZ70f8KQ6 2rxQbaihLVK1ZzWGiRKjuHfesLi+LKuyi29Wu07NtwaEmMdLxA0LGdEzRiIUjVa0BSHc 4aCg== 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=FWOKokYgOdYyPyNBc/kmXXfL1puU0yPnCgnJ7r6pbTA=; b=cVaXlf4upKoEjTf1XIV0EW+76y2su9i3uLnHaRsgyZQ+XbtdEzZTzk6TVtnUIhE2iQ GJS2IA9ef+lBf3pxEilnT0IZq8QpIssv+CvEnoKX6GMFFuy/p6BQQFDArE9ZQk0/Hzcb j/RbFjtVZ7YCkZNXemyrhO+s2o11E9W3M+7p0/a1sfoZlyKetuvK0tF7NnNnqcR6kBGL 8eVA6mgYcQvcFYSYcBRMehzixMUX8dpqowyCp5GMlSyez68x4Fb5zV9D3pICKo9u3PTC E1HCFQiaHtT++mhYruYF1h3xlXLsE/1YVkfv4uWIQZs+WY7p1NLAQdsv+xQJHTreLeMY aF5Q== X-Gm-Message-State: AG10YORSraejEfAr+yBrzZx8orLjv58xzwZ9bHJ56Eo+pVer+aZ80pMFQb2vK6Ejed/ZpivabA44B40LDVl91A== MIME-Version: 1.0 X-Received: by 10.112.132.36 with SMTP id or4mr4485132lbb.50.1454624142065; Thu, 04 Feb 2016 14:15:42 -0800 (PST) Received: by 10.25.79.208 with HTTP; Thu, 4 Feb 2016 14:15:41 -0800 (PST) In-Reply-To: References: Date: Thu, 4 Feb 2016 17:15:41 -0500 Message-ID: From: Gavin Andresen To: Gregory Maxwell Content-Type: multipart/alternative; boundary=047d7b3a822c450c5e052af9136b X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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: Thu, 04 Feb 2016 22:30:16 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Hardfork bit BIP 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: Thu, 04 Feb 2016 22:15:44 -0000 --047d7b3a822c450c5e052af9136b Content-Type: text/plain; charset=UTF-8 It is always possible I'm being dense, but I still don't understand how this proposal makes a chain-forking situation better for anybody. If there are SPV clients that don't pay attention to versions in block headers, then setting the block version negative doesn't directly help them, they will ignore it in any case. If the worry is full nodes that are not upgraded, then a block with a negative version number will, indeed, fork them off the the chain, in exactly the same way a block with new hard-forking consensus rules would. And with the same consequences (if there is any hashpower not paying attention, then a worthless minority chain might continue on with the old rules). If the worry is not-upgraded SPV clients connecting to the old, not-upgraded full nodes, I don't see how this proposed BIP helps. I think a much better idea than this proposed BIP would be a BIP that recommends that SPV clients to pay attention to block version numbers in the headers that they download, and warn if there is a soft OR hard fork that they don't know about. It is also a very good idea for SPV clients to pay attention to timestamps in the block headers that the receive, and to warn if blocks were generated either much slower or faster than statistically likely. Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in general. -- -- Gavin Andresen --047d7b3a822c450c5e052af9136b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is always possible I'm being dense, but I still don= 't understand how this proposal makes a chain-forking situation better = for anybody.

If there are SPV clients that don't pay= attention to versions in block headers, then setting the block version neg= ative doesn't directly help them, they will ignore it in any case.

If the worry is full nodes that are not upgraded, then= a block with a negative version number will, indeed, fork them off the the= chain, in exactly the same way a block with new hard-forking consensus rul= es would. And with the same consequences (if there is any hashpower not pay= ing attention, then a worthless minority chain might continue on with the o= ld rules).

If the worry is not-upgraded SPV client= s connecting to the old, not-upgraded full nodes, I don't see how this = proposed BIP helps.

I think a much better idea tha= n this proposed BIP would be a BIP that recommends that SPV clients to pay = attention to block version numbers in the headers that they download, and w= arn if there is a soft OR hard fork that they don't know about.

It is also a very good idea for SPV clients to pay attent= ion to timestamps in the block headers that the receive, and to warn if blo= cks were generated either much slower or faster than statistically likely. = Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in ge= neral.

--
--
Gavin An= dresen

--047d7b3a822c450c5e052af9136b--