summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMark Friedenbach <mark@friedenbach.org>2017-06-20 19:11:15 -0700
committerbitcoindev <bitcoindev@gnusha.org>2017-06-21 02:11:38 +0000
commit916b15437baaf239a3abf6068de562a8514545aa (patch)
tree028d32cf5ea1557ed2eb4d23a4763a8ad5f738a9
parent90125b078ac8c5ce5f43c05d7c62010a38907ef4 (diff)
downloadpi-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/2de90e87675bb24811079e5bfdcee83e0dc213287
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
+>>
+>
+