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 32F48BB3 for ; Sat, 8 Apr 2017 00:05:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5187FFC for ; Sat, 8 Apr 2017 00:05:18 +0000 (UTC) Received: by mail-wm0-f53.google.com with SMTP id w64so2919566wma.0 for ; Fri, 07 Apr 2017 17:05:18 -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; bh=pz8mq2c60gevKeVJb+E+Ouz1WnS92jCKRry2UWHG3B4=; b=IjI+DfMYLlSzVBr2RCNrPoraiBCcJm+XemYyGy8NnCNAhF53DR0+Gte6g6U4J5VdUX POyLQS2B6VsWn8+xPYbK6x8CWeVlc/MrkqsrTfkVDGpFEB8DTqiSjxN6J6NCrB5ZH24F R2xeGy+mT1FC1rNWbWPE/BWR6QRmB6jLvuaK3FeDOcAtqU6sza5Vesgo8mIbphvlUV5e oWEItnz5cgC4RwIX5jRVMefWqCdyFdAJqhciUIwtJ9yCM4vOYH3Cx4L6y8c/bnc3j60k ZsR3vJrLBVXASwoybEc4+9et1rdw0t6RiUNSrbmoYZ7xkevAkT9v0FAEb2+7M/bHxyez olAw== 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; bh=pz8mq2c60gevKeVJb+E+Ouz1WnS92jCKRry2UWHG3B4=; b=EV2xVojH/Ykd0ffqqMV8Zzy7FXFHhf6Eo7owPutXAzwrYoG0Jarr6HpHhxm8S9FYyc f7r2VUiLdSrPKy9mTIbBK3vos87y4wTZbwI1KNxcGZe/toZiuldVUfSaMQO4/oDNeN20 gAAFK9it3sNxh5DPdKovQ3m35No4ksSVn4Mh6E5pcFjXD3VsmXkbIae4r59Eg2nezK8a EGF7aI5a7DCajh+QqeO94xmWJLJHbH4o12p6WmsgXDQ8zOg+DhoS3HOcjTUHUT0s3Go+ +6LT1To1Z4YEgdZxlE4noGayXk2KHK0G/3CNyBrYdu52MqceSnKJXzeVf98E+27nl2+0 RTGg== X-Gm-Message-State: AN3rC/6O71Iz3CI92W96B8RR+eE4Da5aGSE5THIOd8ALd4AABRtquPt3 onTLlhaRBczzv8CTkMAv2XsFdOQbMnwH X-Received: by 10.28.212.67 with SMTP id l64mr1460428wmg.76.1491609916850; Fri, 07 Apr 2017 17:05:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.134.243 with HTTP; Fri, 7 Apr 2017 17:05:16 -0700 (PDT) In-Reply-To: References: From: Jimmy Song Date: Fri, 7 Apr 2017 19:05:16 -0500 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11469e583cca81054c9c7f20 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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: Sat, 08 Apr 2017 00:39:08 +0000 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: Sat, 08 Apr 2017 00:05:19 -0000 --001a11469e583cca81054c9c7f20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've gotten feedback from Adam Back that you actually don't need all 32 bits in the header for overt ASICBoost, so I'm modifying my proposal. Of the 32-bit version field, bits 16 to 23 are reserved for miners, the witness commitment stays as defined in BIP-141 except that it's now required. BIP9 then is modified so that bits 16 to 23 are now no longer usable. On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song wrote: > Hey everyone, This is an idea that I had about Segwit and Gregory's > proposal from yesterday that I wanted to run by everyone on this list. I'= m > not at all sure what this would mean for non-upgraded nodes on the networ= k > and would like feedback on that. This is not a formal BIP as it's a > modification to a previously submitted one, but I'm happy to formalize it > if it would help. > ---------------------------------------- > MotivationOne of the interesting aspects of Gregory Maxwell=E2=80=99s pro= posal is > that it only precludes the covert version of ASICBoost. He specifically > left the overt version alone. > > Overt ASICBoost requires grinding on the version bits of the Block header > instead of the Merkle Root. This is likely more efficient than the Merkle > Root grinding (aka covert ASICBoost) and requires way less resources > (much less RAM, SHA256 calculations, no tx shuffling, etc). > > If we combine Gregory Maxwell=E2=80=99s proposal with BIP-141 (Segwit) an= d add a > slight modification, this should, in theory, make ASICBoost a lot more > useful to miners and appeal to their financial interests. > The Modification > > Currently, the version bits (currently 4 bytes, or 32 bits) in the header > are used for BIP9 signaling. We change the version bits to a nonce-space = so > the miners can use it for overt ASICBoost. The 32-bits are now moved over > to the Coinbase transaction as part of the witness commitment. The witnes= s > commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being us= ed > as the version bits in the block header previously. The witness commitmen= t > becomes required as per Gregory Maxwell=E2=80=99s proposal. > Reasoning > > First, this brings ASICBoost out into the open. Covert ASICBoost becomes > much more costly and overt ASICBoost is now encouraged. > > Second, we can make this change relatively quickly. Most of the Segwit > testing stays valid and this change can be deployed relatively quickly. > > Note on SPV clients > > Currently Segwit stores the witness commitment in the Coinbase tx, so > lightweight clients will need to get the Coinbase tx + Merkle proof to > validate segwit transactions anyway. Putting block version information in > the Coinbase tx will not impose an extra burden on upgraded light clients= . > --001a11469e583cca81054c9c7f20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've gotten feedback from Adam Back that you actually = don't need all 32 bits in the header for overt ASICBoost, so I'm mo= difying my proposal. Of the 32-bit version field, bits 16 to 23 are reserve= d for miners, the witness commitment stays as defined in BIP-141 except tha= t it's now required. BIP9 then is modified so that bits 16 to 23 are no= w no longer usable.

