Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EB709F31 for ; Tue, 29 Dec 2015 21:51:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EBACF162 for ; Tue, 29 Dec 2015 21:51:29 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id l9so165941879oia.2 for ; Tue, 29 Dec 2015 13:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gQL+2glXuKr+Hh26Wu9hstnGC3uIDuhdYWbE14+7EUg=; b=AKazzpor0lSjImU24KXxUlpt+ZWyv2to7j22CmuFIrJDYqbM85I9PQUYBCE5WRU83F ou+Zxgq8PPboQkvV9JtfjL+byJDBGTWYROCwOIgXK9IkcUDgTbLZFQp+ye61dPRTrJjf aUstglOBBmvqLUD5c6sOUTvz7b8GJ6oO/Q276a4py28hTOKOaO4Ig6eSiyp4OqpsO198 lxS5WDjjIFtxMPYj+bD4w9U5SVKwPGo/JhnCyCfdFoBwWohA+JDE8W5aCoxC1X6odLWk S+OMPHbO/F2qn1TdmYpjucjrRtrz9QzarwJ8xzmCogUmhTqoLrBDKmuUBIPfPsGa523L ZLHg== MIME-Version: 1.0 X-Received: by 10.202.222.193 with SMTP id v184mr37238761oig.15.1451425889336; Tue, 29 Dec 2015 13:51:29 -0800 (PST) Sender: dscotese@gmail.com Received: by 10.60.125.35 with HTTP; Tue, 29 Dec 2015 13:51:29 -0800 (PST) In-Reply-To: References: <20151219184240.GB12893@muck> <4882BD35-D890-4860-9222-5C23AEB6AE89@mattcorallo.com> <20151220044450.GA23942@muck> <20151228191228.GC12298@muck> Date: Tue, 29 Dec 2015 13:51:29 -0800 X-Google-Sender-Auth: J5tjd2MIQEyVPdZTPhH7wJlwABM Message-ID: From: Dave Scotese To: Allen Piscitello Content-Type: multipart/alternative; boundary=001a113d54d48d42430528106c90 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 Subject: Re: [bitcoin-dev] We need to fix the block withholding attack 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: Tue, 29 Dec 2015 21:51:31 -0000 --001a113d54d48d42430528106c90 Content-Type: text/plain; charset=UTF-8 It cannot possibly be enforced. Enforcement is not important when you're setting defaults. In fact, you don't want to enforce defaults, but rather allow anyone who cares to deviate from them to do so. The importance of default behavior is proportional to the number of folks who mess with the defaults, and that, among miners, is pretty small as far as I know, at least in the area of deciding how to decide which block to build on when two show up at nearly the same time. On Tue, Dec 29, 2015 at 11:25 AM, Allen Piscitello < allen.piscitello@gmail.com> wrote: > How could this possibly be enforced? > > On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> There have been no decent objections to altering the block-selection >> mechanism (when two block solutions appear at nearly the same time) as >> described at >> >> http://bitcoin.stackexchange.com/questions/39226 >> >> Key components are: >> >> - Compute BitcoinDaysDestroyed using only transactions that have been >> in your mempool for some time as oBTCDD ("old BTCDD"). >> - Use "nearly the same time" to mean separated in time by your guess >> of the average duration of block propagation times. >> - When two block solutions come in at nearly the same time, build on >> the one that has the most oBTCDD, rather than the one that came in first. >> >> The goal of this change is to reduce the profitability of withholding >> block solutions by severely reducing the chances that a block solved a >> while ago can orphan one solved recently. "Came in first" seems more >> easily gamed than "most oBTCDD". As I wrote there, "*old coins* is >> always a dwindling resource and *global nodes willing to help cheat* is >> probably a growing one." >> >> I will write a BIP if anyone agrees it's a good idea. >> >> On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> Far more concerning is network propagation effects between large and >>>> small miners. For that class of issues, if you are in an environemnt >>>> where selfish mining is possible - a fairly flat, easily DoS/sybil >>>> attacked network topology - the profitability difference between small >>>> and large miners even *without* attacks going on is a hugely worrying >>>> problem. OTOH, if you're blocksize is small enough that propagation time >>>> is negligable to profitability, then selfish mining attacks with <30% >>>> hashing power aren't much of a concern - they'll be naturally defeated >>>> by anti-DoS/anti-sybil measures. >>>> >>> >>> Let's agree that one factor in mining profitability is bandwidth/network >>> reliability/stability. Why focus on that vs electricity contracts or >>> vertically integrated chip manufacturers? Surely, sufficient network >>> bandwidth is a more broadly available commodity than <$0.02/kwh >>> electricity, for example. I'm not sure that your stranded hydroelectric >>> miner is any more desirable than thousands of dorm room miners with access >>> to 10gbit university connections and free electricity. >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> >> -- >> I like to provide some work at no charge to prove my value. Do you need a >> techie? >> I own Litmocracy and Meme Racing >> (in alpha). >> I'm the webmaster for The Voluntaryist >> which now accepts Bitcoin. >> I also code for The Dollar Vigilante . >> "He ought to find it more profitable to play by the rules" - Satoshi >> Nakamoto >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --001a113d54d48d42430528106c90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It cannot possibly be enforced.=C2=A0 Enforcement is = not important when you're setting defaults.=C2=A0 In fact, you don'= t want to enforce defaults, but rather allow anyone who cares to deviate fr= om them to do so.

