MIME-Version: 1.0
References: <CALFqKjTY6d2nQtUe-NyyKJEYcWKEj1mfdQfAzKkB-NRDwYD5JQ@mail.gmail.com>
 <STSmfzWKGGPx0yJ9ysTPbDw-KpvlBLmr9R5IPDogPw0FRzG0BZ7Bk_NeWiwPUYw6Nhrqkq5DlrmtN9T3vXE83p_JH6LDizMTWZ9MCQSaous=@protonmail.com>
In-Reply-To: <STSmfzWKGGPx0yJ9ysTPbDw-KpvlBLmr9R5IPDogPw0FRzG0BZ7Bk_NeWiwPUYw6Nhrqkq5DlrmtN9T3vXE83p_JH6LDizMTWZ9MCQSaous=@protonmail.com>
From: Mike Brooks <m@ib.tc>
Date: Thu, 8 Oct 2020 16:05:05 -0700
Message-ID: <CALFqKjRL9c_z5o-35zkXQ0kxzgYmiPinhk8zqhTWRCqKqDfkag@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004aa52105b12a61b1"
Subject: Re: [bitcoin-dev] Progress on Miner Withholding - FPNC
Precedence: list

--0000000000004aa52105b12a61b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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:

> Good morning all,
>
> >
> > Below is a novel discussion on block-withholding attacks and FPNC. Thes=
e
> 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 =E2=80=94 and I greatly appreciate this detail.   A=
fter
> touching base with ZmnSCPxj and Greg Maxwell there is an overwhelming vie=
w
> 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 payo=
ff
> 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 bitcoi=
n
> protocol provides a material incentive to delay transactions and encourag=
es
> 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 th=
e
> same height =E2=80=94 no one benefits. Disagreement on the bitcoin networ=
k 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
>

--0000000000004aa52105b12a61b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Very interesting,<div><br></div><div>Block mixing did not =
resolve the selfish mining that is currently observed on the network.=C2=A0=
 This mitigation was only=C2=A0intended to limit the maximum impact of wait=
ing for a 2nd block to be produced.</div><div><br></div><div>Rebalancing=C2=
=A0the selfish-mining incentives with FPNC and a faster block creation=C2=
=A0time is the single best thing we can do to decentralize mining efforts.=
=C2=A0 It will also produce a better network.</div><div><br></div></div><di=
v dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 7, 2020 at 6:40 PM ZmnSCPxj =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning all,<=
br>
<br>
&gt;<br>
&gt; Below is a novel discussion=C2=A0on block-withholding=C2=A0attacks and=
 FPNC. These are=C2=A0two very simple changes being proposed here that will=
 dramatically=C2=A0impact the network for the better.<br>
&gt;<br>
&gt; But first of all, I&#39;d like to say that the idea for FPNC came out =
of a conversation=C2=A0with ZmnSCPxj&#39;s in regards to=C2=A0re-org stabil=
ity.=C2=A0 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 b=
igger problem than I initially had thought=C2=A0=E2=80=94 and I greatly app=
reciate this detail.=C2=A0 =C2=A0After touching base with ZmnSCPxj and Greg=
 Maxwell there is an overwhelming view that the current problems that face =
the network outweigh any theoretical ones.<br>
&gt;<br>
&gt; Currently the elephant in the room is the miner withholding attack.=C2=
=A0There is an unintended incentive to hold onto blocks because keeping kno=
wledge of this coinbase private gives a greedy miner more time to calculate=
 the next block.=C2=A0 Major mining pools are actively employing this strat=
egy because winning two blocks in a row has a much greater payoff than comm=
on robbery. This unfair advantage=C2=A0happens each time a=C2=A0new block i=
s found, and provides a kind of home-field advantage for large pools, and c=
ontributes to a more centralized network. This odd feature of the bitcoin p=
rotocol provides a material incentive to delay transactions and encourages =
the formation of disagreements. In a sense, withholding is a deception of t=
he computational power of a miner, and by extension a deception of their in=
fluence within the electorate.=C2=A0 In effect, other miners are forced to =
work harder,=C2=A0and when they are successful in finding a 2nd solution of=
 the same height=C2=A0=E2=80=94 no one benefits. Disagreement on the bitcoi=
n 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.<br>
<br>
This is my understanding:<br>
<br>
The selfish mining attack described above was already presented and known a=
bout **many years** ago, with the solution presented here: <a href=3D"https=
://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf" rel=3D"noreferrer" =
target=3D"_blank">https://www.cs.cornell.edu/~ie53/publications/btcProcFC.p=
df</a><br>
<br>
The solution was later determined to actually raise the needed threshhold t=
o 33%, not 25% in the paper.<br>
<br>
That solution is what is used in the network today.<br>
<br>
Implementing floating-point Nakamoto Consensus removes the solution present=
ed in the paper, and therefore risks reintroducing the selfish mining attac=
k.<br>
<br>
Therefore, floating-point Nakamoto Consensus is a hard NAK.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000004aa52105b12a61b1--