{"type":"rich","version":"1.0","author_name":"npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3t","author_url":"https://nostr.ae/npub1dpdfw74plzm03mzglkdegp3hqn6qs9yffqefa5kh98mru49nrg7szymz3t","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-04-02\n📝 Original message:Hi,\n\nI'd like to discuss assumeutxo, which is an appealing and simple\noptimization in the spirit of assumevalid[0].\n\n# Motivation\n\nTo start a fully validating bitcoin client from scratch, that client\ncurrently\nneeds to perform an initial block download. To the surprise of no one, IBD\ntakes a linear amount time based on the length of the chain's history. For\nclients running on modest hardware under limited bandwidth constraints,\nsay a mobile device, completing IBD takes a considerable amount of time\nand thus poses serious usability challenges.\n\nAs a result, having fully validating clients run on such hardware is rare\nand\nbasically unrealistic. Clients with even moderate resource constraints\nare encouraged to rely on the SPV trust model. Though we have promising\nimprovements to existing SPV modes pending deployment[1], it's worth\nthinking about a mechanism that would allow such clients to use trust\nmodels closer to full validation.\n\nThe subject of this mail is a proposal for a complementary alternative to\nSPV\nmodes, and which is in the spirit of an existing default, `assumevalid`. It\nmay\nhelp modest clients transact under a security model that closely resembles\nfull validation within minutes instead of hours or days.\n\n# assumeutxo\n\nThe basic idea is to allow nodes to initialize using a serialized version\nof the\nUTXO set rendered by another node at some predetermined height. The\ninitializing node syncs the headers chain from the network, then obtains and\nloads one of these UTXO snapshots (i.e. a serialized version of the UTXO set\nbundled with the block header indicating its \"base\" and some other\nmetadata).\n\nBased upon the snapshot, the node is able to quickly reconstruct its\nchainstate,\nand compares a hash of the resulting UTXO set to a preordained hash\nhard-coded\nin the software a la assumevalid. This all takes ~23 minutes, not\naccounting for\ndownload of the 3.2GB snapshot[2].\n\nThe node then syncs to the network tip and afterwards begins a simultaneous\nbackground validation (i.e., a conventional IBD) up to the base height of\nthe\nsnapshot in order to achieve full validation. Crucially, even while the\nbackground validation is happening the node can validate incoming blocks and\ntransact with the benefit of the full (assumed-valid) UTXO set.\n\nSnapshots could be obtained from multiple separate peers in the same manner\nas\nblock download, but I haven't put much thought into this. In concept it\ndoesn't\nmatter too much where the snapshots come from since their validity is\ndetermined via content hash.\n\n# Security\n\nObviously there are some security implications due consideration. While this\nproposal is in the spirit of assumevalid, practical attacks may become\neasier.\nUnder assumevalid, a user can be tricked into transacting under a false\nhistory\nif an attacker convinces them to start bitcoind with a malicious\n`-assumevalid`\nparameter, sybils their node, and then feeds them a bogus chain encompassing\nall of the hard-coded checkpoints[3].\n\nThe same attack is made easier in assumeutxo because, unlike in assumevalid,\nthe attacker need not construct a valid PoW chain to get the victim's node\ninto\na false state; they simply need to get the user to accept a bad\n`-assumeutxo`\nparameter and then supply them an easily made UTXO snapshot containing,\nsay, a\nfalse coin assignment.\n\nFor this reason, I recommend that if we were to implement assumeutxo, we not\nallow its specification via commandline argument[4].\n\nBeyond this risk, I can't think of material differences in security\nrelative to\nassumevalid, though I appeal to the list for help with this.\n\n# More fully validating clients\n\nA particularly exciting use-case for assumeutxo is the possibility of mobile\ndevices functioning as fully validating nodes with access to the complete\nUTXO\nset (as an alternative to SPV models). The total resource burden needed to\nstart a node\nfrom scratch based on a snapshot is, at time of writing, a ~(3.2GB\n+ blocks_to_tip * 4MB) download and a few minutes of processing time, which\nsounds\nmanageable for many mobile devices currently in use.\n\nA mobile user could initialize an assumed-valid bitcoin node within an hour,\ntransact immediately, and complete a pruned full validation of their\nassumed-valid chain over the next few days, perhaps only doing the\nbackground\nIBD when their device has access to suitable high-bandwidth connections.\n\nIf we end up implementing an accumulator-based UTXO scaling design[5][6]\ndown\nthe road, it's easy to imagine an analogous process that would allow very\nfast\nstartup using an accumulator of a few kilobytes in lieu of a multi-GB\nsnapshot.\n\n---\n\nI've created a related issue at our Github repository here:\n  https://github.com/bitcoin/bitcoin/issues/15605\n\nand have submitted a draft implementation of snapshot usage via RPC here:\n  https://github.com/bitcoin/bitcoin/pull/15606\n\nI'd like to discuss here whether this is a good fit for Bitcoin\nconceptually. Concrete\nplans for deployment steps should be discussed in the Github issue, and\nafter all\nthat my implementation may be reviewed as a sketch of the specific software\nchanges necessary.\n\nRegards,\nJames\n\n\n[0]:\nhttps://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks\n[1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki\n[2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @\n2.10GHz\n[3]:\nhttps://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161\n[4]: Marco Falke is due credit for this point\n[5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc\n[6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/46b25dd8/attachment-0001.html\u003e"}