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>
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits
Precedence: list

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