summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJacob Eliosoff <jacob.eliosoff@gmail.com>2017-06-20 18:29:27 -0400
committerbitcoindev <bitcoindev@gnusha.org>2017-06-20 22:29:31 +0000
commit87167349a7ce45b016c2185798e415fcdf3ec43a (patch)
treeec62a18862b36acfa1b2d09580aa0128ec49403e
parent1420e8ba2ef3ffa3babbe3cb798977b922cc6be1 (diff)
downloadpi-bitcoindev-87167349a7ce45b016c2185798e415fcdf3ec43a.tar.gz
pi-bitcoindev-87167349a7ce45b016c2185798e415fcdf3ec43a.zip
Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated
-rw-r--r--35/fa1a839bece998d57e709c9a4a86da93c017df302
1 files changed, 302 insertions, 0 deletions
diff --git a/35/fa1a839bece998d57e709c9a4a86da93c017df b/35/fa1a839bece998d57e709c9a4a86da93c017df
new file mode 100644
index 000000000..c82161ebc
--- /dev/null
+++ b/35/fa1a839bece998d57e709c9a4a86da93c017df
@@ -0,0 +1,302 @@
+Return-Path: <jacob.eliosoff@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 8FCE1891
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 20 Jun 2017 22:29:31 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com
+ [209.85.215.50])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1CC3323D
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 20 Jun 2017 22:29:30 +0000 (UTC)
+Received: by mail-lf0-f50.google.com with SMTP id h22so3682895lfk.3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 20 Jun 2017 15:29:29 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
+ h=mime-version:in-reply-to:references:from:date:message-id:subject:to
+ :cc; bh=8BKo8rNroDPEQFno6LI+2/QWiL6QIE6g9fI0QBSWFdA=;
+ b=Y/7M6LJhDyz4eiuInFBYwExSZzpFG6fAb9hBwgQ7R1hUwzO9/MOBWCqEnucBvjN1IX
+ gVGghwwUUhYM/eYtHWEVkpUFg8cftwoB+8mca7iqEPpjbRxG7ke0mWbSZzVmO4Qknlq5
+ MFmmiS3MHB1HNAzzwk7tG4L13h2O/RhIpqOItFy0hl/dsotZA++KNjKGdoL6LiU37DWL
+ QVbJVpNjOmurhyKeaPrLJUnRs+Xh7aiBH1AL2ZV6f9+k7n20RAfgIuuUG62z4KHtpdBq
+ h7FP1arqfdWZ+RcSs9DQDAohe9OS1xJo7FYeMN0BVYjayb01pFCKtNzbrk6q0wvfubqF
+ EnBA==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:in-reply-to:references:from:date
+ :message-id:subject:to:cc;
+ bh=8BKo8rNroDPEQFno6LI+2/QWiL6QIE6g9fI0QBSWFdA=;
+ b=evEg3kSFHE1ZoUJXFew8XBUZjMQBYP+GkgGXfTgc9k4YAWwWIYQEHXiVbhKJ0LjJZ2
+ +eJs+o4bXjm8D7LY3xukAhhmFW0XI9kRriOeF44Jza0S9XKdif9U0p07JQPbXSME7K0L
+ i4zPnjvslLOCx+RyqXYxRHPoT4Om5kFdcs/jyfiJ8bOCxZtJ6Iamqcv2dBX9ZouOdkOS
+ 9f/uUEY+575twZGea2CodVuDowRFnDmGOPd1aOqOtq1zfSYnF1xrZgwZabd/ib6Cpg/r
+ IEpaoNyF/KeLBLusvNpb0pLWwCqronneBamKDOUZOnpDezqMRCCoRZxqFlEu78jVyNd8
+ 3uNQ==
+X-Gm-Message-State: AKS2vOyJojfP7uY4P3nn3zghpiKi5ZGw/IlqgdMwnmmi+9UotKKJhFUz
+ 838AQuP4mztSW28A4qbnLzmGm9mz6w==
+X-Received: by 10.25.67.21 with SMTP id q21mr9116139lfa.125.1497997768490;
+ Tue, 20 Jun 2017 15:29:28 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.25.86.26 with HTTP; Tue, 20 Jun 2017 15:29:27 -0700 (PDT)
+Received: by 10.25.86.26 with HTTP; Tue, 20 Jun 2017 15:29:27 -0700 (PDT)
+In-Reply-To: <CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
+References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>
+ <CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
+ <CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
+From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
+Date: Tue, 20 Jun 2017 18:29:27 -0400
+Message-ID: <CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com>
+To: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
+Content-Type: multipart/alternative; boundary="f403045e9de2dd852905526bc8e3"
+X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
+ RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+ smtp1.linux-foundation.org
+X-Mailman-Approved-At: Tue, 20 Jun 2017 22:31:28 +0000
+Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to
+ get segwit activated
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Protocol 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: Tue, 20 Jun 2017 22:29:31 -0000
+
+--f403045e9de2dd852905526bc8e3
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+If segwit is activated before Aug 1, as now seems likely, there will be no
+split that day. But if activation is via Segwit2x (also likely), and at
+least some nodes do & some don't follow through with the HF 3mo later
+(again, likely), agreed w/ Greg that *then* we'll see a split - probably in
+Sep/Oct. How those two chains will match up and how the split will play
+out is anyone's guess...
+
+
+
+On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoin-dev" <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> Ironically, it looks like most of the segwit2x signaling miners are
+> faking it (because they're not signaling segwit which it requires).
+> It'll be unfortunate if some aren't faking it and start orphaning
+> their own blocks because they are failing to signal segwit.
+
+Well, they're doing some kind of "pre-signaling" in the coinbase at the
+moment, because the segwit2x project is still in alpha-phase according to
+the timeline. They're just showing commitment.
+I'm sure they will begin signaling on version bit 4/BIP91 as well as
+actually running a segwit2x node when the time comes.
+
+
+> As far as prevent a chain split goes, all those things
+> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
+> don't think that holds.
+
+Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
+BIP148) node, because they wouldn't have the new consensus rule of
+requiring all blocks to signal for segwit.
+I don't believe there would be any long lasting chainsplit though (because
+of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get
+unlucky.
+
+Hampus
+
+2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org>:
+
+> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
+> <bitcoin-dev@lists.linuxfoundation.org> wrote:
+> > Because a large percentage of miners are indifferent, right now miners
+> have
+> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
+>
+> Miners can simply continuing signaling segwit, which will leave them
+> at least soft-fork compatible with BIP148 and BIP91 (and god knows
+> what "segwit2x" is since they keep changing the actual definition and
+> do not have a specification; but last I saw the near-term behavior the
+> same as BIP91 but with a radically reduced activation window, so the
+> story would be the same there in the near term).
+>
+> Ironically, it looks like most of the segwit2x signaling miners are
+> faking it (because they're not signaling segwit which it requires).
+> It'll be unfortunate if some aren't faking it and start orphaning
+> their own blocks because they are failing to signal segwit.
+>
+> I don't think the rejection of segwit2x from Bitcoin's developers
+> could be any more resolute than what we've already seen:
+> https://en.bitcoin.it/wiki/Segwit_support
+>
+> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
+> <bitcoin-dev@lists.linuxfoundation.org> wrote:
+> > I think it is very na=C3=AFve to assume that any shift would be tempora=
+ry.
+> > We have a hard enough time getting miners to proactively upgrade to
+> > recent versions of the reference bitcoin daemon. If miners interpret
+> > the situation as being forced to run non-reference software in order
+> > to prevent a chain split because a lack of support from Bitcoin Core,
+> > that could be a one-way street.
+>
+> I think this is somewhat naive and sounds a lot like the repeat of the
+> previously debunked "XT" and "Classic" hysteria.
+>
+> There is a reason that segwit2x is pretty much unanimously rejected by
+> the technical community. And just like with XT/Classic/Unlimited
+> you'll continue to see a strong correlation with people who are
+> unwilling and unable to keep updating the software at an acceptable
+> level of quality-- esp. because the very founding on their fork is
+> predicated on discarding those properties.
+>
+> If miners want to go off and create an altcoin-- welp, thats something
+> they can always do, and nothing about that will force anyone to go
+> along with it.
+>
+> As far as prevent a chain split goes, all those things
+> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
+> don't think that holds.
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+
+_______________________________________________
+bitcoin-dev mailing list
+bitcoin-dev@lists.linuxfoundation.org
+https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+
+--f403045e9de2dd852905526bc8e3
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"auto"><div>If segwit is activated before Aug 1, as now seems li=
+kely, there will be no split that day.=C2=A0 But if activation is via Segwi=
+t2x (also likely), and at least some nodes do &amp; some don&#39;t follow t=
+hrough with the HF 3mo later (again, likely), agreed w/ Greg that *then* we=
+&#39;ll see a split - probably in Sep/Oct.=C2=A0 How those two chains will =
+match up and how the split will play out is anyone&#39;s guess...<div dir=
+=3D"auto"><br></div><br><div class=3D"gmail_extra"><br><div class=3D"gmail_=
+quote">On Jun 20, 2017 6:16 PM, &quot;Hampus Sj=C3=B6berg via bitcoin-dev&q=
+uot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
+ev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><blockq=
+uote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
+padding-left:1ex"><div dir=3D"ltr"><div><div><div><div class=3D"quoted-text=
+"><div>&gt; Ironically, it looks like most of the segwit2x signaling miners=
+ are<br>&gt; faking it (because they&#39;re not signaling segwit which it r=
+equires).<br>
+&gt; It&#39;ll be unfortunate if some aren&#39;t faking it and start orphan=
+ing<br>
+&gt; their own blocks because they are failing to signal segwit.<br><br></d=
+iv></div>Well, they&#39;re doing some kind of &quot;pre-signaling&quot; in =
+the coinbase at the moment, because the segwit2x project is still in alpha-=
+phase according to the timeline. They&#39;re just showing commitment.<br>I&=
+#39;m sure they will begin signaling on version bit 4/BIP91 as well as actu=
+ally running a segwit2x node when the time comes.<div class=3D"quoted-text"=
+><br><br>&gt; As far as prevent a chain split goes, all those things<br>&gt=
+; (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I<br=
+>&gt; don&#39;t think that holds.<br><br></div></div> Segwit2x/BIP91/BIP148=
+ will orphan miners that do not run a Segwit2x (or BIP148) node, because th=
+ey wouldn&#39;t have the new consensus rule of requiring all blocks to sign=
+al for segwit.<br></div>I don&#39;t believe there would be any long lasting=
+ chainsplit though (because of the ~80% hashrate support on segwit2x), perh=
+aps 2-3 blocks if we get unlucky.<br><br></div>Hampus<br></div><div class=
+=3D"elided-text"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
+2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <span dir=3D"ltr=
+">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
+lank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span>:<br><blockq=
+uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
+solid;padding-left:1ex"><span>On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronest=
+y via bitcoin-dev<br>
+&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
+nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
+&gt; Because a large percentage of miners are indifferent, right now miners=
+ have<br>
+&gt; to choose between BIP148 and Segwit2x if they want to activate Segwit.=
+<br>
+<br>
+</span>Miners can simply continuing signaling segwit, which will leave them=
+<br>
+at least soft-fork compatible with BIP148 and BIP91 (and god knows<br>
+what &quot;segwit2x&quot; is since they keep changing the actual definition=
+ and<br>
+do not have a specification; but last I saw the near-term behavior the<br>
+same as BIP91 but with a radically reduced activation window, so the<br>
+story would be the same there in the near term).<br>
+<br>
+Ironically, it looks like most of the segwit2x signaling miners are<br>
+faking it (because they&#39;re not signaling segwit which it requires).<br>
+It&#39;ll be unfortunate if some aren&#39;t faking it and start orphaning<b=
+r>
+their own blocks because they are failing to signal segwit.<br>
+<br>
+I don&#39;t think the rejection of segwit2x from Bitcoin&#39;s developers<b=
+r>
+could be any more resolute than what we&#39;ve already seen:<br>
+<a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel=3D"noreferrer" ta=
+rget=3D"_blank">https://en.bitcoin.it/wiki/Seg<wbr>wit_support</a><br>
+<br>
+On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev<br>
+<span>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
+=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
+&gt; I think it is very na=C3=AFve to assume that any shift would be tempor=
+ary.<br>
+&gt; We have a hard enough time getting miners to proactively upgrade to<br=
+>
+&gt; recent versions of the reference bitcoin daemon. If miners interpret<b=
+r>
+&gt; the situation as being forced to run non-reference software in order<b=
+r>
+&gt; to prevent a chain split because a lack of support from Bitcoin Core,<=
+br>
+&gt; that could be a one-way street.<br>
+<br>
+</span>I think this is somewhat naive and sounds a lot like the repeat of t=
+he<br>
+previously debunked &quot;XT&quot; and &quot;Classic&quot; hysteria.<br>
+<br>
+There is a reason that segwit2x is pretty much unanimously rejected by<br>
+the technical community.=C2=A0 And just like with XT/Classic/Unlimited<br>
+you&#39;ll continue to see a strong correlation with people who are<br>
+unwilling and unable to keep updating the software at an acceptable<br>
+level of quality-- esp. because the very founding on their fork is<br>
+predicated on discarding those properties.<br>
+<br>
+If miners want to go off and create an altcoin-- welp, thats something<br>
+they can always do,=C2=A0 and nothing about that will force anyone to go<br=
+>
+along with it.<br>
+<br>
+As far as prevent a chain split goes, all those things<br>
+(148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I<br>
+don&#39;t think that holds.<br>
+<div class=3D"m_-187074116781290509HOEnZb"><div class=3D"m_-187074116781290=
+509h5">______________________________<wbr>_________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
+/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
+</div></div></blockquote></div><br></div>
+</div><br>______________________________<wbr>_________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
+<wbr>linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
+/mailman/listinfo/bitcoin-<wbr>dev</a><br>
+<br></blockquote></div><br></div></div></div>
+
+--f403045e9de2dd852905526bc8e3--
+