<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 1:00 AM, Vincent Truong via bitcoin-dev&#xA;&lt;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt; have run a node/kept their utxo before they were aware of this change and&#xA;&gt; then realise miners have discarded their utxo. Oops?&#xA;&#xA;I believe you have misunderstood jl2012&#39;s post.  His post does not&#xA;cause the outputs to become discarded. They are still spendable,&#xA;but the transactions must carry a membership proof to spend them.&#xA;They don&#39;t have to have stored the data themselves, but they must&#xA;get it from somewhere-- including archive nodes that serve this&#xA;purpose rather than having every full node carry all that data forever.&#xA;&#xA;Please be conservative with the send button. The list loses its&#xA;utility if every moderately complex idea is hit with reflexive&#xA;opposition by people who don&#39;t understand it.&#xA;&#xA;Peter Todd has proposed something fairly similar with &#34;STXO&#xA;commitments&#34;. The primary argument against this kind of approach that&#xA;I&#39;m aware of is that the membership proofs get pretty big, and if too&#xA;aggressive this trades bandwidth for storage, and storage is usually&#xA;the cheaper resource. Though at least the membership proofs could be&#xA;omitted when transmitting to a node which has signaled that it has&#xA;kept the historical data anyways.</html></oembed>