From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Jimmy Song <jaejoon@gmail.com>
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: <CAJR7vkpRhNsQsem-nFkeubX04xx1y7aHwCENfg0d1266oOsXMw@mail.gmail.com>
	<CAJR7vkri7UX2Mqsdp0y21FapQBeg49oHFM_eLUd=ZBarzGc3-A@mail.gmail.com>
In-Reply-To: <CAJR7vkri7UX2Mqsdp0y21FapQBeg49oHFM_eLUd=ZBarzGc3-A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201704081459.13185.luke@dashjr.org>
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
Precedence: list

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 <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
> > 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.