Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4102989E for ; Wed, 29 Mar 2017 17:14:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED38B1D9 for ; Wed, 29 Mar 2017 17:14:49 +0000 (UTC) Received: by mail-wr0-f179.google.com with SMTP id l43so25075549wre.1 for ; Wed, 29 Mar 2017 10:14:49 -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=No7qS6JMatS7A4BKxPkQP7fjQobrVOxF0EIzNQ4o0eg=; b=hIWcyEaiwOGyjFOJ1i4fH8NtveuGWlB9Esxye4Iv30TCkS5XtkV4kbNFy4oVe04JiQ MPRLWnGLw6iwLQdlY4RW551CDpJfix4wAGw1H3Ki3OEb+1JJOLmX4wIieDAhFGbmW/9f 48t975cLIdyMD4g3AI9oDcQho03KtqqV7hr0nh0dZJAL4VhQYZ6PoSAXVPBy4sHXhHrA dZ2TxsuOrRa0tL5OudTx6LyzeH3eF4g4B9kuiNbs53stpoGswRmpjKM0eoqsPX/6WlMy ad4PKwdW5g0FVZxrFMAwIN1s+KQOCR7xI+BGadO2hn+JLcz4NBjwd3pfU9UgYVUOSe98 qSyA== 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=No7qS6JMatS7A4BKxPkQP7fjQobrVOxF0EIzNQ4o0eg=; b=O0Uk/f03ivM2FOSOD8uQR2g7xBWWFXCcgsJpUwVsZC+A1L/VJdog9cP1OOcXYafBFA w+40XQ0v0isP09EyIc+Byhn7MEZ8BHyAYxhElDywyqKHQFPHgYc1zCZeWBTITKXFTzIK B+xNw9v4XSwHpERm+vDLg7pFjXBxz1NQhmPvxvr1/exws1Dm2hV8f3LzOQCgtd22Kzr3 QeU95uXSb2mckLPcnpkHWTqz4F6DgOFd8HqjcaY8O7mfu3C2Q2BpiyPqkLEuiHhSC+51 kJFkcEKNZfQkXFxAAUqrFXygD66dIoN0in1cIR9jmyHqgta0LHg459hKL04ZsyEqhzU0 92yw== X-Gm-Message-State: AFeK/H1Pi/lBA4P9QiI+zEtpFUgX7EVorAqzANDwNSIEtUwgJgGA4A48quOHu2wlmSEKIg== X-Received: by 10.28.211.9 with SMTP id k9mr1781214wmg.96.1490807688606; Wed, 29 Mar 2017 10:14:48 -0700 (PDT) Received: from [192.168.1.10] (ANice-654-1-52-124.w83-201.abo.wanadoo.fr. [83.201.223.124]) by smtp.googlemail.com with ESMTPSA id s17sm10234171wrc.25.2017.03.29.10.14.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 10:14:47 -0700 (PDT) To: Andrew Johnson , David Vorick References: From: Aymeric Vitte Message-ID: <237b67c9-6233-906d-c754-19a5c74285b7@gmail.com> Date: Wed, 29 Mar 2017 19:14:50 +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="------------2CAD60577B871E0EAF28861B" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,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 Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting 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: Wed, 29 Mar 2017 17:14:51 -0000 This is a multi-part message in MIME format. --------------2CAD60577B871E0EAF28861B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Well it's not going off-topic since the btc folks need now to find a way to counter the attack The disk space story is know to be a non issue, because encouraging people to run nodes while they don't know how to dedicate the right storage space that is trivial and not expensive to get today is just stupid, they should not try to run full nodes, and no I tested with non SSD drives, I was more wondering about cpu and bandwidth use, but did not notice any impact, just stopped because a repeated sw bug or drive issue desynched the chain and bitcoin-qt was trying to reload it from the begining each time, which in my case was taking 10 days despite of good bandwidth (which would allow me to torrent the entire chain + state in less than 20 hours), so I stopped after the 3rd crash, setting up a full node on my servers is still in the todo list (very low priority for the reasons already explained) Running a prune node implies first to setup a full node, so the same problematic applies and then the advantage of pruning is not really obvious, I don't know what's the strange story about "archival nodes", I proposed something else Back to the topic, the conclusion is that this is not difficult at all for many people to run efficient full nodes, ideally the community should promote this, seed a torrent with a recent state, implement a patch to defeat BU plans and have everybody upgrade But of course this will not happen Le 29/03/2017 à 18:41, Andrew Johnson a écrit : > I believe that as we continue to add users to the system by scaling > capacity that we will see more new nodes appear, but I'm at a bit of a > loss as to how to empirically prove it. > > I do see your point on increasing load on archival nodes, but the > majority of that load is going to come from new nodes coming online, > they're the only ones going after very old blocks. I could see that > as a potential attack vector, overwhelm the archival nodes by spinning > up new nodes constantly, therefore making it difficult for a "real" > new node to get up to speed in a reasonable amount of time. > > Perhaps the answer there would be a way to pay an archival node a > small amount of bitcoin in order to retrieve blocks older than a > certain cutoff? Include an IP address for the node asking for the > data as metadata in the transaction... Archival nodes could set and > publish their own policy, let the market decide what those older > blocks are worth. Would also help to incentivize running archival > node, which we do need. Of course, this isn't very user friendly. > > We can take this to bitcoin-discuss, if we're getting too far off topic. > > > On Wed, Mar 29, 2017 at 11:25 AM David Vorick > wrote: > > > On Mar 29, 2017 12:20 PM, "Andrew Johnson" > > > wrote: > > What's stopping these users from running a pruned node? Not > every node needs to store a complete copy of the blockchain. > > > Pruned nodes are not the default configuration, if it was the > default configuration then I think you would see far more users > running a pruned node. > > But that would also substantially increase the burden on archive > nodes. > > > Further discussion about disk space requirements should be taken > to another thread. > > > -- > Andrew Johnson > -- 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 --------------2CAD60577B871E0EAF28861B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Well it's not going off-topic since the btc folks need now to find a way to counter the attack

