Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2EA93BC3 for ; Mon, 13 Jul 2015 17:49:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0F395145 for ; Mon, 13 Jul 2015 17:49:42 +0000 (UTC) Received: by lagw2 with SMTP id w2so18996956lag.3 for ; Mon, 13 Jul 2015 10:49:40 -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=Iwfepl3n6DXXWqkrzqlf3xp/x5Hhc7x7OfzCS0+xFM8=; b=KlT2CatKlC4lNyTpYf8vkHccKjnZ37i09K0OMh4hHWNG5XsCiLvnIUnsQ2Nw7894zH Ih0G+zGXMpPiFDEseYct/oJilaep8GUz++hN8ZPST3rpe59RVT2Bsx2t4ka7QfcE4z6L ohAdt2FzgV3CXrZ6mw66Pd/edOhcwTGgh37fWtLZR43omJG64vzWFN6zmF1YLla5trvs DsrRMx5CqlyOItg6mpcSblDoehTbwRZImWuGCdWJrCQbMT3+FTsT2REH5ct64Ppv3fNl ZCFHruTQpODrH2X51lcsOsst8RfqKUdoKs2s3d5Qp80J2ynP9UXxx7NWrOTBJ1dem89D 0Pow== MIME-Version: 1.0 X-Received: by 10.112.219.200 with SMTP id pq8mr18274332lbc.110.1436809780437; Mon, 13 Jul 2015 10:49:40 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Mon, 13 Jul 2015 10:49:40 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Mon, 13 Jul 2015 10:49:40 -0700 (PDT) In-Reply-To: <20150713160453.GB19337@savin.petertodd.org> References: <20150713160453.GB19337@savin.petertodd.org> Date: Mon, 13 Jul 2015 10:49:40 -0700 Message-ID: From: Eric Lombrozo To: Peter Todd Content-Type: multipart/alternative; boundary=001a11c25ca692aa46051ac55835 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: Mon, 13 Jul 2015 17:49:43 -0000 --001a11c25ca692aa46051ac55835 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My other email client messed up. I apologize for the blank message. Anyhow... Even though the cost of mining bad blocks is high enough to deter most deliberate attacks, if we're not properly validating blocks, this deterrence does not stop bugs nor version issues and it opens up attack vectors like someone hacking into a mining pool server. It is imperative we continue to look for ways to make secure validation cheaper. I would make this #1 priority. Not only is it crucial to the integrity of our security model - it is crucial for scalability and decentralization as well. - Eric Lombrozo On Jul 13, 2015 11:05 AM, "Peter Todd" wrote: > On Sat, Jul 11, 2015 at 11:24:48AM +0200, Jorge Tim=C3=B3n wrote: > > 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 make= s > 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. > > You're missing something really critical about what F2Pool/AntPool were > (are?) doing: They're finding out about new blocks not by getting block > headers from just anywhere, but by connecting to other pools' via > stratum anonymously and determining what block hash they're telling the > hashers at the pool to work on. (e.g. what prevblockhash is in the block > header of shares being generated) > > If other pools try to fake this information they're immediately and > directly losing money, because they're telling their own hashers to make > invalid blocks. This of course has a high chance of being detected, and > can easily be FUDed into "STOP MINING AT FOO POOL!" reardless of what > the ivory tower game theory might say. The only hope the pools have is > to somehow identify which connections correspond to other pools with > high reliability and target just those connections - good luck on that. > > > Anyway, all this concern about SPV mining is misguided: relying purely > on SPV w/ low #'s of confirmations just isn't very smart. What SPV can > do - at least while the inflation subsidy is still high - is give > reasonable protection against your third-party-run trusted full nodes > from lying to you, simply because doing so has well-defined costs in > terms of energy to create fake blocks. Targetting enough people at once > to make a fake block a worthwhile investment is difficult, particularly > when you take into account how timing works in the defenders favor - the > attacker probably only has a small % of hashing power, so they're going > to wait a long time to find their fake block. Between that and a trusted > third party-run full node you're probably reasonably safe, for now. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000086007e31decd6eb80e07f77271ef50c69e1e6342161f4e5 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11c25ca692aa46051ac55835 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

My other email client messed up. I apologize for the blank m= essage.

Anyhow...

Even though the cost of mining bad blocks is high enough to = deter most deliberate attacks, if we're not properly validating blocks,= this deterrence does not stop bugs nor version issues and it opens up atta= ck vectors like someone hacking into a mining pool server.

It is imperative we continue to look for ways to make secure= validation cheaper. I would make this #1 priority. Not only is it crucial = to the integrity of our security model - it is crucial for scalability and = decentralization as well.

- Eric Lombrozo

On Jul 13, 2015 11:05 AM, "Peter Todd"= <pete@petertodd.org> wrote= :
On Sat, Jul 11, 20= 15 at 11:24:48AM +0200, Jorge Tim=C3=B3n wrote:
> All miners should validate transactions precisely because of the lates= t
> attack you've described. Full miners can gain a lot from this atta= ck to
> leverage their full validation against spv miners who blindly spend en= ergy
> hashing on top of something that may be worthless crap. SPV mining mak= es no
> sense, but some miners claim they're doind it for very short perio= ds 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 th= e old
> block until they've fully validated the new block (which shouldn&#= 39;t take so
> long anyway), even if this slightly increases the orphan rate.

You're missing something really critical about what F2Pool/AntPool were=
(are?) doing: They're finding out about new blocks not by getting block=
headers from just anywhere, but by connecting to other pools' via
stratum anonymously and determining what block hash they're telling the=
hashers at the pool to work on. (e.g. what prevblockhash is in the block header of shares being generated)

If other pools try to fake this information they're immediately and
directly losing money, because they're telling their own hashers to mak= e
invalid blocks. This of course has a high chance of being detected, and
can easily be FUDed into "STOP MINING AT FOO POOL!" reardless of = what
the ivory tower game theory might say. The only hope the pools have is
to somehow identify which connections correspond to other pools with
high reliability and target just those connections - good luck on that.


Anyway, all this concern about SPV mining is misguided: relying purely
on SPV w/ low #'s of confirmations just isn't very smart. What SPV = can
do - at least while the inflation subsidy is still high - is give
reasonable protection against your third-party-run trusted full nodes
from lying to you, simply because doing so has well-defined costs in
terms of energy to create fake blocks. Targetting enough people at once
to make a fake block a worthwhile investment is difficult, particularly
when you take into account how timing works in the defenders favor - the attacker probably only has a small % of hashing power, so they're going=
to wait a long time to find their fake block. Between that and a trusted third party-run full node you're probably reasonably safe, for now.

--
'peter'[:-1]@petertodd.org
0000000000000000086007e31decd6eb80e07f77271ef50c69e1e6342161f4e5

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

--001a11c25ca692aa46051ac55835--