The importance of default behavior is propor= tional to the number of folks who mess with the defaults, and that, among m= iners, is pretty small as far as I know, at least in the area of deciding h= ow to decide which block to build on when two show up at nearly the same ti= me.

On T= ue, Dec 29, 2015 at 11:25 AM, Allen Piscitello <allen.piscitello@= gmail.com> wrote:
How could this possibly be enforced?

O= n Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
There have been no decent= objections to altering the block-selection mechanism (when two block solut= ions appear at nearly the same time) as described at

http://bit= coin.stackexchange.com/questions/39226

Key components are:=
  • Compute BitcoinDaysDestroyed using only transactions that have = been in your mempool for some time as oBTCDD ("old BTCDD").
    • <= li>Use "nearly the same time" to mean separated in time by your g= uess of the average duration of block propagation times.
  • When t= wo block solutions come in at nearly the same time, build on the one that h= as the most oBTCDD, rather than the one that came in first.

The= goal of this change is to reduce the profitability of withholding block so= lutions by severely reducing the chances that a block solved a while ago ca= n orphan one solved recently.=C2=A0 "Came in first" seems more ea= sily gamed than "most oBTCDD".=C2=A0 As I wrote there, "= old coins is always a dwindling resource and global nodes willing = to help cheat is probably a growing one."

I will write = a BIP if anyone agrees it's a good idea.


On Mon, Dec 28, 2015 at = 12:26 PM, Ivan Brightly via bitcoin-dev <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
On Mon, Dec 28, 2015 at 2:12= PM, Peter Todd via bitcoin-dev=C2=A0<bitcoin-dev@list= s.linuxfoundation.org>=C2=A0wrote:
Far more concerning is network propagation effects between large and
small miners. For that class of issues, if you are in an environemnt
where selfish mining is possible - a fairly flat, easily DoS/sybil
attacked network topology - the profitability difference between small
and large miners even *without* attacks going on is a hugely worrying
problem. OTOH, if you're blocksize is small enough that propagation tim= e
is negligable to profitability, then selfish mining attacks with <30% hashing power aren't much of a concern - they'll be naturally defea= ted
by anti-DoS/anti-sybil measures.

Let's agree that one factor in mining profitability is bandwidth/netwo= rk reliability/stability. Why focus on that vs electricity contracts or ver= tically integrated chip manufacturers? Surely, sufficient network bandwidth= is a more broadly available commodity than <$0.02/kwh electricity, for = example. I'm not sure that your stranded hydroelectric miner is any mor= e desirable than thousands of dorm room miners with access to 10gbit univer= sity connections and free electricity.

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




--
I like to provide some work at no= charge to prove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha). <= br>I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code = for The Dollar Vi= gilante.
"He ought to find it more profitable to play by the ru= les" - Satoshi Nakamoto

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





--
I like to provide some work at no cha= rge to prove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I= 'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for = The Dollar Vigila= nte.
"He ought to find it more profitable to play by the rules&= quot; - Satoshi Nakamoto
--001a113d54d48d42430528106c90--