<oembed><type>rich</type><version>1.0</version><author_name>npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_name><author_url>https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-12-20&#xA;📝 Original message:On Sun, Dec 13, 2015 at 02:07:36AM +0000, Gregory Maxwell via bitcoin-dev wrote:&#xA;&gt; On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev&#xA;&gt; &lt;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt; &gt; have run a node/kept their utxo before they were aware of this change and&#xA;&gt; &gt; then realise miners have discarded their utxo. Oops?&#xA;&gt; &#xA;&gt; I believe you have misunderstood jl2012&#39;s post.  His post does not&#xA;&gt; cause the outputs to become discarded. They are still spendable,&#xA;&gt; but the transactions must carry a membership proof to spend them.&#xA;&gt; They don&#39;t have to have stored the data themselves, but they must&#xA;&gt; get it from somewhere-- including archive nodes that serve this&#xA;&gt; purpose rather than having every full node carry all that data forever.&#xA;&gt; &#xA;&gt; Please be conservative with the send button. The list loses its&#xA;&gt; utility if every moderately complex idea is hit with reflexive&#xA;&gt; opposition by people who don&#39;t understand it.&#xA;&gt; &#xA;&gt; Peter Todd has proposed something fairly similar with &#34;STXO&#xA;&gt; commitments&#34;. The primary argument against this kind of approach that&#xA;&#xA;That&#39;s incorrect terminology - what I proposed are &#34;TXO commitments&#34;. I&#xA;proposed that a MMR of all prior transaction outputs&#39;s, spent and&#xA;unspent, be committed too in blocks along with a spentness flag, not&#xA;just spent transaction outputs.&#xA;&#xA;That&#39;s why I often use the term (U)TXO commitments to refer to both&#xA;classes of proposals.&#xA;&#xA;&gt; I&#39;m aware of is that the membership proofs get pretty big, and if too&#xA;&gt; aggressive this trades bandwidth for storage, and storage is usually&#xA;&gt; the cheaper resource. Though at least the membership proofs could be&#xA;&gt; omitted when transmitting to a node which has signaled that it has&#xA;&gt; kept the historical data anyways.&#xA;&#xA;What I proprosed is that a consensus-critical maximum UTXO age be part&#xA;of the protocol; UTXO&#39;s younger than that age are expected to be cached.&#xA;For UTXO&#39;s older than that age, they can be dropped from the cache,&#xA;however to spend them you are required to provide the proof, and that&#xA;proof counts as blockchain space to account for the fact that they do&#xA;need to be broadcast on the network.&#xA;&#xA;The proofs are relatively large, but not so much larger than a CTxIn as&#xA;to make paying for that data infeasible.&#xA;&#xA;-- &#xA;&#39;peter&#39;[:-1]@petertodd.org&#xA;00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d&#xA;-------------- next part --------------&#xA;A non-text attachment was scrubbed...&#xA;Name: signature.asc&#xA;Type: application/pgp-signature&#xA;Size: 650 bytes&#xA;Desc: Digital signature&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/ee109d4b/attachment.sig&gt;</html></oembed>