{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-13\n📝 Original message:On Sun, Dec 13, 2015 at 9:17 AM, Chris Priest \u003ccp368202 at ohiou.edu\u003e wrote:\n\u003e\u003e In none of these cases do you lose anything.\n\u003e\n\u003e Nor do you gain anything. Archive nodes will still need to exist\n\nNot every node is an archive node; that's even the case today.\nLowering the resource requirements to independently enforce the rules\nof the system is highly virtuous.\n\n\u003e precisely because paper wallets don't include UTXO data. This is like\n\u003e adding the ability to partially seed a movie with bittorrent.\n[...]\n\u003e Every paper wallet would have to be re-printed with UTXO data\n\nThey are not printed now with UTXO data\n(txid:vout:scriptpubkey:amount), and unless you start and fully\nsynchronize (or are running a full node) you already cannot author a\ntransaction without that data. The private key is already not enough,\nand no Bitcoin node will just give you what you need to know.\n\nThe only additional information JL2012's scheme would add would be the\nhash tree fragments to show membership; and the same places that\ncurrently give you what is required to author a transaction could\nprovide it for you.\n\n\u003e included. It doesn't even solve the core problem because someone can\n\u003e still flood the network with lots of UTXOs, as long as they spend them\n\u003e quickly.\n\nThe system already inhibits the rate new UTXO can be added; but we're\nstill left with the perpetually growing history that contains many\nlost and otherwise unspendable outputs."}