From: Jonas Schnelli <dev@jonasschnelli.ch>
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 <luke@dashjr.org>
References: <E1313B4E-6061-49CA-9E8C-E5FD468531C0@jonasschnelli.ch>
	<201705111924.22055.luke@dashjr.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits
Precedence: list


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

</jonas>


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