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 2C694C0A for ; Wed, 29 Mar 2017 16:41:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AA1DE19F for ; Wed, 29 Mar 2017 16:41:40 +0000 (UTC) Received: by mail-qt0-f180.google.com with SMTP id n21so17609165qta.1 for ; Wed, 29 Mar 2017 09:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p9Lj9V2T4OyOPQgmJwywrr6koEfn0eGhpAFrj2RoaUs=; b=jhiFsGOhpCYiKANJmCPfA1kH8XDl4qMBajXPDmMwWjF9SUly2q21Pldp7nKtVgAA/V NBhH+wUDhY+qq875OAopqW9ir6Sh0vzM35d40CysUOxKuStIT4sZ5cvlYD8qiTFXYryV 4+cR+mDPwnzuniWtRFaJSq6ED5trf+xr+xMF1T6jdmWLVybIaVj/dFOZSPYMFBmjA5bT a0Yh5O2YrPYgEtSoVQFms3hbCbFNgckEJwXVjOkAIWVT9YaTaJR6BEx7vfKqxDCCrkJA I3UA7e1l8aVmh0rO1QpefhdPRrFF1M8+uJiEcZCH9/EUF2z0Xio8Hdlg58P1Rc5SWopC M6Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p9Lj9V2T4OyOPQgmJwywrr6koEfn0eGhpAFrj2RoaUs=; b=EYr0dGYKuo2qlFH7sWoch6mAeiXwqsQuRvMFvKIo8pydoEwnLQ3ZI8PnXH18lxVMJl 5XWD2sjBmOmHuJfk2JkriIumCLUZTRU2ZrlYpR1yzS3GTp7NYULT94F/zl28slnNXD4S Nl5h9ejmreC+gdaLcfCWqOFDk7BpINguS15JzdlHAU1PPIAkRsUIVP/+qjMrV06psogL J7qtQg3XMJxs4JPqQVc6u5HoMuxVIqVdEotqEKbgJ6Eh2W9jQX6Y8H75gZ5NjhgNEMQM GEybaRyFnCEJ1cVzuPCqZSCX14fEGPV064PvB8X6x471yxJCCG5vF9/qciaDtymPMtML b5jg== X-Gm-Message-State: AFeK/H0VNY371CPeKfjIBdWU1LenDG91gxp4tcRQWIRy320eQIcEIhnPDFW/xdv55TqeWMeZVJtnR/bCFprpMg== X-Received: by 10.200.34.38 with SMTP id o35mr1549116qto.226.1490805699807; Wed, 29 Mar 2017 09:41:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Johnson Date: Wed, 29 Mar 2017 16:41:29 +0000 Message-ID: To: David Vorick Content-Type: multipart/alternative; boundary=001a11403c682a916e054be14059 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 29 Mar 2017 16:45:31 +0000 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 16:41:41 -0000 --001a11403c682a916e054be14059 Content-Type: text/plain; charset=UTF-8 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 --001a11403c682a916e054be14059 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe that as we continue to add users to the system by scaling ca= pacity that we will see more new nodes appear, but I'm at a bit of a lo= ss as to how to empirically prove it.=C2=A0

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

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

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


On Wed, Mar 29, 20= 17 at 11:25 AM David Vorick <d= avid.vorick@gmail.com> wrote:

On Mar 29, 2017 12:20 PM, "Andrew Johns= on" <andrew.johnson83@gmail.com> wrote:
What's stopping these users fro= m running a pruned node?=C2=A0 Not every node needs to store a complete cop= y of the blockchain.=C2=A0

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

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


Furthe= r discussion about disk space requirements should be taken to another threa= d.

--
Andrew Johnson

--001a11403c682a916e054be14059--