diff options
author | Gavin Andresen <gavinandresen@gmail.com> | 2015-06-23 17:24:23 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-23 21:24:26 +0000 |
commit | 22555ec672dc73ca4cb0cf417323a805b6b91ebc (patch) | |
tree | 473c68e0d46175cdc92d4a33fb629ec44455d184 | |
parent | 8416195aeec5459cf05eb93362007b77731a40aa (diff) | |
download | pi-bitcoindev-22555ec672dc73ca4cb0cf417323a805b6b91ebc.tar.gz pi-bitcoindev-22555ec672dc73ca4cb0cf417323a805b6b91ebc.zip |
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
-rw-r--r-- | 77/029257810852b3672c5166c83283f20879d83a | 195 |
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"><<a href=3D"ma= +ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></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'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"">> .= +.. until transaction fees become significant.=C2=A0 But by the time that<br= +> +> happens, protocol optimizations of block propagation will make the blo= +ck<br> +> size an insignificant term in the "how profitable is it to mine i= +n THIS<br> +> particular place on the Internet / part of the world" equation.<b= +r> +<br> +</span>These block propagation improvements are both already implemented (M= +att<br> +Corallo'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'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'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 "Gish= + Gallop" and "Moving the Goalposts" ?<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 "how much do you think is too = +much" 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-- + |