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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
