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