Stratum specs

[achow101]

To me, that sounds even worse. It would mean that miners, and nodes (and new of the same) would slowly move to an entirely new chain as they restart (or come online for the first time). It would also change consensus rules because nodes would be rejecting valid blocks. It would also create an attack vector (similar to malleability, but IMO worse), in which a (network of) well connected node(s) could listen for valid SW blocks, and quickly rebroadcast them with invalid signature data, causing SW miners and nodes to reject these valid blocks. 

But this attack assumes that there are 51% of miners who are not enforcing segwit. This is one reason why there's an activation threshold that requires 95% of the hashrate to signal that they are enforcing the segwit rules.

Also, such an attack is possible for any soft fork, not just segwit. But again, that is why soft forks still require 95% to activate.

[1715604266]

1715604266

[1715604266]

1715604266

[1715604266]

1715604266

[amaclin]

The malicious pool could find a valid SW block (block "n", block height "x"),
release the valid block with invalid signature data

Without signature data.

The SW miners would think the block is invalid and ignore the block

Are you sure about it?
Assume you are pool admin. You see a block in old format height "x". You saw such blocks
a day ago, and you know that the valid block with the same header will come to you
in a couple of seconds. Why not to start mining empty block on top with height "x+1"?

Also, such an attack is possible for any soft fork, not just segwit.

No
There was no infrastructure in past which was able to broadcast blocks with
valid headers (suitable to mine on top of them) and invalid data (not suitable to insert
into blockchain) faster than bitcoin network. Now we have such infrastructure

But this attack assumes that there are 51% of miners who are not enforcing segwit.

No. You can use segwit-client on your mining node but with some SPV cheats
for increasing revenue.  Why should you check the whole block if you can to start
mining on top of it without waiting?

[achow101]

Are you sure about it?
Assume you are pool admin. You see a block in old format height "x". You saw such blocks
a day ago, and you know that the valid block with the same header will come to you
in a couple of seconds. Why not to start mining empty block on top with height "x+1"?

Unless humans are actively monitoring their pool and watching what blocks are received, what blocks are mined, whether their node is accepting or rejecting some blocks, etc., that won't happen. In order for such a thing to happen, humans must be involved, and I would surprised if pool operators are actually that attentive to that sort of information.

No
There was no infrastructure in past which was able to broadcast blocks with
valid headers (suitable to mine on top of them) and invalid data (not suitable to insert
into blockchain) faster than bitcoin network. Now we have such infrastructure

How so?

We have had the infrastructure to broadcast headers only since 0.10.0.

