From: Jimmy Song <jaejoon@gmail•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Small Modification to Segwit
Date: Sat, 8 Apr 2017 10:17:47 -0500 [thread overview]
Message-ID: <CAJR7vkp4XCzqp-Lw4T_ssV8ZW0vgto62x7ee3PHzyZfAuK_=9w@mail.gmail.com> (raw)
In-Reply-To: <201704081459.13185.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 4581 bytes --]
>
> 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
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. 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
> > > 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’s proposal
> 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 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’s 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
> > >
> > > 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 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’s 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
> in
> > > the Coinbase tx will not impose an extra burden on upgraded light
> > > clients.
>
[-- Attachment #2: Type: text/html, Size: 5955 bytes --]
next prev parent reply other threads:[~2017-04-08 15:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 20:06 Jimmy Song
2017-04-08 0:05 ` Jimmy Song
2017-04-08 14:59 ` Luke Dashjr
2017-04-08 15:17 ` Jimmy Song [this message]
2017-04-08 16:05 ` Luke Dashjr
2017-04-08 16:16 ` Jimmy Song
2017-04-08 16:19 ` Timo Hanke
2017-04-08 1:48 ` praxeology_guy
2017-04-08 2:46 ` Jimmy Song
2017-04-08 8:33 ` Pavel Moravec
2017-04-08 14:35 ` Jimmy Song
2017-04-08 16:38 ` Pavel Moravec
2017-04-08 22:19 ` Jimmy Song
2017-04-08 18:15 ` praxeology_guy
2017-04-08 18:51 ` Eric Voskuil
2017-04-08 20:38 ` praxeology_guy
2017-04-09 11:46 ` Jorge Timón
2017-04-08 16:27 ` Jorge Timón
2017-04-08 17:22 ` Jorge Timón
2017-04-08 22:26 ` Jimmy Song
2017-04-09 11:48 ` Jorge Timón
2017-04-09 14:01 ` Jimmy Song
[not found] ` <CABm2gDqfsBREj2x5Uz9hxwt-Y6m=KHd2-hRw4gV0CbO+-8B0dg@mail.gmail.com>
2017-04-10 9:16 ` Jorge Timón
2017-04-09 18:44 ` Erik Aronesty
2017-04-09 21:16 ` Jared Lee Richardson
2017-04-09 23:51 ` David Vorick
2017-04-10 0:20 ` Erik Aronesty
2017-04-10 1:45 ` Thomas Daede
2017-04-10 14:34 ` Bram Cohen
2017-04-10 14:46 ` Bram Cohen
2017-04-10 15:25 ` g
2017-04-10 18:17 ` Erik Aronesty
2017-04-11 2:39 ` g
2017-04-11 18:39 ` Staf Verhaegen
2017-04-11 9:31 ` Sancho Panza
2017-04-11 13:00 ` Jorge Timón
2017-04-11 7:59 ` Tom Zander
2017-04-11 13:25 ` Sancho Panza
2017-04-11 14:40 ` Jimmy Song
2017-04-11 21:25 ` Jorge Timón
2017-04-11 23:42 ` Jimmy Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJR7vkp4XCzqp-Lw4T_ssV8ZW0vgto62x7ee3PHzyZfAuK_=9w@mail.gmail.com' \
--to=jaejoon@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox