diff options
| author | Jared Lee Richardson <jaredr26@gmail.com> | 2017-03-29 15:17:40 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-03-29 22:17:44 +0000 |
| commit | b56b664e4a6e79849764936a4b0aaf8ec3013af2 (patch) | |
| tree | 5718db625ff2b26909bc2cdb5309b472df45c7d0 | |
| parent | c552ba8be0975e2b5b3f5511b9b2ccf051897f92 (diff) | |
| download | pi-bitcoindev-b56b664e4a6e79849764936a4b0aaf8ec3013af2.tar.gz pi-bitcoindev-b56b664e4a6e79849764936a4b0aaf8ec3013af2.zip | |
Re: [bitcoin-dev] Hard fork proposal from last week's meeting
| -rw-r--r-- | f2/877ad83e39128ddaa319bd698dda8a0eab63ed | 482 |
1 files changed, 482 insertions, 0 deletions
diff --git a/f2/877ad83e39128ddaa319bd698dda8a0eab63ed b/f2/877ad83e39128ddaa319bd698dda8a0eab63ed new file mode 100644 index 000000000..c576cd969 --- /dev/null +++ b/f2/877ad83e39128ddaa319bd698dda8a0eab63ed @@ -0,0 +1,482 @@ +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">>=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't work without a way for a new node to dif= +ferentiate between a false history and a true one.<br><br>>=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= +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'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"><<a href=3D"mailto:= +bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.= +linuxfoundation.org</a>></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 "get the ball rolling" 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 <<a href=3D"mailto:bitcoin-de= +v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linux= +foundation.org</a>> 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 <</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">></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 <</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">= +></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 <</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">></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'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 <</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">></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"= +;utf-8"</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'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= +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 "real" 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'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'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 <</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">></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">></span><br style=3D"font-family:sans-serif;font-size:13.696p= +x"><span style=3D"font-family:sans-serif;font-size:13.696px">> On Mar 29= +, 2017 12:20 PM, "Andrew Johnson" <</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= +">></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 s= +tyle=3D"font-family:sans-serif;font-size:13.696px"><span style=3D"font-fami= +ly:sans-serif;font-size:13.696px">></span><br style=3D"font-family:sans-= +serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-size:1= +3.696px">> What'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">> 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">></span><br style=3D"font-family:sans-serif;font-size:1= +3.696px"><span style=3D"font-family:sans-serif;font-size:13.696px">></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">> 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">> 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">> 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">></span><br style=3D"font-famil= +y:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font= +-size:13.696px">> 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">></span><= +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:s= +ans-serif;font-size:13.696px"><span style=3D"font-family:sans-serif;font-si= +ze:13.696px">> 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">> 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">></span><br style=3D"font= +-family:sans-serif;font-size:13.696px"><span style=3D"font-family:sans-seri= +f;font-size:13.696px">></span><br style=3D"font-family:sans-serif;font-s= +ize: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"><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: <</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">></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-- + |