{"type":"rich","version":"1.0","author_name":"npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxs","author_url":"https://nostr.ae/npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxs","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-04-03\n📝 Original message:Thanks James for the post.\n\nI proposed a similar idea [1] back in 2016 with the difference of signing the UTXO-set hash in a gitian-ish way.\n\nWhile the idea of UTXO-set-syncs are attractive, there are probably still significant downsides in usability (compared to models with less security), mainly:\n* 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,… probably CPU-days on a phone)\n* 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?\n\nIf 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’m not sure if this proposal will lead to a satisfactory user experience.\n\nThe 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 to perform a painless full validation.\n\n/jonas\n\n[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html\n\n\u003e Am 02.04.2019 um 22:43 schrieb James O'Beirne via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e \n\u003e Hi,\n\u003e \n\u003e I'd like to discuss assumeutxo, which is an appealing and simple\n\u003e optimization in the spirit of assumevalid[0].\n\u003e \n\u003e # Motivation\n\u003e \n\u003e To start a fully validating bitcoin client from scratch, that client currently\n\u003e needs to perform an initial block download. To the surprise of no one, IBD\n\u003e takes a linear amount time based on the length of the chain's history. For\n\u003e clients running on modest hardware under limited bandwidth constraints,\n\u003e say a mobile device, completing IBD takes a considerable amount of time\n\u003e and thus poses serious usability challenges.\n\u003e \n\u003e As a result, having fully validating clients run on such hardware is rare and\n\u003e basically unrealistic. Clients with even moderate resource constraints\n\u003e are encouraged to rely on the SPV trust model. Though we have promising\n\u003e improvements to existing SPV modes pending deployment[1], it's worth\n\u003e thinking about a mechanism that would allow such clients to use trust\n\u003e models closer to full validation.\n\u003e \n\u003e The subject of this mail is a proposal for a complementary alternative to SPV\n\u003e modes, and which is in the spirit of an existing default, `assumevalid`. It may\n\u003e help modest clients transact under a security model that closely resembles\n\u003e full validation within minutes instead of hours or days.\n\u003e \n\u003e # assumeutxo\n\u003e \n\u003e The basic idea is to allow nodes to initialize using a serialized version of the\n\u003e UTXO set rendered by another node at some predetermined height. The\n\u003e initializing node syncs the headers chain from the network, then obtains and\n\u003e loads one of these UTXO snapshots (i.e. a serialized version of the UTXO set\n\u003e bundled with the block header indicating its \"base\" and some other metadata).\n\u003e \n\u003e Based upon the snapshot, the node is able to quickly reconstruct its chainstate,\n\u003e and compares a hash of the resulting UTXO set to a preordained hash hard-coded\n\u003e in the software a la assumevalid. This all takes ~23 minutes, not accounting for\n\u003e download of the 3.2GB snapshot[2].\n\u003e \n\u003e The node then syncs to the network tip and afterwards begins a simultaneous\n\u003e background validation (i.e., a conventional IBD) up to the base height of the\n\u003e snapshot in order to achieve full validation. Crucially, even while the\n\u003e background validation is happening the node can validate incoming blocks and\n\u003e transact with the benefit of the full (assumed-valid) UTXO set.\n\u003e \n\u003e Snapshots could be obtained from multiple separate peers in the same manner as\n\u003e block download, but I haven't put much thought into this. In concept it doesn't\n\u003e matter too much where the snapshots come from since their validity is\n\u003e determined via content hash.\n\u003e \n\u003e # Security\n\u003e \n\u003e Obviously there are some security implications due consideration. While this\n\u003e proposal is in the spirit of assumevalid, practical attacks may become easier.\n\u003e Under assumevalid, a user can be tricked into transacting under a false history\n\u003e if an attacker convinces them to start bitcoind with a malicious `-assumevalid`\n\u003e parameter, sybils their node, and then feeds them a bogus chain encompassing\n\u003e all of the hard-coded checkpoints[3].\n\u003e \n\u003e The same attack is made easier in assumeutxo because, unlike in assumevalid,\n\u003e the attacker need not construct a valid PoW chain to get the victim's node into\n\u003e a false state; they simply need to get the user to accept a bad `-assumeutxo`\n\u003e parameter and then supply them an easily made UTXO snapshot containing, say, a\n\u003e false coin assignment.\n\u003e \n\u003e For this reason, I recommend that if we were to implement assumeutxo, we not\n\u003e allow its specification via commandline argument[4].\n\u003e \n\u003e Beyond this risk, I can't think of material differences in security relative to\n\u003e assumevalid, though I appeal to the list for help with this.\n\u003e \n\u003e # More fully validating clients\n\u003e \n\u003e A particularly exciting use-case for assumeutxo is the possibility of mobile\n\u003e devices functioning as fully validating nodes with access to the complete UTXO\n\u003e set (as an alternative to SPV models). The total resource burden needed to start a node\n\u003e from scratch based on a snapshot is, at time of writing, a ~(3.2GB\n\u003e + blocks_to_tip * 4MB) download and a few minutes of processing time, which sounds\n\u003e manageable for many mobile devices currently in use.\n\u003e \n\u003e A mobile user could initialize an assumed-valid bitcoin node within an hour,\n\u003e transact immediately, and complete a pruned full validation of their\n\u003e assumed-valid chain over the next few days, perhaps only doing the background\n\u003e IBD when their device has access to suitable high-bandwidth connections.\n\u003e \n\u003e If we end up implementing an accumulator-based UTXO scaling design[5][6] down\n\u003e the road, it's easy to imagine an analogous process that would allow very fast\n\u003e startup using an accumulator of a few kilobytes in lieu of a multi-GB snapshot.\n\u003e \n\u003e ---\n\u003e \n\u003e I've created a related issue at our Github repository here:\n\u003e   https://github.com/bitcoin/bitcoin/issues/15605\n\u003e \n\u003e and have submitted a draft implementation of snapshot usage via RPC here:\n\u003e   https://github.com/bitcoin/bitcoin/pull/15606\n\u003e \n\u003e I'd like to discuss here whether this is a good fit for Bitcoin conceptually. Concrete\n\u003e plans for deployment steps should be discussed in the Github issue, and after all\n\u003e that my implementation may be reviewed as a sketch of the specific software\n\u003e changes necessary.\n\u003e \n\u003e Regards,\n\u003e James\n\u003e \n\u003e \n\u003e [0]: https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks\n\u003e [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki\n\u003e [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @ 2.10GHz\n\u003e [3]: https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161\n\u003e [4]: Marco Falke is due credit for this point\n\u003e [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc\n\u003e [6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/0005961e/attachment.sig\u003e"}