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 309A4B63 for ; Thu, 11 May 2017 15:13:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id A038822C for ; Thu, 11 May 2017 15:13:15 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 36A6C2E20111; Thu, 11 May 2017 17:13:14 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1, HTML_MESSAGE autolearn=ham version=3.3.1 Received: from [192.168.0.9] (cable-static-238-67.teleport.ch [213.188.238.67]) by server3 (Postfix) with ESMTPSA id B7AB62D00225 for ; Thu, 11 May 2017 17:13:13 +0200 (CEST) From: Jonas Schnelli Content-Type: multipart/signed; boundary="Apple-Mail=_B3834C37-58D1-4038-9828-DFB6EB938649"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 11 May 2017 17:13:12 +0200 To: bitcoin-dev X-Mailer: Apple Mail (2.3273) Subject: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits 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, 11 May 2017 15:13:16 -0000 --Apple-Mail=_B3834C37-58D1-4038-9828-DFB6EB938649 Content-Type: multipart/alternative; boundary="Apple-Mail=_F29B06BA-130C-4081-A868-44259C690DED" --Apple-Mail=_F29B06BA-130C-4081-A868-44259C690DED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Currently, pruned peers have no way how to signal their (valuable) = service. A BIP proposal to improve this (draft): = https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT = Feedback is highly welcome. --Apple-Mail=_F29B06BA-130C-4081-A868-44259C690DED Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi

Currently, pruned peers have no way how to signal their (valuable) service.
A BIP proposal to improve this (draft):

Feedback is highly welcome.

