diff options
author | Jacob Eliosoff <jacob.eliosoff@gmail.com> | 2017-06-20 18:29:27 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-06-20 22:29:31 +0000 |
commit | 87167349a7ce45b016c2185798e415fcdf3ec43a (patch) | |
tree | ec62a18862b36acfa1b2d09580aa0128ec49403e | |
parent | 1420e8ba2ef3ffa3babbe3cb798977b922cc6be1 (diff) | |
download | pi-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/fa1a839bece998d57e709c9a4a86da93c017df | 302 |
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 & some don't follow t= +hrough with the HF 3mo later (again, likely), agreed w/ Greg that *then* we= +'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'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, "Hampus Sj=C3=B6berg via bitcoin-dev&q= +uot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= +ev@lists.linuxfoundation.org</a>> 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>> Ironically, it looks like most of the segwit2x signaling miners= + are<br>> faking it (because they're not signaling segwit which it r= +equires).<br> +> It'll be unfortunate if some aren't faking it and start orphan= +ing<br> +> their own blocks because they are failing to signal segwit.<br><br></d= +iv></div>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.<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>> 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'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't have the new consensus rule of requiring all blocks to sign= +al for segwit.<br></div>I don'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= +"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b= +lank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></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> +<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla= +nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br> +> Because a large percentage of miners are indifferent, right now miners= + have<br> +> 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 "segwit2x" 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're not signaling segwit which it requires).<br> +It'll be unfortunate if some aren't faking it and start orphaning<b= +r> +their own blocks because they are failing to signal segwit.<br> +<br> +I don't think the rejection of segwit2x from Bitcoin's developers<b= +r> +could be any more resolute than what we'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><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= +=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br> +> I think it is very na=C3=AFve to assume that any shift would be tempor= +ary.<br> +> We have a hard enough time getting miners to proactively upgrade to<br= +> +> recent versions of the reference bitcoin daemon. If miners interpret<b= +r> +> the situation as being forced to run non-reference software in order<b= +r> +> to prevent a chain split because a lack of support from Bitcoin Core,<= +br> +> 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 "XT" and "Classic" 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'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'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-- + |