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 E14F0484 for ; Fri, 31 Jul 2015 21:43:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DD9DB169 for ; Fri, 31 Jul 2015 21:43:45 +0000 (UTC) Received: by lafd3 with SMTP id d3so52050832laf.1 for ; Fri, 31 Jul 2015 14:43:44 -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=1eX/N8WwM6+xwoueUAChbUnlq7hHg5p+gBs7FvZYdfc=; b=wj4DDMJNjVFjuJqgsol+7UuPyJFH0tcebeRDGwL36rL68clrqCcHBD0c6LOfqStTmM eBu3jUzPF9y8ecpRE5JvGqeMenAxgG+2OWIMUplza0imXF0xW4S6DRUoIz6ldALVgPmh /3M9CEBy/SkkYJafN+yEs8KhaQTkMM2AScptWiVf0xuE/zUp7B5er+AwTNXxvA4BiYpH aUyQg2VDHaTDaGFvBD7G2wHnEg+0zUbEHMZeKDjLUgEK6KZSqaEKg/0eBIFdaqNePYxn r5Bv1d/r5cRrW8GX6DBUDhJyacUPf/qeaPNfjdobrgcUKhWAugmcZTCyDE7Kkn/X83k2 vhIw== MIME-Version: 1.0 X-Received: by 10.152.5.65 with SMTP id q1mr5486065laq.110.1438379024183; Fri, 31 Jul 2015 14:43:44 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 14:43:43 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 14:43:43 -0700 (PDT) In-Reply-To: References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org> <55B94FAD.7040205@mail.bihthai.net> <74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com> <25FD9AAD-99F5-4322-AF34-243F75AE82C4@gmail.com> <55BABE17.7050900@bitcoins.info> Date: Fri, 31 Jul 2015 14:43:43 -0700 Message-ID: From: Eric Lombrozo To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=089e013d1754c9f764051c32b61f 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: Jean-Paul Kogelman via bitcoin-dev Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary 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: Fri, 31 Jul 2015 21:43:47 -0000 --089e013d1754c9f764051c32b61f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I generally agree with this as well. I think it is crucial we avoid controversial hardforks. The risks greatly outweigh the benefits. This is a good start to making it less controversial. - Eric On Jul 31, 2015 2:31 PM, "Jorge Tim=C3=B3n" < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev > wrote: > > These are the types of things I have been discussing in relation to a > > process: > > > > -A list of metrics > > -A Risk analysis of the baseline system. Bitcoin as it is now. > > -Mitigation strategies for each risk. > > -A set of goals. > > -A Road map for each goal that lists the changes or possible avenues to > > achieve that goal. > > > > Proposed changes would be measured against the same metrics and a risk > > analysis done so it can be compared with the baseline. > > > > For example, the block size debate would be discussed in the context of= a > > road map related to a goal of increase scaling. One of the metrics > would be > > a decentralization metric. (A framework for a decentralization metric > is at > > > http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider= _Decentralization.pdf > ). > > Cost would be one aspect of the decentralization metric. > > All this sounds very reasonable and useful. > And if a formal organization owns this "process", that's fine as well. > I still think hardforks need to be uncontroversial (using the vague "I > will know it when I see it" defintion) and no individual or > organization can be an "ultimate decider" or otherwise Bitcoin losses > all it's p2p nature (and this seems the point where you, Milly, and I > disagree). > But metrics and data tend to help when it comes to "I will know it > when I see it" and "evidences". > So, yes, by all means, let's have an imperfect decentralization metric > rather than not having anything to compare proposals. Competing > decentralization metrics can appear later: we need a first one first. > I would add that we should have sets of simulations being used to > calculate some of those metrics, but maybe I'm just going too deep > into details. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --089e013d1754c9f764051c32b61f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I generally agree with this as well. I think it is crucial w= e avoid controversial hardforks. The risks greatly outweigh the benefits.

This is a good start to making it less controversial.

- Eric

On Jul 31, 2015 2:31 PM, "Jorge Tim=C3=B3n&= quot; <bitcoin-= dev@lists.linuxfoundation.org> wrote:
On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via= bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> These are the types of things I have been discussing in relation to a<= br> > process:
>
> -A list of metrics
> -A Risk analysis of the baseline system.=C2=A0 Bitcoin as it is now. > -Mitigation strategies for each risk.
> -A set of goals.
> -A Road map for each goal that lists the changes or possible avenues t= o
> achieve that goal.
>
> Proposed changes would be measured against the same metrics and a risk=
> analysis done so it can be compared with the baseline.
>
> For example, the block size debate would be discussed in the context o= f a
> road map related to a goal of increase scaling.=C2=A0 One of the metri= cs would be
> a decentralization metric.=C2=A0 (A framework for a decentralization m= etric is at
> h= ttp://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_De= centralization.pdf).
> Cost would be one aspect of the decentralization metric.

All this sounds very reasonable and useful.
And if a formal organization owns this "process", that's fine= as well.
I still think hardforks need to be uncontroversial (using the vague "I=
will know it when I see it" defintion) and no individual or
organization can be an "ultimate decider" or otherwise Bitcoin lo= sses
all it's p2p nature (and this seems the point where you, Milly, and I disagree).
But metrics and data tend to help when it comes to "I will know it
when I see it" and "evidences".
So, yes, by all means, let's have an imperfect decentralization metric<= br> rather than not having anything to compare proposals. Competing
decentralization metrics can appear later: we need a first one first.
I would add that we should have sets of simulations being used to
calculate some of those metrics, but maybe I'm just going too deep
into details.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--089e013d1754c9f764051c32b61f--