{"type":"rich","version":"1.0","author_name":"npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8","author_url":"https://nostr.ae/npub15wz8j5cse6sexlw6f5q7arc5efe5hxn6kcxxyy222et8qms4u3lsemaru8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-04-03\n📝 Original message:Every block's hash is smaller than the difficulty at that time.  Block\n569927's hash was VERY small (started with 21 zeros).  The ratio of block\nhash to difficulty requirement (0xffffffff - difficulty, I think) could be\nused to identify blocks as \"special,\" thus providing the opportunity to\npopularize unimportant but memorable-and-therefore-useful details.  How can\nthey be useful if they are unimportant?  They are useful for sanity\nchecking.  For example, if the drunken bishop walk (or some other popular\nrandomart) produced by block 569927's hash looked like a face, that would\nbe memorable: \"The block with the smallest hash in 2019 (maybe ever?) looks\nlike a face after the drunken bishop walk.\"\n\nIf a few of these showed up each year, then Bob and/or Alice would have a\ngood chance of seeing that something was wrong if and when they checked.\nIt would not be surprising, given Ethan's assumption that the invalid block\nBob found contributed to Alice's UTXOs, that at some point, the history one\nof them has would be missing the memorable things beginning at some block\nheight because, clearly, one of them has been forked.\n\nLuke's comment that it could \"lead to users trusting third parties (like\ndevelopers) way too much\" is pertinent too, but I think an honest abatement\nof that concern is impossible without teaching everyone C++.  \"Developers\"\nas an open group (anyone can fork the github repo, find a problem, and make\nan issue) deserve the trust we put in them, and that's because they're\naccountable (any such error found in the repo will have been put there by\nsomeone).  The same thing goes for making it possible to download (*not\njust the compiled software*, but) the entire UTXO Set if a commitment of it\nis hardcoded into the software, as James suggests.  We all trust\n\"developers\" like that, and it's okay.  No one holds the \"ring of power.\"\n\nOn Wed, Apr 3, 2019 at 8:39 AM Ethan Scruples via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Jonas,\n\u003e\n\u003e If we can get mandatory UTXO commitments soft forked into Bitcoin, we get\n\u003e the advantage of a non-growing IBD, which I think everyone would agree is a\n\u003e benefit that, uh, grows over time. The thing I do not see people noticing\n\u003e is that we actually pay little to no security price for this benefit.\n\u003e\n\u003e To see this, consider Alice, who starts from a UTXO snapshot made at\n\u003e current height - 50,000 and Bob who validates from genesis.\n\u003e\n\u003e After her partial validation, Alice is satisfied that she is in possession\n\u003e of the UTXO set-- she is in consensus with the rest of the network peers.\n\u003e\n\u003e However, Bob realizes that there is actually an invalid block at current\n\u003e height - 50,001.\n\u003e\n\u003e Three things to notice:\n\u003e\n\u003e 1. This scenario essentially cannot happen. There is no way that the\n\u003e miners are going to stack 50,000 blocks on top of an invalid block without\n\u003e the economic majority abandoning the invalid chain.\n\u003e\n\u003e 2. If this scenario DOES happen, Bob has learned about it too late for it\n\u003e to matter to Bob. The blockchain Bob wants to be on is the one that\n\u003e everyone has been using for the last year, whether or not it is besmirched\n\u003e by an invalid block.\n\u003e\n\u003e 3. If this scenario DOES happen, and Bob DOES want to reject the last\n\u003e 50,000 mined blocks as invalid, he may discover to his dismay that in the 1\n\u003e year since the invalid block, mischievous entities have enough time to mine\n\u003e equally weighted alternative histories from the Genesis block forward to\n\u003e the invalid block, meaning that Bob has no way to use POW to come to\n\u003e consensus with other Bobs out there.\n\u003e\n\u003e On Wed, Apr 3, 2019 at 3:33 AM Jonas Schnelli via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Thanks James for the post.\n\u003e\u003e\n\u003e\u003e I proposed a similar idea [1] back in 2016 with the difference of signing\n\u003e\u003e the UTXO-set hash in a gitian-ish way.\n\u003e\u003e\n\u003e\u003e While the idea of UTXO-set-syncs are attractive, there are probably still\n\u003e\u003e significant downsides in usability (compared to models with less security),\n\u003e\u003e mainly:\n\u003e\u003e * Assume the UTXO set is 6 weeks old (which seems a reasonable age for\n\u003e\u003e providing enough security) a peer using that snapshot would still require\n\u003e\u003e to download and verify ~6048 blocks (~7.9GB at 1.3MB blocks,… probably\n\u003e\u003e CPU-days on a phone)\n\u003e\u003e * Do we semi-trust the peer that servers the UTXO set (compared to a\n\u003e\u003e block or tx which we can validate)? What channel to we use to serve the\n\u003e\u003e snapshot?\n\u003e\u003e\n\u003e\u003e If the goal is to run a full node on a consumer device that is also been\n\u003e\u003e used for other CPU intense operations (like a phone, etc.), I’m not sure if\n\u003e\u003e this proposal will lead to a satisfactory user experience.\n\u003e\u003e\n\u003e\u003e The longer I think around this problem, the more I lean towards accepting\n\u003e\u003e the fact that one need to use dedicated hardware in his own environment to\n\u003e\u003e perform a painless full validation.\n\u003e\u003e\n\u003e\u003e /jonas\n\u003e\u003e\n\u003e\u003e [1]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html\n\u003e\u003e\n\u003e\u003e \u003e Am 02.04.2019 um 22:43 schrieb James O'Beirne via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e:\n\u003e\u003e \u003e\n\u003e\u003e \u003e Hi,\n\u003e\u003e \u003e\n\u003e\u003e \u003e I'd like to discuss assumeutxo, which is an appealing and simple\n\u003e\u003e \u003e optimization in the spirit of assumevalid[0].\n\u003e\u003e \u003e\n\u003e\u003e \u003e # Motivation\n\u003e\u003e \u003e\n\u003e\u003e \u003e To start a fully validating bitcoin client from scratch, that client\n\u003e\u003e currently\n\u003e\u003e \u003e needs to perform an initial block download. To the surprise of no one,\n\u003e\u003e IBD\n\u003e\u003e \u003e takes a linear amount time based on the length of the chain's history.\n\u003e\u003e For\n\u003e\u003e \u003e clients running on modest hardware under limited bandwidth constraints,\n\u003e\u003e \u003e say a mobile device, completing IBD takes a considerable amount of time\n\u003e\u003e \u003e and thus poses serious usability challenges.\n\u003e\u003e \u003e\n\u003e\u003e \u003e As a result, having fully validating clients run on such hardware is\n\u003e\u003e rare and\n\u003e\u003e \u003e basically unrealistic. Clients with even moderate resource constraints\n\u003e\u003e \u003e are encouraged to rely on the SPV trust model. Though we have promising\n\u003e\u003e \u003e improvements to existing SPV modes pending deployment[1], it's worth\n\u003e\u003e \u003e thinking about a mechanism that would allow such clients to use trust\n\u003e\u003e \u003e models closer to full validation.\n\u003e\u003e \u003e\n\u003e\u003e \u003e The subject of this mail is a proposal for a complementary alternative\n\u003e\u003e to SPV\n\u003e\u003e \u003e modes, and which is in the spirit of an existing default,\n\u003e\u003e `assumevalid`. It may\n\u003e\u003e \u003e help modest clients transact under a security model that closely\n\u003e\u003e resembles\n\u003e\u003e \u003e full validation within minutes instead of hours or days.\n\u003e\u003e \u003e\n\u003e\u003e \u003e # assumeutxo\n\u003e\u003e \u003e\n\u003e\u003e \u003e The basic idea is to allow nodes to initialize using a serialized\n\u003e\u003e version of the\n\u003e\u003e \u003e UTXO set rendered by another node at some predetermined height. The\n\u003e\u003e \u003e initializing node syncs the headers chain from the network, then\n\u003e\u003e obtains and\n\u003e\u003e \u003e loads one of these UTXO snapshots (i.e. a serialized version of the\n\u003e\u003e UTXO set\n\u003e\u003e \u003e bundled with the block header indicating its \"base\" and some other\n\u003e\u003e metadata).\n\u003e\u003e \u003e\n\u003e\u003e \u003e Based upon the snapshot, the node is able to quickly reconstruct its\n\u003e\u003e chainstate,\n\u003e\u003e \u003e and compares a hash of the resulting UTXO set to a preordained hash\n\u003e\u003e hard-coded\n\u003e\u003e \u003e in the software a la assumevalid. This all takes ~23 minutes, not\n\u003e\u003e accounting for\n\u003e\u003e \u003e download of the 3.2GB snapshot[2].\n\u003e\u003e \u003e\n\u003e\u003e \u003e The node then syncs to the network tip and afterwards begins a\n\u003e\u003e simultaneous\n\u003e\u003e \u003e background validation (i.e., a conventional IBD) up to the base height\n\u003e\u003e of the\n\u003e\u003e \u003e snapshot in order to achieve full validation. Crucially, even while the\n\u003e\u003e \u003e background validation is happening the node can validate incoming\n\u003e\u003e blocks and\n\u003e\u003e \u003e transact with the benefit of the full (assumed-valid) UTXO set.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Snapshots could be obtained from multiple separate peers in the same\n\u003e\u003e manner as\n\u003e\u003e \u003e block download, but I haven't put much thought into this. In concept it\n\u003e\u003e doesn't\n\u003e\u003e \u003e matter too much where the snapshots come from since their validity is\n\u003e\u003e \u003e determined via content hash.\n\u003e\u003e \u003e\n\u003e\u003e \u003e # Security\n\u003e\u003e \u003e\n\u003e\u003e \u003e Obviously there are some security implications due consideration. While\n\u003e\u003e this\n\u003e\u003e \u003e proposal is in the spirit of assumevalid, practical attacks may become\n\u003e\u003e easier.\n\u003e\u003e \u003e Under assumevalid, a user can be tricked into transacting under a false\n\u003e\u003e history\n\u003e\u003e \u003e if an attacker convinces them to start bitcoind with a malicious\n\u003e\u003e `-assumevalid`\n\u003e\u003e \u003e parameter, sybils their node, and then feeds them a bogus chain\n\u003e\u003e encompassing\n\u003e\u003e \u003e all of the hard-coded checkpoints[3].\n\u003e\u003e \u003e\n\u003e\u003e \u003e The same attack is made easier in assumeutxo because, unlike in\n\u003e\u003e assumevalid,\n\u003e\u003e \u003e the attacker need not construct a valid PoW chain to get the victim's\n\u003e\u003e node into\n\u003e\u003e \u003e a false state; they simply need to get the user to accept a bad\n\u003e\u003e `-assumeutxo`\n\u003e\u003e \u003e parameter and then supply them an easily made UTXO snapshot containing,\n\u003e\u003e say, a\n\u003e\u003e \u003e false coin assignment.\n\u003e\u003e \u003e\n\u003e\u003e \u003e For this reason, I recommend that if we were to implement assumeutxo,\n\u003e\u003e we not\n\u003e\u003e \u003e allow its specification via commandline argument[4].\n\u003e\u003e \u003e\n\u003e\u003e \u003e Beyond this risk, I can't think of material differences in security\n\u003e\u003e relative to\n\u003e\u003e \u003e assumevalid, though I appeal to the list for help with this.\n\u003e\u003e \u003e\n\u003e\u003e \u003e # More fully validating clients\n\u003e\u003e \u003e\n\u003e\u003e \u003e A particularly exciting use-case for assumeutxo is the possibility of\n\u003e\u003e mobile\n\u003e\u003e \u003e devices functioning as fully validating nodes with access to the\n\u003e\u003e complete UTXO\n\u003e\u003e \u003e set (as an alternative to SPV models). The total resource burden needed\n\u003e\u003e to start a node\n\u003e\u003e \u003e from scratch based on a snapshot is, at time of writing, a ~(3.2GB\n\u003e\u003e \u003e + blocks_to_tip * 4MB) download and a few minutes of processing time,\n\u003e\u003e which sounds\n\u003e\u003e \u003e manageable for many mobile devices currently in use.\n\u003e\u003e \u003e\n\u003e\u003e \u003e A mobile user could initialize an assumed-valid bitcoin node within an\n\u003e\u003e hour,\n\u003e\u003e \u003e transact immediately, and complete a pruned full validation of their\n\u003e\u003e \u003e assumed-valid chain over the next few days, perhaps only doing the\n\u003e\u003e background\n\u003e\u003e \u003e IBD when their device has access to suitable high-bandwidth connections.\n\u003e\u003e \u003e\n\u003e\u003e \u003e If we end up implementing an accumulator-based UTXO scaling\n\u003e\u003e design[5][6] down\n\u003e\u003e \u003e the road, it's easy to imagine an analogous process that would allow\n\u003e\u003e very fast\n\u003e\u003e \u003e startup using an accumulator of a few kilobytes in lieu of a multi-GB\n\u003e\u003e snapshot.\n\u003e\u003e \u003e\n\u003e\u003e \u003e ---\n\u003e\u003e \u003e\n\u003e\u003e \u003e I've created a related issue at our Github repository here:\n\u003e\u003e \u003e   https://github.com/bitcoin/bitcoin/issues/15605\n\u003e\u003e \u003e\n\u003e\u003e \u003e and have submitted a draft implementation of snapshot usage via RPC\n\u003e\u003e here:\n\u003e\u003e \u003e   https://github.com/bitcoin/bitcoin/pull/15606\n\u003e\u003e \u003e\n\u003e\u003e \u003e I'd like to discuss here whether this is a good fit for Bitcoin\n\u003e\u003e conceptually. Concrete\n\u003e\u003e \u003e plans for deployment steps should be discussed in the Github issue, and\n\u003e\u003e after all\n\u003e\u003e \u003e that my implementation may be reviewed as a sketch of the specific\n\u003e\u003e software\n\u003e\u003e \u003e changes necessary.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Regards,\n\u003e\u003e \u003e James\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e [0]:\n\u003e\u003e https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks\n\u003e\u003e \u003e [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki\n\u003e\u003e \u003e [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116\n\u003e\u003e CPU @ 2.10GHz\n\u003e\u003e \u003e [3]:\n\u003e\u003e https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161\n\u003e\u003e \u003e [4]: Marco Falke is due credit for this point\n\u003e\u003e \u003e [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc\n\u003e\u003e \u003e [6]: Boneh, Bunz, Fisch on accumulators:\n\u003e\u003e https://eprint.iacr.org/2018/1188\n\u003e\u003e \u003e\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\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\u003e\n\n\n-- \nI like to provide some work at no charge to prove my value. Do you need a\ntechie?\nI own Litmocracy \u003chttp://www.litmocracy.com\u003e and Meme Racing\n\u003chttp://www.memeracing.net\u003e (in alpha).\nI'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com\u003e which\nnow accepts Bitcoin.\nI also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\"He ought to find it more profitable to play by the rules\" - Satoshi\nNakamoto\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/d942b813/attachment-0001.html\u003e"}