SegWit and SPV-mining. What if...?

[amaclin]

Is the following scenario valid?

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

[1714926092]

1714926092

[1714926092]

1714926092

[1714926092]

1714926092

[gmaxwell]

Is the following scenario valid?

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.

[amaclin]

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.

There is a difference.
Today there is an algorithm which produces 'true' if a portion of data is valid block and 'false' otherwize.
Spending 1M Satoshi's coins without his signature is invalid.
Valid PoW block without segwit data is neigher 'true' nor 'false'. It can be either 'valid' or 'unknown yet'

There is a difference.
Today everyone can check the blockchain and say "WTF? This block is invalid" and nobody would argue.
Tomorrow they would say: "Sorry, man. Your client just doesn't have segwit-data. We also can not provide it to you, but we are sure that it exists somewhere so we will not reorganize the main chain."

The segwit data is not sent separately.

Why? One can send block to the network to all nodes 0.12.x, 0.11.x etc, wait 30 seconds, and send the segwit data
Everybody will know the hash and content of future block, but nobody will know is it segwit-correct or not.

[gmaxwell]

Tomorrow they would say: "Sorry, man. Your client just doesn't have segwit-data. We also can not provide it to you, but we are sure that it exists somewhere so we will not reorganize the main chain."

Pedantically, that isn't how the protocol works. You cannot transfer the block without segwit data to supporting full node systems. Older systems don't get it, but it doesn't matter if they get it or not as they wouldn't enforce any rules with it. I think your question is actually about old systems, in which case the transmission part is a distraction.

The segwit data is not sent separately.

Why? One can send block to the network to all nodes 0.12.x, 0.11.x etc, wait 30 seconds, and send the segwit data

Old software indeed doesn't necessarily verify all the rules that are at play: this is unavoidable, since you cannot even know potentially all the rules that are at play as miners could be enforcing ones no one but they know about. The same holds for any rule addition, like P2SH, or CLTV, or CSV.

At least for intentional public rule additions, the process limits exposure:  In the BIP9 protocol no new rules are added until two weeks after 95% of hashpower signals an intent to enforce. During that time and before full node software will have been producing loud warnings: "Warning: Unknown block versions being mined! It's possible unknown rules are in effect", "unknown new rules are about to activate", and "Warning: unknown new rules activated", notices for a month-- allowing parties to upgrade or connect their node via another upgraded node (that filters the blocks they receive). The process also is date gated to give time for upgrades even before it potentially begins. No non-upgraded full node software will create addresses using the new rules (nor would any prudent wallet generate them until they're widely enforced in the network) nor accept unconfirmed transactions that use them as they're non-standard. One could set their wallet to automatically delay or withhold action when a new rule they haven't been updated for has gone into effect, until upgraded or manually bypassed for that particular new rule, but for virtually any application that would be excessive-- considering that 95% of hashpower are updated to enforce and a process which results in wide deployment of node software.

(As an aside, segwit would be in 0.12.2/0.12.3; and potentially 0.11.x too though it looks like there isn't demand for it)

[amaclin]

You cannot transfer the block without segwit data to supporting full node systems. Older systems don't get it, but it doesn't matter if they get it or not as they wouldn't enforce any rules with it. I think your question is actually about old systems, in which case the transmission part is a distraction.

I will pass the block without segwit data to "old" notes.
The SPV-miners are interested in receiving 256-bit hash as fast as possible to switch their hashpower to new height.
This is "cheating" for increasing their total incomes. And they actually do it today.

Old software indeed doesn't necessarily verify all the rules that are at play: this is unavoidable, since you cannot even know potentially all the rules that are at play as miners could be enforcing ones no one but they know about. The same holds for any rule addition, like P2SH, or CLTV, or CSV.

With segwit there will be other bets in this game. 
Today the risk is "not to earn 25+ btc reward" and the winning is "earn 25+ btc"
Tomorrow the risk will be "not to earn 12.5 btc" and the winning is "take all amounts from top-1000 utxo"

(As an aside, segwit would be in 0.12.2/0.12.3; and potentially 0.11.x too though it looks like there isn't demand for it)

I mean the nodes which do not upgrade to segwit. Exact version numbers do not matter.
For example, I will pass my block without segwit data to bc.i 

[hhanh00]

Do you really think that they would not be upgraded by then?

[amaclin]

Do you really think that they would not be upgraded by then?

Are you asking about bc.i ?
segwit is soft-fork afair.
nobody (except of miners) is forced to upgrade.

bc.i had a lot of issues with consensus and policy in past.
(some references are in my profile in "trust" section  )
i do not think that something has been changed.