Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 15ED8AB9 for ; Thu, 4 May 2017 14:58:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E555413E for ; Thu, 4 May 2017 14:58:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out01.mykolab.com (Postfix) with ESMTPS id B005E62228 for ; Thu, 4 May 2017 16:58:00 +0200 (CEST) From: Tom Zander To: bitcoin-dev@lists.linuxfoundation.org, Erik Aronesty via bitcoin-dev Date: Thu, 04 May 2017 16:57:59 +0200 Message-ID: <67911104.PTmAhAhWMc@strawberry> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 04 May 2017 14:58:48 +0000 Subject: Re: [bitcoin-dev] Full node "tip" function X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:58:05 -0000 I agree with you here, Erik. Greg's standard answer doesn=E2=80=99t apply t= o your=20 suggestion. I think he was a bit too trigger happy because we have seen a lot of simila= r=20 suggestions that have the Sybill issue he mentioned. On Thursday, 4 May 2017 15:15:02 CEST Erik Aronesty via bitcoin-dev wrote: > > Greg > > The primary result would be paying people to sybil attack the network. >=20 > I cannot imagine the benefit to replicating an ip address in this case, > except maybe you think that you would be more likely to be selected as a > peer? But there would be no actual advantage since download peers are > selected based on throughput and actual blocks served. =2D-=20 Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel