Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B8D3D4A for ; Wed, 9 Dec 2015 08:46:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 339EB149 for ; Wed, 9 Dec 2015 08:46:51 +0000 (UTC) Received: by ioc74 with SMTP id 74so51768452ioc.2 for ; Wed, 09 Dec 2015 00:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=o+VJsUR/PU/URKY4tCd1i7eydj7kF3EoXkU990mzM4I=; b=0kHJH+UMgM2HB+JzeAsolSlhyV2WGMMFmZCZWfN7P0iPcHJ7aWksfb3ypcKD5sRoH3 6ZRi1C/H352xrESS2eNqton1V7/czazGPBhsyFNASNsrNQc2dzr9gVspdfeMCtS60qTf phipr9DYqc8c/k1u51k7uKhmJhDc2CPBlGedJgjzVpsRM6DS5Bha5J/KHsnmxFCogSCz XirbPzjvG6Njo4/bN5UaLGYkNR58mCSwc+9VtZRrXCsK/oFVj0a6URQAlw3VLlI6aQSE 9NCBWW+omXXnLPlNr8tPHYWmyPfGo9oNFsBui1W3VcC4GbweKDCEIZg4T0Ac/fSZTsy9 G5LQ== 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:from:date :message-id:subject:to:cc:content-type; bh=o+VJsUR/PU/URKY4tCd1i7eydj7kF3EoXkU990mzM4I=; b=G6z+MwIgpAyU16L5BRrB4PmpjFWT0JaZ+xIxMQV8J4BH7RriukzYRX4KW/rNpg1McH EkwUiUSHvcgfd3MJgqexQmUjfn9oIdbwALKusQ9Ebo/WjslVEKCsw5exUv/pfLBDxxNk +5usG1gs+vG7HADXtTmamC+Yfzf/hD1djXvS4O7uCdLtmU4hm6NPd/8szS7N1QxIrIit Ycg5pGED6m8K7BeOLqtV/FPy+yRghzB5nv79lxcJZh9nFvBwVP0dBnqhLBT655ii6dz4 beX/BVBV+oHsbwa9AHpWON59ZZCYVxEhDzNrPzYMIp6KOxyhmkPQfum196UVc6rpln7Z NhLA== X-Gm-Message-State: ALoCoQlK/FVThU8odBB4Iu4SYdsjqRF8dYlL+8MzZgVeFzyNVbHxliGcoLvxf0NhPCt9QWizagb9pdvkAOGAeGVOW5m9TdqWLQ== X-Received: by 10.107.44.81 with SMTP id s78mr4814735ios.159.1449650810617; Wed, 09 Dec 2015 00:46:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.133.217 with HTTP; Wed, 9 Dec 2015 00:46:31 -0800 (PST) X-Originating-IP: [202.83.241.113] In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> From: Mark Friedenbach Date: Wed, 9 Dec 2015 16:46:31 +0800 Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a113971609d94e9052673218b X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB, URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system. 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: Wed, 09 Dec 2015 08:46:52 -0000 --001a113971609d94e9052673218b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My apologies for the apparent miscommunication earlier. It is of interest to me that the soft-fork be done which is necessary to put a commitment in the most efficient spot possible, in part because that commitment could be used for other data such as the merged mining auxiliary blocks, which are very sensitive to proof size. Perhaps we have a different view of how the commitment transaction would be generated. Just as GBT doesn't create the coinbase, it was my expectation that it wouldn't generate the commitment transaction either -- but generation of the commitment would be easy, requiring either the coinbase txid 100 blocks back, or the commitment txid of the prior transaction (note this impacts SPV mining). The truncation shouldn't be an issue because the commitment txn would not be part of the list of transactions selected by GBT, and in any case the truncation would change the witness data which changes the commitment. On Wed, Dec 9, 2015 at 4:03 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Dec 9, 2015 at 7:54 AM, Jorge Tim=C3=B3n wrote= : > > From this question one could think that when you said "we can do the > > cleanup hardfork later" earlier you didn't really meant it. And that > > you will oppose to that hardfork later just like you are opposing to > > it now. > > As said I disagree that making a softfork first and then move the > > commitment is less disruptive (because people will need to adapt their > > software twice), but if the intention is to never do the second part > > then of course I agree it would be less disruptive. > > How long after the softfork would you like to do the hardfork? > > 1 year after the softfork? 2 years? never? > > I think it would be logical to do as part of a hardfork that moved > commitments generally; e.g. a better position for merged mining (such > a hardfork was suggested in 2010 as something that could be done if > merged mining was used), room for commitments to additional block > back-references for compact SPV proofs, and/or UTXO set commitments. > Part of the reason to not do it now is that the requirements for the > other things that would be there are not yet well defined. For these > other applications, the additional overhead is actually fairly > meaningful; unlike the fraud proofs. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113971609d94e9052673218b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My apologies for the apparent miscommunication earlie= r. It is of interest to me that the soft-fork be done which is necessary to= put a commitment in the most efficient spot possible, in part because that= commitment could be used for other data such as the merged mining auxiliar= y blocks, which are very sensitive to proof size.

Perhaps we h= ave a different view of how the commitment transaction would be generated. = Just as GBT doesn't create the coinbase, it was my expectation that it = wouldn't generate the commitment transaction either -- but generation o= f the commitment would be easy, requiring either the coinbase txid 100 bloc= ks back, or the commitment txid of the prior transaction (note this impacts= SPV mining). The truncation shouldn't be an issue because the commitme= nt txn would not be part of the list of transactions selected by GBT, and i= n any case the truncation would change the witness data which changes the c= ommitment.

On Wed, Dec 9, 2015 at 4:03 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Wed, Dec 9, 2015 at 7:= 54 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> From this question one could think that when you said "we can do = the
> cleanup hardfork later" earlier you didn't really meant it. A= nd that
> you will oppose to that hardfork later just like you are opposing to > it now.
> As said I disagree that making a softfork first and then move the
> commitment is less disruptive (because people will need to adapt their=
> software twice), but if the intention is to never do the second part > then of course I agree it would be less disruptive.
> How long after the softfork would you like to do the hardfork?
> 1 year after the softfork? 2 years? never?

I think it would be logical to do as part of a hardfork that moved commitments generally; e.g. a better position for merged mining (such
a hardfork was suggested in 2010 as something that could be done if
merged mining was used), room for commitments to additional block
back-references for compact SPV proofs, and/or UTXO set commitments.
Part of the reason to not do it now is that the requirements for the
other things that would be there are not yet well defined. For these
other applications, the additional overhead is actually fairly
meaningful; unlike the fraud proofs.
___________________________________= ____________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a113971609d94e9052673218b--