1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0653CBC3
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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.
</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--
|
