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 A1EB3958 for ; Tue, 11 Apr 2017 23:42:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 905FF108 for ; Tue, 11 Apr 2017 23:42:43 +0000 (UTC) Received: by mail-wm0-f47.google.com with SMTP id t189so12053258wmt.1 for ; Tue, 11 Apr 2017 16:42:43 -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=tgx8mGxtw1yEUrwP/4Td6dzV9gYZ5XLtUv4L3RKTFiA=; b=czieXlIYc/+qc0UWR1shT1MCWPlxzv0/mpk+0f8AakY1SUT0FJ2XQt1n8Yq5S8i4wq eCkUWu2fjvc0QR7Q18T8qDTuEipE76PKbIuDkIC2K95pefTKHu8yyB6vbRGwA1wMj9A6 zJp8imSl2ggWBKTmTajCPI5mqPfkutQA2gaq5LdaI8vuYi7y1t/j8jQtSxz0p9XGyZLG VNI7Id683pVZ17fGHfu73+akulbTDqvb+Az5sS01FCCG3aHWzHCU0OkVbqMf+fh1pcuY OU77DJbszYh0sKc+5ZAa5lw2jwF/uGrryNyRzlr3SvSR0mCs261Lagu2tPE3GE0IR2ku 0aVg== 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=tgx8mGxtw1yEUrwP/4Td6dzV9gYZ5XLtUv4L3RKTFiA=; b=TBXeuGFYu1sstuKANO2aSdYLpDarVccUsK56LWxXKZ1LZW//e+KGdWZobO5WSVLVjD LU70o9CgN8y+pQKtLjxejZZyyJWv1HNhVuHC2aWSjq3jZEoIvwlSNicvAJsGojyywFVI 8vjPOROyvHel0SkJ0e3nplmUOjjUqTXzx5GCQNdaL5eFQtvRrpVRsEIP/sxw2IoonQuk 7Ufa6091mXRMXtO62J+BTpHv11WEVc5v+Vf5+v8prFSU3rcAqaMTtL6rxKd+nauaFHhA YAV5vlyQbiRX9ZzGk7PosZCKQYCAfW6EqSyiR0MTFzLojOEIGMIu7ohUBvRKrgIUi30C 5xWA== X-Gm-Message-State: AN3rC/6LTWtlzEZxNFWuhgwOjLHQejFrRK05Jlju6gX6nnYxnJN8EAA4CV2C7V51sNOI+HZz8rgvmy+G6kNZ6w== X-Received: by 10.28.71.8 with SMTP id u8mr153711wma.39.1491954162225; Tue, 11 Apr 2017 16:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.131.225 with HTTP; Tue, 11 Apr 2017 16:42:41 -0700 (PDT) In-Reply-To: References: <2151650.Y6dYBXdtR5@strawberry> <04bbsNGwBdLiye5VgB_cNxkCNiOSNJBWFpI2QbN_o_ZQWRLEU7FjgkfOi5DZXrrBeQIuacMn_JHGzzX4dCmoyjmpT6PI9GZDu3JDgpgT4Pw=@protonmail.com> From: Jimmy Song Date: Tue, 11 Apr 2017 18:42:41 -0500 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=94eb2c0d0918dc5a23054ceca51d X-Spam-Status: No, score=0.2 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,URIBL_BLACK 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: Tue, 11 Apr 2017 23:47:25 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] A Small Modification to Segwit 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: Tue, 11 Apr 2017 23:42:44 -0000 --94eb2c0d0918dc5a23054ceca51d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jorge, I'll be happy to discuss with you more about whether allowing ASICBoost would actually secure the network more or not, but that's not my main motivation. My main motivation is to get more miners to accept segwit. The version bit usage part, I don't believe requires any code changes as those bits aren't being used by BIP9 anyway, though some cleanup to restrict them later is probably a good idea. The requiring witness commitment part would require some changes, but according to Timo Hanke, that's actually not necessary as overt is so much more efficient. In any case, I'm happy to close this discussion until there's some indication that more miners would accept segwit as a result of this change. Jimmy On Tue, Apr 11, 2017 at 4:25 PM, Jorge Tim=C3=B3n wrote: > On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev > wrote: > > I've changed the proposal so only 8 bits are given to grinding so > something > > like 20 bits are available for signaling. > > > > I have to say I'm at a loss here as to what's next? Should I make a new > BIP > > or try to convince the authors of BIP141 to modify their BIP? Could > someone > > inform me on the next part of the process? > > See bip2, specifically > https://github.com/bitcoin/bips/blob/master/bip-0002. > mediawiki#bip-workflow > > "Following a discussion, the proposal should be submitted to the BIPs > git repository as a pull request. This draft must be written in BIP > style as described below, and named with an alias such as > "bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP > number (authors MUST NOT self-assign BIP numbers)." > > But I think it's kind of late to modify bip141, given that there's > code out there with the current specification. > I guess you can propose extensions or alternatives to replace it. I'm > really not sure what's the next step, but I don't think you have > provided enough motivation as to why we would want to maintain > asicboost. You said it makes the network more secure, but that's not > the case, as explained, not even if all honest miners use it. > > > On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev > > wrote: > >> > >> Tom Zander wrote: > >> > >> > The version field is still needed to actually allow future block > version > >> > upgrades. We would cut off our road forward if that were to be > blocked. > >> > >> I tend to agree, if all 32 bits were given up to grinding. > >> > >> But it's worth pointing out that BIP9 is purely informational, and the > top > >> 3 bits are still reserved for other purposes. One of them could perhap= s > be > >> used to signal for an extended version field somewhere else, leaving t= he > >> bottom 29 as entropy? > >> > >> Not a direction I prefer, but just a technical possibility perhaps. > >> > >> _______________________________________________ > >> 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 > > > --94eb2c0d0918dc5a23054ceca51d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jorge, I'll be happy to discuss with you more about wh= ether allowing ASICBoost would actually secure the network more or not, but= that's not my main motivation. My main motivation is to get more miner= s to accept segwit.=C2=A0