</jonas>
--Apple-Mail=_F29B06BA-130C-4081-A868-44259C690DED-- --Apple-Mail=_B3834C37-58D1-4038-9828-DFB6EB938649 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlkUf4gACgkQHrd2uwPH ki18DxAAx8b53NT5Gviboq6JJ1dTDN1MCoXfWWGN+Invkpqdm5bVoGfssaSOQxJs /yd3ptI2Z6su7m+grgl+mfW8B8y+obT/ShxEbRZC6FANiw6e04512FkgHIAhi9g0 S/T1iufLdR9/XI3GoliQ+4OBK9KtZXKRCbAT6vXogO2rEpo7NIUA8NdZjkMmBBis pTdqVcXGTwCjPJps6Tg3kRjXTp2uyyDdtPxde0drzEu/6aJ/9ovDVDcM1XfXpEQp RIKkw/mlFb4yexk1qjiVcESSCGalsBpRRT9rBB+jCV+OQD3Uu4v1yRMZz/RK1ET9 p4HCQsNhiEZG2zC8iKccYd6w+9MrtdazQCg3mUcejTT3lSRk/pVEIrG9sMlaEYuI +PpAGZCEEzHOiLhlNE5rp96o71tejfrxkxPY/LRoML65yjiT/hMnT/Rx1p5OFg7W kux3dgLI0YUyoDMoJoGvIzlA/iqFQscQTPFlJttN3BrjLLeFicjMyaql5zmjxpn3 TP49fJnzzNwosPL/Zi8CdrMYRTrp3f1Dj787Vcc5yd43lVhSGvLyQByqmp5RRAOB tgl8ysvsLRwxHjAjtJDmOyZtcdAQAbUKKAnudYfPq70LKqrvSoW2gotz3rJkWZw7 E1oWlvLCFmlh7i0qdUeoK5xJaOFTodBfkWbriNRnWm+oNmlJx1w= =q1X3 -----END PGP SIGNATURE----- --Apple-Mail=_B3834C37-58D1-4038-9828-DFB6EB938649-- 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 B26895AC for ; Thu, 11 May 2017 18:17:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C911F0 for ; Thu, 11 May 2017 18:17:21 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id x71so6051523vkd.0 for ; Thu, 11 May 2017 11:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=Q//+hKdIpccbnAks7zlbQnFRtd1KucLkQ1mhjB8vFNc=; b=rhGS43lGX4EfLNbECQZVNFgcyT8R7EVxvjhnDMRjtvzPJGCnj+xK5x5J3H/Ebwz5qY uUrY5jDvUiDZfM0juuppORXeuugZMVheFQAGmKT7ynv1+QFKrzamKU/3QPfBLDbIw3nt W48w6cnUg5AjWo2nr6r+pKw6yqmUzbIOe0qnTF15prirTjj5QuXo4t4byGO3TYjfX6fV tmRw4YsAHJyn05sPddu8Wq0mHwYzExJ/fx1NREkAN9YiJFpCuxY58MAwx4Os7osznUby fL3Tpo88imbI0yw2/9CimQNEWj6PM1UfkZXpAnKtyivHlkaDq3hZbt9y89EKAbBo3qTy PbzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=Q//+hKdIpccbnAks7zlbQnFRtd1KucLkQ1mhjB8vFNc=; b=n+4mpULZtrDotzYAbaw1H9qN0eW5hK0CFZc32tKUtjA3Ka57RgpOqjvHA0GoYioII+ lE9AhIKyNghNf+F42JK5PwpcyBsIH0xyirfp5rEJbSERILaDNggESCh/vv0v/eB1lYjS CwfNbpedkR7BxGAARs0GAE/7Eg62pQHL6ozSjDCAaG+GOClZxBZFEopDdzEU7BSBL45g usUQA0GPL+QKrMFA8SBcQhMpQpTkym9F94ALjIQixvDkCxSvQ6p8cKChktHXybcQE/BV i+49iwDCqx6l99Y3JzwZklt7mnwP6vKu5Q2TqBm5F5bKtSvodBK72IenCUFYBawu/fEO zrLA== X-Gm-Message-State: AODbwcDH9HaadspWGOaGJiLRQQiGGqAhi1kTDZnekgmfqZmohFxTJtDz vKx6cd8UlP33spn9Ur1ZL49OpQt1Jvo4 X-Received: by 10.31.30.18 with SMTP id e18mr130184vke.52.1494526640094; Thu, 11 May 2017 11:17:20 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.20.66 with HTTP; Thu, 11 May 2017 11:17:19 -0700 (PDT) In-Reply-To: References: From: Gregory Maxwell Date: Thu, 11 May 2017 18:17:19 +0000 X-Google-Sender-Auth: pTjsPinKwUcNt_JBQaz2i19T-Xo Message-ID: To: Bitcoin Dev Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits 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, 11 May 2017 18:17:22 -0000 It probably should be stated in terms of what you're promising to do-- 288 and 1152 blocks, not what we hope it will accomplish. Then advise clients to use peers with headroom because their estimates could be wrong and reorgs. Reorgs aren't the only concerns that drive larger numbers: The peak at syncing is at ~24 hours, but sometimes there are quite a few more than 144 blocks in 24 hours. Also, new blocks show up in the chain: you think you're 144 behind but by the time you connect you find you're 146 behind from that peer's perspective. I think it's a bit ambiguous what it's saying about the headers, especially because it goes into detail about address relay. I believe nodes with any of these settings should be willing to serve headers for their entire best chain. Perhaps you could say that this is equivalent to NODE_NETWORK except that they aren't necessarily willing to server historical blocks. I'm unsure about the third depth level. Perhaps that should be left undefined for sending right now and treated as least 1152 blocks by receivers-- I don't have any reason to think 7056 is a particularly useful choice, and we'll need another (longer) level for UTXO based sync. You could probably go further and say that nodes shouldn't send it now, but if sent it means they intend to keep 2016*2 blocks. (Not sending because the requirement for sending it may be that the node is able to send you a UTXO data feed.) > consider to switch a low percentage That isn't grammatical, you want "switching". But I think it would be better to say that when a node believe it is in sync enough to use NODE_NETWORK_LIMITED_X it should just treat them identically to NODE_NETWORK in peer selection. We don't really need any more topology distortion than that. In particular, I don't want to be in a case where NODE_NETWORK peers suddenly find themselves far less well connected. In terms of making room, a node network peer could choose to disconnect the least useful peers that aren't syncing from them to make more room for ones that are. This lets them decide what connections they want, based on how full they are and what is useful to them, rather than finding themselves all lonely because nodes decided to avoid them to be "helpful", and we already use disconnections to manage fullness. On Thu, May 11, 2017 at 3:13 PM, Jonas Schnelli via bitcoin-dev wrote: > Hi > > Currently, pruned peers have no way how to signal their (valuable) service. > A BIP proposal to improve this (draft): > https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT > > Feedback is highly welcome. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > 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 BB364BBF for ; Thu, 11 May 2017 19:25:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 5319D1D9 for ; Thu, 11 May 2017 19:25:28 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 27C9438A0EB7; Thu, 11 May 2017 19:24:23 +0000 (UTC) X-Hashcash: 1:25:170511:bitcoin-dev@lists.linuxfoundation.org::ZW6cWFYHtvM=t46p:bXE+n X-Hashcash: 1:25:170511:dev@jonasschnelli.ch::4qcUF0qkpfa1kLSZ:dxO+5 From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Jonas Schnelli Date: Thu, 11 May 2017 19:24:21 +0000 User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201705111924.22055.luke@dashjr.org> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits 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, 11 May 2017 19:25:28 -0000 > A peer signaling NODE_NETWORK_LIMITED_LOW & NODE_NETWORK_LIMITED_HIGH MUST > be capable of serving at least the last 7'056 blocks (~49 days) > (NODE_NETWORK_LIMITED_HIGH's value ^2). Is 49 days particularly useful? Would it be a problem to instead leave both- bits undefined? I'm thinking this might be better as a way to indicate "7 days, plus a deterministically chosen set of historical blocks"... > Current Bitcoin-Core pruned full nodes guarantees a minimum of 288 blocks, > thus allowing to signal NODE_NETWORK_LIMITED_LOW with the current minimum > configuration. This is technically true right now, but as soon as segwit activates, it will no longer be... Therefore, I suggest striking it from the BIP, expounding on it in greater detail, or making it true for the longer term. > Peers following this BIP SHOULD connect a limited amount of their available > outbound connections to peers signaling one or both of the > NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks > than the signaled number. This isn't entirely clear whether it refers to peers downloading blocks, or peers serving them. (I assume the former, but it should be clarified.) > Light clients (and such) who are not checking the nServiceFlags (service > bits) from a relayed addr-message may unwillingly connect to a pruned peer > and ask for (filtered) blocks at a depth below their pruned depth. Wouldn't this already be a problem, without the BIP? Luke 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 0653CBC3 for ; Thu, 11 May 2017 20:10:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 255681E8 for ; Thu, 11 May 2017 20:10:14 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 0B26F2E20112; Thu, 11 May 2017 22:10:12 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from [192.168.0.9] (cable-static-238-67.teleport.ch [213.188.238.67]) by server3 (Postfix) with ESMTPSA id D11372D00543; Thu, 11 May 2017 22:10:11 +0200 (CEST) From: Jonas Schnelli Message-Id: <61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_BFFE861F-8D60-4FEE-BA6C-CF365B03400D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 22:10:08 +0200 In-Reply-To: <201705111924.22055.luke@dashjr.org> To: Luke Dashjr References: <201705111924.22055.luke@dashjr.org> X-Mailer: Apple Mail (2.3273) Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits 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, 11 May 2017 20:10:15 -0000 --Apple-Mail=_BFFE861F-8D60-4FEE-BA6C-CF365B03400D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Is 49 days particularly useful? Would it be a problem to instead leave = both- > bits undefined? I'm thinking this might be better as a way to indicate = "7 > days, plus a deterministically chosen set of historical blocks"=E2=80=A6= I though two service bits allow three states and we should define all = three combinations. But I guess an adequate =E2=80=9Edefinition=E2=80=9C would be to reserve = it for future =E2=80=9Edefinitions=E2=80=9C. Or use Gregory's proposal of min 2016*2 blocks & keep it =E2=80=9Eundefine= d=E2=80=9C for now. 49 days was chosen to allow SPV peers to be =E2=80=9Eoffline=E2=80=9C = for a month and still be capable to catch-up with a peer pruned to a = datadir of ~10GB. >=20 > This is technically true right now, but as soon as segwit activates, = it will > no longer be... Therefore, I suggest striking it from the BIP, = expounding on > it in greater detail, or making it true for the longer term. AFAIK Core does also guaranteed the 288 blocks post segwit activation: = https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f43= 58c5ae/src/validation.h#L204 But maybe I=E2=80=99m confused. >=20 >> Peers following this BIP SHOULD connect a limited amount of their = available >> outbound connections to peers signaling one or both of the >> NODE_NETWORK_LIMITED_* service bits if they expect to request less = blocks >> than the signaled number. >=20 > This isn't entirely clear whether it refers to peers downloading = blocks, or > peers serving them. (I assume the former, but it should be clarified.) Indeed. I=E2=80=99ll try to make that more clear. >=20 >> Light clients (and such) who are not checking the nServiceFlags = (service >> bits) from a relayed addr-message may unwillingly connect to a pruned = peer >> and ask for (filtered) blocks at a depth below their pruned depth. >=20 > Wouldn't this already be a problem, without the BIP? AFAIK, Core does currently only relay NODE_NETWORK addresses. But yes, It may be a problem already. --Apple-Mail=_BFFE861F-8D60-4FEE-BA6C-CF365B03400D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlkUxSAACgkQHrd2uwPH ki33fw/9Efsw1BX4hTnLj0EfF/z2ybkoG9MsUS07+8du46QxK//IAbztXK8bk6eP J2vaXrU0pxt55fpsLcpyl1YG8IOvzmRKu+5AsBFJ3IveBB1OshJdHrSMk0Yf4fvK +UoWwsZhYp4r1VxKLj/uURFGUmyO5qkq3DwcCvCANvYHLVZB8REZQ0nHRSSbOFQU ygnYWJlr3utXpbdNC+H2KSuWMunTkdD3PSF8HBZMQa/A2cMjS5Z5JV8CrCEcR8cQ 0OukCvVawqJ9MI3sY+zfIgRom2mrsukbnCU8ADnE7Vkh/pWIv2+esd7cxmpek+TT Dvj+3oLYdlh2XsztvoujX0YJ/OQXmf/Qx8LrfelrYvIP4EYnMxt7/HLXSfqsEZKR cnZNS0G1OoLRAobuaIbR/2vMcp4Mf2YoaH2bSWyoeETd3jG7v4l/NGny1MLat5Dw PPsn5rUhmLRmRzZwZ1mx5ZskUuGDR9/HEBe7UKdidh5NpNqqGCtBDpzqwY6AFFt+ 3BE3L77JmXq8I0PHlxQaJyh5sMEmETmKygBG3N7DegHHSY/AbN4tMB4dsW0re4VW xuhZAHaky2zaKa3+KxkorUqwhyXf/9BUIaG8Dwv1qGw3JU6HI9+DzDRHnEeP716k 6TwKW2ZxVKaejoEii3pDgzC1pMpV2UNO23e0vrA5AhFpfGCaQQQ= =m23D -----END PGP SIGNATURE----- --Apple-Mail=_BFFE861F-8D60-4FEE-BA6C-CF365B03400D-- 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 4A58FBB3 for ; Thu, 11 May 2017 20:36:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4039E1FE for ; Thu, 11 May 2017 20:36:36 +0000 (UTC) Received: by mail-wr0-f178.google.com with SMTP id l50so30478141wrc.3 for ; Thu, 11 May 2017 13:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=MxeZRq8GCZ+63lQvEmfo6oSFVWAo2APJJ6IBLsoFyWA=; b=Qf6lxNxlYhdqa+vCiU/DgwMUtNBBPRNrU8hG8csI+A5LqAR67cublpeK5ssWI4CjPn gCy9/8IXzHvLq0BbHfENXFFswOULotat+TEme0OQtdbPoM91EI3qWFF6+GUlsKUxuPCi 4g3kJ7NafSl9TNKZIv+akQliGqnZhfI2COJuWFqvPWfz+JkYdzNFcdphYkSohgQFDYOl yNkjaAnXDofdF5g4FzwW1BCf0MJclxpb/gZwSj486QZ/4rv24Wth3LP01WKIv5ZCNYHD WLewDVFTBgWUG8IyFCJT8Zr10GSSq3s/Oe74Fpa2RakQX5+8Pfw6LM5bKc7PP8sbb7M8 XmVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=MxeZRq8GCZ+63lQvEmfo6oSFVWAo2APJJ6IBLsoFyWA=; b=i67lYEMr3q5G60rjY9uMphNquWf5sEs6ejRG76DNsg8GC7Q8GNRI+ThBxA6AXPIxvB 7TbQFNrF0dXjyrQg8ZvAXuDPzLvd4fLHX4c0qe2P7fYbIBahPChYmk7ReTQTPosw2fGS NHnhtJMODMOthF1gYkavEHB/SZciwhglwZHsbtwzyXSlP1zu2nWiqMLN/ciNKQBzPt4X NFKL3coL0KJddkcc0CGSRR8usrkBb7o8zVoddLeVQs9jWvtc9J1EohZHkdafJU4mZ+LU d/cn+fnYhvXLqrVEnS2N1hedyOaKjerUolKk/I8M+TjNw2evJ/G/GVGT0rwUnw66MDdE mbFw== X-Gm-Message-State: AODbwcDr2YP8E8RM03QjSy6kphs6Ny3QM9xnWH/hHBTjyxCsPq3J1c1p 6g9WZAR7OhGlaPZB X-Received: by 10.223.182.144 with SMTP id j16mr284756wre.64.1494534994681; Thu, 11 May 2017 13:36:34 -0700 (PDT) Received: from [192.168.1.10] (ANice-654-1-58-18.w83-201.abo.wanadoo.fr. [83.201.229.18]) by smtp.googlemail.com with ESMTPSA id e125sm1876351wmd.33.2017.05.11.13.36.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 13:36:34 -0700 (PDT) To: Jonas Schnelli , Luke Dashjr References: <201705111924.22055.luke@dashjr.org> <61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch> From: Aymeric Vitte Message-ID: Date: Thu, 11 May 2017 22:36:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch> Content-Type: multipart/alternative; boundary="------------6C428E037CFC9FB467CE0C34" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits 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, 11 May 2017 20:36:37 -0000 This is a multi-part message in MIME format. --------------6C428E037CFC9FB467CE0C34 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry again, is this discussion really serious? In this thread, previous ones or others, the level of approximation is obvious, often shadowed by useless maths/papers and strange calculations that are not helping, at the end nobody knows what would happen "if", how far the chain can roll back, etc Then don't make pruning the default if it's the current concern, pruning is of no use Again, the priority should be to scale the full nodes Le 11/05/2017 =E0 22:10, Jonas Schnelli via bitcoin-dev a =E9crit : >> Is 49 days particularly useful? Would it be a problem to instead leave= both- >> bits undefined? I'm thinking this might be better as a way to indicate= "7 >> days, plus a deterministically chosen set of historical blocks"=85 > I though two service bits allow three states and we should define all t= hree combinations. > But I guess an adequate =84definition=93 would be to reserve it for fut= ure =84definitions=93. > Or use Gregory's proposal of min 2016*2 blocks & keep it =84undefined=93= for now. > > 49 days was chosen to allow SPV peers to be =84offline=93 for a month a= nd still be capable to catch-up with a peer pruned to a datadir of ~10GB.= > >> This is technically true right now, but as soon as segwit activates, i= t will >> no longer be... Therefore, I suggest striking it from the BIP, expound= ing on >> it in greater detail, or making it true for the longer term. > AFAIK Core does also guaranteed the 288 blocks post segwit activation: > https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893= f4358c5ae/src/validation.h#L204 > But maybe I=92m confused. > >>> Peers following this BIP SHOULD connect a limited amount of their ava= ilable >>> outbound connections to peers signaling one or both of the >>> NODE_NETWORK_LIMITED_* service bits if they expect to request less bl= ocks >>> than the signaled number. >> This isn't entirely clear whether it refers to peers downloading block= s, or >> peers serving them. (I assume the former, but it should be clarified.)= > Indeed. I=92ll try to make that more clear. > >>> Light clients (and such) who are not checking the nServiceFlags (serv= ice >>> bits) from a relayed addr-message may unwillingly connect to a pruned= peer >>> and ask for (filtered) blocks at a depth below their pruned depth. >> Wouldn't this already be a problem, without the BIP? > AFAIK, Core does currently only relay NODE_NETWORK addresses. > But yes, It may be a problem already. > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=20 Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.o= rg Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms --------------6C428E037CFC9FB467CE0C34 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Sorry again, is this discussion really serious?

