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 <peter_r@gmx.com>
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: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
	<CA+w+GKSNa3TWgHXrp3=3gXdAbE6vVjW_uzus3_2YG9gzKJSskg@mail.gmail.com>
	<5612ACF3.2080006@gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>
Sender: Peter_R@gmx.com
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork
	technical debate
Precedence: list


--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/ =
<https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_co=
re_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 =
<bitcoin-dev@lists.linuxfoundation.org> 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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D""><div class=3D"">Dear Bitcoin Development =
Community:</div><div class=3D""><br class=3D""></div><div class=3D"">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). &nbsp;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. =
&nbsp;</div><div class=3D""><br class=3D""></div><div class=3D"">I also =
agree with Mike that Core's requirement for unanimous consensus results =
in development grid lock and should be revisited. &nbsp;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. &nbsp;It shouldn=E2=80=99t matter really how the chain becomes =
the longest=E2=80=94only that it does. &nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">I believe that a good way to return =
power to the bitcoin community is to foster mutiple forkwise-compatible =
implementations of the protocol. &nbsp;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. &nbsp;If a super majority does not =
support the change, then it won=E2=80=99t be activated. &nbsp;I created =
an animated GIF that visualizes one possibility for how multiple =
protocol implementations might emerge over time:</div><div class=3D""><br =
class=3D""></div><div class=3D""><a =
href=3D"https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bit=
coin_core_visualizing_the/" =
class=3D"">https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_=
bitcoin_core_visualizing_the/</a></div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Nodes would express their acceptance of =
a block by mining on top of it. &nbsp;Consensus would be determined by =
the code we choose to run.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">Best regards,</div><div =
class=3D"">Peter&nbsp;</div></div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Oct 5, 2015, at 10:01 AM, =
Paul Sztorc via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D"">On 10/5/2015 12:56 =
PM, Mike Hearn via bitcoin-dev wrote:<br class=3D""><blockquote =
type=3D"cite" class=3D""><br class=3D"">As everyone in the Bitcoin =
community has been clearly told that<br class=3D"">controversial changes =
to the consensus rules must not happen, it's<br class=3D"">clear that =
CLTV cannot happen in its current form.<br class=3D""></blockquote><br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></body></html>=

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