{"type":"rich","version":"1.0","author_name":"npub14fwd2yh320mh4ge46ute8ukdyx2kjxy2ak4a05prjwrtzlmh9rvq8hksaj","author_url":"https://nostr.ae/npub14fwd2yh320mh4ge46ute8ukdyx2kjxy2ak4a05prjwrtzlmh9rvq8hksaj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-13\n📝 Original message:I really like ideas that tackle this issue. The question imho is what is\nthe incentive to run a \"Full UTXO node\" instead of a pruned or archive node.\nFor starters, it would be nice to know what would be the savings for Full\nUTXO nodes over archive nodes right now.\nAlso, what advantages would this have over \"archive pruned nodes: nodes\nthat store X blocks of the whole blockchain before 420000\". Seems like an\ninteresting intermediate use case to me too.\n\n2015-12-13 18:11 GMT+00:00 jl2012--- via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA256\n\u003e\n\u003e On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe \u003cdanny.thorpe at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e What is the current behavior / cost that this proposal is trying to\n\u003e\u003e avoid? Are ancient utxos required to be kept in memory always in a fully\n\u003e\u003e validating node, or can ancient utxos get pushed out of memory like a\n\u003e\u003e normal LRU caching db?\n\u003e\u003e\n\u003e\n\u003e I don't see why it must be kept in memory. But storage is still a problem.\n\u003e With the 8 year limit and a fixed max block size, it indirectly sets an\n\u003e upper limit for UTXO set.\n\u003e\n\u003e\n\u003e Chris Priest via bitcoin-dev :\n\u003e\n\u003e\u003e This isn't going to kill bitcoin, but it won't make it any better.\n\u003e\u003e\n\u003e\n\u003e Do you believe that thousands of volunteer full nodes are obliged to store\n\u003e an UTXO record, just because one paid US$0.01 to an anonymous miner 100\n\u003e years ago? It sounds insanely cheap, isn't it? My proposal (or similar\n\u003e proposal by Peter Todd) is to solve this problem. Many commercial banks\n\u003e have a dormant threshold less than 8 years so I believe it is a balanced\n\u003e choice.\n\u003e\n\u003e Back to the topic, I would like to further elaborate my proposal.\n\u003e\n\u003e We have 3 types of full nodes:\n\u003e\n\u003e Archive nodes: full nodes that store the whole blockchain\n\u003e Full UTXO nodes: full nodes that fully store the latest UTXO state, but\n\u003e not the raw blockchain\n\u003e Lite UTXO nodes: full nodes that store only UTXO created in that past\n\u003e 420000 blocks\n\u003e\n\u003e Currently, if one holds nothing but a private key, he must consult either\n\u003e an archive node or a full UTXO node for the latest UTXO state to spend his\n\u003e coin. We currently do not have any lite UTXO node, and such node would not\n\u003e work properly beyond block 420000.\n\u003e\n\u003e With the softfork I described in my original post, if the UTXO is created\n\u003e within the last 420000 blocks, the key holder may consult any type of full\n\u003e node, including a lite UTXO node, to create the transaction.\n\u003e\n\u003e If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO\n\u003e node obviously can't provide the necessary information to spend the coin.\n\u003e However, not even a full UTXO node may do so. A full UTXO node could tell\n\u003e the position of the UTXO in the blockchain, but can't provide all the\n\u003e information required by my specification. Only an archive node may do so.\n\u003e\n\u003e What extra information is needed?\n\u003e\n\u003e (1) If your UTXO was generated in block Y, you first need to know the TXO\n\u003e state (spent / unspent) of all outputs in block Y at block (Y + 420000).\n\u003e Only UTXOs at that time are relevant.\n\u003e\n\u003e (2) You also need to know if there was any spending of any block Y UTXOs\n\u003e after block (Y + 420000).\n\u003e\n\u003e It is not possible to construct the membership prove I require without\n\u003e these information. It is designed this way, so that lite UTXO nodes won't\n\u003e need to store any dormant UTXO records: not even the hash of individual\n\u003e dormant UTXO records. If the blockchain grows to insanely big, it may take\n\u003e days or weeks to retrieve to records. However, I don't think this is\n\u003e relevant as one has already left his coins dormant for \u003e8 years. Actually,\n\u003e you don't even need the full blockchain. For (1), all you need is the\n\u003e 420000 blocks from Y to Y+420000 minus any witness data, as you don't need\n\u003e to do any validation. For (2), you just need the coinbase of Y+420001 to\n\u003e present, where any spending would have been committed, and retrieve the\n\u003e full block only if a spending is found.\n\u003e\n\u003e So the Bitcoin Bank (miners) is not going to shred your record and\n\u003e confiscate your money. Instead, the Bank throws your record to the garage\n\u003e (raw blockchain). You can search for your record by yourself, or employ\n\u003e someone (archive node) to search it for you. In any case it incurs costs.\n\u003e But as thousands of bankers have kept your record on their limited desk\n\u003e space for 8 years for free (though one of them might receive a fraction of\n\u003e a penny from you), you shouldn't complain with any moral, technical, or\n\u003e legal reason. And no matter what users say, I believe something like this\n\u003e will happen when miners and full nodes can't handle the UTXO set.\n\u003e\n\u003e I'd like to see more efficient proposals that archive the same goals.\n\u003e\n\u003e p.s. there were some typos in my original. The second sentence of the\n\u003e second paragraph should be read as \"For every block X+420000, it will\n\u003e commit to a hash for all UTXOs generated in block X.\"\n\u003e -----BEGIN PGP SIGNATURE-----\n\u003e Version: GnuPG v2\n\u003e\n\u003e iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV\n\u003e Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3\n\u003e DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9\n\u003e Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A\n\u003e PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8\n\u003e lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS\n\u003e VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93\n\u003e zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V\n\u003e EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ==\n\u003e =2xRy\n\u003e -----END PGP SIGNATURE-----\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151213/67eaba28/attachment.html\u003e"}