Return-Path: <nathan@leastauthority.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 84F34BC3 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 11 Jul 2015 12:09:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0546163 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 11 Jul 2015 12:09:17 +0000 (UTC) Received: by obbop1 with SMTP id op1so205733780obb.2 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 11 Jul 2015 05:09:17 -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=PmT9M3ixPtsgpb6MEwIzVOjiQ7Wil20nhLjM1RmReNo=; b=d9JKPQHdysqAA6+EPqS0Xw79nAq/FLqst7WAotJkANxY+rSj6I8US9TdmIWR26Rlt6 luwI+sKDSKCU/iKAtk8JN6UXhs27+Z6Z2++ZskxrNXGWrnAHN3npByBMqt7XSMeVjK31 oCOYKs+i2uDp3KTwSfZ4ybM9TFt6DMHTwL131Q7cd+UCdsItZ08ZX2OONPDOHXIB93G9 syd2MHY/R+Vg6aL2xIVHRINai8QlHJa5J4Nb+Qqg1oNYeo/VNq955sA2gtiQ5gD7s/xd yHYnapgWkmnl4IFRJykEzLFutc27IF9NYDF29BAcOt8CqAGpmsW101892Y4wj8cnqyoe UcrA== X-Gm-Message-State: ALoCoQnXN8hBk90eNONlxYKpr6N/kceQVr8DaZsIATpgp8p0wA6uWGMPqJ3stVhAP8n7OvAb/5ND MIME-Version: 1.0 X-Received: by 10.60.83.241 with SMTP id t17mr23649974oey.21.1436616556907; Sat, 11 Jul 2015 05:09:16 -0700 (PDT) Received: by 10.182.47.229 with HTTP; Sat, 11 Jul 2015 05:09:16 -0700 (PDT) In-Reply-To: <CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com> References: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com> <CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com> <CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com> Date: Sat, 11 Jul 2015 05:09:16 -0700 Message-ID: <CAFdHNGj8BXAazAtHZsPe0qwxjRaxn6fQ4G-==bLCqwp+QH09Kg@mail.gmail.com> From: Nathan Wilcox <nathan@leastauthority.com> To: Tier Nolan <tier.nolan@gmail.com> Content-Type: multipart/alternative; boundary=089e0112cd4a8de258051a985b6f X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Sat, 11 Jul 2015 12:09:18 -0000 --089e0112cd4a8de258051a985b6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jul 11, 2015 at 2:24 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote: > All miners should validate transactions precisely because of the latest attack you've described. The problem is one of individual incentives leading to a systemic problem. "All X should do..." solutions which are oblivious to individual incentives don't scale, eg: "If all factories avoid emitting pollution they don't pay for..." does not work if individual factories save their own costs by dumping into the environment. No one wants environmental catastrophe, and no one wants a blockchain where miners don't validate transactions, but there may be a systemic problem of incentives. The bitcoin.org claim that "about half" of miner capacity does SPV Mining, is consistent with the incentives problem as I described it. However, I don't claim the state of mining is certainly due to these incentives and not other incentives we haven't discussed. Also, there may be other incentives that outweigh this issue. On Sat, Jul 11, 2015 at 3:39 AM, Tier Nolan <tier.nolan@gmail.com> wrote: > > > On Sat, Jul 11, 2015 at 10:24 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro= te: > >> 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 t= ake >> so long anyway), even if this slightly increases the orphan rate. > > > Increased orphan rate means that the network is (slightly) less secure. > > If miners have a 5% orphan rate, then an attacker can launch a 51% attack > with 49% of the network. > > It isn't a massive difference, but it is there. > > As long as miners switch back to non-SPV mining after a timeout, > SPV-mining is safe for everyone. > > If there's any cost to non-SPV mining, and the chance that an incoming block contains only valid transactions is very high, isn't there still an incentive to make this timeout longer and longer? The average cost to the miner from building on an invalid block is small, > as long as invalid blocks only happen rarely. > > Yes. If it's rare enough, then skipping transaction validation saves more cost than the expected cost of mining atop an invalid block. ... but if everyone follows that logic, the chance is no longer rare. > Miners still have an incentive to do full validation, so that they can > include transactions and get transaction fees. > > This is a good point. If the benefit to skipping verification outweighs expected transaction costs, then a non-validating miner might also choose to mine empty blocks with only their coinbase. (I recall hearing this occurred somewhat regularly around 2013, but I haven't paid attention since then. How common are empty blocks these days?) This is a benefit of the world where transaction fees approach or surpass block reward. SPV-mining is to prevent hashing hardware from having to waste power when > it isn't needed. > > It may be less of a problem if (when?) electricity costs dominate hardware > capital costs. > Oh. This is a different explanation than Peter Todd's I linked to above, which claimed it was network latency in receiving transactions. Could you explain this a bit more? What is not needed, the hashing hardware or the power? How does SPV Mining affect that? I'll bet there are many individual rationales for SPV-Mining, but ultimately they come down to dropping a cost based on a bet about other miners' behavior. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --=20 Nathan Wilcox Least Authoritarian email: nathan@leastauthority.com twitter: @least_nathan --089e0112cd4a8de258051a985b6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br>On Sat, Jul 11, 2015 at 2:24 AM, Jorge Tim=C3=B3n <spa= n dir=3D"ltr"><<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jti= mon@jtimon.cc</a>></span> wrote:<br>> All miners should validate tran= sactions precisely because of the latest attack you've described.<div c= lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The problem is on= e of individual incentives leading to a systemic problem.=C2=A0 "All X= should do..." solutions which are oblivious to individual incentives = don't scale, eg: "If all factories avoid emitting pollution they d= on't pay for..." does not work if individual factories save their = own costs by dumping into the environment.=C2=A0 No one wants environmental= catastrophe, and no one wants a blockchain where miners don't validate= transactions, but there may be a systemic problem of incentives.<br></div>= <div class=3D"gmail_extra"><br>The <a href=3D"http://bitcoin.org">bitcoin.o= rg</a> claim that "about half" of miner capacity does SPV Mining,= is consistent with the incentives problem as I described it.=C2=A0 However= , I don't claim the state of mining is certainly due to these incentive= s and not other incentives we haven't discussed.=C2=A0 Also, there may = be other incentives that outweigh this issue.<br></div><br><div class=3D"gm= ail_extra"><br><div class=3D"gmail_quote">On Sat, Jul 11, 2015 at 3:39 AM, = Tier Nolan <span dir=3D"ltr"><<a href=3D"mailto:tier.nolan@gmail.com" ta= rget=3D"_blank">tier.nolan@gmail.com</a>></span> wrote:<br><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gma= il_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Sat, Jul 11, 2= 015 at 10:24 AM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D"mailto:j= timon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde= r-left:1px solid rgb(204,204,204);padding-left:1ex">I think it would be mor= e rational for them to keep mining on top of the old block until they'v= e fully validated the new block (which shouldn't take so long anyway), = even if this slightly increases the orphan rate. </blockquote><div><br></div></span><div>Increased orphan rate means that th= e network is (slightly) less secure.<br></div><div><br></div><div>If miners= have a 5% orphan rate, then an attacker can launch a 51% attack with 49% o= f the network.<br><br></div><div>It isn't a massive difference, but it = is there.<br><br></div><div>As long as miners switch back to non-SPV mining= after a timeout, SPV-mining is safe for everyone.<br><br></div></div></div= ></div></blockquote><div><br></div><div>If there's any cost to non-SPV = mining, and the chance that an incoming block contains only valid transacti= ons is very high, isn't there still an incentive to make this timeout l= onger and longer?<br></div><div>=C2=A0<br><br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div= class=3D"gmail_quote"><div></div><div>The average cost to the miner from b= uilding on an invalid block is small, as long as invalid blocks only happen= rarely.<br></div><br></div></div></div></blockquote><div><br></div><div>Ye= s. If it's rare enough, then skipping transaction validation saves more= cost than the expected cost of mining atop an invalid block.=C2=A0 ... but= if everyone follows that logic, the chance is no longer rare.<br></div><di= v><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">= </div>Miners still have an incentive to do full validation, so that they ca= n include transactions and get transaction fees.<br><br></div></div></block= quote><div><br></div><div>This is a good point.=C2=A0 If the benefit to ski= pping verification outweighs expected transaction costs, then a non-validat= ing miner might also choose to mine empty blocks with only their coinbase.= =C2=A0 (I recall hearing this occurred somewhat regularly around 2013, but = I haven't paid attention since then.=C2=A0 How common are empty blocks = these days?)<br><br></div><div>This is a benefit of the world where transac= tion fees approach or surpass block reward.<br></div><div><br><br></div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class= =3D"gmail_extra"></div><div>SPV-mining is to prevent hashing hardware from = having to waste power when it isn't needed.<br>=C2=A0</div></div></bloc= kquote><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"><div dir=3D"l= tr"><div class=3D"gmail_extra">It may be less of a problem if (when?) elect= ricity costs dominate hardware capital costs.<br></div></div></blockquote><= div>=C2=A0</div></div><div>Oh.=C2=A0 This is a different explanation than P= eter Todd's I linked to above, which claimed it was network latency in = receiving transactions.<br><br>Could you explain this a bit more?=C2=A0 Wha= t is not needed, the hashing hardware or the power?=C2=A0 How does SPV Mini= ng affect that?<br><br></div><div>I'll bet there are many individual ra= tionales for SPV-Mining, but ultimately they come down to dropping a cost b= ased on a bet about other miners' behavior.<br></div><div class=3D"gmai= l_quote"><br><br><br><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex"> <br>_______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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> <br></blockquote></div></div><br><br clear=3D"all"><br>-- <br><div class=3D= "gmail_signature"><div dir=3D"ltr"><div class=3D"gmail_signature">Nathan Wi= lcox<br>Least Authoritarian<br><br>email: <a href=3D"mailto:nathan@leastaut= hority.com" target=3D"_blank">nathan@leastauthority.com</a><br>twitter: @le= ast_nathan<br></div></div></div> </div></div> --089e0112cd4a8de258051a985b6f--