In this thread, previous ones or others, the level of approximation is obvious, often shadowed by useless maths/papers and strange calculations that are not helping, at the end nobody knows what would happen "if", how far the chain can roll back, etc

Then don't make pruning the default if it's the current concern, pruning is of no use

Again, the priority should be to scale the full nodes


Le 11/05/2017 ŕ 22:10, Jonas Schnelli via bitcoin-dev a écrit :

      

        
Is 49 days particularly useful? Would it be a problem to instead leave both-
bits undefined? I'm thinking this might be better as a way to indicate "7
days, plus a deterministically chosen set of historical blocks"…


      

      
I though two service bits allow three states and we should define all three combinations.
But I guess an adequate „definition“ would be to reserve it for future „definitions“.
Or use Gregory's proposal of min 2016*2 blocks & keep it „undefined“ for now.

49 days was chosen to allow SPV peers to be „offline“ for a month and still be capable to catch-up with a peer pruned to a datadir of ~10GB.



      

        
This is technically true right now, but as soon as segwit activates, it will
no longer be... Therefore, I suggest striking it from the BIP, expounding on
it in greater detail, or making it true for the longer term.


      

      
AFAIK Core does also guaranteed the 288 blocks post segwit activation:
https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204
But maybe I’m confused.



      

        

        

          
Peers following this BIP SHOULD connect a limited amount of their available
outbound connections to peers signaling one or both of the
NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks
than the signaled number.


        

        
This isn't entirely clear whether it refers to peers downloading blocks, or
peers serving them. (I assume the former, but it should be clarified.)


      

      
Indeed. I’ll try to make that more clear.



      

        

        

          
Light clients (and such) who are not checking the nServiceFlags (service
bits) from a relayed addr-message may unwillingly connect to a pruned peer
and ask for (filtered) blocks at a depth below their pruned depth.


        

        
Wouldn't this already be a problem, without the BIP?


      

      
AFAIK, Core does currently only relay NODE_NETWORK addresses.
But yes, It may be a problem already.

