Mike Brooks [ARCHIVE] on Nostr: đ Original date posted:2020-10-08 đ Original message:Very interesting, Block ...
đ
Original date posted:2020-10-08
đ Original message: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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201008/cbcd37ee/attachment.html>
đ Original message: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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201008/cbcd37ee/attachment.html>