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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 65F59B2B
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2017 21:05:01 +0000 (UTC)
Received: by mail-pf0-f173.google.com with SMTP id m17so19505764pfg.3
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <vitteaymeric@gmail.com>,
Jonas Schnelli <dev@jonasschnelli.ch>, Luke Dashjr <luke@dashjr.org>
References: <E1313B4E-6061-49CA-9E8C-E5FD468531C0@jonasschnelli.ch>
<201705111924.22055.luke@dashjr.org>
<61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch>
<f0417e14-fb2c-3572-f8e9-06c7adbf3d2b@gmail.com>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <b1bd85b6-a2c4-6243-ff41-a514eef1c334@voskuil.org>
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: <f0417e14-fb2c-3572-f8e9-06c7adbf3d2b@gmail.com>
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 <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 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.
>>
>> </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
>
>
>
> _______________________________________________ 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-----
|
