From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B6FDAAC for ; Sat, 11 Jul 2015 15:34:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 473CE195 for ; Sat, 11 Jul 2015 15:34:56 +0000 (UTC) Received: by wiga1 with SMTP id a1so36529299wig.0 for ; Sat, 11 Jul 2015 08:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D8+5A3FQUGQ8I9GG+h/7AhOpCpVMWdMfq6u7Mi+Q+S0=; b=I46cDByWueviBOFubR8yNXYKcz29ktVdfvJRy+i87FNjnj4qo8vhx/uSCVD/od4HRS EmYik61sif78wWYuaF6HLXV/zsMlzgfWVy+MgdkJfoIRwJTmCRvXRk4gpL2mh8duweRp 1M8nDflpj4iwEXZdzqoOBzxM2QF/YUpu6ek9VqOXAplJtgg9LAnBo7KBq3Fva2aN2T/O yXjQw9U3iYoJ3yZIiKYNdUi8waet8zqmMNktKMwmmXKrNAD9CWN8cpEKIlpgFzQgkQ9a Vb/+BF5DJXLG7BnhZAtF68UAs/CbmVSOmRLttZFW3KPQGOtWtOID1Y31pU7OPBh91ozy lYTw== MIME-Version: 1.0 X-Received: by 10.180.101.138 with SMTP id fg10mr7672259wib.46.1436628894901; Sat, 11 Jul 2015 08:34:54 -0700 (PDT) Received: by 10.28.140.196 with HTTP; Sat, 11 Jul 2015 08:34:54 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Jul 2015 11:34:54 -0400 Message-ID: From: Jeff Garzik To: Nathan Wilcox Content-Type: multipart/alternative; boundary=f46d0444e9a5f46d6f051a9b3a15 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] SPV Mining reveals a problematic incentive issue. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 15:34:57 -0000 --f46d0444e9a5f46d6f051a9b3a15 Content-Type: text/plain; charset=UTF-8 The miners with invalid blocks were punished with a loss of bitcoin income... On Sat, Jul 11, 2015 at 4:05 AM, Nathan Wilcox wrote: > Thesis: The disincentive miners have for verifying transactions is > problematic and weakens the network's robustness against forks. > > According to the 2015-07-04 bitcoin.org alert [1]_ so-called "SPV Mining" > has become popular across a large portion of miners, and this enabled the > consensus-violating forks to persist. Peter Todd provides an explanation > of the incentive for SPV Mining over in another thread [2]_. > > .. [1] https://bitcoin.org/en/alert/2015-07-04-spv-mining#cause > > .. [2] > https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00404.html > > If there is a cost to verifying transactions in a received block, then > there is an incentive to *not verify transactions*. However, this is > balanced by the a risk of mining atop an invalid block. > > If we imagine all miners verify all transactions, except Charlie the > Cheapskate, then it's in Charlie's interest to forego transaction > verification. If all miners make a similar wager, then in the extreme, > no miners verify any transactions, and the expected cost of skipping > transaction verification becomes very high. > > Unfortunately, it's difficult to measure how many miners are not > validating transactions, since there's no evidence of this until they > mine atop on invalid block. Because of this, I worry that over time, > more and more miners cut this particular corner, to save on costs. > > If true, then the network continues to grow more brittle towards the kind > of forking-persistence behavior we saw from the July 4th (and 5th) forks. > > This gets weird. For example, a malicious miner which suspects a large > fraction of miners are neglecting transaction verification may choose to > forego a block reward by throwing an erroneous transaction into their > winning block, then, as all the "SPV Miners" run off along a worthless > chain, they can reap a higher reward rate due to controlling a larger > network capacity fraction on the valid chain. > > Can we fix this? > > -- > Nathan Wilcox > Least Authoritarian > > email: nathan@leastauthority.com > twitter: @least_nathan > > Standard Disclaimer: I'm behind on dev archives, irc logs, bitcointalk, > the wiki... if this has been discussed before I appreciate mentions of > that fact. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f46d0444e9a5f46d6f051a9b3a15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The miners with invalid blocks were punished with a loss o= f bitcoin income...


On Sat, Jul 11, 2015 at 4:05 AM, Nathan Wilcox <nathan@leastauthority.com> wrote:
Thesis: The disincentive miners have for ver= ifying transactions is
problematic and weakens the network's robustn= ess against forks.

According to the 2015-07-04 bitcoin.org alert [1]_ so-called "SPV = Mining"
has become popular across a large portion of miners, and th= is enabled the
consensus-violating forks to persist. Peter Todd provides= an explanation
of the incentive for SPV Mining over in another thread [= 2]_.

.. [1] https://bitcoin.org/en/alert/2015-07-04-spv-= mining#cause

.. [2] https://= www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00404.html

If there is a cost to verifying transactions in a received block, = then
there is an incentive to *not verify transactions*.=C2=A0 However, = this is
balanced by the a risk of mining atop an invalid block.

I= f we imagine all miners verify all transactions, except Charlie the
Chea= pskate, then it's in Charlie's interest to forego transaction
ve= rification.=C2=A0 If all miners make a similar wager, then in the extreme,<= br>no miners verify any transactions, and the expected cost of skipping
= transaction verification becomes very high.

Unfortunately, it's = difficult to measure how many miners are not
validating transactions, si= nce there's no evidence of this until they
mine atop on invalid bloc= k. Because of this, I worry that over time,
more and more miners cut thi= s particular corner, to save on costs.

If true, then the network con= tinues to grow more brittle towards the kind
of forking-persistence beha= vior we saw from the July 4th (and 5th) forks.

This gets weird.=C2= =A0 For example, a malicious miner which suspects a large
fraction of mi= ners are neglecting transaction verification may choose to
forego a bloc= k reward by throwing an erroneous transaction into their
winning block, = then, as all the "SPV Miners" run off along a worthless
chain,= they can reap a higher reward rate due to controlling a larger
network = capacity fraction on the valid chain.

Can we fix this?

--
= Nathan Wilcox
Least Authoritarian

email: nathan@leastauthority.com
twi= tter: @least_nathan

Standard Disclaimer: I'm behind on dev archi= ves, irc logs, bitcointalk,
the wiki...=C2=A0 if this has been discussed= before I appreciate mentions of
that fact.


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--f46d0444e9a5f46d6f051a9b3a15--