Stratum specs

[amaclin]

Let assume that a USER has running ASIC connected to a POOL

1) Can the USER by sniffing the TRAFFIC (data sent from a pool) monitor such things as
a) currently mining blockheight
b) coinbase transaction data (scriptSig)

2) How does ASIC <---> POOL protocol works? Is it http longpoll or socket connection?

[1714122366]

1714122366

[1714122366]

1714122366

[1714122366]

1714122366

[1714122366]

1714122366

[1714122366]

1714122366

[1714122366]

1714122366

[amaclin]

See https://bitcointalk.org/index.php?topic=557866.0

Thanks a lot. I will read it later. Is is up-to-date?

c) What information about network and pool can be obtained from sniffing?
d) Can the user be sure that he mines a block by his pool? (The dishonest pool can proxy
users' hashrate to another pool in case)

[mtve]

Thanks a lot. I will read it later. Is is up-to-date?

Nope      Moreover, some pools have some small differences in protocol, with specially tweaked miners software.   But generally the doc is ok.

c) What information about network and pool can be obtained from sniffing?

Miner id (in some pools it's just an address, so payments can be tracked), miner password in this pool, pool current time, how many submissions miner does (its performance and thus its revenue), that's basically all of interesting information.

d) Can the user be sure that he mines a block by his pool? (The dishonest pool can proxy
users' hashrate to another pool in case)

Nope.   The miner build mutual trust with the pool by having flow of payments.    Other than that, you can not be sure on anything in the internet except blockchains  

[amaclin]

Miner id (in some pools it's just an address, so payments can be tracked), miner password
in this pool, current time, that's basically all of interesting information.

I think that we can get the hash-of-previous-block from protocol data.
Because we need it to put in 80-bytes header for current block

And the hash-of-previous-block gives us at least the network we are connected to and
currently running blockheight (I had to say that we can use another sources of information
except sniffing)

[mtve]

I think that we can get the hash-of-previous-block from protocol data.

Yes, you're right.   From metadata we can of course guess the country and maybe even the place, from hashrate and other sessions we can guess the hardware and power consumption, from reconnects we can guess some operations on site etc.

[amaclin]

Yes, you're right.   From metadata we can of course guess the country and maybe even the place, from
hashrate and other sessions we can guess the hardware and power consumption, from reconnects we
can guess some operations on site etc.

In fact I am asking these questions not as MitM between POOL and ASIC
I am interested - what kind of information can obtain POOL_ADMIN about ALL OTHER POOLS
if connect some his own ASICs to concurrent pools.

I want to discuss possible attack vector after segwit activation. Do not know
how to call it. Something like "witness-data-withholding attack". Pushing the mined block
without witness data to pre-segwit network and listening the actions on it from other pools
gives some interesting advantages to dishonest pool admin.

[achow101]

Let assume that a USER has running ASIC connected to a POOL

1) Can the USER by sniffing the TRAFFIC (data sent from a pool) monitor such things as
a) currently mining blockheight

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.

b) coinbase transaction data (scriptSig)

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

2) How does ASIC <---> POOL protocol works? Is it http longpoll or socket connection?

It is a socket connection.

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

[-ck]

I want to discuss possible attack vector after segwit activation. Do not know
how to call it. Something like "witness-data-withholding attack". Pushing the mined block
without witness data to pre-segwit network and listening the actions on it from other pools
gives some interesting advantages to dishonest pool admin.

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.

[amaclin]

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.

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?

[-ck]

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.

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?

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

[amaclin]

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

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?

[-ck]

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.

[amaclin]

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.

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

[DannyHamilton]

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

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.

[amaclin]

I look forward to seeing how he makes use of it

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

[DannyHamilton]

I look forward to seeing how he makes use of it

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

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.

[amaclin]

generate more revenue for your participants

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.

[Quickseller]

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.

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

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.

[achow101]

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.

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.

[Quickseller]

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.

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.

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.