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 0327D1B47 for ; Mon, 5 Oct 2015 17:34:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D417D219 for ; Mon, 5 Oct 2015 17:34:02 +0000 (UTC) Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M24Vr-1abopo4B35-00u4xa; Mon, 05 Oct 2015 19:34:00 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D9EA63B-7F22-4FCA-9D68-48A794B91B68" From: Peter R In-Reply-To: <5612ACF3.2080006@gmail.com> Date: Mon, 5 Oct 2015 10:33:55 -0700 Message-Id: <5570C084-0C2D-4B79-A78E-B25699600EA9@gmx.com> References: <5612ACF3.2080006@gmail.com> To: Paul Sztorc X-Mailer: Apple Mail (2.2104) Sender: Peter_R@gmx.com X-Provags-ID: V03:K0:yN/VrQF2cdUL62dLyKKZ6Zrb/bJ/bSdf9JN/Cbjc0eVYVMM47uh ZDWQqokMtvz1yYoOGHyNXhEs78sTVz9WAX7JzJBSOLPlAQuPtxHFOogjyTCF8ghznzjSaEy FtJ1T01TZgakms80nkfwbonClnE0RUpmO6dusVKC3Bt7+x+n3jwEk+/8nH7HthuZ6zCANo8 NH/h+JDOIqkh2ph7M0W+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:MLfXH7ch2tw=:+JcuqENDpMeMkCj6kLxQin dEnbtu2myQJzWEVSf+elASLn309zw+nC8wvFQ8Eeq5W8vikqWSm3PvNU+10m28xK/tX3I6xDt DMEJDibkVFZJChzQBbxDnwlFGUcVDBxy1GMzjOESd9N7431huEwa8qeqkVOWVoHnZSno80SiU KSzF2GULGQPGYT41z/4iaka8mLX6vzPOLsPOHj1zCdH/eDpr7pR6rGZIerFHUZtkLRu+LcInx rkDCi8r5wkbgtR08o14GdYBQP0b4cWzMvuJ8APVwu5fmRt75LloYMV15FqtXXeGswguL0wmIR 3j2lj7YLYiKnq1Npaq3a/kdF05NipL77NX25lvhPu1LE+HnDlFJXU5j26UEs3Cp6W3lFBiY+4 6aGkaPdnU2RjuZHIl+brRwNy+9W4AGMIS2j1zWAX3rHBCr0G/++afHCxhd5TtW1xMQhRiTNx6 ff72wOaG2kV3N4fXDoNv96TBq9/NbNrQCBmsmoLOoRmGyLNbPSa87sOH+bBH3PuSFY3+h/STu IwXJB5eKrdVvn3Jp9rzJyETEP76iigIseqYOfc/mkKGWTKDMm1uOzoE6YH1CneiLJC6WyBtyH 5tNqBYPbHJeWN0wt+Gwe82DC+J3aZP1p1XefqwJ54FNpSNjjDU0sTE9AYu8zohVVwwF0DgG3o rPOoFxBW3XfTf9ftZhit3eiNj11zeqUY659EZGfV8Pk5GfdwpsQBOXj7VHKfkV/pywGvnKKLc /z/E5MzcpWwghYir/qYSbA+OrstIRL+6/W0M61EGETV3LFPc5vgbq5q+hCby+mqvZRPKgT+FK LsjlGtg X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate 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: Mon, 05 Oct 2015 17:34:04 -0000 --Apple-Mail=_0D9EA63B-7F22-4FCA-9D68-48A794B91B68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Bitcoin Development Community: I would like to share my opinion that Mike is correct regarding the soft = fork versus hard fork debate. I agree that CLTV should be done with a = hard fork for the reasons that Mike has discussed several times in the = past (mainly that a hard forks requires active consensus while a soft = fork requires only indifference). I believe this is a controversial = change and=E2=80=94if Core Dev believes that controversial changes to = the consensus rules must not happen=E2=80=94then my interpretation is = that CLTV should not happen in its current form. =20 I also agree with Mike that Core's requirement for unanimous consensus = results in development grid lock and should be revisited. In my = opinion, the idea that unanimity is required should be replaced with the = idea that the longest chain composed of valid transactions is the = correct chain. It shouldn=E2=80=99t matter really how the chain becomes = the longest=E2=80=94only that it does. =20 I believe that a good way to return power to the bitcoin community is to = foster mutiple forkwise-compatible implementations of the protocol. = Each implementation could have its own governance model and design = objectives and use techniques like BIP101=E2=80=99s 750/1000 signalling = mechanism to activate changes that may be desirable to the community. = If a super majority does not support the change, then it won=E2=80=99t = be activated. I created an animated GIF that visualizes one possibility = for how multiple protocol implementations might emerge over time: = https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_cor= e_visualizing_the/ = Decentralizing development and supporting multiple forkwise-compatible = implementations of the protocol is a worthwhile goal that will = simultaneously make Bitcoin more robust and more responsive to the will = of the market. Nodes would express their acceptance of a block by mining on top of it. = Consensus would be determined by the code we choose to run.=20 Best regards, Peter=20 > On Oct 5, 2015, at 10:01 AM, Paul Sztorc via bitcoin-dev = wrote: >=20 > On 10/5/2015 12:56 PM, Mike Hearn via bitcoin-dev wrote: >>=20 >> As everyone in the Bitcoin community has been clearly told that >> controversial changes to the consensus rules must not happen, it's >> clear that CLTV cannot happen in its current form. >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_0D9EA63B-7F22-4FCA-9D68-48A794B91B68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Bitcoin Development = Community:

I = would like to share my opinion that Mike is correct regarding the soft = fork versus hard fork debate. I agree that CLTV should be done with a = hard fork for the reasons that Mike has discussed several times in the = past (mainly that a hard forks requires active consensus while a soft = fork requires only indifference).  I believe this is a = controversial change and=E2=80=94if Core Dev believes that controversial = changes to the consensus rules must not happen=E2=80=94then my = interpretation is that CLTV should not happen in its current form. =  

I also = agree with Mike that Core's requirement for unanimous consensus results = in development grid lock and should be revisited.  In my opinion, = the idea that unanimity is required should be replaced with the idea = that the longest chain composed of valid transactions is the correct = chain.  It shouldn=E2=80=99t matter really how the chain becomes = the longest=E2=80=94only that it does.  

I believe that a good way to return = power to the bitcoin community is to foster mutiple forkwise-compatible = implementations of the protocol.  Each implementation could have = its own governance model and design objectives and use techniques like = BIP101=E2=80=99s 750/1000 signalling mechanism to activate changes that = may be desirable to the community.  If a super majority does not = support the change, then it won=E2=80=99t be activated.  I created = an animated GIF that visualizes one possibility for how multiple = protocol implementations might emerge over time:

https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_= bitcoin_core_visualizing_the/

Decentralizing development and = supporting multiple forkwise-compatible implementations of the protocol = is a worthwhile goal that will simultaneously make Bitcoin more robust = and more responsive to the will of the market.

Nodes would express their acceptance of = a block by mining on top of it.  Consensus would be determined by = the code we choose to run. 

Best regards,
Peter 


On Oct 5, 2015, at 10:01 AM, = Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On 10/5/2015 12:56 = PM, Mike Hearn via bitcoin-dev wrote:

As everyone in the Bitcoin = community has been clearly told that
controversial changes = to the consensus rules must not happen, it's
clear that = CLTV cannot happen in its current form.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_0D9EA63B-7F22-4FCA-9D68-48A794B91B68--