The disk space story is know to be a non issue, because encouraging people to run nodes while they don't know how to dedicate the right storage space that is trivial and not expensive to get today is just stupid, they should not try to run full nodes, and no I tested with non SSD drives, I was more wondering about cpu and bandwidth use, but did not notice any impact, just stopped because a repeated sw bug or drive issue desynched the chain and bitcoin-qt was trying to reload it from the begining each time, which in my case was taking 10 days despite of good bandwidth (which would allow me to torrent the entire chain + state in less than 20 hours), so I stopped after the 3rd crash, setting up a full node on my servers is still in the todo list (very low priority for the reasons already explained)

Running a prune node implies first to setup a full node, so the same problematic applies and then the advantage of pruning is not really obvious, I don't know what's the strange story about "archival nodes", I proposed something else

Back to the topic, the conclusion is that this is not difficult at all for many people to run efficient full nodes, ideally the community should promote this, seed a torrent with a recent state, implement a patch to defeat BU plans and have everybody upgrade

But of course this will not happen


Le 29/03/2017 à 18:41, Andrew Johnson a écrit :
I believe that as we continue to add users to the system by scaling capacity that we will see more new nodes appear, but I'm at a bit of a loss as to how to empirically prove it. 

I do see your point on increasing load on archival nodes, but the majority of that load is going to come from new nodes coming online, they're the only ones going after very old blocks.   I could see that as a potential attack vector, overwhelm the archival nodes by spinning up new nodes constantly, therefore making it difficult for a "real" new node to get up to speed in a reasonable amount of time. 

Perhaps the answer there would be a way to pay an archival node a small amount of bitcoin in order to retrieve blocks older than a certain cutoff?  Include an IP address for the node asking for the data as metadata in the transaction...  Archival nodes could set and publish their own policy, let the market decide what those older blocks are worth.  Would also help to incentivize running archival node, which we do need.  Of course, this isn't very user friendly. 

We can take this to bitcoin-discuss, if we're getting too far off topic.


On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick@gmail.com> wrote:

On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83@gmail.com> wrote:
What's stopping these users from running a pruned node?  Not every node needs to store a complete copy of the blockchain. 

Pruned nodes are not the default configuration, if it was the default configuration then I think you would see far more users running a pruned node.

But that would also substantially increase the burden on archive nodes.


Further discussion about disk space requirements should be taken to another thread.

--
Andrew Johnson


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