diff options
author | Ethan Scruples <ethan.scruples@gmail.com> | 2019-04-03 11:39:29 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2019-04-03 15:39:43 +0000 |
commit | c3f95c0ac3f915d9a8db414f8906397dda46bc20 (patch) | |
tree | 73cc3e68ae93302ef692ce18c9fb88880b573230 | |
parent | db5f00de1e04b6a93a21fd21e872bd950410be34 (diff) | |
download | pi-bitcoindev-c3f95c0ac3f915d9a8db414f8906397dda46bc20.tar.gz pi-bitcoindev-c3f95c0ac3f915d9a8db414f8906397dda46bc20.zip |
Re: [bitcoin-dev] assumeutxo and UTXO snapshots
-rw-r--r-- | 31/59a046bf04a6c1f28a25883c896f0c5a152d0f | 600 |
1 files changed, 600 insertions, 0 deletions
diff --git a/31/59a046bf04a6c1f28a25883c896f0c5a152d0f b/31/59a046bf04a6c1f28a25883c896f0c5a152d0f new file mode 100644 index 000000000..3d18a49e0 --- /dev/null +++ b/31/59a046bf04a6c1f28a25883c896f0c5a152d0f @@ -0,0 +1,600 @@ +Return-Path: <ethan.scruples@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 6594C1156 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 3 Apr 2019 15:39:43 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com + [209.85.160.181]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF519712 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 3 Apr 2019 15:39:41 +0000 (UTC) +Received: by mail-qt1-f181.google.com with SMTP id p20so19828688qtc.9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 03 Apr 2019 08:39:41 -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; + bh=XxhzRw38eLGhUPuFed5uMYl/2FS7hUM6tw08aDQ8SoM=; + b=hYfDWDUQ3SAMPHYCDu+wKWUpeZDh7Vh3cD25IZL0mnh87TB4qS7bQ+Kq1pIfKipEEG + cHRATAdCM5wEnyWkrqqHlkZKaguEp9yRlF9xYaPtyGJXIbMiIBwwBAOvMQYLlBX7vWAr + wviY+ujXd5OCt0stOiQTqsxGsKDXg5yYc+gVXVZEVSETvqK00AV2mnsU0R1jsSTG5RCh + pYnphMiWc78VK9gXqVDQfFgssZ4OcOn7wiOy8i4SuK0ByzBnUjHD8mn+BIfAomSjnDgr + iQRj33Jy/hYzMsLP5WkDedzcMfDhOC6Yks2damIAaW4Rw4e2x6m3+DuHaHqqMtyCq/5Y + 5cfQ== +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; + bh=XxhzRw38eLGhUPuFed5uMYl/2FS7hUM6tw08aDQ8SoM=; + b=kP2KlDWC9kojJRzhDX0LFSDG1MYHuCBb7cwycDCc7UycKBL0tOPZ/ALU+1D3HhBroC + mqMtlzYudf+wzzk8WMGYnISPQxv7r4lsWX3WZblRTfsES/rlzz5OscQBOismsJVTvkD/ + gz/gO0nnImzsdeE18v3Nr9uk5bdE+TVh5G+UsojlUUq27TAR/lANYhWL5/4bjJjI1ql5 + 93JzmvXOMMmGo5dpVXXaouebISPSRIw42EweUaPZhBWVXH0y/jCsr9tB3bfvVqJtvd2X + GYP6dUW1K0FZhYDB3g9OzhHe0j6naF/R509GrXLkVVo3Hlrq6M7Q7J8VKGdugoCseEwk + 4Nkw== +X-Gm-Message-State: APjAAAWfZrLbHSqtpAUc3TX22MO7on0FvGP/6+PX3ZmiMjBmsad4EYzu + Uz1Vjub8sJf+ilgEWTKYcs7HW1DlyWyKYVk+2cd3dw== +X-Google-Smtp-Source: APXvYqyk1N6OGoRQbFZC2AMFCamWXqn4G0H18V4MEGrmVXF6DyHCSkmZpRIV+w6LRNHQEOsK/14ZQYEJmow6AVH/b3s= +X-Received: by 2002:ac8:65ce:: with SMTP id t14mr516616qto.255.1554305980844; + Wed, 03 Apr 2019 08:39:40 -0700 (PDT) +MIME-Version: 1.0 +References: <CAPfvXf+JS6ZhXUieWVxiaNa4uhhWwafCk3odMKy5F_yi=XwngA@mail.gmail.com> + <816FFA03-B4D9-4ECE-AF15-85ACBFA4BA8F@jonasschnelli.ch> +In-Reply-To: <816FFA03-B4D9-4ECE-AF15-85ACBFA4BA8F@jonasschnelli.ch> +From: Ethan Scruples <ethan.scruples@gmail.com> +Date: Wed, 3 Apr 2019 11:39:29 -0400 +Message-ID: <CACiOHGxxqm5Qn8J9u5oDE5Ek5smqB4E4iz4PJOZHpJO5kwP=-A@mail.gmail.com> +To: Jonas Schnelli <dev@jonasschnelli.ch>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000dc50190585a20f7d" +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE 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, 03 Apr 2019 19:23:04 +0000 +Subject: Re: [bitcoin-dev] assumeutxo and UTXO snapshots +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, 03 Apr 2019 15:39:43 -0000 + +--000000000000dc50190585a20f7d +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Jonas, + +If we can get mandatory UTXO commitments soft forked into Bitcoin, we get +the advantage of a non-growing IBD, which I think everyone would agree is a +benefit that, uh, grows over time. The thing I do not see people noticing +is that we actually pay little to no security price for this benefit. + +To see this, consider Alice, who starts from a UTXO snapshot made at +current height - 50,000 and Bob who validates from genesis. + +After her partial validation, Alice is satisfied that she is in possession +of the UTXO set-- she is in consensus with the rest of the network peers. + +However, Bob realizes that there is actually an invalid block at current +height - 50,001. + +Three things to notice: + +1. This scenario essentially cannot happen. There is no way that the miners +are going to stack 50,000 blocks on top of an invalid block without the +economic majority abandoning the invalid chain. + +2. If this scenario DOES happen, Bob has learned about it too late for it +to matter to Bob. The blockchain Bob wants to be on is the one that +everyone has been using for the last year, whether or not it is besmirched +by an invalid block. + +3. If this scenario DOES happen, and Bob DOES want to reject the last +50,000 mined blocks as invalid, he may discover to his dismay that in the 1 +year since the invalid block, mischievous entities have enough time to mine +equally weighted alternative histories from the Genesis block forward to +the invalid block, meaning that Bob has no way to use POW to come to +consensus with other Bobs out there. + +On Wed, Apr 3, 2019 at 3:33 AM Jonas Schnelli via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Thanks James for the post. +> +> I proposed a similar idea [1] back in 2016 with the difference of signing +> the UTXO-set hash in a gitian-ish way. +> +> While the idea of UTXO-set-syncs are attractive, there are probably still +> significant downsides in usability (compared to models with less security= +), +> mainly: +> * Assume the UTXO set is 6 weeks old (which seems a reasonable age for +> providing enough security) a peer using that snapshot would still require +> to download and verify ~6048 blocks (~7.9GB at 1.3MB blocks,=E2=80=A6 pro= +bably +> CPU-days on a phone) +> * Do we semi-trust the peer that servers the UTXO set (compared to a bloc= +k +> or tx which we can validate)? What channel to we use to serve the snapsho= +t? +> +> If the goal is to run a full node on a consumer device that is also been +> used for other CPU intense operations (like a phone, etc.), I=E2=80=99m n= +ot sure if +> this proposal will lead to a satisfactory user experience. +> +> The longer I think around this problem, the more I lean towards accepting +> the fact that one need to use dedicated hardware in his own environment t= +o +> perform a painless full validation. +> +> /jonas +> +> [1] +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012= +478.html +> +> > Am 02.04.2019 um 22:43 schrieb James O'Beirne via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org>: +> > +> > Hi, +> > +> > I'd like to discuss assumeutxo, which is an appealing and simple +> > optimization in the spirit of assumevalid[0]. +> > +> > # Motivation +> > +> > To start a fully validating bitcoin client from scratch, that client +> currently +> > needs to perform an initial block download. To the surprise of no one, +> IBD +> > takes a linear amount time based on the length of the chain's history. +> For +> > clients running on modest hardware under limited bandwidth constraints, +> > say a mobile device, completing IBD takes a considerable amount of time +> > and thus poses serious usability challenges. +> > +> > As a result, having fully validating clients run on such hardware is +> rare and +> > basically unrealistic. Clients with even moderate resource constraints +> > are encouraged to rely on the SPV trust model. Though we have promising +> > improvements to existing SPV modes pending deployment[1], it's worth +> > thinking about a mechanism that would allow such clients to use trust +> > models closer to full validation. +> > +> > The subject of this mail is a proposal for a complementary alternative +> to SPV +> > modes, and which is in the spirit of an existing default, `assumevalid`= +. +> It may +> > help modest clients transact under a security model that closely +> resembles +> > full validation within minutes instead of hours or days. +> > +> > # assumeutxo +> > +> > The basic idea is to allow nodes to initialize using a serialized +> version of the +> > UTXO set rendered by another node at some predetermined height. The +> > initializing node syncs the headers chain from the network, then obtain= +s +> and +> > loads one of these UTXO snapshots (i.e. a serialized version of the UTX= +O +> set +> > bundled with the block header indicating its "base" and some other +> metadata). +> > +> > Based upon the snapshot, the node is able to quickly reconstruct its +> chainstate, +> > and compares a hash of the resulting UTXO set to a preordained hash +> hard-coded +> > in the software a la assumevalid. This all takes ~23 minutes, not +> accounting for +> > download of the 3.2GB snapshot[2]. +> > +> > The node then syncs to the network tip and afterwards begins a +> simultaneous +> > background validation (i.e., a conventional IBD) up to the base height +> of the +> > snapshot in order to achieve full validation. Crucially, even while the +> > background validation is happening the node can validate incoming block= +s +> and +> > transact with the benefit of the full (assumed-valid) UTXO set. +> > +> > Snapshots could be obtained from multiple separate peers in the same +> manner as +> > block download, but I haven't put much thought into this. In concept it +> doesn't +> > matter too much where the snapshots come from since their validity is +> > determined via content hash. +> > +> > # Security +> > +> > Obviously there are some security implications due consideration. While +> this +> > proposal is in the spirit of assumevalid, practical attacks may become +> easier. +> > Under assumevalid, a user can be tricked into transacting under a false +> history +> > if an attacker convinces them to start bitcoind with a malicious +> `-assumevalid` +> > parameter, sybils their node, and then feeds them a bogus chain +> encompassing +> > all of the hard-coded checkpoints[3]. +> > +> > The same attack is made easier in assumeutxo because, unlike in +> assumevalid, +> > the attacker need not construct a valid PoW chain to get the victim's +> node into +> > a false state; they simply need to get the user to accept a bad +> `-assumeutxo` +> > parameter and then supply them an easily made UTXO snapshot containing, +> say, a +> > false coin assignment. +> > +> > For this reason, I recommend that if we were to implement assumeutxo, w= +e +> not +> > allow its specification via commandline argument[4]. +> > +> > Beyond this risk, I can't think of material differences in security +> relative to +> > assumevalid, though I appeal to the list for help with this. +> > +> > # More fully validating clients +> > +> > A particularly exciting use-case for assumeutxo is the possibility of +> mobile +> > devices functioning as fully validating nodes with access to the +> complete UTXO +> > set (as an alternative to SPV models). The total resource burden needed +> to start a node +> > from scratch based on a snapshot is, at time of writing, a ~(3.2GB +> > + blocks_to_tip * 4MB) download and a few minutes of processing time, +> which sounds +> > manageable for many mobile devices currently in use. +> > +> > A mobile user could initialize an assumed-valid bitcoin node within an +> hour, +> > transact immediately, and complete a pruned full validation of their +> > assumed-valid chain over the next few days, perhaps only doing the +> background +> > IBD when their device has access to suitable high-bandwidth connections= +. +> > +> > If we end up implementing an accumulator-based UTXO scaling design[5][6= +] +> down +> > the road, it's easy to imagine an analogous process that would allow +> very fast +> > startup using an accumulator of a few kilobytes in lieu of a multi-GB +> snapshot. +> > +> > --- +> > +> > I've created a related issue at our Github repository here: +> > https://github.com/bitcoin/bitcoin/issues/15605 +> > +> > and have submitted a draft implementation of snapshot usage via RPC her= +e: +> > https://github.com/bitcoin/bitcoin/pull/15606 +> > +> > I'd like to discuss here whether this is a good fit for Bitcoin +> conceptually. Concrete +> > plans for deployment steps should be discussed in the Github issue, and +> after all +> > that my implementation may be reviewed as a sketch of the specific +> software +> > changes necessary. +> > +> > Regards, +> > James +> > +> > +> > [0]: +> https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-block= +s +> > [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki +> > [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CP= +U +> @ 2.10GHz +> > [3]: +> https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-= +L161 +> > [4]: Marco Falke is due credit for this point +> > [5]: utreexo: https://www.youtube.com/watch?v=3DedRun-6ubCc +> > [6]: Boneh, Bunz, Fisch on accumulators: +> https://eprint.iacr.org/2018/1188 +> > +> > _______________________________________________ +> > 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 +> + +--000000000000dc50190585a20f7d +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Jonas,<div><br></div><div>If we can get mandatory UTXO com= +mitments soft forked into Bitcoin, we get the advantage of a non-growing IB= +D, which I think everyone would agree is a benefit that, uh, grows over tim= +e. The thing I do not see people noticing is that we actually pay little to= + no security price for this benefit.</div><div><br></div><div>To see this, = +consider Alice, who starts from a UTXO snapshot made at current height - 50= +,000 and Bob who validates from genesis.</div><div><br></div><div>After her= + partial validation, Alice is satisfied that she is in possession of the UT= +XO set-- she is in consensus with the rest of the network peers.</div><div>= +<br></div><div>However, Bob realizes that there is actually an invalid bloc= +k at current height - 50,001.</div><div><br></div><div>Three things to noti= +ce:</div><div><br></div><div>1. This scenario essentially cannot happen. Th= +ere is no way that the miners are going to stack 50,000 blocks on top of an= + invalid block without the economic majority abandoning the invalid chain.<= +/div><div><br></div><div>2. If this scenario DOES happen, Bob has learned a= +bout it too late for it to matter to Bob. The blockchain Bob wants to be on= + is the one that everyone has been using for the last year, whether or not = +it is besmirched by an invalid block.</div><div><br></div><div>3. If this s= +cenario DOES happen, and Bob DOES want to reject the last 50,000 mined bloc= +ks as invalid, he may discover to his dismay that in the 1 year since the i= +nvalid block, mischievous entities have enough time to mine equally weighte= +d alternative histories from the Genesis block forward to the invalid block= +, meaning that Bob has no way to use POW to come to consensus with other Bo= +bs out there.<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr= +" class=3D"gmail_attr">On Wed, Apr 3, 2019 at 3:33 AM Jonas Schnelli via bi= +tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc= +oin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class= +=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= +b(204,204,204);padding-left:1ex">Thanks James for the post.<br> +<br> +I proposed a similar idea [1] back in 2016 with the difference of signing t= +he UTXO-set hash in a gitian-ish way.<br> +<br> +While the idea of UTXO-set-syncs are attractive, there are probably still s= +ignificant downsides in usability (compared to models with less security), = +mainly:<br> +* Assume the UTXO set is 6 weeks old (which seems a reasonable age for prov= +iding enough security) a peer using that snapshot would still require to do= +wnload and verify ~6048 blocks (~7.9GB at 1.3MB blocks,=E2=80=A6 probably C= +PU-days on a phone)<br> +* Do we semi-trust the peer that servers the UTXO set (compared to a block = +or tx which we can validate)? What channel to we use to serve the snapshot?= +<br> +<br> +If the goal is to run a full node on a consumer device that is also been us= +ed for other CPU intense operations (like a phone, etc.), I=E2=80=99m not s= +ure if this proposal will lead to a satisfactory user experience.<br> +<br> +The longer I think around this problem, the more I lean towards accepting t= +he fact that one need to use dedicated hardware in his own environment to p= +erform a painless full validation.<br> +<br> +/jonas<br> +<br> +[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016= +-February/012478.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l= +inuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html</a><br> +<br> +> Am 02.04.2019 um 22:43 schrieb James O'Beirne via bitcoin-dev <= +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a>>:<br> +> <br> +> Hi,<br> +> <br> +> I'd like to discuss assumeutxo, which is an appealing and simple<b= +r> +> optimization in the spirit of assumevalid[0].<br> +> <br> +> # Motivation<br> +> <br> +> To start a fully validating bitcoin client from scratch, that client c= +urrently<br> +> needs to perform an initial block download. To the surprise of no one,= + IBD<br> +> takes a linear amount time based on the length of the chain's hist= +ory. For<br> +> clients running on modest hardware under limited bandwidth constraints= +,<br> +> say a mobile device, completing IBD takes a considerable amount of tim= +e<br> +> and thus poses serious usability challenges.<br> +> <br> +> As a result, having fully validating clients run on such hardware is r= +are and<br> +> basically unrealistic. Clients with even moderate resource constraints= +<br> +> are encouraged to rely on the SPV trust model. Though we have promisin= +g<br> +> improvements to existing SPV modes pending deployment[1], it's wor= +th<br> +> thinking about a mechanism that would allow such clients to use trust<= +br> +> models closer to full validation.<br> +> <br> +> The subject of this mail is a proposal for a complementary alternative= + to SPV<br> +> modes, and which is in the spirit of an existing default, `assumevalid= +`. It may<br> +> help modest clients transact under a security model that closely resem= +bles<br> +> full validation within minutes instead of hours or days.<br> +> <br> +> # assumeutxo<br> +> <br> +> The basic idea is to allow nodes to initialize using a serialized vers= +ion of the<br> +> UTXO set rendered by another node at some predetermined height. The<br= +> +> initializing node syncs the headers chain from the network, then obtai= +ns and<br> +> loads one of these UTXO snapshots (i.e. a serialized version of the UT= +XO set<br> +> bundled with the block header indicating its "base" and some= + other metadata).<br> +> <br> +> Based upon the snapshot, the node is able to quickly reconstruct its c= +hainstate,<br> +> and compares a hash of the resulting UTXO set to a preordained hash ha= +rd-coded<br> +> in the software a la assumevalid. This all takes ~23 minutes, not acco= +unting for<br> +> download of the 3.2GB snapshot[2].<br> +> <br> +> The node then syncs to the network tip and afterwards begins a simulta= +neous<br> +> background validation (i.e., a conventional IBD) up to the base height= + of the<br> +> snapshot in order to achieve full validation. Crucially, even while th= +e<br> +> background validation is happening the node can validate incoming bloc= +ks and<br> +> transact with the benefit of the full (assumed-valid) UTXO set.<br> +> <br> +> Snapshots could be obtained from multiple separate peers in the same m= +anner as<br> +> block download, but I haven't put much thought into this. In conce= +pt it doesn't<br> +> matter too much where the snapshots come from since their validity is<= +br> +> determined via content hash.<br> +> <br> +> # Security<br> +> <br> +> Obviously there are some security implications due consideration. Whil= +e this<br> +> proposal is in the spirit of assumevalid, practical attacks may become= + easier.<br> +> Under assumevalid, a user can be tricked into transacting under a fals= +e history<br> +> if an attacker convinces them to start bitcoind with a malicious `-ass= +umevalid`<br> +> parameter, sybils their node, and then feeds them a bogus chain encomp= +assing<br> +> all of the hard-coded checkpoints[3].<br> +> <br> +> The same attack is made easier in assumeutxo because, unlike in assume= +valid,<br> +> the attacker need not construct a valid PoW chain to get the victim= +9;s node into<br> +> a false state; they simply need to get the user to accept a bad `-assu= +meutxo`<br> +> parameter and then supply them an easily made UTXO snapshot containing= +, say, a<br> +> false coin assignment.<br> +> <br> +> For this reason, I recommend that if we were to implement assumeutxo, = +we not<br> +> allow its specification via commandline argument[4].<br> +> <br> +> Beyond this risk, I can't think of material differences in securit= +y relative to<br> +> assumevalid, though I appeal to the list for help with this.<br> +> <br> +> # More fully validating clients<br> +> <br> +> A particularly exciting use-case for assumeutxo is the possibility of = +mobile<br> +> devices functioning as fully validating nodes with access to the compl= +ete UTXO<br> +> set (as an alternative to SPV models). The total resource burden neede= +d to start a node<br> +> from scratch based on a snapshot is, at time of writing, a ~(3.2GB<br> +> + blocks_to_tip * 4MB) download and a few minutes of processing time, = +which sounds<br> +> manageable for many mobile devices currently in use.<br> +> <br> +> A mobile user could initialize an assumed-valid bitcoin node within an= + hour,<br> +> transact immediately, and complete a pruned full validation of their<b= +r> +> assumed-valid chain over the next few days, perhaps only doing the bac= +kground<br> +> IBD when their device has access to suitable high-bandwidth connection= +s.<br> +> <br> +> If we end up implementing an accumulator-based UTXO scaling design[5][= +6] down<br> +> the road, it's easy to imagine an analogous process that would all= +ow very fast<br> +> startup using an accumulator of a few kilobytes in lieu of a multi-GB = +snapshot.<br> +> <br> +> ---<br> +> <br> +> I've created a related issue at our Github repository here:<br> +>=C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/issues/15605= +" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/i= +ssues/15605</a><br> +> <br> +> and have submitted a draft implementation of snapshot usage via RPC he= +re:<br> +>=C2=A0 =C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/15606" = +rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pul= +l/15606</a><br> +> <br> +> I'd like to discuss here whether this is a good fit for Bitcoin co= +nceptually. Concrete<br> +> plans for deployment steps should be discussed in the Github issue, an= +d after all<br> +> that my implementation may be reviewed as a sketch of the specific sof= +tware<br> +> changes necessary.<br> +> <br> +> Regards,<br> +> James<br> +> <br> +> <br> +> [0]: <a href=3D"https://bitcoincore.org/en/2017/03/08/release-0.14.0/#= +assumed-valid-blocks" rel=3D"noreferrer" target=3D"_blank">https://bitcoinc= +ore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks</a><br> +> [1]: <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0157.m= +ediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/b= +ips/blob/master/bip-0157.mediawiki</a><br> +> [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 C= +PU @ 2.10GHz<br> +> [3]: <a href=3D"https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/ch= +ainparams.cpp#L145-L161" rel=3D"noreferrer" target=3D"_blank">https://githu= +b.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161</a><br> +> [4]: Marco Falke is due credit for this point<br> +> [5]: utreexo: <a href=3D"https://www.youtube.com/watch?v=3DedRun-6ubCc= +" rel=3D"noreferrer" target=3D"_blank">https://www.youtube.com/watch?v=3Ded= +Run-6ubCc</a><br> +> [6]: Boneh, Bunz, Fisch on accumulators: <a href=3D"https://eprint.iac= +r.org/2018/1188" rel=3D"noreferrer" target=3D"_blank">https://eprint.iacr.o= +rg/2018/1188</a><br> +> <br> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org= +/mailman/listinfo/bitcoin-dev</a><br> +<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--000000000000dc50190585a20f7d-- + |