The version bit usage part, I = don't believe requires any code changes as those bits aren't being = used by BIP9 anyway, though some cleanup to restrict them later is probably= a good idea.
The requiring witness commitment part would require= some changes, but according to Timo Hanke, that's actually not necessa= ry as overt is so much more efficient.

In any case= , I'm happy to close this discussion until there's some indication = that more miners would accept segwit as a result of this change.
=
Jimmy

On Tue, Apr 11, 2017 at 4:25 PM, Jorge Tim=C3=B3n <jtimon@= jtimon.cc> wrote:
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> I've changed the proposal so only 8 bits are given to grinding so = something
> like 20 bits are available for signaling.
>
> I have to say I'm at a loss here as to what's next? Should I m= ake a new BIP
> or try to convince the authors of BIP141 to modify their BIP? Could so= meone
> inform me on the next part of the process?

See bip2, specifically
https://github.com/bitcoi= n/bips/blob/master/bip-0002.mediawiki#bip-workflow

"Following a discussion, the proposal should be submitted to the BIPs<= br> git repository as a pull request. This draft must be written in BIP
style as described below, and named with an alias such as
"bip-johndoe-infinitebitcoins" until the editor has assigned it a= BIP
number (authors MUST NOT self-assign BIP numbers)."

But I think it's kind of late to modify bip141, given that there's<= br> code out there with the current specification.
I guess you can propose extensions or alternatives to replace it. I'm really not sure what's the next step, but I don't think you have provided enough motivation as to why we would want to maintain
asicboost. You said it makes the network more secure, but that's not the case, as explained, not even if all honest miners use it.

> On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
> <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
>>
>> Tom Zander wrote:
>>
>> > The version field is still needed to actually allow future bl= ock version
>> > upgrades. We would cut off our road forward if that were to b= e blocked.
>>
>> I tend to agree, if all 32 bits were given up to grinding.
>>
>> But it's worth pointing out that BIP9 is purely informational,= and the top
>> 3 bits are still reserved for other purposes. One of them could pe= rhaps be
>> used to signal for an extended version field somewhere else, leavi= ng the
>> bottom 29 as entropy?
>>
>> Not a direction I prefer, but just a technical possibility perhaps= .
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--94eb2c0d0918dc5a23054ceca51d--