path: root/f2/877ad83e39128ddaa319bd698dda8a0eab63ed

Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5BCD5B30
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 22:17:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com
	[209.85.213.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ACF38160
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 22:17:41 +0000 (UTC)
Received: by mail-vk0-f51.google.com with SMTP id d188so34619181vka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Mar 2017 15:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=TDZSXU32uYZ4m6GMBfe9iDGDdftGgerau6XHHWwmOWw=;
	b=OiYAU0DXgqVf58Mh3JPWl/PnnkrMc6i0w3npsBHBQp8RAqwIPxZE640m/tHOlvD5Ny
	0kyBcoOBYYoTvKPJBXBTRR/ylo4TPKaaohBKJJObYLDZYKGtJgO6+0RErow2e9+fLwDZ
	4Cx7G2F0A7/IcuAEnpb4SqWqHcLFngpOWyCnyzba6bbQR5QcKpXwy3xYMdUt+q3Ht3LS
	CLYp/pfyMtxYiqJWL2YFy70XsJxT3pY13duH+MUw+/ooNVYVnC2Kzj4WUQWpYc0jADS2
	Cm/WzMV4DrcLv5DDH18BtkJ2ncieIeZNDKMZYYPIDPOfo/+W2WuzuMZCZCd9hGJnalUu
	DsDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=TDZSXU32uYZ4m6GMBfe9iDGDdftGgerau6XHHWwmOWw=;
	b=ibJO+vsIMIERATzS/6HmFRUs9xLcSWawoplOuha/yy7KujKZE2RZAIuhyDMMCa3fFz
	lce/7izEsyBIP2FTFnmiArRIUTkGK/PbhNR4q2zqDi15EGgAkPbHqhs7EXZaM99VtMgp
	66UvgBB8t++JXmNQyyZF1FlJctyuOSBhSjGpNzXIIfnv8ydwGTQezU4Qzenxj06pXZLd
	a2/og3QG4RtBy9+EfkOOuW+OWVfEiWc2nbtTOCM8mzAbEg2VhCSyGBAVPkHaZFQINFfs
	PI8IXndrOjl/yVpo3JXR1bItQfgfNwqPs2sVpi/s3sYMJ0BI8TnRdQmhmYXrwvUjGWEY
	ih0w==
X-Gm-Message-State: AFeK/H1wqbQUNwCE/I1FVjp9OLhTrxSJ0m1/duq2bM3/nbC77Yn4oW6wcK0vzKQ8NlHkMLQCuBwbh5WdQxDdKQ==
X-Received: by 10.176.4.40 with SMTP id 37mr1679132uav.58.1490825860791; Wed,
	29 Mar 2017 15:17:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.143 with HTTP; Wed, 29 Mar 2017 15:17:40 -0700 (PDT)
In-Reply-To: <E54123C8-F124-449A-9C65-F40FA6917813@gmx.com>
References: <CAEgR2PEG1UMqY0hzUH4YE_an=qOvQUgfXreSRsoMWfFWxG3Vqg@mail.gmail.com>
	<E54123C8-F124-449A-9C65-F40FA6917813@gmx.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Wed, 29 Mar 2017 15:17:40 -0700
Message-ID: <CAD1TkXsv3cu4w-vEJ5=jPxFC6EHr0ryGNy5ao3RrDNDCn5xELQ@mail.gmail.com>
To: Peter R <peter_r@gmx.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c06b716dac456054be5f19a
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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 22:22:10 +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 <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: Wed, 29 Mar 2017 22:17:44 -0000

--94eb2c06b716dac456054be5f19a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> I=E2=80=99m confident that we could work with the miners who we have good
relationships with to start including the root hash of the (lagging) UTXO
set in their coinbase transactions, in order to begin transforming this
idea into reality.

By itself, this wouldn't work without a way for a new node to differentiate
between a false history and a true one.

>  We could also issue regular transactions from =E2=80=9Csemi-trusted=E2=
=80=9D addresses
controlled by known people that include the same root hash in an OP_RETURN
output, which would allow cross-checking against the miners=E2=80=99 UTXO
commitments, as part of this initial =E2=80=9Cprototype=E2=80=9D

This might work, but I fail to understand how a new node could verify an
address / transaction without a blockchain to back it.  Even if it could,
it becomes dependent upon those addresses not being compromised, and the
owners of those addresses would become targets for potential government
operations.

Having the software silently attempt to resolve the problem is risky unless
it is foolproof.  Otherwise, users will assume their software is showing
them the correct history/numbers implicitly, and if the change the utxo
attacker made was small, the users might be able to follow the main chain
totally until it was too late and the attacker struck with an address that
otherwise never transacted.  Sudden, bizarre, hard to debug fork and
potentially double spend against people who picked up the fraudulent utxo.

Users already treat wallet software with some level of suspicion, asking if
they can trust x or y or z, or like the portion of the BU community
convinced that core has been compromised by blockstream bigwigs.  Signed
releases could provide the same thing but would encourage both open-source
security checks of the signed utxo's and potentially of users to check
download signatures.

Either approach is better than what we have now though, so I'd support
anything.

On Wed, Mar 29, 2017 at 1:28 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I believe nearly everyone at Bitcoin Unlimited would be supportive of a
> UTXO check-pointing scheme.  I=E2=80=99d love to see this happen, as it w=
ould
> greatly reduce the time needed to get a new node up-and-running, for node
> operators who are comfortable trusting these commitments.
>
> I=E2=80=99m confident that we could work with the miners who we have good
> relationships with to start including the root hash of the (lagging) UTXO
> set in their coinbase transactions, in order to begin transforming this
> idea into reality.  We could also issue regular transactions from
> =E2=80=9Csemi-trusted=E2=80=9D addresses controlled by known people that =
include the same
> root hash in an OP_RETURN output, which would allow cross-checking agains=
t
> the miners=E2=80=99 UTXO commitments, as part of this initial =E2=80=9Cpr=
ototype=E2=80=9D system.
>
> This would "get the ball rolling" on UTXO commitments in a permissionless
> way (no one can stop us from doing this). If the results from this
> prototype commitment scheme were positive, then perhaps there would be
> support from the community and miners to enforce a new rule which require=
s
> the (lagging) root hashes be included in new blocks.  At that point, the
> UTXO commitment scheme is no longer a prototype but a trusted feature of
> the Bitcoin network.
>
> On that topic, are there any existing proposals detailing a canonical
> ordering of the UTXO set and a scheme to calculate the root hash?
>
> Best regards,
> Peter
>
>
> On Mar 29, 2017, at 12:33 PM, Daniele Pinna via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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 <andrew.johnson83@gmail.com>
> To: David Vorick <david.vorick@gmail.com>
> Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
> Message-ID:
>         <CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg@mail.gm
> ail.com>
> Content-Type: text/plain; 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 lo=
ss
> as to how to empirically prove it.
>
> I do see your point on increasing load on archival nodes, but the majorit=
y
> 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, le=
t
> 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 prune=
d
> > 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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/atta
> chments/20170329/9b48ebe3/attachment.html>
>
> ------------------------------
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c06b716dac456054be5f19a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">I=E2=80=99m con=
fident that we could work with the miners who we have good relationships wi=
th to start including the root hash of the (lagging) UTXO set in their coin=
base transactions, in order to begin transforming this idea into reality.<b=
r><br>By itself, this wouldn&#39;t work without a way for a new node to dif=
ferentiate between a false history and a true one.<br><br>&gt;=C2=A0</span>=
<span style=3D"font-size:12.8px">=C2=A0We could also issue regular transact=
ions from =E2=80=9Csemi-trusted=E2=80=9D addresses controlled by known peop=
le that include the same root hash in an OP_RETURN output, which would allo=
w cross-checking against the miners=E2=80=99 UTXO commitments, as part of t=
his initial =E2=80=9Cprototype=E2=80=9D<br><br>This might work, but I fail =
to understand how a new node could verify an address / transaction without =
a blockchain to back it.=C2=A0 Even if it could, it becomes dependent upon =
those addresses not being compromised, and the owners of those addresses wo=
uld become targets for potential government operations.</span><div><span st=
yle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.=
8px">Having the software silently attempt to resolve the problem is risky u=
nless it is foolproof.=C2=A0 Otherwise, users will assume their software is=
 showing them the correct history/numbers implicitly, and if the change the=
 utxo attacker made was small, the users might be able to follow the main c=
hain totally until it was too late and the attacker struck with an address =
that otherwise never transacted.=C2=A0 Sudden, bizarre, hard to debug fork =
and potentially double spend against people who picked up the fraudulent ut=
xo. =C2=A0</span></div><div><span style=3D"font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-size:12.8px">Users already treat wallet softwar=
e with some level of suspicion, asking if they can trust x or y or z, or li=
ke the portion of the BU community convinced that core has been compromised=
 by blockstream bigwigs.=C2=A0 Signed releases could provide the same thing=
 but would encourage both open-source security checks of the signed utxo&#3=
9;s and potentially of users to check download signatures.<br><br></span></=
div><div><span style=3D"font-size:12.8px">Either approach is better than wh=
at we have now though, so I&#39;d support anything.</span></div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Mar 29, 2017 a=
t 1:28 PM, Peter R via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div style=3D"word-wrap:break-word">I believe nearly everyone at Bitcoin U=
nlimited would be supportive of a UTXO check-pointing scheme.=C2=A0 I=E2=80=
=99d love to see this happen, as it would greatly reduce the time needed to=
 get a new node up-and-running, for node operators who are comfortable trus=
ting these commitments. =C2=A0<div><br></div><div>I=E2=80=99m confident tha=
t we could work with the miners who we have good relationships with to star=
t including the root hash of the (lagging) UTXO set in their coinbase trans=
actions, in order to begin transforming this idea into reality.=C2=A0 We co=
uld also issue regular transactions from =E2=80=9Csemi-trusted=E2=80=9D add=
resses controlled by known people that include the same root hash in an OP_=
RETURN output, which would allow cross-checking against the miners=E2=80=99=
 UTXO commitments, as part of this initial =E2=80=9Cprototype=E2=80=9D syst=
em.</div><div><br></div><div>This would &quot;get the ball rolling&quot; on=
 UTXO commitments in a permissionless way (no one can stop us from doing th=
is). If the results from this prototype commitment scheme were positive, th=
en perhaps there would be support from the community and miners to enforce =
a new rule which requires the (lagging) root hashes be included in new bloc=
ks.=C2=A0 At that point, the UTXO commitment scheme is no longer a prototyp=
e but a trusted feature of the Bitcoin network. =C2=A0 =C2=A0<div><br></div=
><div>On that topic, are there any existing proposals detailing a canonical=
 ordering of the UTXO set and a scheme to calculate the root hash?</div><di=
v><br></div><div>Best regards,</div><div>Peter<br><div><br></div><div><br><=
div><blockquote type=3D"cite"><div><div class=3D"h5"><div>On Mar 29, 2017, =
at 12:33 PM, Daniele Pinna via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linux=
foundation.org</a>&gt; wrote:</div><br class=3D"m_3214366301479993905Apple-=
interchange-newline"></div></div><div><div><div class=3D"h5"><div dir=3D"au=
to"><div dir=3D"auto">What about periodically committing the entire UTXO se=
t to a special checkpoint block which becomes the new de facto Genesis bloc=
k?=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Daniele=C2=A0</=
div><div dir=3D"auto"><br></div><div dir=3D"auto"><span style=3D"font-famil=
y:sans-serif;font-size:13.696px">------------------------------</span><br s=
tyle=3D"font-family:sans-serif;font-size:13.696px"><br style=3D"font-family=
:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-=
size:13.696px">Message: 5</span><br style=3D"font-family:sans-serif;font-si=
ze:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">Date=
: Wed, 29 Mar 2017 16:41:29 +0000</span><br style=3D"font-family:sans-serif=
;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696=
px">From: Andrew Johnson &lt;</span><a href=3D"mailto:andrew.johnson83@gmai=
l.com" style=3D"text-decoration:none;color:rgb(66,133,244);font-family:sans=
-serif;font-size:13.696px" target=3D"_blank">andrew.johnson83@gmail.com</a>=
<span style=3D"font-family:sans-serif;font-size:13.696px">&gt;</span><br st=
yle=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-famil=
y:sans-serif;font-size:13.696px">To: David Vorick &lt;</span><a href=3D"mai=
lto:david.vorick@gmail.com" style=3D"text-decoration:none;color:rgb(66,133,=
244);font-family:sans-serif;font-size:13.696px" target=3D"_blank">david.vor=
ick@gmail.com</a><span style=3D"font-family:sans-serif;font-size:13.696px">=
&gt;</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span st=
yle=3D"font-family:sans-serif;font-size:13.696px">Cc: Bitcoin Dev &lt;</spa=
n><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" style=3D"text-de=
coration:none;color:rgb(66,133,244);font-family:sans-serif;font-size:13.696=
px" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a><span s=
tyle=3D"font-family:sans-serif;font-size:13.696px">&gt;</span><br style=3D"=
font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-=
serif;font-size:13.696px">Subject: Re: [bitcoin-dev] Hard fork proposal fro=
m last week&#39;s meeting</span><br style=3D"font-family:sans-serif;font-si=
ze:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">Mess=
age-ID:</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span=
 style=3D"font-family:sans-serif;font-size:13.696px">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 &lt;</span><a href=3D"mailto:CAAy62_%2BJtoAuM-RsrAAp5eiGiO%2BOHLDjzq=
gbnF2De7TUU7TyYg@mail.gmail.com" style=3D"text-decoration:none;color:rgb(66=
,133,244);font-family:sans-serif;font-size:13.696px" target=3D"_blank">CAAy=
62_+JtoAuM-RsrAAp5eiGiO+O<wbr>HLDjzqgbnF2De7TUU7TyYg@mail.gm<wbr>ail.com</a=
><span style=3D"font-family:sans-serif;font-size:13.696px">&gt;</span><br s=
tyle=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-fami=
ly:sans-serif;font-size:13.696px">Content-Type: text/plain; charset=3D&quot=
;utf-8&quot;</span><br style=3D"font-family:sans-serif;font-size:13.696px">=
<br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font=
-family:sans-serif;font-size:13.696px">I believe that as we continue to add=
 users to the system by scaling</span><br style=3D"font-family:sans-serif;f=
ont-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px=
">capacity that we will see more new nodes appear, but I&#39;m at a bit of =
a loss</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span =
style=3D"font-family:sans-serif;font-size:13.696px">as to how to empiricall=
y prove it.</span><br style=3D"font-family:sans-serif;font-size:13.696px"><=
br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-=
family:sans-serif;font-size:13.696px">I do see your point on increasing loa=
d on archival nodes, but the majority</span><br style=3D"font-family:sans-s=
erif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13=
.696px">of that load is going to come from new nodes coming online, they&#3=
9;re the</span><br style=3D"font-family:sans-serif;font-size:13.696px"><spa=
n style=3D"font-family:sans-serif;font-size:13.696px">only ones going after=
 very old blocks.=C2=A0 =C2=A0I could see that as a potential</span><br sty=
le=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family=
:sans-serif;font-size:13.696px">attack vector, overwhelm the archival nodes=
 by spinning up new nodes</span><br style=3D"font-family:sans-serif;font-si=
ze:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">cons=
tantly, therefore making it difficult for a &quot;real&quot; new node to ge=
t up</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span st=
yle=3D"font-family:sans-serif;font-size:13.696px">to speed in a reasonable =
amount of time.</span><br style=3D"font-family:sans-serif;font-size:13.696p=
x"><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"f=
ont-family:sans-serif;font-size:13.696px">Perhaps the answer there would be=
 a way to pay an archival node a small</span><br style=3D"font-family:sans-=
serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size:1=
3.696px">amount of bitcoin in order to retrieve blocks older than a certain=
 cutoff?</span><br style=3D"font-family:sans-serif;font-size:13.696px"><spa=
n style=3D"font-family:sans-serif;font-size:13.696px">Include an IP address=
 for the node asking for the data as metadata in the</span><br style=3D"fon=
t-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-ser=
if;font-size:13.696px">transaction...=C2=A0 Archival nodes could set and pu=
blish their own policy, let</span><br style=3D"font-family:sans-serif;font-=
size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">th=
e market decide what those older blocks are worth.=C2=A0 Would also help to=
</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=
=3D"font-family:sans-serif;font-size:13.696px">incentivize running archival=
 node, which we do need.=C2=A0 Of course, this isn&#39;t</span><br style=3D=
"font-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans=
-serif;font-size:13.696px">very user friendly.</span><br style=3D"font-fami=
ly:sans-serif;font-size:13.696px"><br style=3D"font-family:sans-serif;font-=
size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">We=
 can take this to bitcoin-discuss, if we&#39;re getting too far off topic.<=
/span><br style=3D"font-family:sans-serif;font-size:13.696px"><br style=3D"=
font-family:sans-serif;font-size:13.696px"><br style=3D"font-family:sans-se=
rif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size:13.=
696px">On Wed, Mar 29, 2017 at 11:25 AM David Vorick &lt;</span><a href=3D"=
mailto:david.vorick@gmail.com" style=3D"text-decoration:none;color:rgb(66,1=
33,244);font-family:sans-serif;font-size:13.696px" target=3D"_blank">david.=
vorick@gmail.com</a><span style=3D"font-family:sans-serif;font-size:13.696p=
x">&gt;</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span=
 style=3D"font-family:sans-serif;font-size:13.696px">wrote:</span><br style=
=3D"font-family:sans-serif;font-size:13.696px"><br style=3D"font-family:san=
s-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size=
:13.696px">&gt;</span><br style=3D"font-family:sans-serif;font-size:13.696p=
x"><span style=3D"font-family:sans-serif;font-size:13.696px">&gt; On Mar 29=
, 2017 12:20 PM, &quot;Andrew Johnson&quot; &lt;</span><a href=3D"mailto:an=
drew.johnson83@gmail.com" style=3D"text-decoration:none;color:rgb(66,133,24=
4);font-family:sans-serif;font-size:13.696px" target=3D"_blank">andrew.john=
son83@gmail.com</a><span style=3D"font-family:sans-serif;font-size:13.696px=
">&gt;</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span =
style=3D"font-family:sans-serif;font-size:13.696px">&gt; wrote:</span><br s=
tyle=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-fami=
ly:sans-serif;font-size:13.696px">&gt;</span><br style=3D"font-family:sans-=
serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size:1=
3.696px">&gt; What&#39;s stopping these users from running a pruned node?=
=C2=A0 Not every node</span><br style=3D"font-family:sans-serif;font-size:1=
3.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">&gt; nee=
ds to store a complete copy of the blockchain.</span><br style=3D"font-fami=
ly:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;fon=
t-size:13.696px">&gt;</span><br style=3D"font-family:sans-serif;font-size:1=
3.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">&gt;</sp=
an><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"f=
ont-family:sans-serif;font-size:13.696px">&gt; Pruned nodes are not the def=
ault configuration, if it was the default</span><br style=3D"font-family:sa=
ns-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-siz=
e:13.696px">&gt; configuration then I think you would see far more users ru=
nning a pruned</span><br style=3D"font-family:sans-serif;font-size:13.696px=
"><span style=3D"font-family:sans-serif;font-size:13.696px">&gt; node.</spa=
n><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"fo=
nt-family:sans-serif;font-size:13.696px">&gt;</span><br style=3D"font-famil=
y:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font=
-size:13.696px">&gt; But that would also substantially increase the burden =
on archive nodes.</span><br style=3D"font-family:sans-serif;font-size:13.69=
6px"><span style=3D"font-family:sans-serif;font-size:13.696px">&gt;</span><=
br style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-=
family:sans-serif;font-size:13.696px">&gt;</span><br style=3D"font-family:s=
ans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-si=
ze:13.696px">&gt; Further discussion about disk space requirements should b=
e taken to</span><br style=3D"font-family:sans-serif;font-size:13.696px"><s=
pan style=3D"font-family:sans-serif;font-size:13.696px">&gt; another thread=
.</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=
=3D"font-family:sans-serif;font-size:13.696px">&gt;</span><br style=3D"font=
-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-seri=
f;font-size:13.696px">&gt;</span><br style=3D"font-family:sans-serif;font-s=
ize:13.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">&gt=
; --</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span st=
yle=3D"font-family:sans-serif;font-size:13.696px">Andrew Johnson</span><br =
style=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-fam=
ily:sans-serif;font-size:13.696px">-------------- next part --------------<=
/span><br style=3D"font-family:sans-serif;font-size:13.696px"><span style=
=3D"font-family:sans-serif;font-size:13.696px">An HTML attachment was scrub=
bed...</span><br style=3D"font-family:sans-serif;font-size:13.696px"><span =
style=3D"font-family:sans-serif;font-size:13.696px">URL: &lt;</span><a href=
=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/2017=
0329/9b48ebe3/attachment.html" style=3D"text-decoration:none;color:rgb(66,1=
33,244);font-family:sans-serif;font-size:13.696px" target=3D"_blank">http:/=
/lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/atta<wbr>chments/2017=
0329/9b48ebe3/atta<wbr>chment.html</a><span style=3D"font-family:sans-serif=
;font-size:13.696px">&gt;</span><br style=3D"font-family:sans-serif;font-si=
ze:13.696px"><br style=3D"font-family:sans-serif;font-size:13.696px"><span =
style=3D"font-family:sans-serif;font-size:13.696px">-----------------------=
-------</span><br style=3D"font-family:sans-serif;font-size:13.696px"></div=
></div></div></div><span class=3D"">
______________________________<wbr>_________________<br>bitcoin-dev mailing=
 list<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br><a href=3D"https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank=
">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev<=
/a><br></span></div></blockquote></div><br></div></div></div></div><br>____=
__________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c06b716dac456054be5f19a--