diff options
author | Mark Friedenbach <mark@friedenbach.org> | 2017-06-20 19:11:15 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-06-21 02:11:38 +0000 |
commit | 916b15437baaf239a3abf6068de562a8514545aa (patch) | |
tree | 028d32cf5ea1557ed2eb4d23a4763a8ad5f738a9 | |
parent | 90125b078ac8c5ce5f43c05d7c62010a38907ef4 (diff) | |
download | pi-bitcoindev-916b15437baaf239a3abf6068de562a8514545aa.tar.gz pi-bitcoindev-916b15437baaf239a3abf6068de562a8514545aa.zip |
Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated
-rw-r--r-- | bf/2de90e87675bb24811079e5bfdcee83e0dc213 | 287 |
1 files changed, 287 insertions, 0 deletions
diff --git a/bf/2de90e87675bb24811079e5bfdcee83e0dc213 b/bf/2de90e87675bb24811079e5bfdcee83e0dc213 new file mode 100644 index 000000000..eb9af65bb --- /dev/null +++ b/bf/2de90e87675bb24811079e5bfdcee83e0dc213 @@ -0,0 +1,287 @@ +Return-Path: <mark@friedenbach.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id EFECF596 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 21 Jun 2017 02:11:38 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-it0-f45.google.com (mail-it0-f45.google.com + [209.85.214.45]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0A3A61B4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 21 Jun 2017 02:11:36 +0000 (UTC) +Received: by mail-it0-f45.google.com with SMTP id g184so20484345ita.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 20 Jun 2017 19:11:36 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=friedenbach-org.20150623.gappssmtp.com; s=20150623; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to + :cc:content-transfer-encoding; + bh=TFbf+AT2U2j4dBhBdcz0ca2wP6phI0/Ic0yPWvBgGFg=; + b=fi1i1JbiECfEVSSNDnEe8dRPyrUGjzqPCOK9Yej6xypOd1ZgGe6o0EV/ln7SEnScsU + Qf5L0puAdvBY13EUpb+fSrfTmDUQ03W5YbS9dnVd3AFfhJQh2HeSGgwyTUck58EngI7f + UFXX/UKfaJryUnM/9NQ4F9myqAVWSffiaR/RNc2mFpqepykVvLfZBpIH+fQ5TTTi2TEC + CTneAmXkV3e618YeptpbMB332aMaECMeqV+kLMl7Gp2bDZL5qudRuo5XCYWU9FjksIs0 + CBDlppbWColXbVqIYTBXDiMjhpRhJb90qiEoAezMVGEMvn6GlaMclsYrBHJPCUQo/gqj + ZP7Q== +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:content-transfer-encoding; + bh=TFbf+AT2U2j4dBhBdcz0ca2wP6phI0/Ic0yPWvBgGFg=; + b=KpnBK0Hjt9rmVgC5ZHx+OTok2OBcWIeb/oKrJnIoFDILwEmFgSjET/z8Llm+Zl4HCI + /HX3wI/1jZRzmYbC0TJkQbE4/HdyhTvNZj1djVCHCKYfehg0K+tiLaDyG7ccwvcMCGT4 + +IhWm6KJapLiXPeckh+mVF1EldZdGoFukv7A8EOagRDWI81v21d+CSUwjJxkkn2ASNi6 + Yof02SRHnpnR+8+GeYGl+7qyILK2ZdyQnp0FP2eUbrUnWDYnn4BlZV54QZtFnMKsi6pD + x3DA1t/gzG2FaYKTnuPpatOukLMs8jWM9RrkDAaKylQ1oRNK9bhao2aEQzuqXKjA/1pB + qogg== +X-Gm-Message-State: AKS2vOxixpH1RT0Prl1g4GBLxA2PFKkna2nInvUaWBeVI6Jd6Ps2F+1S + mtZ66x5Kb80ui0+E8BoPFRwWLUuuyZrd/eE= +X-Received: by 10.36.108.74 with SMTP id w71mr6730505itb.45.1498011096253; + Tue, 20 Jun 2017 19:11:36 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.107.138.24 with HTTP; Tue, 20 Jun 2017 19:11:15 -0700 (PDT) +X-Originating-IP: [2601:646:8080:1291:748c:1f1b:d1f6:e7c0] +In-Reply-To: <CAJowKgJcp7d30LsrDZ5iR6-k9Ncz0N90pxs2GmJkuG1qYDG6GQ@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> + <CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com> + <BC758648-BD4F-4DEF-8B79-7E8E0A887033@friedenbach.org> + <CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com> + <CAJowKgJcp7d30LsrDZ5iR6-k9Ncz0N90pxs2GmJkuG1qYDG6GQ@mail.gmail.com> +From: Mark Friedenbach <mark@friedenbach.org> +Date: Tue, 20 Jun 2017 19:11:15 -0700 +Message-ID: <CAOG=w-tPgJ5baaNiZC5rTs_y=eV7AU+F=aGaH+uObqaB-VgL2w@mail.gmail.com> +To: Erik Aronesty <erik@q32.com> +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,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: Wed, 21 Jun 2017 02:17:19 +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: Wed, 21 Jun 2017 02:11:39 -0000 + +80% have set "NYA" in their coinbase string. We have no idea what that +means. People are equating it to BIP 91 -- but BIP 91 did not exist at +the time of the New York agreement, and differs from the actual text +of the NYA in substantive ways. The "Segwit2MB" that existed at the +time of the NYA, and which was explicitly referenced by the text is +the proposal by Sergio Demian Lerner that was made to this mailing +list on 31 March. The text of the NYA grants no authority for +upgrading this proposal while remaining compliant with the agreement. +This is without even considering the fact that in the days after the +NYA there was disagreement among those who signed it as to what it +meant. + +I feel it is a very dangerous and unwarranted assumption people are +making that what we are seeing now is either 80% support for BIP-91 or +for the code in the btc1 repo. + +On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik@q32.com> wrote: +> # Jacob Eliosoff: +> +>> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a spli= +t. +> +> Correct. There are 2 short activation periods in BIP91 either of which +> would avoid a split. +> +> # Gregory Maxwell: +> +>> unclear to me _exactly_ what it would need to implement to be consistent= +. +> +> This is the relevant pull req to core: +> +> https://github.com/bitcoin/bitcoin/pull/10444 +> +> Seems OK. It's technically running now on testnet5. I think it (or a +> -bip148 option) should be merged as soon as feasible. +> +>> previously debunked "XT" and "Classic" hysteria. +> +> apples vs oranges, imo. segwit is not a contentious feature. the +> "bundling" in segwit2x is, but that's not the issue here. the issue is = +we +> are indirectly requiring miners that strongly support segwit to install +> consensus protocol changes outside of bitcoin's standard reference. 80%= + of +> them have signaled they will do so. these are uncharted waters. +> +> +> On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev +> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>> +>> I could be wrong, but the latest BIP91 implementation (also included in +>> Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This h= +as +>> been updated at +>> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So if = +80% +>> of hashpower is actually running that code and signaling on bit 4 by Jul= +y 25 +>> or so, then those 80+% will start orphaning non-bit-1 blocks before Aug = +1, +>> and we avoid a split. +>> +>> There may still be a few non-bit-1 blocks that get orphaned after Aug 1, +>> because they're mined by old BIP141 nodes. But it seems like very few +>> miners won't be signaling either Segwit2x *or* BIP141 by then... +>> +>> Make sense? +>> +>> +>> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <mark@friedenbach.org> +>> wrote: +>>> +>>> Why do you say activation by August 1st is likely? That would require a= +n +>>> entire difficulty adjustment period with >=3D95% bit1 signaling. That s= +eems a +>>> tall order to organize in the scant few weeks remaining. +>>> +>>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev +>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>>> +>>> 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), an= +d 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 - probabl= +y in +>>> Sep/Oct. How those two chains will match up and how the split will pla= +y 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 requ= +iring +>>> 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 mine= +rs +>>>> > have +>>>> > to choose between BIP148 and Segwit2x if they want to activate Segwi= +t. +>>>> +>>>> 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 temp= +orary. +>>>> > 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 +>>> +>>> +>>> _______________________________________________ +>>> 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 +>> +> + |