Bitcoin Forum
May 11, 2024, 11:48:55 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: A solution to block withholding attacks  (Read 670 times)
JoelKatz (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
May 27, 2015, 08:23:19 PM
 #1

I just thought of a neat solution to block withholding attacks. It does require a hard fork to add support because there's a small tweak to legal coinbase transactions and to how block hashes are checked against the target. The basic mechanism involves a hash blinding factor that is included in the coinbase transaction and must be XORed with the block hash before it is tested against the difficulty target.

The scheme works as follows:

1) When the pool creates work for a miner, it generates a random hash blinding factor. It then masks off all the bits in the blinding factor that contribute to whether the miner has found a share or not. The masked blinding factor is included in the coinbase transaction. With difficulty 1 shares, the blinding factor might be 00000000987E872A234...

2) The pool gives the work to the miner.

3) The miner finds a share normally, and the pool gives the miner credit.

4) The pool, knowing the hash blinding factor (because, of course, it must have saved the coinbase transaction because it needs it to submit the block) checks if the miner found a block. If so, it submits it to the network.

5) The miner does not know the blinding factor and so has no idea whether he found a share or a block. So he can't withhold blocks without withholding shares.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
1715471335
Hero Member
*
Offline Offline

Posts: 1715471335

View Profile Personal Message (Offline)

Ignore
1715471335
Reply with quote  #2

1715471335
Report to moderator
1715471335
Hero Member
*
Offline Offline

Posts: 1715471335

View Profile Personal Message (Offline)

Ignore
1715471335
Reply with quote  #2

1715471335
Report to moderator
1715471335
Hero Member
*
Offline Offline

Posts: 1715471335

View Profile Personal Message (Offline)

Ignore
1715471335
Reply with quote  #2

1715471335
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715471335
Hero Member
*
Offline Offline

Posts: 1715471335

View Profile Personal Message (Offline)

Ignore
1715471335
Reply with quote  #2

1715471335
Report to moderator
1715471335
Hero Member
*
Offline Offline

Posts: 1715471335

View Profile Personal Message (Offline)

Ignore
1715471335
Reply with quote  #2

1715471335
Report to moderator
1715471335
Hero Member
*
Offline Offline

Posts: 1715471335

View Profile Personal Message (Offline)

Ignore
1715471335
Reply with quote  #2

1715471335
Report to moderator
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
May 27, 2015, 08:45:44 PM
 #2

I remember a paper that suggested something similar.  It isn't that clear exactly what you are proposing btw.

It was also a hard fork to change the hash rules too.

It had 2 hashes that both had to hit the target.

Hash(header) < T1
Hash(header | blinding factor) < T2

The pool picked T1 and T2.  As long as (T1 / 2256) * (T2 / 2256) <= (T / 2256), then the block had sufficient POW.

I think they included the blinding factor in the header though.  Otherwise, SPV clients wouldn't be able to validate the header chain (without lots of extra data).

If you are going to hard fork, you might as well change that.  It can be done without changing the blocks for ASICs.  It requires changing the meaning of the merkle root field.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!