<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-09&#xA;📝 Original message:On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón &lt;jtimon at jtimon.cc&gt; wrote:&#xA;&gt; From this question one could think that when you said &#34;we can do the&#xA;&gt; cleanup hardfork later&#34; earlier you didn&#39;t really meant it. And that&#xA;&gt; you will oppose to that hardfork later just like you are opposing to&#xA;&gt; it now.&#xA;&gt; As said I disagree that making a softfork first and then move the&#xA;&gt; commitment is less disruptive (because people will need to adapt their&#xA;&gt; software twice), but if the intention is to never do the second part&#xA;&gt; then of course I agree it would be less disruptive.&#xA;&gt; How long after the softfork would you like to do the hardfork?&#xA;&gt; 1 year after the softfork? 2 years? never?&#xA;&#xA;I think it would be logical to do as part of a hardfork that moved&#xA;commitments generally; e.g. a better position for merged mining (such&#xA;a hardfork was suggested in 2010 as something that could be done if&#xA;merged mining was used), room for commitments to additional block&#xA;back-references for compact SPV proofs, and/or UTXO set commitments.&#xA;Part of the reason to not do it now is that the requirements for the&#xA;other things that would be there are not yet well defined. For these&#xA;other applications, the additional overhead is actually fairly&#xA;meaningful; unlike the fraud proofs.</html></oembed>