path: root/40/926def49f334bce06b124b21e90474e4d085c8

Return-Path: <milly@bitcoins.info>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 764C9AF3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 26 Jun 2015 00:42:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.help.org (mail.help.org [70.90.2.18])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B107F4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 26 Jun 2015 00:42:21 +0000 (UTC)
Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA
	; Thu, 25 Jun 2015 20:42:17 -0400
To: bitcoin-dev@lists.linuxfoundation.org
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>
	<558B4632.8080504@bitcoins.info>
	<CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
	<CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com>
From: Milly Bitcoin <milly@bitcoins.info>
Message-ID: <558C9FE3.6000804@bitcoins.info>
Date: Thu, 25 Jun 2015 20:42:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------050404030803010903050601"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
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: Fri, 26 Jun 2015 00:42:23 -0000

This is a multi-part message in MIME format.
--------------050404030803010903050601
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

That description makes sense.  It also makes sense to separate out the 
hard fork from the soft fork process.   Right now some people want to 
use the soft fork procedure for a hard fork simply because there is no 
other way to do it.

I am under the impression that most users expect changes/improvements 
that would require a hard fork so I think some kind of process needs to 
be developed.  Taking the responsibility off the shoulder of the core 
maintainer also makes sense.  The hard fork issue is too much of a 
distraction for people trying to maintain the nuts and bolts of the 
underlying system.

I saw a suggestion that regularly scheduled hard forks should be 
planned.  That seems to make sense so you would have some sort of 
schedule where you would have cut off dates for hard-fork BIP 
submissions.  That way you avoid the debates over whether there should 
be hard forks to what should be contained within the hard fork (if 
needed).  It makes sense to follow the BIP process as close as 
possible.  Possibly adding another step after "Dev acceptance" to 
include input from others such as merchants/exchanges/miners/users.  It 
will only be an approximation of "decentralization" and the process 
won't be perfect but if you want to move forward then you need some way 
to do it.

Russ


On 6/25/2015 4:05 PM, Tier Nolan wrote:
> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach 
> <mark@friedenbach.org <mailto:mark@friedenbach.org>> wrote:
>
>     I'm sorry but this is absolutely not the case, Milly. The reason
>     that people get defensive is that we have a carefully constructed
>     process that does work (thank you very much!) and is well documented.
>
>
> There is no process for handling hard forks, which aren't bug fixes.
>
> Soft forks have a defined process of something like
>
> - BIP proposal + discussion
> - Proposed code
> - Dev acceptance
> - Release
> - Miner vote/acceptance
>
> The devs have a weak veto.  If they refuse to move forward with 
> changes, miners could perform a soft fork on their own.  They don't 
> want to do that, as it would be controversial and the devs know the 
> software better.
>
> The miner veto is stronger (for soft forks) but not absolute.  The 
> devs could checkpoint/blacklist a chain if miners implemented a fork 
> that wasn't acceptable (assuming the community backed them).
>
> When ASICs arrived, it was pointed out by some that the devs could hit 
> back if ASICs weren't made publicly available.  If they slightly 
> tweaked the hashing algorithm, then current generation of ASICs would 
> be useless.   The potential threat may have acted as a disincentive 
> for ASIC manufacturers to use the ASICs themselves.
>
> Moving forward with agreement between all involved is the recommended 
> and desirable approach.
>
> Consensus between all parties is the goal but isn't absolutely 
> required.  This escape valve is partly what makes consensus work.  If 
> you dig your heels in, then the other side can bypass you, but they 
> have an incentive to try to convince you to compromise first.  The 
> outcome is better if a middle ground can be found.
>
> Hard forks are different.  The "checks and balances" of weak vetoes 
> are not present.  This means that things can devolve from consensus to 
> mutual veto.  Consensus ceases to be a goal and becomes a requirement.
>
> This is partly a reflection of the nature of hard forks.  Everyone 
> needs to upgrade.  On the other hand, if most of the various groups 
> upgrade, then users of the legacy software would have to upgrade or 
> get left behind. If 5% of the users decided not to upgrade, should 
> they be allowed to demand that nobody else does?
>
> There is clearly some kind of threshold that is reasonable.
>
> The fundamental problem is that there isn't agreement on what the 
> block size is.  Is it equal in status to the 21 million BTC limit?
>
> If Satoshi had said that 1MB was part of the definition of Bitcoin, 
> then I think people would accept it to the same extent as they accept 
> the 21 million coin limit.  It might cause people to leave the coin 
> though.
>
> It was intended to be temporary, but people have realized that it 
> might be a good idea to keep it.  In effect both sides could argue 
> that they should be considered the status quo.
>
> I wonder if a coin toss would be acceptable :).  "Come to an agreement 
> or we decide by coin toss"
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------050404030803010903050601
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">That description makes sense.  It also
      makes sense to separate out the hard fork from the soft fork
      process.   Right now some people want to use the soft fork
      procedure for a hard fork simply because there is no other way to
      do it.<br>
      <br>
      I am under the impression that most users expect
      changes/improvements that would require a hard fork so I think
      some kind of process needs to be developed.  Taking the
      responsibility off the shoulder of the core maintainer also makes
      sense.  The hard fork issue is too much of a distraction for
      people trying to maintain the nuts and bolts of the underlying
      system.  <br>
      <br>
      I saw a suggestion that regularly scheduled hard forks should be
      planned.  That seems to make sense so you would have some sort of
      schedule where you would have cut off dates for hard-fork BIP
      submissions.  That way you avoid the debates over whether there
      should be hard forks to what should be contained within the hard
      fork (if needed).  It makes sense to follow the BIP process as
      close as possible.  Possibly adding another step after "Dev
      acceptance" to include input from others such as
      merchants/exchanges/miners/users.  It will only be an
      approximation of "decentralization" and the process won't be
      perfect but if you want to move forward then you need some way to
      do it. <br>
      <br>
      Russ<br>
      <br>
      <br>
      On 6/25/2015 4:05 PM, Tier Nolan wrote:<br>
    </div>
    <blockquote
