Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 56914899 for ; Sat, 8 Apr 2017 16:38:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6553FF for ; Sat, 8 Apr 2017 16:38:05 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id w64so11677552wma.0 for ; Sat, 08 Apr 2017 09:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=braiins-cz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kesfdhjPqW+FZAig7YApCd+QX/PvggKnr7bG28ZuWs4=; b=0qw57c9YO0RSF3+w3cEwEuMsfYwDttqXILGX80wcPhRJ2hkhjZoPkikRdOn2s0ShQU J72UGBWtE+YQuIbWYpB+gIMqZOiH2Z8Bo8CVhAcN3Rkhj5dNDrHifvDoBzs5usKNnqbE 5S4emevqlfADLuRvij+lQv0sarK2yuCgCwuj+kBW6X97aPUW+3l0DsDc1/4H6jiKsOht Dfmm3ZSyMBvtNXNwbU9pxcvAnoXVgY17/HI0NTmCqjIk0bMmlB1FA8sK7YwomrHC5QUF 2IzF+ZKEABfhiY/UIxNj0V5/Hg4SFuAZpn1pTR8idJIO2omKrv4u+Mhcnw5OtftyH6Hp 5DzQ== 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=kesfdhjPqW+FZAig7YApCd+QX/PvggKnr7bG28ZuWs4=; b=gvQ+wsiqeFpgITJZ9X+SwJjSGrMGCEnuRyV8h3W6eNSH5nId6F/V2tI6j2nx8/clu5 BMuVOVr61V6ttpsj3EAW7wZqVYUlTHyzi2XU4XPvFTHItRMmIrKgpIj5+iJhbyCNNEMO lF/L+eKckVqtp5DnI2G5nA6dLhL7gD+9Y4du6TnmWDekxuBgjpokZFoUDcVP8qXjXZ9I AQRFHQH8NrXF+4Mc5TyNcNXhKrSjG/yEgKV0bNC7MJPd89ioVzrlXU50ES/UGPgXwBaD dS+V9Zze4LjIRJcEVOFZCXwg45kAi1hX5zHe34IQR5qRnqaFyXX3k+ZkzLKGU63WVUeV VZlg== X-Gm-Message-State: AN3rC/6G/mX/jFSju5cW25cIP/BpCW2nN63u4CXygx6ejm9aoTOd0kpdSGAfBHdYcCxvlRx6U5QE15l2NkCvdQ== X-Received: by 10.28.178.17 with SMTP id b17mr3598518wmf.23.1491669484523; Sat, 08 Apr 2017 09:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.223.138 with HTTP; Sat, 8 Apr 2017 09:38:03 -0700 (PDT) X-Originating-IP: [46.135.49.9] In-Reply-To: References: From: Pavel Moravec Date: Sat, 8 Apr 2017 18:38:03 +0200 Message-ID: To: Jimmy Song Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 16:44:20 +0000 Cc: Bitcoin Protocol Discussion 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 16:38:10 -0000 Jimmy, >> Until all miners update (firmware or hardware), the change encourages >> large difference in mining efficiency. And IMO it gives another >> advantage to large mining operations in general. > > Certainly, there would have to be changes for stratum, pool software, etc. > But the monetary incentives align to all the changes needed. I agree. I only wanted to make clear, that the impact would be significant. Lot of parties would be involved with nonequivalent starting positions. > Remember, overt ASICBoost can get something like a 12.5% efficiency boost > from toggling a single bit in the version (equivalent to 2 colliding work > items), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4% from > 4 bits (see https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf). In lieu > of an explicit allowance of overt ASICBoost, the monetary incentives lead to > odd BIP9 signaling, especially if 4 or more proposals signal at once. There > really isn't a practical way to block overt ASICBoost without forcing the > version bits to be some value. You can e.g. place the version number into a coinbase, similarly to block height. Then, it is the same (number of operations) as modifying the coinbase directly. A cost of version in coinbase is 4B per block, sure, but it allows to save all bits for "more useful" purposes. Either for BIP9 signalling or other future purposes I cannot see now. And it removes an incentive to mess with version bits. Mining empty blocks and finding collisions by toggling bits there can be prevented as well. > In other words, the question isn't about allowing/disallowing ASICBoost at > this point. The question is whether we want ASICBoost open or hidden. I think the ASICBoost can and should be prevented completely. Pavel