summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGavin Andresen <gavinandresen@gmail.com>2015-06-23 17:24:23 -0400
committerbitcoindev <bitcoindev@gnusha.org>2015-06-23 21:24:26 +0000
commit22555ec672dc73ca4cb0cf417323a805b6b91ebc (patch)
tree473c68e0d46175cdc92d4a33fb629ec44455d184
parent8416195aeec5459cf05eb93362007b77731a40aa (diff)
downloadpi-bitcoindev-22555ec672dc73ca4cb0cf417323a805b6b91ebc.tar.gz
pi-bitcoindev-22555ec672dc73ca4cb0cf417323a805b6b91ebc.zip
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
-rw-r--r--77/029257810852b3672c5166c83283f20879d83a195
1 files changed, 195 insertions, 0 deletions
diff --git a/77/029257810852b3672c5166c83283f20879d83a b/77/029257810852b3672c5166c83283f20879d83a
new file mode 100644
index 000000000..14fe5863c
--- /dev/null
+++ b/77/029257810852b3672c5166c83283f20879d83a
@@ -0,0 +1,195 @@
+Return-Path: <gavinandresen@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 82931273
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ 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 <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 23 Jun 2015 21:24:25 +0000 (UTC)
+Received: by lacny3 with SMTP id ny3so14607697lac.3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ 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: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
+ <20150623192838.GG30235@muck>
+ <CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
+ <20150623204646.GA18677@muck>
+Date: Tue, 23 Jun 2015 17:24:23 -0400
+Message-ID: <CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com>
+From: Gavin Andresen <gavinandresen@gmail.com>
+To: Peter Todd <pete@petertodd.org>
+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 <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: 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 <pete@petertodd.org> 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
+
+<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
+ue, Jun 23, 2015 at 4:46 PM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"ma=
+ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span=
+> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
+rder-left:1px #ccc solid;padding-left:1ex">Pieter Wuille showed with simula=
+tions that miners with bad connectivity<br>
+are negatively affected by other miners creating larger blocks.<br></blockq=
+uote><div><br></div><div>... 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&#39;re creating blocks that will propagate quickly=
+ on both sides of the bottleneck).</div><div><br></div><div><br></div><div>=
+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.</div><div><br></div=
+><div>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.</div><div><br>=
+</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
+0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; .=
+.. until transaction fees become significant.=C2=A0 But by the time that<br=
+>
+&gt; happens, protocol optimizations of block propagation will make the blo=
+ck<br>
+&gt; size an insignificant term in the &quot;how profitable is it to mine i=
+n THIS<br>
+&gt; particular place on the Internet / part of the world&quot; equation.<b=
+r>
+<br>
+</span>These block propagation improvements are both already implemented (M=
+att<br>
+Corallo&#39;s relay network, p2pool) and require co-operation.<br></blockqu=
+ote><div><br></div><div>Long term the p2p protocol will evolve to incorpora=
+te those optimizations, so will require no co-operation.</div><div><br></di=
+v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
+.8ex;border-left:1px #ccc solid;padding-left:1ex">For instance, notice the =
+recent full-RBF debate where Coinbase said<br>
+they&#39;d consider getting contracts directly with miners to get<br>
+transactions they desired mined even when they otherwise would not be<br>
+due to double-spends. This is one of many scenarios where block<br>
+propagation improvements fail. Thus for a safety engineering<br>
+analysis we need to talk about worst-case scenarioss</blockquote><div>=C2=
+=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
+r-left:1px #ccc solid;padding-left:1ex">
+Equally, I don&#39;t see any analysis from anyone of that % of non-optimize=
+d<br>
+transactions need to fail for what kind of centralizing pressure.<br>
+<br>
+In any case, this ponts to the need for your proposal to explictly talk<br>
+about what kind of resources are needed by miners for what kind of<br>
+profitability, including the case where other miners are sabotaging<br>
+their profitability.<br>
+<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote></div><div=
+ class=3D"gmail_extra"><br></div>Are you familiar with the terms &quot;Gish=
+ Gallop&quot; and &quot;Moving the Goalposts&quot; ?<br><br>I have written =
+quite a lot about the kind of resources needed to run a full node, and have=
+ asked you, specifically, several times &quot;how much do you think is too =
+much&quot; and received no answer.<br clear=3D"all"><div><br></div>-- <br><=
+div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
+</div></div>
+
+--001a1133d13ca69d63051936034c--
+