Topic: Stratum specs (Read 1873 times)

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

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

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?

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

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

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.

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.

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. 


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.

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.

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.

Without signature data.

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

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?

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.

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. 

That shouldn't be possible.

The chain split could happen, but not the re-org, I think. This is because the SW miners and nodes will have received the block with invalid signatures, saved it to disk, and marked it as invalid. It should remember that a block with the hash of the invalid block was invalid. Then when the malicious miner tries to broadcast it again with valid signature data, the SW miners and nodes will see the block, see that the block hash is that of one it marked invalid, and ignore the block.

If I am not mistaken, then if [malicious pool hashrate] + [non-SW hashrate] >51% of the network hashrate, then the malicious pool can trivially execute a 51% attack.

The malicious pool could find a valid SW block (block "n", block height "x"), release the valid block with invalid signature data (but would retain valid signature data). The SW miners would think the block is invalid and ignore the block, while the non-SW miners would ignore the signature data and build on top of the block. If a non-SW miner find a valid non-SW block, then the non-SW miners and the malicious miner would build on top of this n+1 block, and the rest of the SW miners would be still building on top of the n - 1 block. If another SW miner were to find a valid block (block "b"), and release the block with valid signature data, then the SW miners (less the malicious SW miner) would build on top of block b, which has a height of x, however the rest of the network would be building on top of a block height of x+1. This would continue until the chain containing block n has some positive number of blocks greater than the chain containing block x, and the malicious SW miner would release the valid signature data for his block n, along with the blocks already on top of his chain, causing a re-org.

Boring idea.

I am sure we will see the pools which woulld pay 100+% (including fees) rewards to miners
just to increase the market size of pool.

Perhaps you should start a pool.  If  you can find ways for your pool to generate more revenue for your participants per gigahash than other pools, then your pool may grow to be one of the largest.

I can not.
Because this attack (strategy) can be performed only by mining pool against others.
I am not pool admin.

I wouldn't bet against amaclin.

It's possible that he's missing an important piece of information in his idea, but odds are that he's got a usable idea about how to cause mischief. I look forward to seeing how he makes use of it or what happens when a pool implements his idea.

One of us is stupid. The future will give the answer who is

Segwit blocks look and work just like regular blocks and are no different with or without the node knowing about the witness data. There is no way to use the use them as some kind of different block.

the direct question is:
what is dishonest admin of major pool after segwit activation would push segwit blocks mined by his pool
to pre-segwit nodes immidiately (ommiting witness data of course) and to segwit nodes after some delay
(1 sec for example).

Will other pools catch this trick and use SPV-mining on top of this block saving 1 second of their work?

Sorry I've tried to understand your question but I have no idea what you're talking about now.

Sorry. My English is too bad... I also can not understand my writings
I do not talk not about asic owners. Point.
I do think about pushing the segwit blocks (without witness data of course) to pre-segwit part of
network first and withholding the segwit block for some delay. To make this attack the pool admin
have to answer the question: do other pools wait for segwit block or do they use SPV?

Miners have zero input into what transactions the pool chooses. They don't even know what transactions are being included as they only get enough data to reconstruct the merkle hash. Thus a MitM can't do anything to what transactions the pool is including. Any modification to the merkle hash will make the data invalid and the pool will no longer accept it.

Yes. The message which sends work to a miner contains the previous block hash and the coinbase except for the extranonce(s). Since the coinbase transaction contains the block height currently being mined, you can easily extract that data.

Yes. Since the entire coinbase transaction except the extranonce(s) are sent, the entire coinbase is known.

It is a socket connection.

The actual stratum documentation can be found at https://slushpool.com/help/manual/stratum-protocol