{"type":"rich","version":"1.0","author_name":"npub1g97v5rt5sguagjk0cetckrhhmr3hded8u4vwe5keqphe7ye9tgfsv323pl","author_url":"https://nostr.ae/npub1g97v5rt5sguagjk0cetckrhhmr3hded8u4vwe5keqphe7ye9tgfsv323pl","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-07\n📝 Original message:On Monday, October 5, 2015, Mike Hearn via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e As Greg explained to you repeatedly, a softfork won't cause a\n\u003e\u003e non-upgraded full node to start accepting blocks that create more\n\u003e\u003e subsidy than is valid.\n\u003e\u003e\n\u003e\n\u003e It was an example. Adam Back's extension blocks proposal would, in fact,\n\u003e allow for a soft forking change that creates more subsidy than is valid (or\n\u003e does anything else) by hiding one block inside another.\n\u003e\n\nMaybe I'm missing something, but wouldn't this turn into a hard fork the\nmoment you try to spend an output created in one of these extension blocks?\nSo sure, the block that contains the extension would be considered valid,\nbut unupgraded validators will not update the UTXO set accordingly, meaning\nthat those new TXOs can't be spent because, according to their rules, they\ndon't exist.\n\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151007/a86d8d32/attachment-0001.html\u003e"}