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
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B26895AC
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2017 18:17:21 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id x71so6051523vkd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <E1313B4E-6061-49CA-9E8C-E5FD468531C0@jonasschnelli.ch>
References: <E1313B4E-6061-49CA-9E8C-E5FD468531C0@jonasschnelli.ch>
From: Gregory Maxwell <greg@xiph.org>
Date: Thu, 11 May 2017 18:17:19 +0000
X-Google-Sender-Auth: pTjsPinKwUcNt_JBQaz2i19T-Xo
Message-ID: <CAAS2fgS01Saxb8AtZhSxVGH5XFmXDzaaB0gd+4Zhr3-ahUJbfQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <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 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
<bitcoin-dev@lists.linuxfoundation.org> 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.
>
> </jonas>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
