summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEthan Scruples <ethan.scruples@gmail.com>2019-04-03 11:39:29 -0400
committerbitcoindev <bitcoindev@gnusha.org>2019-04-03 15:39:43 +0000
commitc3f95c0ac3f915d9a8db414f8906397dda46bc20 (patch)
tree73cc3e68ae93302ef692ce18c9fb88880b573230
parentdb5f00de1e04b6a93a21fd21e872bd950410be34 (diff)
downloadpi-bitcoindev-c3f95c0ac3f915d9a8db414f8906397dda46bc20.tar.gz
pi-bitcoindev-c3f95c0ac3f915d9a8db414f8906397dda46bc20.zip
Re: [bitcoin-dev] assumeutxo and UTXO snapshots
-rw-r--r--31/59a046bf04a6c1f28a25883c896f0c5a152d0f600
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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
+oin-dev@lists.linuxfoundation.org</a>&gt; 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>
+&gt; Am 02.04.2019 um 22:43 schrieb James O&#39;Beirne via bitcoin-dev &lt;=
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundation.org</a>&gt;:<br>
+&gt; <br>
+&gt; Hi,<br>
+&gt; <br>
+&gt; I&#39;d like to discuss assumeutxo, which is an appealing and simple<b=
+r>
+&gt; optimization in the spirit of assumevalid[0].<br>
+&gt; <br>
+&gt; # Motivation<br>
+&gt; <br>
+&gt; To start a fully validating bitcoin client from scratch, that client c=
+urrently<br>
+&gt; needs to perform an initial block download. To the surprise of no one,=
+ IBD<br>
+&gt; takes a linear amount time based on the length of the chain&#39;s hist=
+ory. For<br>
+&gt; clients running on modest hardware under limited bandwidth constraints=
+,<br>
+&gt; say a mobile device, completing IBD takes a considerable amount of tim=
+e<br>
+&gt; and thus poses serious usability challenges.<br>
+&gt; <br>
+&gt; As a result, having fully validating clients run on such hardware is r=
+are and<br>
+&gt; basically unrealistic. Clients with even moderate resource constraints=
+<br>
+&gt; are encouraged to rely on the SPV trust model. Though we have promisin=
+g<br>
+&gt; improvements to existing SPV modes pending deployment[1], it&#39;s wor=
+th<br>
+&gt; thinking about a mechanism that would allow such clients to use trust<=
+br>
+&gt; models closer to full validation.<br>
+&gt; <br>
+&gt; The subject of this mail is a proposal for a complementary alternative=
+ to SPV<br>
+&gt; modes, and which is in the spirit of an existing default, `assumevalid=
+`. It may<br>
+&gt; help modest clients transact under a security model that closely resem=
+bles<br>
+&gt; full validation within minutes instead of hours or days.<br>
+&gt; <br>
+&gt; # assumeutxo<br>
+&gt; <br>
+&gt; The basic idea is to allow nodes to initialize using a serialized vers=
+ion of the<br>
+&gt; UTXO set rendered by another node at some predetermined height. The<br=
+>
+&gt; initializing node syncs the headers chain from the network, then obtai=
+ns and<br>
+&gt; loads one of these UTXO snapshots (i.e. a serialized version of the UT=
+XO set<br>
+&gt; bundled with the block header indicating its &quot;base&quot; and some=
+ other metadata).<br>
+&gt; <br>
+&gt; Based upon the snapshot, the node is able to quickly reconstruct its c=
+hainstate,<br>
+&gt; and compares a hash of the resulting UTXO set to a preordained hash ha=
+rd-coded<br>
+&gt; in the software a la assumevalid. This all takes ~23 minutes, not acco=
+unting for<br>
+&gt; download of the 3.2GB snapshot[2].<br>
+&gt; <br>
+&gt; The node then syncs to the network tip and afterwards begins a simulta=
+neous<br>
+&gt; background validation (i.e., a conventional IBD) up to the base height=
+ of the<br>
+&gt; snapshot in order to achieve full validation. Crucially, even while th=
+e<br>
+&gt; background validation is happening the node can validate incoming bloc=
+ks and<br>
+&gt; transact with the benefit of the full (assumed-valid) UTXO set.<br>
+&gt; <br>
+&gt; Snapshots could be obtained from multiple separate peers in the same m=
+anner as<br>
+&gt; block download, but I haven&#39;t put much thought into this. In conce=
+pt it doesn&#39;t<br>
+&gt; matter too much where the snapshots come from since their validity is<=
+br>
+&gt; determined via content hash.<br>
+&gt; <br>
+&gt; # Security<br>
+&gt; <br>
+&gt; Obviously there are some security implications due consideration. Whil=
+e this<br>
+&gt; proposal is in the spirit of assumevalid, practical attacks may become=
+ easier.<br>
+&gt; Under assumevalid, a user can be tricked into transacting under a fals=
+e history<br>
+&gt; if an attacker convinces them to start bitcoind with a malicious `-ass=
+umevalid`<br>
+&gt; parameter, sybils their node, and then feeds them a bogus chain encomp=
+assing<br>
+&gt; all of the hard-coded checkpoints[3].<br>
+&gt; <br>
+&gt; The same attack is made easier in assumeutxo because, unlike in assume=
+valid,<br>
+&gt; the attacker need not construct a valid PoW chain to get the victim&#3=
+9;s node into<br>
+&gt; a false state; they simply need to get the user to accept a bad `-assu=
+meutxo`<br>
+&gt; parameter and then supply them an easily made UTXO snapshot containing=
+, say, a<br>
+&gt; false coin assignment.<br>
+&gt; <br>
+&gt; For this reason, I recommend that if we were to implement assumeutxo, =
+we not<br>
+&gt; allow its specification via commandline argument[4].<br>
+&gt; <br>
+&gt; Beyond this risk, I can&#39;t think of material differences in securit=
+y relative to<br>
+&gt; assumevalid, though I appeal to the list for help with this.<br>
+&gt; <br>
+&gt; # More fully validating clients<br>
+&gt; <br>
+&gt; A particularly exciting use-case for assumeutxo is the possibility of =
+mobile<br>
+&gt; devices functioning as fully validating nodes with access to the compl=
+ete UTXO<br>
+&gt; set (as an alternative to SPV models). The total resource burden neede=
+d to start a node<br>
+&gt; from scratch based on a snapshot is, at time of writing, a ~(3.2GB<br>
+&gt; + blocks_to_tip * 4MB) download and a few minutes of processing time, =
+which sounds<br>
+&gt; manageable for many mobile devices currently in use.<br>
+&gt; <br>
+&gt; A mobile user could initialize an assumed-valid bitcoin node within an=
+ hour,<br>
+&gt; transact immediately, and complete a pruned full validation of their<b=
+r>
+&gt; assumed-valid chain over the next few days, perhaps only doing the bac=
+kground<br>
+&gt; IBD when their device has access to suitable high-bandwidth connection=
+s.<br>
+&gt; <br>
+&gt; If we end up implementing an accumulator-based UTXO scaling design[5][=
+6] down<br>
+&gt; the road, it&#39;s easy to imagine an analogous process that would all=
+ow very fast<br>
+&gt; startup using an accumulator of a few kilobytes in lieu of a multi-GB =
+snapshot.<br>
+&gt; <br>
+&gt; ---<br>
+&gt; <br>
+&gt; I&#39;ve created a related issue at our Github repository here:<br>
+&gt;=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>
+&gt; <br>
+&gt; and have submitted a draft implementation of snapshot usage via RPC he=
+re:<br>
+&gt;=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>
+&gt; <br>
+&gt; I&#39;d like to discuss here whether this is a good fit for Bitcoin co=
+nceptually. Concrete<br>
+&gt; plans for deployment steps should be discussed in the Github issue, an=
+d after all<br>
+&gt; that my implementation may be reviewed as a sketch of the specific sof=
+tware<br>
+&gt; changes necessary.<br>
+&gt; <br>
+&gt; Regards,<br>
+&gt; James<br>
+&gt; <br>
+&gt; <br>
+&gt; [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>
+&gt; [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>
+&gt; [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 C=
+PU @ 2.10GHz<br>
+&gt; [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>
+&gt; [4]: Marco Falke is due credit for this point<br>
+&gt; [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>
+&gt; [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>
+&gt; <br>
+&gt; _______________________________________________<br>
+&gt; bitcoin-dev mailing list<br>
+&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
+ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
+&gt; <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--
+