You can broadcast a block with invalid data for every soft fork Bitcoin has ever had (assuming you send a valid header first). For every single soft fork that Bitcoin has had, post fork you could always create a block which non-upgraded nodes would accept but upgraded ones wouldn't. This didn't apply for when headers first didn't exist, but headers first broadcasting has existed for the OP_CLTV and OP_CSV soft forks. With these soft forks (and all previous ones), you could create a block which has a valid header and invalid data (include an invalid transaction), and with headers first, performed the attack described by Quickseller. There's nothing different or special about segwit that allows this. In fact, with segwit, the impact of such an attack is slightly reduced (very slightly). With segwit, the block is actually invalidated before being written to the disk (because the witness commitment wouldn't match). With all other soft forks, the block would be invalidated after being written to disk when transactions are being validated.

[Quickseller]

To me, that sounds even worse. It would mean that miners, and nodes (and new of the same) would slowly move to an entirely new chain as they restart (or come online for the first time). It would also change consensus rules because nodes would be rejecting valid blocks. It would also create an attack vector (similar to malleability, but IMO worse), in which a (network of) well connected node(s) could listen for valid SW blocks, and quickly rebroadcast them with invalid signature data, causing SW miners and nodes to reject these valid blocks. 

But this attack assumes that there are 51% of miners who are not enforcing segwit. This is one reason why there's an activation threshold that requires 95% of the hashrate to signal that they are enforcing the segwit rules.

Also, such an attack is possible for any soft fork, not just segwit. But again, that is why soft forks still require 95% to activate.

The attack actually requires the hashrate of the malicious pool plus the hashrate of non-SW miners to be 51%. So, for example, if the malicious miner has 20%, then non-SW miners would need to have at least 31% for this attack to work.

SW could potentially activate with significantly less than 95% of miners supporting (and more importantly enforcing SW -- it is not clear that miners currently signaling for SW will enforce SW upon it's activation) SW via BIP 148. Even if SW were to activate upon receiving 95% signaling, it's controversy will likely result in there always be a market for non-SW mining, and this market could potentially grow upon the activation of SW. Miners may signal SW "today" under the threat of a POW change, and return to non-SW mining once it activates.

I agree that this attack is possible with any SF (which is an additional reason not to 'improve' Bitcoin via SFs), however as mentioned above, SW is controversial enough so that there will likely always be a market for non-SW mining, and almost all other SFs have little/no controversy, and as such, pools have no real reason not to enforce their rules. 

The malicious pool could find a valid SW block (block "n", block height "x"),
release the valid block with invalid signature data

Without signature data.

The SW miners would think the block is invalid and ignore the block

Are you sure about it?
Assume you are pool admin. You see a block in old format height "x". You saw such blocks
a day ago, and you know that the valid block with the same header will come to you
in a couple of seconds. Why not to start mining empty block on top with height "x+1"?

I think you are referring to SPV mining, which would probably be a different attack than what I am describing.

In practice pools will only SPV mine for as long as it takes them to validate the received block. If you withhold the signature data altogether, then a pool will never be able to confirm nor deny that a SW block is valid, however pools likely have some kind of 'sanity check' to not SPV mine for too long, especially after the 'fork of July' from a few years ago. I also don't see any economic incentive to engage in this kind of behavior.

[achow101]

The attack actually requires the hashrate of the malicious pool plus the hashrate of non-SW miners to be 51%. So, for example, if the malicious miner has 20%, then non-SW miners would need to have at least 31% for this attack to work.

But in order for segwit to even activate, 95% of the hashrate has to be signalling for segwit.

SW could potentially activate with significantly less than 95% of miners supporting (and more importantly enforcing SW -- it is not clear that miners currently signaling for SW will enforce SW upon it's activation) SW via BIP 148.

If BIP 148 activates, then 100% of miners on the BIP 148 chain will, at the very least, be signalling for segwit. All miners who aren't will be forked off of the BIP 148 chain.

Even if SW were to activate upon receiving 95% signaling, it's controversy will likely result in there always be a market for non-SW mining, and this market could potentially grow upon the activation of SW. Miners may signal SW "today" under the threat of a POW change, and return to non-SW mining once it activates.

Why? There's no logic in not mining SW if you were already supporting it after it activates. A miner would be losing money if they didn't support segwit. Also, why would there be a market for non segwit mining? Segwit being active doesn't preclude non-segwit transactions from being included in blocks. For those who don't support segwit at all and don't want it activated, then they would be using another chain entirely which is not a problem for the chain with segwit activated.

Also, another thing to note is that stuff like Compact Blocks and XThin blocks would help to mitigate such an attack. Since many of the transactions in the block will already be known to nodes, nodes will know about the transactions already so they already have the witnesses and don't need to get the transactions from the block. They will just rebuild the block using the transactions from their mempool which will have the witnesses so they will recognize that the block is valid.

[amaclin]

Unless humans are actively monitoring their pool and watching what blocks are received

Of course, regular asic owners will not do it
I mean that pool admin can monitor the behaviour of concurrent pools with stratum.

could always create a block which non-upgraded nodes would accept but upgraded ones wouldn't.

this block would not move faster through the network ( do not tell me about BIP-16 - it is
the past, we talk about future )

We have had the infrastructure to broadcast headers only since 0.10.0.

I do not talk about "headers first" and other protocol optimizations.
Just the standard protocol: "inv" --> "getdata" --> "block" packets

OK, imagine you and me are pool admins.
I create artificial block, containing 2k segwit transactions you haven't seen in raw form.
I broadcast this block to pre-segwit part of network (without signatures).
One of my own asics is connected to your pool.

You are able to receive this incomplete block from one of pre-segwit nodes.
You know that this situation is standard, because block without signatures moves
much more faster. You have two opportunities: (a) ignore it and wait more time for
valid block in segwit consensus rules (b) start mining empty block on top of it.

What would you do in this case to increase your revenue?
What would you do if this case will happen regulary?

The attack actually requires the hashrate of the malicious pool plus the hashrate of non-SW miners to be 51%

I've described only the first step. Not an attack itself Go on!