</jonas>



      

      

      

      
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


    

    

    
-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

  


--------------6C428E037CFC9FB467CE0C34--


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 65F59B2B
	for ;
	Thu, 11 May 2017 21:05:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com
	[209.85.192.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 68A2F227
	for ;
	Thu, 11 May 2017 21:05:01 +0000 (UTC)
Received: by mail-pf0-f173.google.com with SMTP id m17so19505764pfg.3
	for ;
	Thu, 11 May 2017 14:05:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=subject:to:references:cc:from:message-id:date:user-agent
	:mime-version:in-reply-to:content-transfer-encoding;
	bh=/LP5ylDZQvrWPT39F52qI8ipt3JjXEA34oqGMCdVKUw=;
	b=IXE/37kfawYz+VLTSAIVfpi2/NG3t/tdZOzWhThqj3+k8i0D5zSw1frGOlJYKQaU6x
	vaa3EA76nT5z/WcLGUoHTJio6pCS/JHWqw7AdcaiYeoG3TxVLRPZl9wtbDoDnDIFe8ST
	jfrAjVztlgLwt+ztI3YZQB7lYc9Kdkfbne+qRqqqXp4fU7DsEIxKIIYU/aEYZIDUo15E
	lRX4L93CiBksKpGSnHZ1ItN88xvYwjnK6l11HBGE/MohIJkaFQ3n1MYUxd4AFP2fomg5
	/lyQbkiqhnMWetPCVoD7+fLBWhDC7Y1Lc7rtAzUWD44A+L9aerXXovtezLGz+ithn5KR
	o8vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:cc:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-transfer-encoding;
	bh=/LP5ylDZQvrWPT39F52qI8ipt3JjXEA34oqGMCdVKUw=;
	b=KIuVw6WbzbUdNK4JZ8drWttS4nNl9NJ24z2Eot5VsjRS6kVdAFPdhXjqGR6Mq5Y5x4
	RWYQjqMayXmNSqBSwflsohxZhXQbPI5E/5qfoCad5sGLFhUWInAaj8r1u3HapItd9Vgg
	NJD1bn3ntReEchOsSJ1iJbc/rTyz9brI9JtWjH9Rk7FfxiPVavDTzdRgWUrxLrsj/d0O
	v0hccBFami+WpAGjIt6j5AKB41n19vuJ/bXluYknbOl23MMM3qy0rJZxjfHmNUkoX/cd
	FCwsKj/tpkKN7aPgPLFENViyPwPb20v9+8F+iMHdNL0EIn1j8y7etc5kxYMuM+6Q2r5Y
	zt+A==
X-Gm-Message-State: AODbwcAfeBzVo/D5D+FIY3NWIf+opYDWcFHdKq+Mp+hFjJZY2jn8woIC
	kiaGGHUD3HFN6A==
X-Received: by 10.98.202.213 with SMTP id y82mr538605pfk.212.1494536700926;
	Thu, 11 May 2017 14:05:00 -0700 (PDT)
Received: from ?IPv6:2601:600:9000:d69e:e58e:665a:31e8:9faa?
	([2601:600:9000:d69e:e58e:665a:31e8:9faa])
	by smtp.gmail.com with ESMTPSA id
	c77sm1711160pfe.37.2017.05.11.14.04.59
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 May 2017 14:05:00 -0700 (PDT)
To: Aymeric Vitte ,
	Jonas Schnelli , Luke Dashjr 
References: 
	<201705111924.22055.luke@dashjr.org>
	<61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch>
	
From: Eric Voskuil 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Thu, 11 May 2017 14:05:09 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no 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, 11 May 2017 21:11:25 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits
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, 11 May 2017 21:05:02 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/11/2017 01:36 PM, Aymeric Vitte via bitcoin-dev wrote:
> Sorry again, is this discussion really serious?
> 
> In this thread, previous ones or others, the level of approximation
> is obvious, often shadowed by useless maths/papers and strange
> calculations that are not helping, at the end nobody knows what
> would happen "if", how far the chain can roll back, etc
> 
> Then don't make pruning the default if it's the current concern,
> pruning is of no use
> 
> Again, the priority should be to scale the full nodes

I agree. Every full node operator should (and likely would at some
point) simply never connect to, or relay the address of, any "peer"
advertising itself as diminished. Why on earth would a full node
operator want to encourage shrinking support for bootstrapping and
deep reorgs, resulting in greater load for himself. That's a race to
the bottom.

We are literally talking about $7.50 for the *entire chain* with
breathing room. If someone wants to save a few dollars they are better
off attempting to hide their pruning.

e

> Le 11/05/2017 Ă  22:10, Jonas Schnelli via bitcoin-dev a Ă©crit :
>>> Is 49 days particularly useful? Would it be a problem to
>>> instead leave both- bits undefined? I'm thinking this might be
>>> better as a way to indicate "7 days, plus a deterministically
>>> chosen set of historical blocks"…
>> I though two service bits allow three states and we should define
>> all three combinations. But I guess an adequate „definition“
>> would be to reserve it for future „definitions“. Or use Gregory's
>> proposal of min 2016*2 blocks & keep it „undefined“ for now.
>> 
>> 49 days was chosen to allow SPV peers to be „offline“ for a month
>> and still be capable to catch-up with a peer pruned to a datadir
>> of ~10GB.
>> 
>>> This is technically true right now, but as soon as segwit
>>> activates, it will no longer be... Therefore, I suggest
>>> striking it from the BIP, expounding on it in greater detail,
>>> or making it true for the longer term.
>> AFAIK Core does also guaranteed the 288 blocks post segwit
>> activation: 
>> https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa624008
93f4358c5ae/src/validation.h#L204
>>
>> 
But maybe I’m confused.
>> 
>>>> Peers following this BIP SHOULD connect a limited amount of
>>>> their available outbound connections to peers signaling one
>>>> or both of the NODE_NETWORK_LIMITED_* service bits if they
>>>> expect to request less blocks than the signaled number.
>>> This isn't entirely clear whether it refers to peers
>>> downloading blocks, or peers serving them. (I assume the
>>> former, but it should be clarified.)
>> Indeed. I’ll try to make that more clear.
>> 
>>>> Light clients (and such) who are not checking the
>>>> nServiceFlags (service bits) from a relayed addr-message may
>>>> unwillingly connect to a pruned peer and ask for (filtered)
>>>> blocks at a depth below their pruned depth.
>>> Wouldn't this already be a problem, without the BIP?
>> AFAIK, Core does currently only relay NODE_NETWORK addresses. But
>> yes, It may be a problem already.
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev@lists.linuxfoundation.org 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> -- Zcash wallets made simple:
> https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple:
> https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic
> blocklist: http://peersm.com/getblocklist Check the 10 M passwords
> list: http://peersm.com/findmyass Anti-spies and private torrents,
> dynamic blocklist: http://torrent-live.org Peersm :
> http://www.peersm.com torrent-live:
> https://github.com/Ayms/torrent-live node-Tor :
> https://www.github.com/Ayms/node-Tor GitHub :
> https://www.github.com/Ayms
> 
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZFNHtAAoJEDzYwH8LXOFOYRwH/0By+TNSgnV6m4c7g1ZrjboG
8fZSeGaz7FXmAUZ69XMdQ1H+wlP0e4OAz9eRCcVqcn3K9OZJn++hbzI2K+zijyxZ
cpQjg/2dcTc4B0Z3PZdnuZx5mnHzavr/1vPlgOYla7AbYqcKB5dkq/HqgD6tFsJP
HXPClbEkVRF6UFP/7sDfzW8FMJycMSVcbEpuWAhcx2d+NusywWhbkuc5NiT9J1Ug
/3OFhHVJtd+rDl2B4iRHXHOhysUGffvmmLANZpPMcOgplM6Xwv7nMT34FV4HCdgs
Gyxc9GSFsD6xsOshBRPICtEZe+IDDb0cnOLjDdAnUnKeolUljFY52djSa300Fp0=
=REyc
-----END PGP SIGNATURE-----


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 2ABD62C
	for ;
	Fri, 12 May 2017 02:22:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com
	[209.85.217.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AE47D1A1
	for ;
	Fri, 12 May 2017 02:22:16 +0000 (UTC)
Received: by mail-ua0-f181.google.com with SMTP id e55so39569065uaa.2
	for ;
	Thu, 11 May 2017 19:22:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=1JhcbXXCAitNbCH51DQ7Uqdbm9HloC2u6eUi0j3EI2U=;
	b=itYqaRPcUXj7uRXHZ0BifckE8scpp5kPTe43mBFdlTxfGk/LyF2ufLNYpDr/JtPave
	a3HyyK/vjbn45zmv84Y17UojmotO6g+LX8YB/G1etV/Urg+pcvRUlbw032WiR4BDYPCT
	9XYlUVC1dtbCXZL+mfBj7Ux6U8woua2U4V5SpgGFk8r7VHJCyDAOcV/FpwIAsiO8biFy
	Ku9c6j/YTvm32FL+Bk9aB7OCD0KgORszv6BYHws/YurdsErr6oFtygct++KgFhT0aHUy
	FZn0K6GprtrJujkAFfkULeLfKmQsmVs/gXNoYofBMprjJu+bCV+7kFdmJywpkP5qBxrC
	V0Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=1JhcbXXCAitNbCH51DQ7Uqdbm9HloC2u6eUi0j3EI2U=;
	b=PpcyJvfBj6QpzdTE7rIxgWHpXD8gjEtyoFmmm7F+7UuaeikNMsoQSL+3/KNFvr7y3o
	fQEB/99SwxJNLSC03EoJFnMhx1RNjVI9jsrQOJEnft/X2RKa4lFo3WIXg0XUM3vl6Xd+
	DxwB6AcSGk9/pthtt1ScO2kOghFrU4pORCdgMuGnNGgV2iE9yQh2q0kXjqsvckiMfj20
	rUhVd7Ie89AF03YC065E7ZvnYKyKbv6OJPnKWZtzr79WNMBYA1Pl4IYhftJEYGHQRdAA
	jauu8rqz7EfpaUShSUAPsOQbcP/uicJapHdnx3iy2AIyiU23C4KuA2i3zplItj9Kcb1G
	8mnA==
X-Gm-Message-State: AODbwcAtYPWMJkzuMuCHSWD8eUsPyQ9QrQ4Pluf0JtI6SObD66J8YwWa
	jp+gkRQSJOfpu13VqCKMj9QHvIPiyw==
X-Received: by 10.159.32.66 with SMTP id 60mr845006uam.78.1494555735818; Thu,
	11 May 2017 19:22:15 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.103.20.66 with HTTP; Thu, 11 May 2017 19:22:15 -0700 (PDT)
In-Reply-To: 
References: 
From: Gregory Maxwell 
Date: Fri, 12 May 2017 02:22:15 +0000
X-Google-Sender-Auth: s_NYdZUh1TQ-rZ09TchO2lOjyRY
Message-ID: 
To: Jonas Schnelli 
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM 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 
Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits
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: Fri, 12 May 2017 02:22:17 -0000

On Thu, May 11, 2017 at 3:13 PM, Jonas Schnelli via bitcoin-dev
 wrote:
> Hi
>
> Currently, pruned peers have no way how to signal their (valuable) service.
> A BIP proposal to improve this (draft):
> https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT

The instructions for relay addresses should not instruct you to relay
these addresses but rather that you should relay addresses you would
connect to, under the generalized assumption that if it is useful to
you it will be useful to others.

This avoids instructing someone who might not consider
non-node-network peers useful from being directed by the BIP to relay
things that they don't find useful. (In particular, it means that the
obvious implementation of just throwing out the 'useless' information
works fine.)  I think would better reflect what people are likely to
actually do.