rich1.0npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8njumphttps://nostr.ae📅 Original date posted:2015-12-09 📝 Original message:Fair enough. On Dec 9, 2015 4:03 PM, "Gregory Maxwell" <greg at xiph.org> wrote: > On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón <jtimon at jtimon.cc> wrote: > > From this question one could think that when you said "we can do the > > cleanup hardfork later" earlier you didn't really meant it. And that > > you will oppose to that hardfork later just like you are opposing to > > it now. > > As said I disagree that making a softfork first and then move the > > commitment is less disruptive (because people will need to adapt their > > software twice), but if the intention is to never do the second part > > then of course I agree it would be less disruptive. > > How long after the softfork would you like to do the hardfork? > > 1 year after the softfork? 2 years? never? > > I think it would be logical to do as part of a hardfork that moved > commitments generally; e.g. a better position for merged mining (such > a hardfork was suggested in 2010 as something that could be done if > merged mining was used), room for commitments to additional block > back-references for compact SPV proofs, and/or UTXO set commitments. > Part of the reason to not do it now is that the requirements for the > other things that would be there are not yet well defined. For these > other applications, the additional overhead is actually fairly > meaningful; unlike the fraud proofs. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/0845be33/attachment.html>