rich1.0npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uhttps://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0unjumphttps://nostr.ae📅 Original date posted:2015-12-09 📝 Original message:My apologies for the apparent miscommunication earlier. It is of interest to me that the soft-fork be done which is necessary to put a commitment in the most efficient spot possible, in part because that commitment could be used for other data such as the merged mining auxiliary blocks, which are very sensitive to proof size. Perhaps we have a different view of how the commitment transaction would be generated. Just as GBT doesn't create the coinbase, it was my expectation that it wouldn't generate the commitment transaction either -- but generation of the commitment would be easy, requiring either the coinbase txid 100 blocks back, or the commitment txid of the prior transaction (note this impacts SPV mining). The truncation shouldn't be an issue because the commitment txn would not be part of the list of transactions selected by GBT, and in any case the truncation would change the witness data which changes the commitment. On Wed, Dec 9, 2015 at 4:03 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/0736595c/attachment.html>