From: =?utf-8?B?w5ZuZGVyIEfDvHJjYW4=?= <onder.gurcan@gmail.com>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 8 Oct 2020 11:18:59 +0200
References: <CALFqKjTY6d2nQtUe-NyyKJEYcWKEj1mfdQfAzKkB-NRDwYD5JQ@mail.gmail.com>
 <STSmfzWKGGPx0yJ9ysTPbDw-KpvlBLmr9R5IPDogPw0FRzG0BZ7Bk_NeWiwPUYw6Nhrqkq5DlrmtN9T3vXE83p_JH6LDizMTWZ9MCQSaous=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Developers List <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <STSmfzWKGGPx0yJ9ysTPbDw-KpvlBLmr9R5IPDogPw0FRzG0BZ7Bk_NeWiwPUYw6Nhrqkq5DlrmtN9T3vXE83p_JH6LDizMTWZ9MCQSaous=@protonmail.com>
Message-Id: <572BB236-5E4F-4DFC-AB16-2B22906B58CD@gmail.com>
Subject: Re: [bitcoin-dev] Progress on Miner Withholding - FPNC
Precedence: list

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,

=C3=96nder


> On 8 Oct 2020, at 03:39, ZmnSCPxj via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Good morning all,
>=20
>>=20
>> 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.
>>=20
>> 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.   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.
>>=20
>> 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 =E2=80=94 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.
>=20
> This is my understanding:
>=20
> 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
>=20
> The solution was later determined to actually raise the needed =
threshhold to 33%, not 25% in the paper.
>=20
> That solution is what is used in the network today.
>=20
> Implementing floating-point Nakamoto Consensus removes the solution =
presented in the paper, and therefore risks reintroducing the selfish =
mining attack.
>=20
> Therefore, floating-point Nakamoto Consensus is a hard NAK.
>=20
>=20
> Regards,
> ZmnSCPxj
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev