path: root/0c/6fbed0545868e254c84d3fb57f1cbe8dc4db52

Return-Path: <timo.t.hanke@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 802E66C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Apr 2017 16:19:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com
	[209.85.213.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8CABA5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  8 Apr 2017 16:19:03 +0000 (UTC)
Received: by mail-vk0-f46.google.com with SMTP id d188so92063764vka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 08 Apr 2017 09:19:03 -0700 (PDT)
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;
	bh=fUwvPUlPg2JiYl0WJsdIMtoUD49ZX+yTZ5zwG2JA5ug=;
	b=nJYeel0Q5iNglz5cTpcuqj4RJ71RVItXKkQa8pqaWk7wXbY4qYGH32Ee7tyWaIF8zX
	mKwGzSeVM+qBub0VT9oa0EiLeK31iQA8u3d7tVPTsKs/QeMjcKLeB0HiqCjsk+b+z1x0
	F8iB4BC0cHajvDtzTS9EYKCEUTDW4cQAI4VIhKk02U2+8zG5SyEdwIiQCjjS9sv8W9Fk
	aE3kt3gs4soWWEu7cPV28nuMPIVYb1sxtWBcOsGTjZUCh9Kfha33RWmtlZEdSBGaFnMR
	m6qecmfO3/EWIreWAQFFKTpnaa9yB8Zups78bQePGtGy5N6zv6zfuUbvVBvAHF+mb6so
	j5zw==
X-Gm-Message-State: AFeK/H2f/9aS5uXxlUC0Cp1CGyrGvHPdy5S12+Bz1OkXxuXZB74eVskeKJDd3V3CXs6+SQ==
X-Received: by 10.31.47.213 with SMTP id v204mr21271113vkv.2.1491668342653;
	Sat, 08 Apr 2017 09:19:02 -0700 (PDT)
Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com.
	[209.85.217.178])
	by smtp.gmail.com with ESMTPSA id l94sm2207569ual.1.2017.04.08.09.19.02
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 08 Apr 2017 09:19:02 -0700 (PDT)
Received: by mail-ua0-f178.google.com with SMTP id q26so6867369uaa.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 08 Apr 2017 09:19:02 -0700 (PDT)
X-Received: by 10.159.36.11 with SMTP id 11mr1236700uaq.84.1491668341854; Sat,
	08 Apr 2017 09:19:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.122.149 with HTTP; Sat, 8 Apr 2017 09:19:01 -0700 (PDT)
In-Reply-To: <CAJR7vkri7UX2Mqsdp0y21FapQBeg49oHFM_eLUd=ZBarzGc3-A@mail.gmail.com>
References: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
	<CAJR7vkri7UX2Mqsdp0y21FapQBeg49oHFM_eLUd=ZBarzGc3-A@mail.gmail.com>
From: Timo Hanke <timo.hanke@web.de>
Date: Sat, 8 Apr 2017 09:19:01 -0700
X-Gmail-Original-Message-ID: <CAH6h1LssVvAw8Mk6=f+Yg_U7nhZkC51ev2O-z4coDMOUhU3+Fg@mail.gmail.com>
Message-ID: <CAH6h1LssVvAw8Mk6=f+Yg_U7nhZkC51ev2O-z4coDMOUhU3+Fg@mail.gmail.com>
To: Jimmy Song <jaejoon@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11353ba8a39d54054caa19c4
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,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
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 16:19:04 -0000

--001a11353ba8a39d54054caa19c4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, you only need a few bits in the version number, probably less than 8.

If you encourage the overt method of using AsicBoost I would argue that you
no longer need to dis-encourage the couvert method anymore as in Greg's
proposal. Nobody would use the couvert method anyway because the overt
method is so much simpler. So maybe the proposals can be completely
disentangled?


On Fri, Apr 7, 2017 at 5:05 PM, Jimmy Song via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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.
>
> 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 the netwo=
rk
>> 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 i=
t
>> if it would help.
>> ----------------------------------------
>> MotivationOne of the interesting aspects of Gregory Maxwell=E2=80=99s pr=
oposal
>> 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 th=
e
>> 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) a=
nd 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 heade=
r
>> 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 witne=
ss
>> 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 i=
n
>> the Coinbase tx will not impose an extra burden on upgraded light client=
s.
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a11353ba8a39d54054caa19c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Yes, you only need a few bits in the version number, =
probably less than 8.=C2=A0<br></div><div><br></div><div>If you encourage t=
he overt method of using AsicBoost I would argue that you no longer need to=
 dis-encourage the couvert method anymore as in Greg&#39;s proposal. Nobody=
 would use the couvert method anyway because the overt method is so much si=
mpler. So maybe the proposals can be completely disentangled?</div><div><br=
></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On F=
ri, Apr 7, 2017 at 5:05 PM, Jimmy Song via bitcoin-dev <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr">I&#39;ve gotten feedback from Adam Ba=
ck that you actually don&#39;t need all 32 bits in the header for overt ASI=
CBoost, so I&#39;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&#39;s now required. BIP9 then is modified so that=
 bits 16 to 23 are now no longer usable.</div><div class=3D"HOEnZb"><div cl=
