Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 82931273 for ; Tue, 23 Jun 2015 21:24:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79E34118 for ; Tue, 23 Jun 2015 21:24:25 +0000 (UTC) Received: by lacny3 with SMTP id ny3so14607697lac.3 for ; Tue, 23 Jun 2015 14:24:23 -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=ArbjCaYZPa/P8UZROjmm/99eHsK14JvohnbtZbI+t/A=; b=YI0074u5fNIQztBUKI6LNoqZ1OXdXCCLBmJfBXhv13HXkfwTLPNCAmKm81a5DXoXjM cq5IOMKTTIJq+TGc17Ph5EzTd9pm41yB2UReG+9VI38FX+wc7A7enXfbwV0u0bFbdhrR TrVy8Gv9zJItyQHroVp4Jch/IOB5mgHMvL1B4UABoORhXLQCx0SdxkoGeQjaRqvBQUIy IscgI0DXyAIYb3F6CwtZVeyMYb2SjbubG0GEVa3z5rHl0JDAZ/7FUPWWIEqtBWaqM3kE 9tVyJDQz/xkjSSaLjCsbSJ6HaAicno1qva+P0QHpeRBXtQFHzgOy5pUqWIZCrzgdU5on XpQg== MIME-Version: 1.0 X-Received: by 10.112.55.70 with SMTP id q6mr35255767lbp.99.1435094663730; Tue, 23 Jun 2015 14:24:23 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Tue, 23 Jun 2015 14:24:23 -0700 (PDT) In-Reply-To: <20150623204646.GA18677@muck> References: <20150623192838.GG30235@muck> <20150623204646.GA18677@muck> Date: Tue, 23 Jun 2015 17:24:23 -0400 Message-ID: From: Gavin Andresen To: Peter Todd Content-Type: multipart/alternative; boundary=001a1133d13ca69d63051936034c 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] Draft BIP : fixed-schedule block size increase 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, 23 Jun 2015 21:24:26 -0000 --001a1133d13ca69d63051936034c Content-Type: text/plain; charset=UTF-8 On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd wrote: > Pieter Wuille showed with simulations that miners with bad connectivity > are negatively affected by other miners creating larger blocks. > ... but the effect is only significant if they have an absurdly low-bandwidth connection and do NOTHING to work around it (like rent a server on the other side of the bandwidth bottleneck and write some code to make sure you're creating blocks that will propagate quickly on both sides of the bottleneck). Why do you think connectivity is a centralizing effect? It is just one factor in the profitability-of-mining equation. A location with bad connectivity (the US, maybe) but 10% cheaper electricity might be just as good as one with great connectivity but more expensive electricity. Having lots of variables in the profitability equation is a decentralizing force, it means there is very likely to be several different places in the world / on the net where mining is equally profitable. > ... until transaction fees become significant. But by the time that > > happens, protocol optimizations of block propagation will make the block > > size an insignificant term in the "how profitable is it to mine in THIS > > particular place on the Internet / part of the world" equation. > > These block propagation improvements are both already implemented (Matt > Corallo's relay network, p2pool) and require co-operation. > Long term the p2p protocol will evolve to incorporate those optimizations, so will require no co-operation. > For instance, notice the recent full-RBF debate where Coinbase said > they'd consider getting contracts directly with miners to get > transactions they desired mined even when they otherwise would not be > due to double-spends. This is one of many scenarios where block > propagation improvements fail. Thus for a safety engineering > analysis we need to talk about worst-case scenarioss > Equally, I don't see any analysis from anyone of that % of non-optimized > transactions need to fail for what kind of centralizing pressure. > > In any case, this ponts to the need for your proposal to explictly talk > about what kind of resources are needed by miners for what kind of > profitability, including the case where other miners are sabotaging > their profitability. > Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ? I have written quite a lot about the kind of resources needed to run a full node, and have asked you, specifically, several times "how much do you think is too much" and received no answer. -- -- Gavin Andresen --001a1133d13ca69d63051936034c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@petertodd.org> wrote:
Pieter Wuille showed with simula= tions that miners with bad connectivity
are negatively affected by other miners creating larger blocks.

... but the effect is only significant if they hav= e an absurdly low-bandwidth connection and do NOTHING to work around it (li= ke rent a server on the other side of the bandwidth bottleneck and write so= me code to make sure you're creating blocks that will propagate quickly= on both sides of the bottleneck).


= Why do you think connectivity is a centralizing effect? It is just one fact= or in the profitability-of-mining equation. A location with bad connectivit= y (the US, maybe) but 10% cheaper electricity might be just as good as one = with great connectivity but more expensive electricity.

Having lots of variables in the profitability equation is a decentral= izing force, it means there is very likely to be several different places i= n the world / on the net where mining is equally profitable.

=

> .= .. until transaction fees become significant.=C2=A0 But by the time that > happens, protocol optimizations of block propagation will make the blo= ck
> size an insignificant term in the "how profitable is it to mine i= n THIS
> particular place on the Internet / part of the world" equation.
These block propagation improvements are both already implemented (M= att
Corallo's relay network, p2pool) and require co-operation.

Long term the p2p protocol will evolve to incorpora= te those optimizations, so will require no co-operation.

=C2=A0
For instance, notice the = recent full-RBF debate where Coinbase said
they'd consider getting contracts directly with miners to get
transactions they desired mined even when they otherwise would not be
due to double-spends. This is one of many scenarios where block
propagation improvements fail. Thus for a safety engineering
analysis we need to talk about worst-case scenarioss
=C2= =A0
Equally, I don't see any analysis from anyone of that % of non-optimize= d
transactions need to fail for what kind of centralizing pressure.

In any case, this ponts to the need for your proposal to explictly talk
about what kind of resources are needed by miners for what kind of
profitability, including the case where other miners are sabotaging
their profitability.

Are you familiar with the terms "Gish= Gallop" and "Moving the Goalposts" ?

I have written = quite a lot about the kind of resources needed to run a full node, and have= asked you, specifically, several times "how much do you think is too = much" and received no answer.

--
<= div class=3D"gmail_signature">--
Gavin Andresen
--001a1133d13ca69d63051936034c--