{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-09\n📝 Original message:My apologies for the apparent miscommunication earlier. It is of interest\nto me that the soft-fork be done which is necessary to put a commitment in\nthe most efficient spot possible, in part because that commitment could be\nused for other data such as the merged mining auxiliary blocks, which are\nvery sensitive to proof size.\n\nPerhaps we have a different view of how the commitment transaction would be\ngenerated. Just as GBT doesn't create the coinbase, it was my expectation\nthat it wouldn't generate the commitment transaction either -- but\ngeneration of the commitment would be easy, requiring either the coinbase\ntxid 100 blocks back, or the commitment txid of the prior transaction (note\nthis impacts SPV mining). The truncation shouldn't be an issue because the\ncommitment txn would not be part of the list of transactions selected by\nGBT, and in any case the truncation would change the witness data which\nchanges the commitment.\n\nOn Wed, Dec 9, 2015 at 4:03 PM, Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e \u003e From this question one could think that when you said \"we can do the\n\u003e \u003e cleanup hardfork later\" earlier you didn't really meant it. And that\n\u003e \u003e you will oppose to that hardfork later just like you are opposing to\n\u003e \u003e it now.\n\u003e \u003e As said I disagree that making a softfork first and then move the\n\u003e \u003e commitment is less disruptive (because people will need to adapt their\n\u003e \u003e software twice), but if the intention is to never do the second part\n\u003e \u003e then of course I agree it would be less disruptive.\n\u003e \u003e How long after the softfork would you like to do the hardfork?\n\u003e \u003e 1 year after the softfork? 2 years? never?\n\u003e\n\u003e I think it would be logical to do as part of a hardfork that moved\n\u003e commitments generally; e.g. a better position for merged mining (such\n\u003e a hardfork was suggested in 2010 as something that could be done if\n\u003e merged mining was used), room for commitments to additional block\n\u003e back-references for compact SPV proofs, and/or UTXO set commitments.\n\u003e Part of the reason to not do it now is that the requirements for the\n\u003e other things that would be there are not yet well defined. For these\n\u003e other applications, the additional overhead is actually fairly\n\u003e meaningful; unlike the fraud proofs.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/0736595c/attachment.html\u003e"}