From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BFF2E898 for ; 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 ; Sat, 22 Aug 2015 03:21:24 +0000 (UTC) Received: by lbcbn3 with SMTP id bn3so53665750lbc.2 for ; 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: <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: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Peter Todd 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

Don't you mean profits instead of revenue?

On Aug 21, 2015 5:01 PM, "Peter Todd via bitcoin-dev&qu= ot; <bitcoin-de= v@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 r= egularly
> > > they'll fail during heavy braking, potentially killing s= omeone. You've
> > > countered with a study of highway driving, showing that if t= he car is
> > > only used on the highway the brakes have no issues, claiming= that the
> > > car design is perfectly safe.
> >
> > No.=C2=A0 If we must play the analogy game, it was found that the= car crashes
> > when the brakes are bad (minority hash power partitioned) the rad= io 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 abl= e to
> resist? E.g. DoS attacks, hacking, etc.
>
> That would let me know if you're definition of "the brakes ar= e 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@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a11c3888efa3eae051ddde006--