{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-18\n📝 Original message:I believe the discussion here is on improving initial-sync time by\nsimply skipping initial-sync and getting a committed-to utxo set. This\nis obviously a new security model in between SPV and full-node (I would\ncall it SPV with future validation). Still, I'm not convinced it buys us\nanything, we really should just tweak Bitcoin Core to do spv mode at\nstartup and validate backwards in the background. I think this would\nalleviate most of the concerns raised, given the chain growth is not\nentirely unreasonable going forward.\n\nOn 09/18/15 20:07, Alex Morcos via bitcoin-dev wrote:\n\u003e I guess I always assumed that UTXO set commitments were an alternative\n\u003e security model (between SPV and full-node), not that they would cause\n\u003e the existing security model to be deprecated.\n\u003e \n\u003e \n\u003e On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e     Full nodes using UTXO set commitments is a change to the bitcoin\n\u003e     security model.\n\u003e \n\u003e     Currently an attacker with \u003e50% of the network hashrate can rewrite\n\u003e     history.\n\u003e \n\u003e     If full nodes rely on UTXO set commitments such an attacker could create\n\u003e     an infinite number of bitcoins (as in many times more than the current\n\u003e     21 million bitcoin limit).\n\u003e \n\u003e     Before we consider mechanisms for UTXO set commitments, we should\n\u003e     seriously discuss whether the security model reduction is reasonable.\n\u003e \n\u003e     On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:\n\u003e     \u003e Currently, when a new node wants to join the network, it needs to\n\u003e     retrieve the entire blockchain history, starting from January 2009\n\u003e     and up until now, in order to derive a UTXO set that it can verify\n\u003e     new blocks/transactions against. With a blockchain size of 40GB and\n\u003e     a UTXO size of around 1GB, the extra bandwidth required is\n\u003e     significant, and will keep increasing indefinitely. If a newly mined\n\u003e     block were to include the UTXO set hash of the chain up until the\n\u003e     previous block — the hash of the UTXO set on top of which this block\n\u003e     builds — then new nodes, who want to know whether a transaction is\n\u003e     valid, would be able to acquire the UTXO set in a trustless manner,\n\u003e     by only verifying proof-of-work headers, and knowing that a block\n\u003e     with an invalid UTXO set hash would be rejected.\n\u003e     \u003e\n\u003e     \u003e I’m not talking about calculating a complicated tree structure\n\u003e     from the UTXO set, which would put further burden on already\n\u003e     burdened Bitcoin Core nodes. We simply include the hash of the\n\u003e     current UTXO set in a newly created block, such that the\n\u003e     transactions in the new block build *on top* of the UTXO set whose\n\u003e     hash is specified. This actually alleviates Bitcoin Core nodes, as\n\u003e     it will now become possible for nodes without the entire blockchain\n\u003e     to answer SPV queries (by retrieving the UTXO set trustlessly and\n\u003e     using this to answer queries). It also saves bandwidth for Bitcore\n\u003e     Core nodes, who only need to send roughly 1GB of data, in order to\n\u003e     synchronise a node, rather than 40GB+. I will continue to run a full\n\u003e     Bitcoin Core node, saving the entire blockchain history, but it\n\u003e     shouldn’t be a requirement to hold the entire transaction history in\n\u003e     order to start verifying new transactions.\n\u003e     \u003e\n\u003e     \u003e As far as I can see, this also forces miners to actually maintain\n\u003e     an UTXO set, rather than just build on top of the chain with the\n\u003e     most proof-of-work. Producing a UTXO set and verifying a block\n\u003e     against a chain is the same thing, so by including the hash of the\n\u003e     UTXO set we force miners to verify the block that they want to build\n\u003e     on top of.\n\u003e     \u003e\n\u003e     \u003e Am I missing something obvious, because as far as I can see, this\n\u003e     solves the problem of quadratic time complexity for initial sync:\n\u003e     http://www.youtube.com/watch?v=TgjrS-BPWDQ\u0026t=2h02m12s\n\u003e     \u003e\n\u003e     \u003e The only added step to verifying a block is to hash the UTXO set.\n\u003e     So it does require additional computation, but most modern CPUs have\n\u003e     a SHA256 throughput of around 500 MB/s, which means it takes only\n\u003e     two seconds to hash the UTXO set. And this can be improved further\n\u003e     (GPUs can do 2-3 GB/s). A small sacrifice for the added ease of\n\u003e     initial syncing, in my opinion.\n\u003e     \u003e\n\u003e     \u003e /Rune\n\u003e     \u003e _______________________________________________\n\u003e     \u003e bitcoin-dev mailing list\n\u003e     \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e     \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e     _______________________________________________\n\u003e     bitcoin-dev mailing list\n\u003e     bitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \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\u003e"}