That’s not a “theory”. It is a disturbingly pernicious and persistent urban legend about Segwit, predicated on a common misconception about the role of miners. Miners have one, only one, and exactly one job: To provide the ordering of transactions in a Byzantine fault-tolerant manner (which in turn prevents double-spends). That’s what miners do. That is all miners do. Granted, it is an important and resource-intensive job; that’s why miners get paid for it. But that is the one and only security function of miners.
Of course, miners must validate each block they produce; if they didn’t, they would be unable to reliably produce valid blocks. But miners are not the parties responsible for enforcing validation on the network. Full nodes do that. Each individual full node does that, so as to provide better security for its owner; and all full nodes collectively do that, thus providing validation security for the whole network. Observe how here as everywhere, Bitcoin precisely aligns the individual’s selfish interest with the common good.
Full nodes do not blindly “follow the longest chain”. They follow the chain independently validated by them which has the highest total POW. A miner (or 51+% of miners) who produced invalid blocks would only be wasting hashrate, and likely risking widespread blacklisting of IP addresses. It doesn’t matter if the invalid blocks steal money from Segwit transactions, steal money from old-style transactions, create 21 billion new coins, or are filled with gibberish from /dev/random. An invalid block is an invalid block, and shall be promptly discarded by all full nodes—period.
That begs the question: It can’t actually happen. Segwit transactions require signatures, just like old-style transactions. Segwit transactions have security greater than or equal to old-style transactions in each and every characteristic. If a miner could somehow steal Segwit funds with a 51% attack, then the same attack could be used against all bitcoins, including Satoshi’s coins. But such an attack is impossible; the whole idea is ridiculous, just nonsense peddled by Btrash supporters so that
can smear the Segwit upgrade. And why do they hate Segwit? Because the Segwit upgrade stops
from covertly exploiting a security vulnerability which gives an unfair advantage of up to 30% in the energy costs of mining. Of course, they will hate Segwit; and their cronies and shills lie about Segwit. Give them no credence.
DannyHamilton is correct on all points here. I just have a few things to add or expand upon.
I always wonder why nobody stops to notice that the same “attack” based on the “anyone-can-spend” notion could be used against all P2SH transactions. Oh no, Btrash is also vulnerable!
WRONG.
WRONG.
I am sometimes amazed at the confident airs put on people who make authoritative-sounding declarations of totally incorrect information.
Here is good topic about it - https://bitcointalksearch.org/topic/segwit-and-spv-mining-what-if-1434842
Interesting link. Did you read past the OP? Try the second post, to which I just awarded merit:
1. Some unhonest segwit mining pool takes top-1000 segwit utxo and mines a block at height N with a transaction which transfers all funds to his p2pkh address
2. This block does not have segwit data portion, but it can be broadcasted to all non-segwit nodes on the network
3. All other pools have a dilema - wait the segwit data associated with this block or start mining block N+1 on the top of N
4. What if miners will use SPV-mining on the top of this block? They will create blocks at heights N+1, N+2... etc without checking the segwit-validity of block N
No different than the situation today with "spend all the coins in the first 10000 blocks, without knowing the private key; and hope that miners extend the chain without having or checking the block. The segwit data is not sent separately.
In either case the corrupt chain would be simply reorged out after miners hit their limit of mining without data or otherwise some process realizes they are mining a chain the network is rejecting. Non-validating clients would be exposed to the reorganization, ones that are validating would not be.