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 C0BE840F for ; Sat, 8 Apr 2017 15:17:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C09DB127 for ; Sat, 8 Apr 2017 15:17:49 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id t189so10486311wmt.1 for ; Sat, 08 Apr 2017 08:17:49 -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=X8e1UmhIOycCb4vd8tid/2TzxUbo65WtMlYM6RmDtsk=; b=QSfxC07zIjduUV04Rt/oGwmU7ZFA8CU9+G1bUUUpWklq+eEoPVgmmlHUqIfzr6GxpC L00OH5k3l8Nw6jt0lVJpz23utWfk2I3qWYm9xJ4Dtvl5lKUK0v3ynbID4lJYyEq800kP HMgWPhT5lwz9DhNWgnymQbt1TLs/1ncSnOiM0IRGC6HeWsKAOLv0gSdOqdA4iWILdSwl v6zG1wW/erTvzU/XB/fvQEf1RyFdskZrk2zjEnOdokYGPJUs1aedT82eLAUgMJ2Hu16z ZzHdRus8EqIw48POKYeD39SEJyXtC9WsB30caUOfINeCKX/3KZL0CfzL8ksyga+98n/j TctQ== 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=X8e1UmhIOycCb4vd8tid/2TzxUbo65WtMlYM6RmDtsk=; b=s7ufJcu+AwlLlUQ+49yUsGIj87Ysnfzu1drimA6aWd8wCbyErAseFzNOGkyvdMEbiG gvAXWLYl7zBltjsOLjvJPfbShmkFlajjjcWHMYxgM5RMsu85joeloVIPoXUdLXSJFySZ RRfwaEPfIy8GKkX/REzb9SKnbx5yKVeGohhnO456ZCvvvNgAHUzsKZi5EKZlumE2Qyag TWfVj52jp1AQ+q6EvF7wjjoBXCkEP3T9nea5qdnp2kW4tZWWUI2RpZkLZjNvFDV6GbJ/ ebvCooTSmKwdv5/vYOjr0On3h88CHcxDhmwpunW5Zuo8088y89+kANQGUjL0Yg17UvzC 8sJw== X-Gm-Message-State: AN3rC/44M9RIV8G7pue7BPuLEpbyB09GVpIMkGXkzZNKyO9FhJH2/DzT/lwltIMU+RqfT+Au7XmScJKrNJyQqA== X-Received: by 10.28.102.86 with SMTP id a83mr3655475wmc.76.1491664668420; Sat, 08 Apr 2017 08:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.134.243 with HTTP; Sat, 8 Apr 2017 08:17:47 -0700 (PDT) In-Reply-To: <201704081459.13185.luke@dashjr.org> References: <201704081459.13185.luke@dashjr.org> From: Jimmy Song Date: Sat, 8 Apr 2017 10:17:47 -0500 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary=001a114b2ec4af7c8e054ca93e07 X-Spam-Status: No, score=-1.5 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 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: Sat, 08 Apr 2017 16:22:32 +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 15:17:50 -0000 --001a114b2ec4af7c8e054ca93e07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > I think it might be important that the mandatory commitment expire as in > Greg's proposal - when we do eventually hardfork, it will be simpler to d= o > in > a safe manner if such a commitment in the fake "old block" is not require= d. > OK, that makes sense. I'll modify my proposal this way: Beginning block X and until block Y the coinbase transaction of each block MUST contain a BIP-141 segwit commitment > I don't like your proposal because it allows ASICBoost. ASICBoost > effectively > makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of > entry to > new mining chip manufacturers, and gives a larger advantage to the miners > able > to make use of it. Instead, IMO we should fix the vulnerability exploited > by > ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change > the > PoW to an algorithm that is more ASIC-friendly. > Overt ASICBoost is allowed on the network already. Until a proposal explicitly blocking overt ASICBoost as a soft fork is activated, this seems to be better than the current state which is that overt ASICBoost is allowed, but at a cost to BIP9 signals. Jimmy > That being said, I don't think I would oppose the proposal if it gained > notably better support than Segwit currently has (as yet another > compromise), > and the above concerns were addressed (eg, Bitfury and Canaan state they > can > 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. O= f > > 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 th= e > > > 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= proposal > is > > > that it only precludes the covert version of ASICBoost. He specifical= ly > > > 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 mor= e > > > 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 mov= ed > > > over to the Coinbase transaction as part of the witness commitment. T= he > > > 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 Segwi= t > > > testing stays valid and this change can be deployed relatively quickl= y. > > > > > > 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 t= o > > > validate segwit transactions anyway. Putting block version informatio= n > in > > > the Coinbase tx will not impose an extra burden on upgraded light > > > clients. > --001a114b2ec4af7c8e054ca93e07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it might be important= that the mandatory commitment expire as in
Greg's proposal - when we do eventually hardfork, it will be simpler to= do in
a safe manner if such a commitment in the fake "old block" is not= required.

OK, that makes sense. I'= ll modify my proposal this way:

Beginning block X and until block Y the coinbase transaction of
e= ach block MUST contain a BIP-141 segwit commitment
=C2=A0
I don't like your proposal because it allows ASICBoost. ASICBoost effec= tively
makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of entry= to
new mining chip manufacturers, and gives a larger advantage to the miners a= ble
to make use of it. Instead, IMO we should fix the vulnerability exploited b= y
ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change th= e
PoW to an algorithm that is more ASIC-friendly.

Overt ASICBoost is allowed on the network already. Until a proposa= l explicitly blocking overt ASICBoost as a soft fork is activated, this see= ms to be better than the current state which is that overt ASICBoost is all= owed, but at a cost to BIP9 signals.

Jimmy
=C2=A0
That being said, I don't think I would oppose the proposal if it gained=
notably better support than Segwit currently has (as yet another compromise= ),
and the above concerns were addressed (eg, Bitfury and Canaan state they ca= n
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 ne= ed all 32
> bits in the header for overt ASICBoost, so I'm modifying my propos= al. 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 no= w
> required. BIP9 then is modified so that bits 16 to 23 are now no longe= r
> usable.
>
> On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song <jaejoon@gmail.com> 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 nod= es 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 Maxwel= l=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 bits of the Bloc= k header
> > instead of the Merkle Root. This is likely more efficient than th= e Merkle
> > Root grinding (aka covert ASICBoost) and requires way less resour= ces
> > (much less RAM, SHA256 calculations, no tx shuffling, etc).
> >
> > If we combine Gregory Maxwell=E2=80=99s proposal with BIP-141 (Se= gwit) 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 th= e header
> > are used for BIP9 signaling. We change the version bits to a nonc= e-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 commitmen= t. 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. Th= e
> > 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 S= egwit
> > 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
> > lightweight clients will need to get the Coinbase tx + Merkle pro= of to
> > validate segwit transactions anyway. Putting block version inform= ation in
> > the Coinbase tx will not impose an extra burden on upgraded light=
> > clients.

--001a114b2ec4af7c8e054ca93e07--