Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5762EB7C for ; Wed, 29 Mar 2017 19:34:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85CA6292 for ; Wed, 29 Mar 2017 19:34:00 +0000 (UTC) Received: by mail-ot0-f169.google.com with SMTP id 102so17475291otv.0 for ; Wed, 29 Mar 2017 12:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=74f0pqaiEH8hwK2+EAVFKnqYTbLXO0HUp5/1n8HcVTw=; b=szo8j3Vp43MRm8hT7VZvHnEDhlTQz+vncdBOXLGjnkk/ZPYP9kgJN7nPLcXIEhBT/s H9DZAgj90wm0qG3wBB90AIy10bE0Zilk1P+RUKeGVm5PeZkrLcpTUUGCx9hg3ljSEeae 6xAbLUC2nc6iaCwZ3sgKoCSFuyfcHbnXubpym7z4orQVHAgkm7CzuNZOputI0ZjoYhaA 4R1b/W1VW98qGBqOf/JANw19n49kuy7Im+MC2s9oOPDwuZbILFdsvu1FGzgURqDD132W MAW/UseSLVhHQndeuufTbU4i2TYxcnQ9beVTr9ojv+fMLSSPxDbZNrpmhK4Smr0GGmqf ur+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=74f0pqaiEH8hwK2+EAVFKnqYTbLXO0HUp5/1n8HcVTw=; b=uc/gtDpYACSUja3iIFHZ2tCjTeYHQYVM81ykXLcJJsqy6GoIuNtCeZlR15omX4P3s9 bg08feNE/ZtfGcUmVovKf9uRamtilTJBJimEIufNhlnankzcWZ/7MOO2Xhoca6ma1vZR YzNJy6Z/nqm1NQU0niSL9z1c6jyacAnSTb/gTcbgzMaSpTxejBwTAvEypw3LgRN0LELB b9DxdCgHqTWWYOK0lYN+yxCaQmbi53cHkM1LlvZH7DqGi6p53gvy8ZjCW0LIzXk6rRmb 0dHWUZFSRUbyGRv34Bn/oAW4ib19/SPRDiJxQzrDoprKWyEo76KYhDZMGhG7Tu/kiTAd mqgw== X-Gm-Message-State: AFeK/H1i4hNX+SbxLAdcIYL8Z7Okx12VHxC2v9XuZo1QkT900JAxD3JjL+CS2nKVRF74abU1nYLFxEU22DnGUA== X-Received: by 10.157.57.228 with SMTP id y91mr1322108otb.33.1490816039329; Wed, 29 Mar 2017 12:33:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.43.18 with HTTP; Wed, 29 Mar 2017 12:33:58 -0700 (PDT) Received: by 10.157.43.18 with HTTP; Wed, 29 Mar 2017 12:33:58 -0700 (PDT) From: Daniele Pinna Date: Wed, 29 Mar 2017 21:33:58 +0200 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11406d5a73234b054be3a8ba X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Wed, 29 Mar 2017 19:59:09 +0000 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 19:34:01 -0000 --001a11406d5a73234b054be3a8ba Content-Type: text/plain; charset=UTF-8 What about periodically committing the entire UTXO set to a special checkpoint block which becomes the new de facto Genesis block? Daniele ------------------------------ Message: 5 Date: Wed, 29 Mar 2017 16:41:29 +0000 From: Andrew Johnson To: David Vorick Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ --001a11406d5a73234b054be3a8ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What about periodically committing the = entire UTXO set to a special checkpoint block which becomes the new de fact= o Genesis block?=C2=A0

D= aniele=C2=A0

----------------------------= --

Message: 5
Date: Wed, 29 Mar 2017 16:41:29 +0000
From: Andrew Johnson <andrew.johnson83@gmail.com>
To: David Vorick <david.vorick@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@list= s.linuxfoundation.org>
Subject: Re:= [bitcoin-dev] Hard fork proposal from last week's meeting
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mai= l.gmail.com>
Content-Type: text/pla= in; charset=3D"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 t= o how to empirically prove it.

<= span style=3D"font-family:sans-serif;font-size:13.696px">I do see your poin= t on increasing load on archival nodes, but the majority
of that load is going to come from new nodes com= ing online, they're the
on= ly ones going after very old blocks.=C2=A0 =C2=A0I could see that as a pote= ntial
attack vector, overwhelm= the archival nodes by spinning up new nodes
constantly, therefore making it difficult for a "real&q= uot; new node to get up
to spe= ed in a reasonable amount of time.

Perhaps the an= swer 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...=C2=A0 Archival n= odes could set and publish their own policy, let
the market decide what those older blocks are worth.=C2= =A0 Would also help to
incenti= vize running archival node, which we do need.=C2=A0 Of course, this isn'= ;t
very user friendly.<= br style=3D"font-family:sans-serif;font-size:13.696px">
We can take this to bitcoin-discuss, if we're gettin= g too far off topic.


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

>
> On M= ar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83@gmail.c= om>=
> wrote:
>
>= What's stopping these users from running a pruned node?=C2=A0 Not ever= y node
> needs to store a c= omplete copy of the blockchain.
>
>
> Pruned nodes are not the default configurat= ion, if it was the default
>= ; configuration then I think you would see far more users running a pruned<= /span>
> node.
>
> But that would also substantially increase the burden on archive = nodes.
>
>
> Further discussion about disk space requirements should be taken to<= /span>
> another thread.<= br style=3D"font-family:sans-serif;font-size:13.696px">>
>
> --
Andrew Johnson
-------------- next part --------------An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.o= rg/pipermail/bitcoin-dev/attachments/20170329/9b48ebe3/attachment= .html>

------------------------------
--001a11406d5a73234b054be3a8ba--