Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 36839FD8 for ; Mon, 1 Feb 2016 19:29:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3FA5168 for ; Mon, 1 Feb 2016 19:29:32 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id 5so19380631igt.0 for ; Mon, 01 Feb 2016 11:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=PNyn+QXQ5+e/dWnnbuBOjhCq2MK3psWSxDTPTRODu0M=; b=hw42btSvq7Ombte2xXdjsvTN9F7x5at6fq8xRUdSBj783gv2CH+yIVBNJWjbIG0Dgx +TQ238AYBcM1Jzl9AG+RMO4RTPNIqyFxuTlTKZn2CZ862fX6wI8hKc34HACl+tccU2sP O93ehyvnqxrEyfXHLFz6f83ozww/H8KyR//C4T4NcVyejYXgWOdOQsKdGDwL84kNN0oj bQi2Xo8fRBrguQF1EHKBB2/EktV5beV7diiPxR+2wwINrZgc8oNhB2j/0Eo/tPb3PbPC NrEmjTVsXOt1nnEWBHD/M/24W947JroYR3dNpfftJCnNnDqLBYZG9wesIxkwxVhxON+0 xHzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=PNyn+QXQ5+e/dWnnbuBOjhCq2MK3psWSxDTPTRODu0M=; b=NsP6gHve//uIdGMMY3JfgyASZS941/7lhuaK7cjO5cewlwWpAB9VugqTUH7i2C/7OR mxqr4cWcYTAHCQvkTjaNixoVYKB5CAFdYpgqN7sLVpf0bOhC2DFyAPT8PzXIAPBxpT+5 UtGYU2R/zL/AaP1Ms05qU3Q/sbU7xRcgnFy8uWa4Mufuyi7Wlm1QmFPsSPCWmcgG04gT 1AILsrvrYQyRghJJ+F/DceBu9g6C1JPL3m+3oxwed1mdXRD3PyplYd8cblqUG/FGcOx/ u37QiDh9oLmEYCgr2trytONdoEUPCxpvfRD68Lz10TGgP3Ib6Q1+p/tL7eYDaJSViAUX TvLg== X-Gm-Message-State: AG10YOSWiolH5wBtBl7VrFaUTzEByb6+LZ69pWhiDu12TPldVry8o/UB1OzOMsExbfBP4mGMBODetZpxfEuxmA== MIME-Version: 1.0 X-Received: by 10.50.73.137 with SMTP id l9mr13043271igv.95.1454354972181; Mon, 01 Feb 2016 11:29:32 -0800 (PST) Received: by 10.79.77.65 with HTTP; Mon, 1 Feb 2016 11:29:32 -0800 (PST) In-Reply-To: References: <20160128185124.GA5140@savin.petertodd.org> Date: Mon, 1 Feb 2016 19:29:32 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e013a22687e8e8f052aba67e0 X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_IMAGE_ONLY_28, HTML_MESSAGE, MALFORMED_FREEMAIL,MISSING_HEADERS,RCVD_IN_DNSWL_LOW,T_REMOTE_IMAGE autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Segwit Upgrade Procedures & Block Extension Data X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 19:29:33 -0000 --089e013a22687e8e8f052aba67e0 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 1, 2016 at 4:55 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > * The coinbase scriptSig gets a second number push (similar to the > current BIP34 height push), which pushes a number O. O is a byte > offset inside the coinbase transaction (excluding its witness data) > that points to a 32-byte hash H. This is more flexible and more > compact than what we have now (a suggestion by jl2012). > So, the script sig is " ..... "? Why is this just not the offset in the extra nonce? > A significant design consideration is that if arbitrary data can be > > added, it is very likely that miners will make use of that ability for > > non-Bitcoin purposes; > I agree with the concern, but I don't really understand how this idea > solves it. > > It could be enforced that the data in the coinbase witness stack has a fixed number of entries, which depends on the block version number. Version 5 blocks would only have 1 entry. This would mean a soft-fork could be used to add new entries in the stack. This email has been sent from a virus-free computer protected by Avast. www.avast.com <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --089e013a22687e8e8f052aba67e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 1, 2016 at 4:55 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
* The coinbase scriptSig gets a second number push (similar to the
current BIP34 height push), which pushes a number O. O is a byte
offset inside the coinbase transaction (excluding its witness data)
that points to a 32-byte hash H. This is more flexible and more
compact than what we have now (a suggestion by jl2012).

So, the script sig is=C2=A0 "<height> <offse= t> ..... <H>"?
=C2=A0
Why is this= just not the offset in the extra nonce?

> A significant design consideration is that if arbitrary data can be > added, it is very likely that miners will make use of that ability for=
> non-Bitcoin purposes;
I agree with the concern, but I don't really understand how this= idea solves it.


It could be enforced that the data in the coinbase w= itness stack has a fixed number of entries, which depends on the block vers= ion number.=C2=A0 Version 5 blocks would only have 1 entry.

This would mean a soft-fork could be used to add new entries in the stac= k.
This email has been = sent from a virus-free computer protected by Avast.
www.avast.com
--089e013a22687e8e8f052aba67e0--