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 C2EBABF9 for ; Thu, 20 Apr 2017 14:23:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yb0-f177.google.com (mail-yb0-f177.google.com [209.85.213.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C57C9E2 for ; Thu, 20 Apr 2017 14:23:41 +0000 (UTC) Received: by mail-yb0-f177.google.com with SMTP id 6so26463115ybq.2 for ; Thu, 20 Apr 2017 07:23:41 -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=ledx19BtjmtAOUHVjB7ZZT6/0soSyQUBbheomt64Ax0=; b=LGr1rIgFMplA7we69ifMA1B8cRVQYbj2nr8dVmMQq8EwCLzzIgWv9TdXlTB+8JcALw 7fiMT3r0lxm+Q7qWZI4ycpvfN5eoTT4F7751Pw+kJUqKAW0yxR9kTziKd3onyS19fVxo v7mT1qnJfDrYQyOTB2/P6tPfOC04iqO9IUkWLfnz+td5/3+cJr3fmJZp7Q8XNlP588UV XpDtofDQniSwUHNHCx/fDhB2uab9f0SM1LIuPSpjz8zSzfk65GAj+cKW7belYvZWzNb3 PKPn9Yex7wflY4tYjPM2onxQW32rqX+eVEVHUFA3SwRCucAc8c0XhZh26rYjh3xlVK1o WrUw== 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=ledx19BtjmtAOUHVjB7ZZT6/0soSyQUBbheomt64Ax0=; b=TAAk+mWCCjLaDBmUh8KFcwDuFKWtcNYkWt/gFxygA50JwUEKY3EKh01IfOiKYG22Ji CxECgMw5sHVpQoPpX9KXHh/cbUKEPFzApYJYH7/D8lxpfe7nzJspyJXj22HqWcHQF9sp +RpjnOU37XwoidJrrzTdKFks2/3Ghsi6ZLkCoaWZu8EN2eLRlbdRBftjo9qkL9DbtmBC q0o9wH1u1pA9hbiHLg5GwMuRnnJKjw0QHMilNRba30aRLRJQY/RWZApP/ZrbkIsf6ZZ8 0zWjc83ryJSCR4eicxwijB/8bYVA+K7X5pVQMc4uV34+ncXtTfKQrSbeQrmwxl3vlqGc cIOA== X-Gm-Message-State: AN3rC/56rVmqB2a4/q9ItE5DvwWsS+Ohbs7/hV0Z69y8p5rrr59RE6Zj yf+wHFrhSMlJhKdfyGROC/f95QKRWA== X-Received: by 10.99.6.139 with SMTP id 133mr8345636pgg.154.1492698220945; Thu, 20 Apr 2017 07:23:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.141.72 with HTTP; Thu, 20 Apr 2017 07:23:40 -0700 (PDT) In-Reply-To: References: From: Alphonse Pace Date: Thu, 20 Apr 2017 09:23:40 -0500 Message-ID: To: Erik Aronesty Content-Type: multipart/alternative; boundary=001a114f49d83766b0054d99e389 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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: Thu, 20 Apr 2017 14:24:40 +0000 Cc: Bitcoin Dev 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: Thu, 20 Apr 2017 14:23:42 -0000 --001a114f49d83766b0054d99e389 Content-Type: text/plain; charset=UTF-8 A WTXID commitment would (likely) need to be a UASF. On Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The "UASF movement" seems a bit premature to me - I doubt UASF will be > necessary if a WTXID commitment is tried first. I think that should be > first-efforts focus. > > On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> 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. >>> >> >> I do not follow the argument that a critical design feature of a >> particular "user activated soft fork" could be that it is users don't need >> to be involved. If the goal is user activation I would think that the >> expectation would be that the overwhelming majority of users would be >> upgrading to do it, if that isn't the case, then it isn't really a user >> activated softfork-- it's something else. >> >> >>> 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. >>> >> >> So it has to be supported by the public but I can't say why I don't >> support it? This seems extremely suspect to me. >> >> >> >> _______________________________________________ >> 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 > > --001a114f49d83766b0054d99e389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A WTXID commitment would (likely) need to be a UASF.
<= br>

On= Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The "UASF movement&q= uot; seems a bit premature to me - I doubt UASF will be necessary if a WTXI= D commitment is tried first.=C2=A0=C2=A0 I think that should be first-effor= ts focus.

On Sat, Apr 15, 2017 at 2:50 PM, Gregory Max= well via bitcoin-dev <bitcoin-dev@lists.linuxfoun= dation.org> wrote:
On Sat, Apr 15, 2017 at 1= :42 PM, Mark Friedenbach via bitcoin-dev <bitcoin-dev@= lists.linuxfoundation.org> wrote:
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.
<= /div>

I do not= follow the argument that a critical design feature of a particular "u= ser activated soft fork" could be that it is users don't need to b= e involved.=C2=A0 If the goal is user activation I would think that the exp= ectation would be that the overwhelming majority of users would be upgradin= g to do it, if that isn't the case, then it isn't really a user act= ivated softfork-- it's something else.
=C2=A0
=
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.

So it has to be supported by the public but I c= an't say why I don't support it? This seems extremely suspect to me= .

=C2=A0

_____________________________________= __________
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


--001a114f49d83766b0054d99e389--