From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BBCD6720 for ; Sat, 15 Apr 2017 13:42:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31D6D79 for ; Sat, 15 Apr 2017 13:42:47 +0000 (UTC) Received: by mail-io0-f170.google.com with SMTP id o22so2946561iod.3 for ; Sat, 15 Apr 2017 06:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GkVrTr6B7cJ8f6wFaYr8Ewpmlf4MfH1fhWn5AFDwhxA=; b=OUMOnxVWrKTx5sYLKpO7hC9CZOYDg4Uop9UwJJnyVNMidh83YrU7ma86XkfObpfvav XwyLOO1nEEGFue+KFH4MKRa3FPVfndMRp7LOWhCIE5Q8ZNBQt3INlz7/HqzkFFnW2HTs KQ+bIXrA+oG2fgOb/D8MVquJca5cz568ahY+nqtgvf1vdypiKRVfyNVZJugcGQtG5UnH nkQCrW0jGROYSLoX+2P5Rp1ny9a1LmNFGBLKt+pu7a0FkmVKdwLnbXITZdkC5aP5e5TN BWwOAtkgdCXW5zGn/3dpqtj8Sc6RNk7ZBdBKV6Damh8b3NcEGCsV4S/Vaf/iGC6wC+hR Iivw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GkVrTr6B7cJ8f6wFaYr8Ewpmlf4MfH1fhWn5AFDwhxA=; b=oSBuI1LPSZP+qU7v4QjN37TEmZj0Tr5A39hfR1cU7uPb2Mmkq8nLtHP7qOG7MyRpkr dWhQHaFRCZ4XYihijLSe6ev/TzgI6l1sHV9BjHnzJ90vS5pS/8oFDx3+WIEt1kxPDZ42 Xy/6tpDAO1ZtajfIQBbz5e9A589RHVh0GJN0DAGKtblQRf/RBh+XQ+LZSZ5fRgu6dJ7Q 0YBxTmq8r+WF50nzgUYCnfy7n3q5nlfNSqbyJ3wKfhoj+NWONR1UjT6mPQuHOgQrfU+O UPI2Oa1FCiFhTfT97c8tEaUP0ohkqoYbl9yy3ZYj7saNzD4FpAOlDZeaD3AqRTWFra0g fB7w== X-Gm-Message-State: AN3rC/7PApIQJLkyasgtMluN1MuzK77G80DiIDow+wfRmTLBY1MA89UD 1+owSyEbLH306rdwOBoQmFEcPhQXjB+UOBA= X-Received: by 10.107.1.205 with SMTP id 196mr2088995iob.131.1492263766230; Sat, 15 Apr 2017 06:42:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.51.137 with HTTP; Sat, 15 Apr 2017 06:42:25 -0700 (PDT) X-Originating-IP: [108.48.174.158] From: Mark Friedenbach Date: Sat, 15 Apr 2017 09:42:25 -0400 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113a673cb2a5e3054d34bb72 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_IMAGE_ONLY_16,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,T_REMOTE_IMAGE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 15 Apr 2017 13:57:06 +0000 Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 13:42:47 -0000 --001a113a673cb2a5e3054d34bb72 Content-Type: text/plain; charset=UTF-8 Greg, If I understand correctly, the crux of your argument against BIP148 is that it requires the segwit BIP9 activation flag to be set in every block after Aug 1st, until segwit activates. This will cause miners which have not upgrade and indicated support for BIP141 (the segwit BIP) to find their blocks ignored by UASF nodes, at least for the month or two it takes to activate segwit. Isn't this however the entire point of BIP148? I understand if you object to this, but let's be clear that this is a design requirement of the proposal, not a technical oversight. The alternative you present (new BIP bit) has the clear downside of not triggering BIP141 activation, and therefore not enabling the new consensus rules on already deployed full nodes. BIP148 is making an explicit choice to favor dragging along those users which have upgraded to BIP141 support over those miners who have failed to upgrade. On an aside, I'm somewhat disappointed that you have decided to make a public statement against the UASF proposal. Not because we disagree -- that is fine -- but because any UASF must be a grassroots effort and endorsements (or denouncements) detract from that. Mark Friedenbach --001a113a673cb2a5e3054d34bb72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greg,=

If I=20 understand correctly, the crux of your argument against BIP148 is that=20 it requires the segwit BIP9 activation flag to be set in every block=C2=A0<= a dir=3D"ltr">after Aug 1st, until segwit activates. This will cause miners which have not upgrade=20 and indicated support for BIP141 (the segwit BIP) to find their blocks=20 ignored by UASF nodes, at least for the month or two it takes to=20 activate segwit.

Isn't this however the entire point of BIP148? = I understand if you object to this, but let's be clear that this is a=20 design requirement of the proposal, not a technical oversight. The=20 alternative you present (new BIP bit) has the clear downside of not=20 triggering BIP141 activation, and therefore not enabling the new=20 consensus rules on already deployed full nodes. BIP148 is making an=20 explicit choice to favor dragging along those users which have upgraded=20 to BIP141 support over those miners who have failed to upgrade.

On an aside, I'm somewhat disappointed that you have decided to make a=20 public statement against the UASF proposal. Not because we disagree --=20 that is fine -- but because any UASF must be a grassroots effort and=20 endorsements (or denouncements) detract from that.

Mark Friedenbach
--001a113a673cb2a5e3054d34bb72--