diff options
| author | Eric Voskuil <eric@voskuil.org> | 2017-05-11 14:05:09 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-05-11 21:05:02 +0000 |
| commit | aa82fb022fbb1412ce351c906a13a73fabdd8854 (patch) | |
| tree | 047ddc5875fc8fff99c52567dd9ab9bdabd30cb7 | |
| parent | 697e414f0fcd9ec8645ff2bede0052f675a35450 (diff) | |
| download | pi-bitcoindev-aa82fb022fbb1412ce351c906a13a73fabdd8854.tar.gz pi-bitcoindev-aa82fb022fbb1412ce351c906a13a73fabdd8854.zip | |
Re: [bitcoin-dev] BIP proposal: NODE_NETWORK_LIMITED service bits
| -rw-r--r-- | 0c/0977680e8770652f30ef46cff5326006cc8a84 | 193 |
1 files changed, 193 insertions, 0 deletions
diff --git a/0c/0977680e8770652f30ef46cff5326006cc8a84 b/0c/0977680e8770652f30ef46cff5326006cc8a84 new file mode 100644 index 000000000..a4b3be308 --- /dev/null +++ b/0c/0977680e8770652f30ef46cff5326006cc8a84 @@ -0,0 +1,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----- + |