{"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-08\n📝 Original message:On Dec 9, 2015 7:41 AM, \"Jonathan Toomim via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I also think that a hard fork is better for SegWit, as it reduces the\nsize of fraud proofs considerably, makes the whole design more elegant and\nless kludgey, and is safer for clients who do not upgrade in a timely\nfashion.\n\nI agree, although I disagree with the last reason.\n\n\u003e I don't like the idea that SegWit would invalidate the security\nassumptions of non-upgraded clients (including SPV wallets). I think that\nfor these clients, no data is better than invalid data. Better to force\nthem to upgrade by cutting them off the network than to let them think\nthey're validating transactions when they're not.\n\nI don't undesrtand. SPV nodes won't think they are validating transactions\nwith the new version unless they adapt to the new format. They will be\nsimply unable to receive payments using the new format if it is a softfork\n(although as said I agree with making it a hardfork on the simpler design\nand smaller fraud proofs grounds alone).\n\n\u003e\n\u003e On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e \u003e If such a change is going to be deployed via a soft fork instead of a\n\u003e \u003e hard fork, then the coinbase is the worst place to put the segwitness\n\u003e \u003e merkle root.\n\u003e \u003e\n\u003e \u003e Instead, put it in the first output of the generation transaction as an\n\u003e \u003e OP_RETURN script.\n\u003e \u003e\n\u003e \u003e This is a better pattern because coinbase space is limited while output\n\u003e \u003e space is not. The next time there's a good reason to tie another merkle\n\u003e \u003e tree to a block, that proposal can be designated for the second output\n\u003e \u003e of the generation transaction.\n\u003e\n\u003e\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/2af9dc6d/attachment.html\u003e"}