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 AB16BABF for ; Sat, 11 Jul 2015 09:24:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4BFC711A for ; Sat, 11 Jul 2015 09:24:49 +0000 (UTC) Received: by wgov12 with SMTP id v12so80656622wgo.1 for ; Sat, 11 Jul 2015 02:24:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qJ3RFlMHQsmotnkukXpeRVNGbjK154NySR3kGic2KXM=; b=dXcUgWa7d/juW6AJjmwYrMSgl+bSsurNOLR6SOHGbZKXGoS01rZ4KcoCGPGMFpRBjR KsioTO59zyJTsiDecqmBrQLIiyCLLk9K3yU8hCJnrZA8wNHdQpinrIeta84aIkYBwk+a QzmCuq5KM7A8Z946HyNqWOgEKR1l+HG3DrIH7fcSsRqbcYLw03fOtCwsMOTMDNC2Jz75 fdZSAbCTHTsPYuD4I/yKD/bl+2YuV0EbEU/mturI7XwoTIkB44tct2S2rNG3XWK6aaOe uFaMJAlp4KT2Lkvred0LKiGevD9FYZ6R91HfI6DfLuoKhr7bqlTiAKlb4Gq1qdTChnuf dGFw== X-Gm-Message-State: ALoCoQlUcV+b4anStRPV9jPBjFvekyTDfM3g/0WPkGgF2lriyIclVoXUSb9L4hNRRBXCZeptGEk1 MIME-Version: 1.0 X-Received: by 10.180.80.229 with SMTP id u5mr5144829wix.92.1436606688449; Sat, 11 Jul 2015 02:24:48 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Sat, 11 Jul 2015 02:24:48 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Sat, 11 Jul 2015 02:24:48 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Jul 2015 11:24:48 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Nathan Wilcox Content-Type: multipart/alternative; boundary=f46d04428e4058eb9c051a960fe7 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 09:24:51 -0000 --f46d04428e4058eb9c051a960fe7 Content-Type: text/plain; charset=UTF-8 All miners should validate transactions precisely because of the latest attack you've described. Full miners can gain a lot from this attack to leverage their full validation against spv miners who blindly spend energy hashing on top of something that may be worthless crap. SPV mining makes no sense, but some miners claim they're doind it for very short periods of time, which shouldn't be as bad as doing it all the time. I think it would be more rational for them to keep mining on top of the old block until they've fully validated the new block (which shouldn't take so long anyway), even if this slightly increases the orphan rate. On Jul 11, 2015 10: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 > > --f46d04428e4058eb9c051a960fe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

All miners should validate transactions precisely because of= the latest attack you've described. Full miners can gain a lot from th= is attack to leverage their full validation against spv miners who blindly = spend energy hashing on top of something that may be worthless crap. SPV mi= ning makes no sense, but some miners claim they're doind it for very sh= ort periods of time, which shouldn't be as bad as doing it all the time= .

I think it would be more rational for them to keep mining on= top of the old block until they've fully validated the new block (whic= h shouldn't take so long anyway), even if this slightly increases the o= rphan rate.

On Jul 11, 2015 10:05 AM, "Nathan Wilcox&qu= ot; <nathan@leastauthority.= com> wrote:
<= div dir=3D"ltr">Thesis: The disincentive miners have for verifying transact= ions is
problematic and weakens the network's robustness against for= ks.

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<= br>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-archiv= e.com/bitcoin-dev@lists.linuxfoundation.org/msg00404.html

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

If we imagine al= l miners verify all transactions, except Charlie the
Cheapskate, then it= 's in Charlie's interest to forego transaction
verification.=C2= =A0 If all miners make a similar wager, then in the extreme,
no miners v= erify any transactions, and the expected cost of skipping
transaction ve= rification becomes very high.

Unfortunately, it's difficult to m= easure 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 c= orner, to save on costs.

If true, then the network continues to grow= more brittle towards the kind
of forking-persistence behavior we saw fr= om the July 4th (and 5th) forks.

This gets weird.=C2=A0 For example,= a malicious miner which suspects a large
fraction of miners are neglect= ing transaction verification may choose to
forego a block reward by thro= wing 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 fractio= n on the valid chain.

Can we fix this?

--
Nathan WilcoxLeast Authoritarian

email: nathan@leastauthority.com
twitter: @least_nat= han

Standard Disclaimer: I'm behind on dev archives, irc logs, b= itcointalk,
the wiki...=C2=A0 if this has been discussed before I apprec= iate mentions of
that fact.


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

--f46d04428e4058eb9c051a960fe7--