📅 Original date posted:2017-04-14
📝 Original message:Chris,
>Food for thought, why are we rejecting *all* blocks that do not signal segwit? Can't we just reject blocks that *do not* signal segwit, but *do* contain segwit transactions? It seems silly to me that if a miner mines a block with all pre segwit txs to reject that block. Am I missing something here?
If you read my email, you will see that I am requesting that gmaxwell or someone code up an alternative that doesn't unnecessarily orphan blocks, just as you are requesting.
> Re: old blocks containing SegWit transactions
From my understanding, old blocks can contain txos w/ the new SegWit format. But if transaction tries to spend a new SegWit format txo in an old block, such would already break protocol rules, particularly for SegWit activated nodes. And old nodes don't have code that even knows how to spend SegWit format txos. Worst case, such may lead to a fork if <= 50% of the miners are verifying SegWit blocks.
> Re: Reckless hand waving:
Maybe first you need to prove that forks are necessarily bad for our long term success. How much do we need to be getting delayed in rolling out new good policy before we come to consensus on forking from the delayers?
The operating assumption of 148 is that no matter what we are going to fork. So might as well do it then in a controlled manner instead of later when someone creates an invalid SegWit block. Then my only recommendation would be to also implement a boilerplate replay attack prevention just in case the SegWit delayers aren't bluffing.
Cheers,
Praxeology Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/9c02fbf0/attachment.html>;
praxeology_guy [ARCHIVE] /
npub1hz…7nzv7
2023-06-07 18:00:04
in reply to nevent1q…vrls
Author Public Key
npub1hzkv59ax7ax80nv2fzvcgmveqyk3k5sg9gq695n48l9scenf5c9sa7nzv7Published at
2023-06-07 18:00:04Event JSON
{
"id": "a3e59b223b908c6d7e33a45bb33c84f727f2b8d93326d1b95e69adba4e28b6d5",
"pubkey": "b8acca17a6f74c77cd8a4899846d99012d1b52082a01a2d2753fcb0c6669a60b",
"created_at": 1686160804,
"kind": 1,
"tags": [
[
"e",
"5d1e64c970da07b0178aa4b0869114a6c0b54023e99bc79f83d180601afc646b",
"",
"root"
],
[
"e",
"9d1fdc93005cbf09156dd9726f4f15324c30646b17a6743afeec4dca3f0e793f",
"",
"reply"
],
[
"p",
"e3e3813ca5b2f45117ae42a2a1c99f5c6bd172c115acc2538066aad916544817"
]
],
"content": "📅 Original date posted:2017-04-14\n📝 Original message:Chris,\n\n\u003eFood for thought, why are we rejecting *all* blocks that do not signal segwit? Can't we just reject blocks that *do not* signal segwit, but *do* contain segwit transactions? It seems silly to me that if a miner mines a block with all pre segwit txs to reject that block. Am I missing something here?\n\nIf you read my email, you will see that I am requesting that gmaxwell or someone code up an alternative that doesn't unnecessarily orphan blocks, just as you are requesting.\n\n\u003e Re: old blocks containing SegWit transactions\nFrom my understanding, old blocks can contain txos w/ the new SegWit format. But if transaction tries to spend a new SegWit format txo in an old block, such would already break protocol rules, particularly for SegWit activated nodes. And old nodes don't have code that even knows how to spend SegWit format txos. Worst case, such may lead to a fork if \u003c= 50% of the miners are verifying SegWit blocks.\n\n\u003e Re: Reckless hand waving:\nMaybe first you need to prove that forks are necessarily bad for our long term success. How much do we need to be getting delayed in rolling out new good policy before we come to consensus on forking from the delayers?\n\nThe operating assumption of 148 is that no matter what we are going to fork. So might as well do it then in a controlled manner instead of later when someone creates an invalid SegWit block. Then my only recommendation would be to also implement a boilerplate replay attack prevention just in case the SegWit delayers aren't bluffing.\n\nCheers,\nPraxeology Guy\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/9c02fbf0/attachment.html\u003e",
"sig": "2202aa2a40e9bb942e92bbdd5eae63a85a329c60ff82509d989136e55c4d1bc9aeb0a467fab0a95848c06f47b8d2e1b91c8510c6270a2a672ae43759d50ff1db"
}