path: root/ed/22086e0f1af3746971caffd72134c9881350a7

Return-Path: <vitteaymeric@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4A58FBB3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 11 May 2017 20:36:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com
	[209.85.128.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4039E1FE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 11 May 2017 20:36:36 +0000 (UTC)
Received: by mail-wr0-f178.google.com with SMTP id l50so30478141wrc.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 11 May 2017 13:36:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=subject:to:references:cc:from:message-id:date:user-agent
	:mime-version:in-reply-to;
	bh=MxeZRq8GCZ+63lQvEmfo6oSFVWAo2APJJ6IBLsoFyWA=;
	b=Qf6lxNxlYhdqa+vCiU/DgwMUtNBBPRNrU8hG8csI+A5LqAR67cublpeK5ssWI4CjPn
	gCy9/8IXzHvLq0BbHfENXFFswOULotat+TEme0OQtdbPoM91EI3qWFF6+GUlsKUxuPCi
	4g3kJ7NafSl9TNKZIv+akQliGqnZhfI2COJuWFqvPWfz+JkYdzNFcdphYkSohgQFDYOl
	yNkjaAnXDofdF5g4FzwW1BCf0MJclxpb/gZwSj486QZ/4rv24Wth3LP01WKIv5ZCNYHD
	WLewDVFTBgWUG8IyFCJT8Zr10GSSq3s/Oe74Fpa2RakQX5+8Pfw6LM5bKc7PP8sbb7M8
	XmVw==
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;
	bh=MxeZRq8GCZ+63lQvEmfo6oSFVWAo2APJJ6IBLsoFyWA=;
	b=i67lYEMr3q5G60rjY9uMphNquWf5sEs6ejRG76DNsg8GC7Q8GNRI+ThBxA6AXPIxvB
	7TbQFNrF0dXjyrQg8ZvAXuDPzLvd4fLHX4c0qe2P7fYbIBahPChYmk7ReTQTPosw2fGS
	NHnhtJMODMOthF1gYkavEHB/SZciwhglwZHsbtwzyXSlP1zu2nWiqMLN/ciNKQBzPt4X
	NFKL3coL0KJddkcc0CGSRR8usrkBb7o8zVoddLeVQs9jWvtc9J1EohZHkdafJU4mZ+LU
	d/cn+fnYhvXLqrVEnS2N1hedyOaKjerUolKk/I8M+TjNw2evJ/G/GVGT0rwUnw66MDdE
	mbFw==
X-Gm-Message-State: AODbwcDr2YP8E8RM03QjSy6kphs6Ny3QM9xnWH/hHBTjyxCsPq3J1c1p
	6g9WZAR7OhGlaPZB
X-Received: by 10.223.182.144 with SMTP id j16mr284756wre.64.1494534994681;
	Thu, 11 May 2017 13:36:34 -0700 (PDT)
Received: from [192.168.1.10] (ANice-654-1-58-18.w83-201.abo.wanadoo.fr.
	[83.201.229.18]) by smtp.googlemail.com with ESMTPSA id
	e125sm1876351wmd.33.2017.05.11.13.36.33
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 11 May 2017 13:36:34 -0700 (PDT)
To: 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>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <f0417e14-fb2c-3572-f8e9-06c7adbf3d2b@gmail.com>
Date: Thu, 11 May 2017 22:36:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
	Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch>
Content-Type: multipart/alternative;
	boundary="------------6C428E037CFC9FB467CE0C34"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	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
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:36:37 -0000

This is a multi-part message in MIME format.
--------------6C428E037CFC9FB467CE0C34
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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


Le 11/05/2017 =E0 22:10, Jonas Schnelli via bitcoin-dev a =E9crit :
>> 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"=85
> I though two service bits allow three states and we should define all t=
hree combinations.
> But I guess an adequate =84definition=93 would be to reserve it for fut=
ure =84definitions=93.
> Or use Gregory's proposal of min 2016*2 blocks & keep it =84undefined=93=
 for now.
>
> 49 days was chosen to allow SPV peers to be =84offline=93 for a month a=
nd 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, i=
t will
>> no longer be... Therefore, I suggest striking it from the BIP, expound=
ing 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/08a7316c144f9f2516db8fa62400893=
f4358c5ae/src/validation.h#L204
> But maybe I=92m confused.
>
>>> Peers following this BIP SHOULD connect a limited amount of their ava=
ilable
>>> outbound connections to peers signaling one or both of the
>>> NODE_NETWORK_LIMITED_* service bits if they expect to request less bl=
ocks
>>> than the signaled number.
>> This isn't entirely clear whether it refers to peers downloading block=
s, or
>> peers serving them. (I assume the former, but it should be clarified.)=

> Indeed. I=92ll try to make that more clear.
>
>>> Light clients (and such) who are not checking the nServiceFlags (serv=
ice
>>> 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

--=20
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.o=
rg
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


--------------6C428E037CFC9FB467CE0C34
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Sorry again, is this discussion really serious?</p>
    <p>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<br>
    </p>
    <p>Then don't make pruning the default if it's the current concern,
      pruning is of no use</p>
    <p>Again, the priority should be to scale the full nodes<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Le 11/05/2017 à 22:10, Jonas Schnelli
      via bitcoin-dev a écrit :<br>
    </div>
    <blockquote
      cite="mid:61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">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"…
</pre>
      </blockquote>
      <pre wrap="">
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 &amp; 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.

</pre>
      <blockquote type="cite">
        <pre wrap="">
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.
</pre>
      </blockquote>
      <pre wrap="">
AFAIK Core does also guaranteed the 288 blocks post segwit activation:
<a class="moz-txt-link-freetext" href="https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204">https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204</a>
But maybe I’m confused.

</pre>
      <blockquote type="cite">
        <pre wrap="">
</pre>
        <blockquote type="cite">
          <pre wrap="">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.
</pre>
        </blockquote>
        <pre wrap="">
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.)
</pre>
      </blockquote>
      <pre wrap="">
Indeed. I’ll try to make that more clear.

</pre>
      <blockquote type="cite">
        <pre wrap="">
</pre>
        <blockquote type="cite">
          <pre wrap="">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.
</pre>
        </blockquote>
        <pre wrap="">
Wouldn't this already be a problem, without the BIP?
</pre>
      </blockquote>
      <pre wrap="">
AFAIK, Core does currently only relay NODE_NETWORK addresses.
But yes, It may be a problem already.

&lt;/jonas&gt;

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
  </body>
</html>

--------------6C428E037CFC9FB467CE0C34--