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--