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 73977BFE for ; Thu, 20 Apr 2017 15:48:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 559671A7 for ; Thu, 20 Apr 2017 15:48:23 +0000 (UTC) Received: by mail-qk0-f169.google.com with SMTP id h67so50107808qke.0 for ; Thu, 20 Apr 2017 08:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7LnlwvtsAnFrnjblS/TWiGG/SeeclOy6HzEBNa1p/UA=; b=otvxInXR6JFxpGRXKmv3GBhq8QYtxZHLnVtBiboZi7o/cVbuXHjHTSWVCmcmkHSlef kbNQGI+XHFdwIxiWtELqfIYd4VKDtJw8gjPraeeO0c78roEVxi5cD1hZJ3xoDKcakYHC ci4eLPDMZH/AKIFVbbZPqQ+EvONahl+F2woq2c//GGE9tLiv386f9CAAn6lU6OcgbN0+ a+yiCF5MIBp4cjuZPBbZAqGH7Gni6F/pE21FuACvQTGHZzrBEGUqpwkQG3DvIK6I12BQ lYqpZ49bRGc+l34x00PKHXthFXq+XD5QylkCaIPTUiJaIndVl4uFqgExVzvEGovx0tSH Bwow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7LnlwvtsAnFrnjblS/TWiGG/SeeclOy6HzEBNa1p/UA=; b=pqoOQ9IKTlfcmpwuK0jxw1pSlr6OaV/cLPec9YDrFAJ6zQNLL6slGeHxg3VGPlBeYf 4LtfbatWjE7Q8NTLA/dzQVozE/3pL5pJFQSuB2AMRehwc1qEg85ZbZJZ7QibPP81I4Q4 LXv5VHkUFzGtdnGLrRlyjFmBFOcN+RIGq8IOk5KcTN5+jta9OzL1bPcnF9fazKe63S6q D/JQGRQtW0nLFxbJgHJVzFCRlFh4kFZfMpQilHI610ApNJzHWQUDbZdoTfE83Lr33/9x ICAZ/dgs4G1JgvYGcUpej46rvJOlhLn/5UMWr9U0GTL9C+IP5rRoUc0XJk+0pNlL7M8t v0+w== X-Gm-Message-State: AN3rC/60+f8Lz6b4c9o+AgTA4P/2WYTEzi9xpZlo+XJaG2yFQOnPudPc aU+E7mpkbH5aaPkoQYj0jI7bhW88zA== X-Received: by 10.55.104.139 with SMTP id d133mr8169411qkc.56.1492703302407; Thu, 20 Apr 2017 08:48:22 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.200.0.146 with HTTP; Thu, 20 Apr 2017 08:48:21 -0700 (PDT) In-Reply-To: References: From: Erik Aronesty Date: Thu, 20 Apr 2017 11:48:21 -0400 X-Google-Sender-Auth: cyU_Wrrl7zZEAPwivMLKkq_6uCA Message-ID: To: Alphonse Pace Content-Type: multipart/alternative; boundary=94eb2c055e9c185ef7054d9b12d4 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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: Thu, 20 Apr 2017 15:53:32 +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 15:48:24 -0000 --94eb2c055e9c185ef7054d9b12d4 Content-Type: text/plain; charset=UTF-8 Bitcoin must level the playing field for mining or it is fundamentally broken. And there are two obvious solutions: 1. WTXID commitment has as a flag day upgrade. It's a fix to a fairly serious security issue - made even worse by the existence of patents on the code. 2. Embed the code for performing a covert ASICBOOST into Bitcoin core's reference implementation. But, since this would violate patents held in China and the U.S., it could be a problem. Of these, I think the first should be far less controversial. One or the other must be done - if we can't fix security and licensing problems in Bitcoin, what can we fix? On Thu, Apr 20, 2017 at 10:23 AM, Alphonse Pace wrote: > 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 >> >> > --94eb2c055e9c185ef7054d9b12d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bitcoin must level the playing field for mi= ning or it is fundamentally broken.=C2=A0=C2=A0 And there are two obvious s= olutions:

1. WTXID commitment has as a flag day upgrade. It's a = fix to a fairly serious security issue - made even worse by the existence o= f patents on the code.=C2=A0=C2=A0

2. Embed the code for performing= a covert ASICBOOST into Bitcoin core's reference implementation.=C2=A0= =C2=A0 But, since this would violate patents held in China and the U.S., it= could be a problem.

Of these, I think the first should = be far less controversial.=C2=A0=C2=A0

One or the other must be don= e - if we can't fix security and licensing problems in Bitcoin, what ca= n we fix?

<= br>
On Thu, Apr 20, 2017 at 10:23 AM, Alphonse Pa= ce <alp.bitcoin@gmail.com> wrote:
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 b= it premature to me - I doubt UASF will be necessary if a WTXID commitment i= s tried first.=C2=A0=C2=A0 I think that should be first-efforts focus.
<= /div>

<= div class=3D"m_-1452426406923278833h5">On Sat, Apr 15, 2017 at 2:50 PM, Gre= gory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.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

_______________________________________________<= br> 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



--94eb2c055e9c185ef7054d9b12d4--