diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2015-08-22 05:21:22 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-22 03:21:25 +0000 |
| commit | 9c495c6369355b11b4f226b67836fef54f905539 (patch) | |
| tree | 5efc51f6acd32244e9afdc07394cf1a03da3faab | |
| parent | 7f4e570feb1759462a28967e4d8ed7c6222a9370 (diff) | |
| download | pi-bitcoindev-9c495c6369355b11b4f226b67836fef54f905539.tar.gz pi-bitcoindev-9c495c6369355b11b4f226b67836fef54f905539.zip | |
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
| -rw-r--r-- | 54/e9e078be442ce43e07343d9bb77f11bd53c2d9 | 176 |
1 files changed, 176 insertions, 0 deletions
diff --git a/54/e9e078be442ce43e07343d9bb77f11bd53c2d9 b/54/e9e078be442ce43e07343d9bb77f11bd53c2d9 new file mode 100644 index 000000000..07f6aa614 --- /dev/null +++ b/54/e9e078be442ce43e07343d9bb77f11bd53c2d9 @@ -0,0 +1,176 @@ +Return-Path: <jtimon@jtimon.cc> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id BFF2E898 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 22 Aug 2015 03:21:25 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com + [209.85.217.178]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF3AA89 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 22 Aug 2015 03:21:24 +0000 (UTC) +Received: by lbcbn3 with SMTP id bn3so53665750lbc.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 21 Aug 2015 20:21:23 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:to:cc:content-type; + bh=IS0Iz3yDGAg3LHHnSusRNatA4ZzPJ8gNdeQ/BDYYi14=; + b=ECt4fMw4XMuIweG98IvGRpjsOBN8/rx26MvLX1BKfv/7eL+cQbina9paNPgLG0kUff + 7XpZXnVytfRhJODP+xXMG/eAN7xKAH5I6jg9eHzLjfHnshU+XyDXFfW0pIWlUTjDK14B + lG9GlS6gDXiI6s+LPNGe+7nuS3c13Mr8G//yluOO5dECCfi1+ammhhZfvCA4i9MSM9n3 + e/zu6mVvf+63BJqNBBmi95rGcvfmuKZFYsmR/yIeVxgPRU4dK8dwFlDXfXOFoKybneKQ + wCU0RjN4X9Wh4OKT6MjwkBGUZFWT6eyqLZUAiYKLL3LfklWk2pj1g6mnEtWGEEZ4JHly + 3uJA== +X-Gm-Message-State: ALoCoQlx3xbMepG858pPNlzuMEVXbUkUKgs3z2jG/WpjKcehuXqdKg3Hm4dE3KjB0EhF7i4zPbO5 +MIME-Version: 1.0 +X-Received: by 10.112.172.201 with SMTP id be9mr10484342lbc.39.1440213683021; + Fri, 21 Aug 2015 20:21:23 -0700 (PDT) +Received: by 10.25.15.22 with HTTP; Fri, 21 Aug 2015 20:21:22 -0700 (PDT) +Received: by 10.25.15.22 with HTTP; Fri, 21 Aug 2015 20:21:22 -0700 (PDT) +In-Reply-To: <20150822000127.GA5679@muck> +References: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com> + <CAEieSeSw04FYCCa-Df+V6BgJo1RHqPvJWt9t=c-JCC=dnhraWA@mail.gmail.com> + <CABm2gDp0o5DBzuoyZ=SFvnBXTwPYFWhdOqUPkP_M_3koNMVP1g@mail.gmail.com> + <55D5AA8E.7070403@bitcoins.info> <55D67017.9000106@thinlink.com> + <20150821003751.GA19230@muck> <55D7575B.6030505@thinlink.com> + <20150821222153.GD7450@muck> <55D7B157.904@thinlink.com> + <20150822000127.GA5679@muck> +Date: Sat, 22 Aug 2015 05:21:22 +0200 +Message-ID: <CABm2gDrH=Kz1rnrD=T-L81vNr1+gjRe1qcHxj2KQvw6-RWc9CA@mail.gmail.com> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +To: Peter Todd <pete@petertodd.org> +Content-Type: multipart/alternative; boundary=001a11c3888efa3eae051ddde006 +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap +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: Sat, 22 Aug 2015 03:21:25 -0000 + +--001a11c3888efa3eae051ddde006 +Content-Type: text/plain; charset=UTF-8 + +Don't you mean profits instead of revenue? + +On Aug 21, 2015 5:01 PM, "Peter Todd via bitcoin-dev" < +bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote: +> > On 8/21/2015 3:21 PM, Peter Todd wrote: +> > > To use a car analogy, Pieter Wuille has shown that the brake cylinders +> > > have a fatigue problem, and if used in stop-and-go traffic regularly +> > > they'll fail during heavy braking, potentially killing someone. You've +> > > countered with a study of highway driving, showing that if the car is +> > > only used on the highway the brakes have no issues, claiming that the +> > > car design is perfectly safe. +> > +> > No. If we must play the analogy game, it was found that the car crashes +> > when the brakes are bad (minority hash power partitioned) the radio is +> > on (partitioned miners had small individual hashrate). +> > +> > I checked the scenario where only the radio is on, and found the car +> > does not crash. +> +> Incidentally, what's your acceptable revenue difference between a small +> (1% hashing power) and large (%30 hashing power) miner, all else being +> equal? (remember that we shouldn't preclude variance reduction +> techniques such as p2pool and pooled-solo mode) +> +> Equally, what kind of attacks on miners do you think we need to be able to +> resist? E.g. DoS attacks, hacking, etc. +> +> That would let me know if you're definition of "the brakes are bad" +> corresponds to normal usage, or something that's not reasonable to +> design for. +> +> -- +> 'peter'[:-1]@petertodd.org +> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--001a11c3888efa3eae051ddde006 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<p dir=3D"ltr">Don't you mean profits instead of revenue?</p> +<p dir=3D"ltr">On Aug 21, 2015 5:01 PM, "Peter Todd via bitcoin-dev&qu= +ot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de= +v@lists.linuxfoundation.org</a>> wrote:<br> +><br> +> On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:<br> +> > On 8/21/2015 3:21 PM, Peter Todd wrote:<br> +> > > To use a car analogy, Pieter Wuille has shown that the brake= + cylinders<br> +> > > have a fatigue problem, and if used in stop-and-go traffic r= +egularly<br> +> > > they'll fail during heavy braking, potentially killing s= +omeone. You've<br> +> > > countered with a study of highway driving, showing that if t= +he car is<br> +> > > only used on the highway the brakes have no issues, claiming= + that the<br> +> > > car design is perfectly safe.<br> +> ><br> +> > No.=C2=A0 If we must play the analogy game, it was found that the= + car crashes<br> +> > when the brakes are bad (minority hash power partitioned) the rad= +io is<br> +> > on (partitioned miners had small individual hashrate).<br> +> ><br> +> > I checked the scenario where only the radio is on, and found the = +car<br> +> > does not crash.<br> +><br> +> Incidentally, what's your acceptable revenue difference between a = +small<br> +> (1% hashing power) and large (%30 hashing power) miner, all else being= +<br> +> equal? (remember that we shouldn't preclude variance reduction<br> +> techniques such as p2pool and pooled-solo mode)<br> +><br> +> Equally, what kind of attacks on miners do you think we need to be abl= +e to<br> +> resist? E.g. DoS attacks, hacking, etc.<br> +><br> +> That would let me know if you're definition of "the brakes ar= +e bad"<br> +> corresponds to normal usage, or something that's not reasonable to= +<br> +> design for.<br> +><br> +> --<br> +> 'peter'[:-1]@<a href=3D"http://petertodd.org">petertodd.org</a= +><br> +> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d<br> +><br> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> +><br> +</p> + +--001a11c3888efa3eae051ddde006-- + |