{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-11\n📝 Original message:On Dec 9, 2015 5:40 PM, \"Gavin Andresen\" \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e\n\u003e On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e I think it would be logical to do as part of a hardfork that moved\n\u003e\u003e commitments generally; e.g. a better position for merged mining (such\n\u003e\u003e a hardfork was suggested in 2010 as something that could be done if\n\u003e\u003e merged mining was used), room for commitments to additional block\n\u003e\u003e back-references for compact SPV proofs, and/or UTXO set commitments.\n\u003e\u003e Part of the reason to not do it now is that the requirements for the\n\u003e\u003e other things that would be there are not yet well defined. For these\n\u003e\u003e other applications, the additional overhead is actually fairly\n\u003e\u003e meaningful; unlike the fraud proofs.\n\u003e\n\u003e\n\u003e So just design ahead for those future uses. Make the merkle tree:\n\u003e\n\u003e\n\u003e              root_in_block_header\n\u003e                      /      \\\n\u003e   tx_data_root      other_root\n\u003e                                /       \\\n\u003e         segwitness_root     reserved_for_future_use_root\n\nThis is basically what I meant by\n\nstruct hashRootStruct\n{\nuint256 hashMerkleRoot;\nuint256 hashWitnessesRoot;\nuint256 hashextendedHeader;\n}\n\nbut my design doesn't calculate other_root as it appears in your tree (is\nnot necessary).\n\nSince stop requiring bip34 (height in coinbase) is also a hardfork (and a\ntrivial one) I suggested to move it at the same time. But thinking more\nabout it, since BIP34 also elegantly solves BIP30, I would keep the height\nin the coinbase (even if we move it to the extented header tree as well for\nconvenience).\nThat should be able to include future consensus-enforced commitments (extra\nback-refs for compact proofs, txo/utxo commitments, etc) or non-consensus\ndata (merged mining data, miner-published data).\nGreg Maxwell suggested to move those later and I answered fair enough. But\nthinking more about it, if the extra commitments field is extensible, we\ndon't need to move anything now, and therefore we don't need for those\ndesigns (extra back-refs for compact proofs, txo/utxo commitments, etc) to\nbe ready to deploy a hardfork segregated witness: you just need to make\nsure that your format is extensible via softfork in the future.\n\nI'm therefore back to the \"let's better deploy segregated witness as a\nhardfork\" position.\nThe change required to the softfork segregated witnesses implementation\nwould be relatively small.\n\nAnother option would be to deploy both parts (sw and the movement from the\ncoinbase to the extra header) at the same time but with different\nactivation conditions, for example:\n\n- For sw: deploy as soon as possible with bip9.\n- For the hardfork codebase to extra header movement: 1 year grace + bip9\nfor later miner upgrade confirmation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151211/2a7a0a4a/attachment.html\u003e"}