<oembed><type>rich</type><version>1.0</version><author_name>npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd</author_name><author_url>https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd</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 6:11 PM, jl2012--- via bitcoin-dev &lt;&#xA;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&#xA;&gt; Back to the topic, I would like to further elaborate my proposal.&#xA;&gt;&#xA;&gt; We have 3 types of full nodes:&#xA;&gt;&#xA;&gt; Archive nodes: full nodes that store the whole blockchain&#xA;&gt; Full UTXO nodes: full nodes that fully store the latest UTXO state, but&#xA;&gt; not the raw blockchain&#xA;&gt; Lite UTXO nodes: full nodes that store only UTXO created in that past&#xA;&gt; 420000 blocks&#xA;&gt;&#xA;&#xA;There is a risk that miners would eventually react by just refusing to&#xA;accept blocks that spend dormant outputs.  This is a risk even without the&#xA;protocol, but I think if there are already lots of UTXO-lite nodes&#xA;deployed, it would be much easier to just define them as the new&#xA;(soft-forked) consensus rule.&#xA;&#xA;There is a precedent for things to be disabled rather than fixed when&#xA;security problems arise.&#xA;&#xA;Imagine a crisis caused by a security related bug with the revival proofs.&#xA;Disabling them is much lower risk than trying to find/fix the bug and then&#xA;deploy the fix.  The longer it takes, the longer the security problem&#xA;remains.&#xA;&#xA;&#xA;&gt;&#xA;&gt; What extra information is needed?&#xA;&gt;&#xA;&gt; (1) If your UTXO was generated in block Y, you first need to know the TXO&#xA;&gt; state (spent / unspent) of all outputs in block Y at block (Y + 420000).&#xA;&gt; Only UTXOs at that time are relevant.&#xA;&gt;&#xA;&gt; (2) You also need to know if there was any spending of any block Y UTXOs&#xA;&gt; after block (Y + 420000).&#xA;&gt;&#xA;&#xA;Is this how it works?&#xA;&#xA;Source transaction is included in block Y.&#xA;&#xA;If the output is spent before Y + 420,000, then no further action is taken.&#xA;&#xA;The miner for block Y + 420,000 will include a commitment to&#xA;merkle_hash(Block Y&#39;s unspent outputs).&#xA;&#xA;It is possible for someone to prove that they didn&#39;t spend their&#xA;transaction before Y + 420,000.&#xA;&#xA;I think the miners have to remember the &#34;live&#34; UTXO merkle root for every&#xA;block?&#xA;&#xA;With the path to the UTXO and the miner can recalculate the root for that&#xA;block.&#xA;&#xA;If there were 20 dormant outputs being spent, then the miner would have to&#xA;commit to 20 updates.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151213/a4cf6d21/attachment.html&gt;</html></oembed>