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