{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-09\n📝 Original message:On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\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\nSo just design ahead for those future uses. Make the merkle tree:\n\n\n             root_in_block_header\n                     /      \\\n  tx_data_root      other_root\n                               /       \\\n        segwitness_root     reserved_for_future_use_root\n\n... where reserved_for_future_use is zero until some future block version\n(or perhaps better, is just chosen arbitrarily by the miner and sent along\nwith the block data until some future block version).\n\nThat would minimize future disruption of any code that produced or consumed\nmerkle proofs of the transaction data or segwitness data, especially if the\nreserved_for_future_use_root is allowed to be any arbitrary 256-bit value\nand not a constant that would get hard-coded into segwitness-proof-checking\ncode.\n\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/89ff9b06/attachment.html\u003e"}