<div dir="ltr"><div dir="ltr"><div>Hi,<br></div><div><br></div><div>I&#39;d like to discuss assumeutxo, which is an appealing and simple </div><div>optimization in the spirit of assumevalid[0].</div><div><br></div><div># Motivation</div><div><br></div><div>To start a fully validating bitcoin client from scratch, that client currently</div><div>needs to perform an initial block download. To the surprise of no one, IBD </div><div>takes a linear amount time based on the length of the chain&#39;s history. For </div><div>clients running on modest hardware under limited bandwidth constraints, </div><div>say a mobile device, completing IBD takes a considerable amount of time </div><div>and thus poses serious usability challenges.</div><div><br></div><div>As a result, having fully validating clients run on such hardware is rare and</div><div>basically unrealistic. Clients with even moderate resource constraints</div><div>are encouraged to rely on the SPV trust model. Though we have promising</div><div>improvements to existing SPV modes pending deployment[1], it&#39;s worth</div><div>thinking about a mechanism that would allow such clients to use trust</div><div>models closer to full validation.</div><div><br></div><div>The subject of this mail is a proposal for a complementary alternative to SPV</div><div>modes, and which is in the spirit of an existing default, `assumevalid`. It may</div><div>help modest clients transact under a security model that closely resembles</div><div>full validation within minutes instead of hours or days.</div><div><br></div><div># assumeutxo</div><div><br></div><div>The basic idea is to allow nodes to initialize using a serialized version of the</div><div>UTXO set rendered by another node at some predetermined height. The</div><div>initializing node syncs the headers chain from the network, then obtains and</div><div>loads one of these UTXO snapshots (i.e. a serialized version of the UTXO set</div><div>bundled with the block header indicating its &quot;base&quot; and some other metadata).</div><div><br></div><div>Based upon the snapshot, the node is able to quickly reconstruct its chainstate,</div><div>and compares a hash of the resulting UTXO set to a preordained hash hard-coded</div><div>in the software a la assumevalid. This all takes ~23 minutes, not accounting for</div><div>download of the 3.2GB snapshot[2]. </div><div><br></div><div>The node then syncs to the network tip and afterwards begins a simultaneous</div><div>background validation (i.e., a conventional IBD) up to the base height of the</div><div>snapshot in order to achieve full validation. Crucially, even while the</div><div>background validation is happening the node can validate incoming blocks and</div><div>transact with the benefit of the full (assumed-valid) UTXO set.</div><div><br></div><div>Snapshots could be obtained from multiple separate peers in the same manner as</div><div>block download, but I haven&#39;t put much thought into this. In concept it doesn&#39;t</div><div>matter too much where the snapshots come from since their validity is</div><div>determined via content hash.</div><div><br></div><div># Security</div><div><br></div><div>Obviously there are some security implications due consideration. While this</div><div>proposal is in the spirit of assumevalid, practical attacks may become easier.</div><div>Under assumevalid, a user can be tricked into transacting under a false history</div><div>if an attacker convinces them to start bitcoind with a malicious `-assumevalid`</div><div>parameter, sybils their node, and then feeds them a bogus chain encompassing</div><div>all of the hard-coded checkpoints[3]. </div><div><br></div><div>The same attack is made easier in assumeutxo because, unlike in assumevalid,</div><div>the attacker need not construct a valid PoW chain to get the victim&#39;s node into</div><div>a false state; they simply need to get the user to accept a bad `-assumeutxo`</div><div>parameter and then supply them an easily made UTXO snapshot containing, say, a</div><div>false coin assignment.</div><div><br></div><div>For this reason, I recommend that if we were to implement assumeutxo, we not</div><div>allow its specification via commandline argument[4].</div><div><br></div><div>Beyond this risk, I can&#39;t think of material differences in security relative to</div><div>assumevalid, though I appeal to the list for help with this.</div><div><br></div><div># More fully validating clients</div><div><br></div><div>A particularly exciting use-case for assumeutxo is the possibility of mobile</div><div>devices functioning as fully validating nodes with access to the complete UTXO</div><div>set (as an alternative to SPV models). The total resource burden needed to start a node</div><div>from scratch based on a snapshot is, at time of writing, a ~(3.2GB</div><div>+ blocks_to_tip * 4MB) download and a few minutes of processing time, which sounds</div><div>manageable for many mobile devices currently in use.</div><div>  </div><div>A mobile user could initialize an assumed-valid bitcoin node within an hour,</div><div>transact immediately, and complete a pruned full validation of their</div><div>assumed-valid chain over the next few days, perhaps only doing the background</div><div>IBD when their device has access to suitable high-bandwidth connections.</div><div><br></div><div>If we end up implementing an accumulator-based UTXO scaling design[5][6] down</div><div>the road, it&#39;s easy to imagine an analogous process that would allow very fast</div><div>startup using an accumulator of a few kilobytes in lieu of a multi-GB snapshot.</div><div><br></div><div>---</div><div><br></div><div>I&#39;ve created a related issue at our Github repository here:</div><div>  <a href="https://github.com/bitcoin/bitcoin/issues/15605">https://github.com/bitcoin/bitcoin/issues/15605</a></div><div><br></div><div>and have submitted a draft implementation of snapshot usage via RPC here:</div><div>  <a href="https://github.com/bitcoin/bitcoin/pull/15606">https://github.com/bitcoin/bitcoin/pull/15606</a></div><div><br></div><div>I&#39;d like to discuss here whether this is a good fit for Bitcoin conceptually. Concrete</div><div>plans for deployment steps should be discussed in the Github issue, and after all </div><div>that my implementation may be reviewed as a sketch of the specific software</div><div>changes necessary.</div><div><br></div><div>Regards,</div><div>James</div><div><br></div><div><br></div><div>[0]: <a href="https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks">https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks</a></div><div>[1]: <a href="https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki</a></div><div>[2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @ 2.10GHz</div><div>[3]: <a href="https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161">https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161</a></div><div>[4]: Marco Falke is due credit for this point</div><div>[5]: utreexo: <a href="https://www.youtube.com/watch?v=edRun-6ubCc">https://www.youtube.com/watch?v=edRun-6ubCc</a></div><div>[6]: Boneh, Bunz, Fisch on accumulators: <a href="https://eprint.iacr.org/2018/1188">https://eprint.iacr.org/2018/1188</a></div><div><br></div></div></div>