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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
