Progress on Miner Withholding - FPNC
5 messages, 8 to 9 Oct 2020. Started by Pieter Wuille.
Mike Brooks (2), Pieter Wuille, ZmnSCPxj, Önder Gürcan
On Wednesday, October 7, 2020 1:31 PM, Mike Brooks via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (1 line)
> 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.
Greg Maxwell isn't on this list, but assuming this is about the conversion you've had on Bitcoin Core's security disclosure list, I believe this is a misrepresentation. The discussion has been mostly around a DoS attack report which turned out to be a mistake.
Cheers,
Good morning all,
Quoted text (6 lines)
> > 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
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
Quoted text (31 lines)
> On 8 Oct 2020, at 03:39, ZmnSCPxj via bitcoin-dev <bitcoin-dev@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@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Very interesting,
Block mixing did not resolve the selfish mining that is currently observed on the network. This mitigation was only intended to limit the maximum impact of waiting for a 2nd block to be produced.
Rebalancing the selfish-mining incentives with FPNC and a faster block creation time is the single best thing we can do to decentralize mining efforts. It will also produce a better network.
On Wed, Oct 7, 2020 at 6:40 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (59 lines)
> 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 >
Pieter,
You are correct.
And also, I did prove what I set out to prove. The code provided privately to the security team will in fact consume 99% of the CPU, which means it does have an effect on the electorate. It is true the node still stubbornly passes messages, but I would argue that this is still very much a problem that would concern operators, and perhaps the threshold for a patch is much too high. A layered security system like what is found in bitcoin necessitates an attack chain. The `getdata` message is an implicit information disclosure that allows for the identification of dissenting nodes. As ZmnSCPxj pointed out, block mixing will give preemption at most 67% of the network, and the remaining dissenting nodes can be quelled by maxing out their processing power. All of this can be used together to make sure that a withheld block becomes the prevailing solution.
FPNC rebalances incentives to serve the interests of the network, and fundamentally resolves a class of abuses that reshape the electorate. FPNC will produce a more deceliterized and fair network than "first seen."
Cheers, Mike
On Wed, Oct 7, 2020 at 5:12 PM Pieter Wuille <bitcoin-dev@wuille•net> wrote:
Quoted text (25 lines)
> On Wednesday, October 7, 2020 1:31 PM, Mike Brooks via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > > 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. > > > Greg Maxwell isn't on this list, but assuming this is about the conversion > you've had on Bitcoin Core's security disclosure list, I believe this is a > misrepresentation. The discussion has been mostly around a DoS attack > report which turned out to be a mistake. > > Cheers, > > -- > Pieter > > >