On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaejoon@gmail.com&= gt; wrote:

Hey ev= eryone,=C2=A0

This is an idea that I had about Segwit and= Gregory's proposal from yesterday that I wanted to run by everyone on = this list. I'm not at all sure what this would mean for non-upgraded no= des on the network and would like feedback on that. This is not a formal BI= P as it's a modification to a previously submitted one, but I'm hap= py to formalize it if it would help.

---------------------------------= -------

Motivation

One of the interest= ing aspects of Gregory Maxwell=E2=80=99s proposal is that it only precludes= the covert version of ASICBoost. He specifical= ly left the overt version alone.

Overt ASICBoost re= quires grinding on the version bits of the Block header instead of the Merk= le Root. This is likely more efficient than the Merkle Root grinding (aka <= span class=3D"m_-1233224201548509828gmail-markup--em m_-1233224201548509828= gmail-markup--p-em">covert ASICBoost) and requires way less resource= s (much less RAM, SHA256 calculations, no tx shuffling, etc).

If we combine Gregory Maxwell=E2=80=99s proposal with BIP-141 (S= egwit) and add a slight modification, this should, in theory, make ASICBoos= t a lot more useful to miners and appeal to their financial interests.=C2= =A0

The Modification

Currently, the version bi= ts (currently 4 bytes, or 32 bits) in the header are used for BIP9 signalin= g. We change the version bits to a nonce-space so the miners can use it for= overt ASICBoost. The 32-bits are now moved ove= r to the Coinbase transaction as part of the witness commitment. The witnes= s commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being us= ed as the version bits in the block header previously. The witness commitme= nt becomes required as per Gregory Maxwell=E2=80=99s proposal.

Reasoning

First, this brings ASICBoost out into the open.= Covert ASICBoost becomes much more costly and = overt ASICBoost is now encouraged.

Second, we can make this change relatively quickly. Most of t= he Segwit testing stays valid and this change can be deployed relatively qu= ickly.

Note on SPV clients

= Currently Segwit stores the witness commitment in the Coinbase tx, so light= weight clients will need to get the Coinbase tx + Merkle proof to validate = segwit transactions anyway. Putting block version information in the Coinba= se tx will not impose an extra burden on upgraded light clients.


--001a11469e583cca81054c9c7f20--