cite="mid:CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Thu, Jun 25, 2015 at 2:50 AM, Mark
            Friedenbach <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div dir="ltr">
                <div>
                  <div>
                    <div>I'm sorry but this is absolutely not the case,
                      Milly. The reason that people get defensive is
                      that we have a carefully constructed process that
                      does work (thank you very much!) and is well
                      documented. </div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>There is no process for handling hard forks, which
              aren't bug fixes.<br>
              <br>
            </div>
            <div>Soft forks have a defined process of something like<br>
            </div>
            <div><br>
              - BIP proposal + discussion<br>
            </div>
            <div>- Proposed code<br>
            </div>
            <div>- Dev acceptance<br>
            </div>
            <div>- Release<br>
            </div>
            <div>- Miner vote/acceptance<br>
              <br>
            </div>
            <div>The devs have a weak veto.  If they refuse to move
              forward with changes, miners could perform a soft fork on
              their own.  They don't want to do that, as it would be
              controversial and the devs know the software better.<br>
              <br>
            </div>
            <div>The miner veto is stronger (for soft forks) but not
              absolute.  The devs could checkpoint/blacklist a chain if
              miners implemented a fork that wasn't acceptable (assuming
              the community backed them).<br>
              <br>
            </div>
            <div>When ASICs arrived, it was pointed out by some that the
              devs could hit back if ASICs weren't made publicly
              available.  If they slightly tweaked the hashing
              algorithm, then current generation of ASICs would be
              useless.   The potential threat may have acted as a
              disincentive for ASIC manufacturers to use the ASICs
              themselves.<br>
            </div>
            <div><br>
            </div>
            <div>Moving forward with agreement between all involved is
              the recommended and desirable approach.<br>
              <br>
            </div>
            <div>Consensus between all parties is the goal but isn't
              absolutely required.  This escape valve is partly what
              makes consensus work.  If you dig your heels in, then the
              other side can bypass you, but they have an incentive to
              try to convince you to compromise first.  The outcome is
              better if a middle ground can be found.<br>
              <br>
            </div>
            <div>Hard forks are different.  The "checks and balances" of
              weak vetoes are not present.  This means that things can
              devolve from consensus to mutual veto.  Consensus ceases
              to be a goal and becomes a requirement.<br>
              <br>
            </div>
            <div>This is partly a reflection of the nature of hard
              forks.  Everyone needs to upgrade.  On the other hand, if
              most of the various groups upgrade, then users of the
              legacy software would have to upgrade or get left behind. 
              If 5% of the users decided not to upgrade, should they be
              allowed to demand that nobody else does?<br>
              <br>
            </div>
            <div>There is clearly some kind of threshold that is
              reasonable.<br>
              <br>
            </div>
            <div>The fundamental problem is that there isn't agreement
              on what the block size is.  Is it equal in status to the
              21 million BTC limit?<br>
              <br>
              If Satoshi had said that 1MB was part of the definition of
              Bitcoin, then I think people would accept it to the same
              extent as they accept the 21 million coin limit.  It might
              cause people to leave the coin though.<br>
              <br>
            </div>
            <div>It was intended to be temporary, but people have
              realized that it might be a good idea to keep it.  In
              effect both sides could argue that they should be
              considered the status quo.<br>
              <br>
            </div>
            <div>I wonder if a coin toss would be acceptable :).  "Come
              to an agreement or we decide by coin toss"<br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------050404030803010903050601--