path: root/9a/11a2583db96f44532fec140fb99e30773e9444

Return-Path: <jaejoon@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C0BE840F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Apr 2017 15:17:49 +0000 (UTC)
Received: by mail-wm0-f48.google.com with SMTP id t189so10486311wmt.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
	<CAJR7vkri7UX2Mqsdp0y21FapQBeg49oHFM_eLUd=ZBarzGc3-A@mail.gmail.com>
	<201704081459.13185.luke@dashjr.org>
From: Jimmy Song <jaejoon@gmail.com>
Date: Sat, 8 Apr 2017 10:17:47 -0500
Message-ID: <CAJR7vkp4XCzqp-Lw4T_ssV8ZW0vgto62x7ee3PHzyZfAuK_=9w@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
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 <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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 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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">I think it might be important=
 that the mandatory commitment expire as in<br>
Greg&#39;s proposal - when we do eventually hardfork, it will be simpler to=
 do in<br>
a safe manner if such a commitment in the fake &quot;old block&quot; is not=
 required.<br></blockquote><div><br></div><div>OK, that makes sense. I&#39;=
ll modify my proposal this way:</div><div><br></div><span style=3D"font-siz=
e:12.8px">Beginning block X and until block Y the coinbase transaction of</=
span><br style=3D"font-size:12.8px"><div><span style=3D"font-size:12.8px">e=
ach block MUST contain a BIP-141 segwit commitment</span></div><div><span s=
tyle=3D"font-size:12.8px"></span>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
I don&#39;t like your proposal because it allows ASICBoost. ASICBoost effec=
tively<br>
makes SHA2 semi-ASIC-resistant. ASIC-resistance raises the barrier of entry=
 to<br>
new mining chip manufacturers, and gives a larger advantage to the miners a=
ble<br>
to make use of it. Instead, IMO we should fix the vulnerability exploited b=
y<br>
ASICBoost entirely to keep SHA2 as ASIC-friendly as possible - or change th=
e<br>
PoW to an algorithm that is more ASIC-friendly.<br></blockquote><div><br></=
div><div>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.</div><div><br></div><div>Jimmy</div><d=
iv>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That being said, I don&#39;t think I would oppose the proposal if it gained=
<br>
notably better support than Segwit currently has (as yet another compromise=
),<br>
and the above concerns were addressed (eg, Bitfury and Canaan state they ca=
n<br>
compete using ASICBoost and the patents are licensed freely to everyone).<b=
r>
<br>
Luke<br>
<span class=3D"m_2281539948983386820gmail-"><br>
<br>
On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote:<b=
r>
&gt; I&#39;ve gotten feedback from Adam Back that you actually don&#39;t ne=
ed all 32<br>
&gt; bits in the header for overt ASICBoost, so I&#39;m modifying my propos=
al. Of<br>
&gt; the 32-bit version field, bits 16 to 23 are reserved for miners, the<b=
r>
&gt; witness commitment stays as defined in BIP-141 except that it&#39;s no=
w<br>
&gt; required. BIP9 then is modified so that bits 16 to 23 are now no longe=
r<br>
&gt; usable.<br>
&gt;<br>
&gt; On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song &lt;<a href=3D"mailto:jaejo=
on@gmail.com" target=3D"_blank">jaejoon@gmail.com</a>&gt; wrote:<br>
&gt; &gt; Hey everyone, This is an idea that I had about Segwit and Gregory=
&#39;s<br>
&gt; &gt; proposal from yesterday that I wanted to run by everyone on this =
list.<br>
&gt; &gt; I&#39;m not at all sure what this would mean for non-upgraded nod=
es on the<br>
&gt; &gt; network and would like feedback on that. This is not a formal BIP=
 as<br>
&gt; &gt; it&#39;s a modification to a previously submitted one, but I&#39;=
m happy to<br>
&gt; &gt; formalize it if it would help.<br>
&gt; &gt; ------------------------------<wbr>----------<br>
</span>&gt; &gt; MotivationOne of the interesting aspects of Gregory Maxwel=
l=E2=80=99s proposal is<br>
<div class=3D"m_2281539948983386820gmail-HOEnZb"><div class=3D"m_2281539948=
983386820gmail-h5">&gt; &gt; that it only precludes the covert version of A=
SICBoost. He specifically<br>
&gt; &gt; left the overt version alone.<br>
&gt; &gt;<br>
&gt; &gt; Overt ASICBoost requires grinding on the version bits of the Bloc=
k header<br>
&gt; &gt; instead of the Merkle Root. This is likely more efficient than th=
e Merkle<br>
&gt; &gt; Root grinding (aka covert ASICBoost) and requires way less resour=
ces<br>
&gt; &gt; (much less RAM, SHA256 calculations, no tx shuffling, etc).<br>
&gt; &gt;<br>
&gt; &gt; If we combine Gregory Maxwell=E2=80=99s proposal with BIP-141 (Se=
gwit) and add a<br>
&gt; &gt; slight modification, this should, in theory, make ASICBoost a lot=
 more<br>
&gt; &gt; useful to miners and appeal to their financial interests.<br>
&gt; &gt; The Modification<br>
&gt; &gt;<br>
&gt; &gt; Currently, the version bits (currently 4 bytes, or 32 bits) in th=
e header<br>
&gt; &gt; are used for BIP9 signaling. We change the version bits to a nonc=
e-space<br>
&gt; &gt; so the miners can use it for overt ASICBoost. The 32-bits are now=
 moved<br>
&gt; &gt; over to the Coinbase transaction as part of the witness commitmen=
t. The<br>
&gt; &gt; witness commitment goes from 38 bytes to 42 bytes, with the last =
4 bytes<br>
&gt; &gt; being used as the version bits in the block header previously. Th=
e<br>
&gt; &gt; witness commitment becomes required as per Gregory Maxwell=E2=80=
=99s proposal.<br>
&gt; &gt; Reasoning<br>
&gt; &gt;<br>
&gt; &gt; First, this brings ASICBoost out into the open. Covert ASICBoost =
becomes<br>
&gt; &gt; much more costly and overt ASICBoost is now encouraged.<br>
&gt; &gt;<br>
&gt; &gt; Second, we can make this change relatively quickly. Most of the S=
egwit<br>
&gt; &gt; testing stays valid and this change can be deployed relatively qu=
ickly.<br>
&gt; &gt;<br>
&gt; &gt; Note on SPV clients<br>
&gt; &gt;<br>
&gt; &gt; Currently Segwit stores the witness commitment in the Coinbase tx=
, so<br>
&gt; &gt; lightweight clients will need to get the Coinbase tx + Merkle pro=
of to<br>
&gt; &gt; validate segwit transactions anyway. Putting block version inform=
ation in<br>
&gt; &gt; the Coinbase tx will not impose an extra burden on upgraded light=
<br>
&gt; &gt; clients.<br>
</div></div></blockquote></div><br></div></div>

--001a114b2ec4af7c8e054ca93e07--