From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D4ABA955 for ; Tue, 18 Apr 2017 23:19:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90376D4 for ; Tue, 18 Apr 2017 23:19:04 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id u2so8911086wmu.0 for ; Tue, 18 Apr 2017 16:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=q3lO3kiEO9t8d9nXzy49XL93/FYK29O6AIHYjFpnvu0=; b=n/Iw6sT2K7Hl9QKHz4Q8y1fImTFXkzSWtgKrV13XPXDS6UTIcv6MWsip6RFj86At13 7o7x8UiodSU326TuLD+4ThEVWNYFijvZvmn1O+kxePvdprTr4blbDAbwJXwf54aJaGah BSsIiDcomBt+fC+YoIi6Nox78b09z9HL6NhWnwXjXoz+mreZAphAA8fQYgR1bmdSUx8t mWTXD4xFouB8xqjL/KVG9gIVkMBzCrJ97N9dOeVlImcmANtfb7zNOUIMyGtQdKlC3v5S Nj5mgpxDT9LvlR8baHYfRISHqMEVlNijoojioEsaWL/2ps6Af2XH8ir7QTBjk7cITsu+ I/GQ== 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:from:message-id:date :user-agent:mime-version:in-reply-to; bh=q3lO3kiEO9t8d9nXzy49XL93/FYK29O6AIHYjFpnvu0=; b=MiPTMnviKuJ7CkUeml2/rkv6/uIqderWBCpq4yFWsMk64l62V2cPEnE3boRHdvYWcg WUvKlMRwycKjVIgPe7hEZCU5Mbxqmon43UbHxuVNDlFj8wqxsFztL2bmIRc5nSPGhQdg +OhB3/0+AOPCSe19pX4h/EySTus9ImU13RgFL0/51lVqD/Vf9v68YvQrhcoTkSanHpDO m1lAZDKHNdqSifXLlT5XlzVaesftmoxdM+ZS/4ysVr920bcswB+62kj5LKaNwvb0aQRI So9TKTXdMEl7UCZd3eT9F4XVl30QqyfWXEA1XkiCwtTybOEr2DXDX70EpPhKKdAyjl1i 4xBQ== X-Gm-Message-State: AN3rC/6f8WQpYKvaPAltsJcFITqz8OiIUGYjLSJBiiiSpdDqBqSkONcE yp9KLf0SahInFLPs X-Received: by 10.28.178.17 with SMTP id b17mr255068wmf.23.1492557542881; Tue, 18 Apr 2017 16:19:02 -0700 (PDT) Received: from [192.168.1.10] (ANice-654-1-153-20.w86-205.abo.wanadoo.fr. [86.205.80.20]) by smtp.googlemail.com with ESMTPSA id r29sm749444wrr.45.2017.04.18.16.19.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 16:19:02 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <2226058.Q8lHjYE4Pt@strawberry> From: Aymeric Vitte Message-ID: Date: Wed, 19 Apr 2017 01:19:04 +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: Content-Type: multipart/alternative; boundary="------------1514DC795F898B236CF0BF5D" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes 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: Tue, 18 Apr 2017 23:19:05 -0000 This is a multi-part message in MIME format. --------------1514DC795F898B236CF0BF5D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit >From the initial post " The situation would likely become problematic quickly if bitcoin-core were to ship with the defaults set to a pruned node." Sorry to be straight, I read the (painful) thread below, and most of what is in there is inept, wrong, obsolete... or biased, cf the first sentence above, if the idea is to invent a workaround to the fact that pruning might/will become the default or might/will be set by the users as the default so full nodes might/will disappear then just say it clearly instead of proposing this kind of non-solution as a solution to secure the blockchain I can't believe this is serious, people now are supposed to prune but will be forced to host a part of the blockchain, how do you expect this to work, why people would do this? Knowing that to start pruning they need a full node, then since we are there, why not continuing with a full node... but indeed, why should they continue with a full node, and therefore why should they accept to host a part of the blockchain if they decline the first proposal? This is absurd, you are not addressing the first priority given the context which is to quickly increase the full nodes and which obviously includes an incentive for people to run them It gives also the feeling that bitcoin wants to reinvent everything not capitalizing on/knowing what exists, sorry again but the concepts of the proposal and others like archival nodes are just funny Le 18/04/2017 à 15:07, Tier Nolan via bitcoin-dev a écrit : > This has been discussed before. > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html > > including a list of nice to have features by Maxwell > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html > > You meet most of these rules, though you do have to download blocks > from multiple peers. > > The suggestion in that thread were for a way to compactly indicate > which blocks a node has. Each node would then store a sub-set of all > the blocks. You just download the blocks you want from the node that > has them. > > Each node would be recommended to store the last few days worth anyway. > > > _______________________________________________ > 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 --------------1514DC795F898B236CF0BF5D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

From the initial post " The situation would likely become problematic quickly if bitcoin-core were to ship with the defaults set to a pruned node."

Sorry to be straight, I read the (painful) thread below, and most of what is in there is inept, wrong, obsolete... or biased, cf the first sentence above, if the idea is to invent a workaround to the fact that pruning might/will become the default or might/will be set by the users as the default so full nodes might/will disappear then just say it clearly instead of proposing this kind of non-solution as a solution to secure the blockchain

I can't believe this is serious, people now are supposed to prune but will be forced to host a part of the blockchain, how do you expect this to work, why people would do this? Knowing that to start pruning they need a full node, then since we are there, why not continuing with a full node... but indeed, why should they continue with a full node, and therefore why should they accept to host a part of the blockchain if they decline the first proposal?

This is absurd, you are not addressing the first priority given the context which is to quickly increase the full nodes and which obviously includes an incentive for people to run them

It gives also the feeling that bitcoin wants to reinvent everything not capitalizing on/knowing what exists, sorry again but the concepts of the proposal and others like archival nodes are just funny


Le 18/04/2017 à 15:07, Tier Nolan via bitcoin-dev a écrit :
You meet most of these rules, though you do have to download blocks from multiple peers.

The suggestion in that thread were for a way to compactly indicate which blocks a node has.  Each node would then store a sub-set of all the blocks.  You just download the blocks you want from the node that has them.

Each node would be recommended to store the last few days worth anyway.


_______________________________________________
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
--------------1514DC795F898B236CF0BF5D--