ass=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri=
, Apr 7, 2017 at 3:06 PM, Jimmy Song <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:jaejoon@gmail.com" target=3D"_blank">jaejoon@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><h3 name=3D"d843" cl=
ass=3D"m_-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191=
437844027m_-1233224201548509828gmail-graf--h3"><span style=3D"font-weight:n=
ormal"><font size=3D"2">Hey everyone,=C2=A0</font></span></h3><h3 name=3D"d=
843" class=3D"m_-6096572191437844027m_-1233224201548509828gmail-graf m_-609=
6572191437844027m_-1233224201548509828gmail-graf--h3"><span style=3D"font-w=
eight:normal"><font size=3D"2">This is an idea that I had about Segwit and =
Gregory&#39;s proposal from yesterday that I wanted to run by everyone on t=
his list. I&#39;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&#39;s a modification to a previously submitted one, but I&#39;m happ=
y to formalize it if it would help.</font></span></h3><div><span style=3D"f=
ont-weight:normal"><font size=3D"2">------------------------------<wbr>----=
------</font></span></div><h3 name=3D"d843" class=3D"m_-6096572191437844027=
m_-1233224201548509828gmail-graf m_-6096572191437844027m_-12332242015485098=
28gmail-graf--h3"><span style=3D"font-weight:normal"><font size=3D"2">Motiv=
ation</font></span></h3><h3 name=3D"d843" class=3D"m_-6096572191437844027m_=
-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828=
gmail-graf--h3"><span style=3D"font-weight:normal"><font size=3D"2">One of =
the interesting aspects of Gregory Maxwell=E2=80=99s proposal is that it on=
ly precludes the <span class=3D"m_-6096572191437844027m_-123322420154850982=
8gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup-=
-p-em">covert</span> version of ASICBoost. He specifically left the <span c=
lass=3D"m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-609=
6572191437844027m_-1233224201548509828gmail-markup--p-em">overt</span> vers=
ion alone.<br></font></span></h3><p name=3D"416c" class=3D"m_-6096572191437=
844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-12332242015=
48509828gmail-graf--p"><span class=3D"m_-6096572191437844027m_-123322420154=
8509828gmail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-m=
arkup--p-em">Overt</span> ASICBoost requires grinding on the version bits o=
f the Block header instead of the Merkle Root. This is likely more efficien=
t than the Merkle Root grinding (aka <span class=3D"m_-6096572191437844027m=
_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-123322420154=
8509828gmail-markup--p-em">covert</span> ASICBoost) and requires way less r=
esources (much less RAM, SHA256 calculations, no tx shuffling, etc).</p><p =
name=3D"26c8" class=3D"m_-6096572191437844027m_-1233224201548509828gmail-gr=
af m_-6096572191437844027m_-1233224201548509828gmail-graf--p">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 m=
iners and appeal to their financial interests.=C2=A0</p><h3 name=3D"49b1" c=
lass=3D"m_-6096572191437844027m_-1233224201548509828gmail-graf m_-609657219=
1437844027m_-1233224201548509828gmail-graf--h3"><font size=3D"2" style=3D"f=
ont-weight:normal">The Modification</font></h3><p name=3D"d82f" class=3D"m_=
-6096572191437844027m_-1233224201548509828gmail-graf m_-6096572191437844027=
m_-1233224201548509828gmail-graf--p">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 <span class=
=3D"m_-6096572191437844027m_-1233224201548509828gmail-markup--em m_-6096572=
191437844027m_-1233224201548509828gmail-markup--p-em">overt</span> ASICBoos=
t. The 32-bits are now moved over to the Coinbase transaction as part of th=
e 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.</p><h3 name=3D"bf2c" class=3D"m_-6096572191437844027m_=
-1233224201548509828gmail-graf m_-6096572191437844027m_-1233224201548509828=
gmail-graf--h3"><font size=3D"2" style=3D"font-weight:normal">Reasoning</fo=
nt></h3><p name=3D"7083" class=3D"m_-6096572191437844027m_-1233224201548509=
828gmail-graf m_-6096572191437844027m_-1233224201548509828gmail-graf--p">Fi=
rst, this brings ASICBoost out into the open. <span class=3D"m_-60965721914=
37844027m_-1233224201548509828gmail-markup--em m_-6096572191437844027m_-123=
3224201548509828gmail-markup--p-em">Covert</span> ASICBoost becomes much mo=
re costly and <span class=3D"m_-6096572191437844027m_-1233224201548509828gm=
ail-markup--em m_-6096572191437844027m_-1233224201548509828gmail-markup--p-=
em">overt</span> ASICBoost is now encouraged.</p><p name=3D"e25f" class=3D"=
m_-6096572191437844027m_-1233224201548509828gmail-graf m_-60965721914378440=
27m_-1233224201548509828gmail-graf--p">Second, we can make this change rela=
tively quickly. Most of the Segwit testing stays valid and this change can =
be deployed relatively quickly.</p><p name=3D"b417" class=3D"m_-60965721914=
37844027m_-1233224201548509828gmail-graf m_-6096572191437844027m_-123322420=
1548509828gmail-graf--p">Note on SPV clients</p><p name=3D"b417" class=3D"m=
_-6096572191437844027m_-1233224201548509828gmail-graf m_-609657219143784402=
7m_-1233224201548509828gmail-graf--p">Currently Segwit stores the witness c=
ommitment in the Coinbase tx, so lightweight clients will need to get the C=
oinbase tx + Merkle proof to validate segwit transactions anyway. Putting b=
lock version information in the Coinbase tx will not impose an extra burden=
 on upgraded light clients.<br></p></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a11353ba8a39d54054caa19c4--