Possible attack scenario on a pool? / 51% type of attack

[skeeterskeeter]

From my knowledge,

A mining pool works in the same way as solo mining. Software acting as node on the network calculates the current blockheader based on its blockchain, and passes this to mining software. This software continually hashes this blockheader looking for the target. For a pool, the pool owners software calculates the blockheader and passes it to its workers/members and they hash the pool owners blockheader.

A question I pose,

The pool owner, or node on the network, receives information from other nodes it is connected to about the current state of the bitcoin blockchain (new transactions, new blocks, longest blockchain). If someone were to control all of the nodes connect to the pool owner, couldn't they edit the block broadcasted from the pool and change the payout address to theirs?

I guess the larger problem I see is if someone were to control all of the connections to someone who has found a block, couldn't they broadcast it altered in their favor and have it accepted faster than the block finder themselves? One because the block finder cannot tell anyone about its block, and two by the time they might find a new connection the network has already accepted the altered one?

To put it differently, if the network is visualized as nodes with a certain weighting of computing power, if you were to control enough nodes around at least 51% of the computing power couldn't you alter the blockchain to your favor? So say the two biggest pools are 21% and 30% of the network collectively but only have 1% of the connection to them (not sure how large/small connection to overall network could be/is), if someone could obtain control of those nodes couldn't they broadcast the work done by the pools to more people than the pool can in the same time?

[Rannasha]

Changing the payout address in a newly mined block requires redoing the proof-of-work.

[skeeterskeeter]

Changing the payout address in a newly mined block requires redoing the proof-of-work.

Ah. The hashing info is calculated taking into account the payout address?

Found this https://en.bitcoin.it/wiki/Block_hashing_algorithm So the block header is comprised on the following components

Component          Reason                                                                                            Updated
Version                Block version number                                                        You upgrade the software and it specifies a new version    
hashPrevBlock       256-bit hash of the previous block header                            A new block comes in    
hashMerkleRoot     256-bit hash based on all of the transactions in the block        A transaction is accepted    
Time                   Current timestamp as seconds since 1970-01-01T00:00 UTC    Every few seconds
Bits                     Current target in compact format                                        The difficulty is adjusted    
Nonce                 32-bit number (starts at 0)                                                 A hash is tried (increments)    

So a transaction is verified if it makes sense based on the nodes blockchain, it is then added to the blockchain and the merkle root is recalculated(?).

When someone is mining, do they add the transaction that pays them out to the blockchain they have, changing the merkleroot, and then hash it and broadcast it? This way someone can not change where the payout goes to without rehashing/doing a crapton of work.


--

Seeing as that fails, what if someone was still able to gain control to all of the nodes one person is connected to?

I guess the most they could be is an annoyance.
They could just not broadcast new blocks to the node, and send it random transactions (generate tons of transactions to and from themselves). If this is done to a node that holds a considerable portion of the networks computational power though, it would weaken the network making it easier to perform a legitimate 51% attack.

[btcrich]

Also, pool operators can and most likely do ensure that they are always connected to trusted nodes.

[jellies]

" if you were to control enough nodes around at least 51% of the computing power couldn't you alter the blockchain to your favor?"


There is already a plausible attack and you just need >= 35% of the hashing power so the current largest mining pool could do it.

The simulator is here:

http://ebfull.github.io/

Basically the evil pool starts to grab an unfair share of the revenue by broadcasting secretly found blocks just before someone else with less connectivity finds a block. Effectively they are exploiting a timing race to tilt the odds and grab revenue due other miners.

This was forshadowed here by a member in 2010 and they also ran some simulations to show the problem, it was re-discovered but with more detail by this guy: http://hackingdistributed.com/2013/11/17/selfish-mining-simulator/

[AnonyMint]

I provided a solution to defeat the selfish-mining attack. See my post at hackingdistributed.com

[Rannasha]

Changing the payout address in a newly mined block requires redoing the proof-of-work.

Ah. The hashing info is calculated taking into account the payout address?

The mining reward payout is just another transaction. Therefore it affects what the merkle root looks like.

So a transaction is verified if it makes sense based on the nodes blockchain, it is then added to the blockchain and the merkle root is recalculated(?).

When someone is mining, do they add the transaction that pays them out to the blockchain they have, changing the merkleroot, and then hash it and broadcast it? This way someone can not change where the payout goes to without rehashing/doing a crapton of work.

Miners collect transactions they've received from other nodes and verified as valid based on their version of the blockchain. They add to this set a transaction paying 25 BTC (right now) plus the amount of fees from the set of transactions collected, to an address of their choosing. The hash of the merkle root is calculated using this set of transaction. This merkle root hash is added into the header for a yet-to-be-mined block and the miner then starts to try and find a nonce-value that, when added to the block header, produces a block-header-hash that meets the requirements. If new transactions come in, the hash of the merkle root is recalculated and mining is resumed with the new data.

Once this happens, the miner broadcasts the entire block to the network and other nodes add the block to their local copy of the blockchain. At this point, anyone wanting to change the payout address of the mining reward, has to alter this transaction, recalculate the merkle root and try and find a suitable nonce (= redo the mining process for this block). All the while competing with legit nodes receiving the unaltered block and starting work on the next block.