Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4E34EC016F for ; Thu, 8 Oct 2020 01:40:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 3ACAE2E0E6 for ; Thu, 8 Oct 2020 01:40:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRNax2+VP78Y for ; Thu, 8 Oct 2020 01:39:59 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by silver.osuosl.org (Postfix) with ESMTPS id 40BE32E0DA for ; Thu, 8 Oct 2020 01:39:59 +0000 (UTC) Date: Thu, 08 Oct 2020 01:39:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1602121196; bh=DrzrQR0tZ3ftilYHpE3MuRZBJf5pb0lJpNrdJNlTsnE=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=wpp5SEDSqDeHd5+rVlit71/mwxoK2DFW+CjmFbjLjYVnmsUJDXZ4+1gdWuSqlY90R g6RSeKXt5jj/Puka4/rNKL490sKKsmmZStPT3XMUbK33Ffr/+iUjNIDtsoJZFZym1F 1T/pmf3lNFD8T70uHLU69nQJ8CkvW3IXdZiJJ7KQ= To: Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Progress on Miner Withholding - FPNC X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 01:40:01 -0000 Good morning all, > > Below is a novel discussion=C2=A0on block-withholding=C2=A0attacks and FP= NC. These are=C2=A0two very simple changes being proposed here that will dr= amatically=C2=A0impact the network for the better. > > But first of all, I'd like to say that the idea for FPNC came out of a co= nversation=C2=A0with ZmnSCPxj's in regards to=C2=A0re-org stability.=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 bigger p= roblem than I initially had thought=C2=A0=E2=80=94 and I greatly appreciate= this detail.=C2=A0 =C2=A0After touching base with ZmnSCPxj and Greg Maxwel= l there is an overwhelming view that the current problems that face the net= work outweigh any theoretical ones. > > 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. This is my understanding: The selfish mining attack described above was already presented and known a= bout **many years** ago, with the solution presented here: https://www.cs.c= ornell.edu/~ie53/publications/btcProcFC.pdf The solution was later determined to actually raise the needed threshhold t= o 33%, not 25% in the paper. That solution is what is used in the network today. Implementing floating-point Nakamoto Consensus removes the solution present= ed in the paper, and therefore risks reintroducing the selfish mining attac= k. Therefore, floating-point Nakamoto Consensus is a hard NAK. Regards, ZmnSCPxj