{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-09\n📝 Original message:On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e From this question one could think that when you said \"we can do the\n\u003e cleanup hardfork later\" earlier you didn't really meant it. And that\n\u003e you will oppose to that hardfork later just like you are opposing to\n\u003e it now.\n\u003e As said I disagree that making a softfork first and then move the\n\u003e commitment is less disruptive (because people will need to adapt their\n\u003e software twice), but if the intention is to never do the second part\n\u003e then of course I agree it would be less disruptive.\n\u003e How long after the softfork would you like to do the hardfork?\n\u003e 1 year after the softfork? 2 years? never?\n\nI think it would be logical to do as part of a hardfork that moved\ncommitments generally; e.g. a better position for merged mining (such\na hardfork was suggested in 2010 as something that could be done if\nmerged mining was used), room for commitments to additional block\nback-references for compact SPV proofs, and/or UTXO set commitments.\nPart of the reason to not do it now is that the requirements for the\nother things that would be there are not yet well defined. For these\nother applications, the additional overhead is actually fairly\nmeaningful; unlike the fraud proofs."}