Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 65F59B2B for ; 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 ; Thu, 11 May 2017 21:05:01 +0000 (UTC) Received: by mail-pf0-f173.google.com with SMTP id m17so19505764pfg.3 for ; 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 , Jonas Schnelli , Luke Dashjr References: <201705111924.22055.luke@dashjr.org> <61C68F26-AD36-4AB4-A065-020BD549CEBC@jonasschnelli.ch> From: Eric Voskuil X-Enigmail-Draft-Status: N1110 Message-ID: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >> >> >> >> >> >> _______________________________________________ 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-----