Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B4EAAB9 for ; Fri, 7 Apr 2017 20:06:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D7C7106 for ; Fri, 7 Apr 2017 20:06:41 +0000 (UTC) Received: by mail-wm0-f54.google.com with SMTP id w64so241720wma.0 for ; Fri, 07 Apr 2017 13:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4BhDtWG+ErbfVleCC7XA9reZ/Sj4coV2krwyXq98GpI=; b=Zr2XyJtMiTPVWcB90ijAmbU0ot+fEtCJ7jQgNi+e1pVPeaiyvu85l//8bkVtalEpxD vAOXPd3RWqZAT+U4LykvXWbW5422yVO6LOyrRdlFXR+jFu1mtvQBGDwS7GK+d73sxzJW nz9K9XTVKbiNgTXJe7WsymEGlQfVv7nrhZEeJouaOoy6qMXqD82eAqtcOFL+lr+uPmi+ gmRqpDukKUjwaNc3MYCVjxRO0/lowj7UoslbNa6TKY0NOgwkQsREYnSRK8+pSGGpKJxj ntz6/nU+NnHUxZo0PYUG0s5RM5m7aiTyJFKjHjoe7gZj0S6OcN65ZlE6CMEvmPM3U4bf cibg== 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=4BhDtWG+ErbfVleCC7XA9reZ/Sj4coV2krwyXq98GpI=; b=reKStZRTxAV8wO0PBWv/tH6vk++IHZqcjplVBDM/pqejmb2h9cy7j2aFGwCrkBr31Y E5EUgVG3Lf74ssbg1vfLBFPmUblEUrXjDeyGVG6cwHfBlMNQRTKUSbCTs+xcCOPct/H0 Zl9d4LB/PoDodcHIQXUmy4V6wyR2uGI9HWbUP7VYWtnhqfCqy2vY1akaqA6ehmYx4ywe uu+sYtJCsyRZHx/P5VLyyw970MILV+63eIsNDZCq31ZctrDHWi6zZApzy9MvceP1tQ8z aYLxU7UYDC2S1ExOyIWts32lDziJuC4h2P5+DAfS52g7pzUeF9a4/zUlkOeAAgVmdiV1 oHBg== X-Gm-Message-State: AN3rC/7qsZGJO5t9R8SgQWz0L6Qz9WbZDnWfrLurO8UucPhTJsO+Hpjz 9o3E5FANeBRREtgM6aZgDKUP4BoTAXWr7kA= X-Received: by 10.28.163.68 with SMTP id m65mr842371wme.19.1491595600103; Fri, 07 Apr 2017 13:06:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.134.243 with HTTP; Fri, 7 Apr 2017 13:06:39 -0700 (PDT) From: Jimmy Song Date: Fri, 7 Apr 2017 15:06:39 -0500 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a114cd954e48fa2054c9929ae 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: Fri, 07 Apr 2017 20:41:10 +0000 Subject: [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: Fri, 07 Apr 2017 20:06:42 -0000 --001a114cd954e48fa2054c9929ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 network 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 propo= sal 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) and = 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 witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used as the version bits in the block header previously. The witness commitment 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. --001a114cd954e48fa2054c9929ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hey everyone,=C2=A0<= /span>

This is an idea that I had about = Segwit and Gregory's proposal from yesterday that I wanted to run by ev= eryone on this list. I'm not at all sure what this would mean for non-u= pgraded nodes on the network 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.

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

Motivation

One of the interesting aspe= cts of Gregory Maxwell=E2=80=99s proposal is that it only precludes the covert version of A= SICBoost. He specifically left the overt version alone.

Overt ASICBoost requires grinding on the version bit= s of the Block header instead of the Merkle Root. This is likely more effic= ient 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) and add a slight modification, this sho= uld, in theory, make ASICBoost a lot more useful to miners and appeal to th= eir financial interests.=C2=A0

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 witness commitment goes from 38 byte= s to 42 bytes, with the last 4 bytes being used as the version bits in the = block header previously. The witness commitment becomes required as per Gre= gory Maxwell=E2=80=99s proposal.

Reasoning

First, this brin= gs ASICBoost out into the open. Covert ASICBoost becomes much more costly and overt ASICBoost is now enco= uraged.

Second, we c= an make this change relatively quickly. Most of the Segwit testing stays va= lid and this change can be deployed relatively quickly.

Note on SPV clients

Currently Segwit stores the witness com= mitment in the Coinbase tx, so lightweight clients will need to get the Coi= nbase tx + Merkle proof to validate segwit transactions anyway. Putting blo= ck version information in the Coinbase tx will not impose an extra burden o= n upgraded light clients.

--001a114cd954e48fa2054c9929ae--