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 802E66C for ; 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 ; Sat, 8 Apr 2017 16:19:03 +0000 (UTC) Received: by mail-vk0-f46.google.com with SMTP id d188so92063764vka.0 for ; 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 (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 ; 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: References: From: Timo Hanke Date: Sat, 8 Apr 2017 09:19:01 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jimmy Song , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Yes, you only need a few bits in the version number, = probably less than 8.=C2=A0

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'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?

On F= ri, Apr 7, 2017 at 5:05 PM, Jimmy Song via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:
I've gotten feedback from Adam Ba= ck that you actually don't need all 32 bits in the header for overt ASI= CBoost, 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> wro= te:

Hey everyone,=C2=A0

This is an idea that I had about Segwit and = Gregory's proposal from yesterday that I wanted to run by everyone on t= his 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 happ= y to formalize it if it would help.

----------------------------------= ------

Motiv= ation

One of = the interesting aspects of Gregory Maxwell=E2=80=99s proposal is that it on= ly precludes the covert version of ASICBoost. He specifically left the overt vers= ion alone.

Overt 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 covert ASICBoost) and requires way less r= esources (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 more useful to m= iners and appeal to their financial interests.=C2=A0

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

Reasoning

Fi= rst, this brings ASICBoost out into the open. Covert ASICBoost becomes much mo= re costly and overt ASICBoost is now encouraged.

Second, we can make this change rela= tively 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 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.



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a11353ba8a39d54054caa19c4--