[bitcoin-dev] Progress on Miner Withholding - FPNC

[Önder Gürcan]

Hello all,

By the way, is this FPNC is similar to the way the current (or recent) code of Ethereum that is selecting branches based on the difficulty of the crypto puzzles solved to obtain the blocks of this branch without comparing the sizes of the subtrees?

Any ideas?

Best,

Önder


> On 8 Oct 2020, at 03:39, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 
> Good morning all,
> 
>> 
>> Below is a novel discussion on block-withholding attacks and FPNC. These are two very simple changes being proposed here that will dramatically impact the network for the better.
>> 
>> But first of all, I'd like to say that the idea for FPNC came out of a conversation with ZmnSCPxj's in regards to re-org stability.  When I had proposed blockchain pointers with the PubRef opcode, he took the time to explain to me concerns around re-orgs and why it is a bigger problem than I initially had thought — and I greatly appreciate this detail.   After touching base with ZmnSCPxj and Greg Maxwell there is an overwhelming view that the current problems that face the network outweigh any theoretical ones.
>> 
>> Currently the elephant in the room is the miner withholding attack. There is an unintended incentive to hold onto blocks because keeping knowledge of this coinbase private gives a greedy miner more time to calculate the next block.  Major mining pools are actively employing this strategy because winning two blocks in a row has a much greater payoff than common robbery. This unfair advantage happens each time a new block is found, and provides a kind of home-field advantage for large pools, and contributes to a more centralized network. This odd feature of the bitcoin protocol provides a material incentive to delay transactions and encourages the formation of disagreements. In a sense, withholding is a deception of the computational power of a miner, and by extension a deception of their influence within the electorate.  In effect, other miners are forced to work harder, and when they are successful in finding a 2nd solution of the same height — no one benefits. Disagreement on the bitcoin network is not good for the environment, or for the users, or for honest miners, but is ideal for dishonest miners looking for an advantage.
> 
> This is my understanding:
> 
> The selfish mining attack described above was already presented and known about **many years** ago, with the solution presented here: https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf
> 
> The solution was later determined to actually raise the needed threshhold to 33%, not 25% in the paper.
> 
> That solution is what is used in the network today.
> 
> Implementing floating-point Nakamoto Consensus removes the solution presented in the paper, and therefore risks reintroducing the selfish mining attack.
> 
> Therefore, floating-point Nakamoto Consensus is a hard NAK.
> 
> 
> Regards,
> ZmnSCPxj
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev