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 EB48C899 for ; Sat, 8 Apr 2017 14:59:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3D4B6107 for ; Sat, 8 Apr 2017 14:59:30 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 9557A38A0058; Sat, 8 Apr 2017 14:59:14 +0000 (UTC) X-Hashcash: 1:25:170408:bitcoin-dev@lists.linuxfoundation.org::z9i5B/bd2ORkYaNs:dAUD X-Hashcash: 1:25:170408:jaejoon@gmail.com::wg=JnIWQ/O3Bf/sh:bgr8Z From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Jimmy Song Date: Sat, 8 Apr 2017 14:59:12 +0000 User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201704081459.13185.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.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: Sat, 08 Apr 2017 14:59:31 -0000 I think it might be important that the mandatory commitment expire as in=20 Greg's proposal - when we do eventually hardfork, it will be simpler to do = in=20 a safe manner if such a commitment in the fake "old block" is not required. I don't like your proposal because it allows ASICBoost. ASICBoost effective= ly=20 makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of entry= to=20 new mining chip manufacturers, and gives a larger advantage to the miners a= ble=20 to make use of it. Instead, IMO we should fix the vulnerability exploited b= y=20 ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change th= e=20 PoW to an algorithm that is more ASIC-friendly. That being said, I don't think I would oppose the proposal if it gained=20 notably better support than Segwit currently has (as yet another compromise= ),=20 and the above concerns were addressed (eg, Bitfury and Canaan state they ca= n=20 compete using ASICBoost and the patents are licensed freely to everyone). Luke On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote: > 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. >=20 > 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 > > 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 p= roposal is > > that it only precludes the covert version of ASICBoost. He specifically > > left the overt version alone. > >=20 > > Overt ASICBoost requires grinding on the version bits of the Block head= er > > instead of the Merkle Root. This is likely more efficient than the Merk= le > > Root grinding (aka covert ASICBoost) and requires way less resources > > (much less RAM, SHA256 calculations, no tx shuffling, etc). > >=20 > > 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 > >=20 > > Currently, the version bits (currently 4 bytes, or 32 bits) in the head= er > > 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 pr= oposal. > > Reasoning > >=20 > > First, this brings ASICBoost out into the open. Covert ASICBoost becomes > > much more costly and overt ASICBoost is now encouraged. > >=20 > > Second, we can make this change relatively quickly. Most of the Segwit > > testing stays valid and this change can be deployed relatively quickly. > >=20 > > Note on SPV clients > >=20 > > 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.