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 C09E2B9B for ; Tue, 8 Dec 2015 23:50:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com [209.85.213.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0D872107 for ; Tue, 8 Dec 2015 23:50:37 +0000 (UTC) Received: by vkca188 with SMTP id a188so33108643vkc.0 for ; Tue, 08 Dec 2015 15:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EkKuSXCbvBkcp8vMDRlpEPZp+DxR73qznS2V3nuha9s=; b=QMdP/Uy9/HYLbCmFWAGPRVNTzZw3Pb6NJnbRfr+P6x9uokOrJKc0HpffLLDdTxP9GE kf3hQIuGXujNM3Grnuw4E+XEfUZLjVqJHWuymDE/iz4QgtnIyT4mO+ppeS5WElVnb7Xg qgcYuPF8wdxhZ+LjNxsMdwzVY+r0I+ABzTdyZUv9e3OhGobvRYbeXp+4I6KJI6P5YXUf W2ZVLVbKzg0eAFfgA0IgoLOE/n/faEmBblvVN2rca5UbIx7T/RKoOmNeipzBqQRGlrLi FHe4/e7NrnaRNbrFAFxYrWIKtHtZmeQwkPrXO2hAkAZFfDMkhXz14hkTS/Nl3AMOjKKK Rm4g== 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:to:cc:content-type; bh=EkKuSXCbvBkcp8vMDRlpEPZp+DxR73qznS2V3nuha9s=; b=h7KjaTiMo5eNuPaFK3P0XHZidewrbjTO5CWCcJVoEfMJ+CI86llJe9PbDam3v87p0E fSehemzqmeSrz3jbHdRnVbLE5ZGUWCW5adMu/VE47/ZUpXW2UWkjzglVT1j2WpiwA+e0 tzuQMUdcQQ4iWTrIkGNd/O8Y6DQ0PVPZ8QmlRwY+psxFTfilJsJaO44dhl3TavLGs+Jj WlRJn9SpuOi03ydB0wDv14Z2Z9gsllZX6OS+pjO5lryCTNlu1KfAblzdb2xsl+rvuyiG mhMaL+jdv2fRxBOYyn2PmFcvM/ut8tEgPzDS8P7+PgBBHdD3Xj/DYk1Quw6nXqBPMb0Z PWyQ== X-Gm-Message-State: ALoCoQke3kgygvW+MRnDqpfh21NixSWaUOXcvzSljeiyM1WwqlFdt2RLbbG7gwQ5H9dDdZ5kobIITXNh9HessewbNVpZtGHy3A== MIME-Version: 1.0 X-Received: by 10.31.154.213 with SMTP id c204mr2176810vke.38.1449618636233; Tue, 08 Dec 2015 15:50:36 -0800 (PST) Received: by 10.31.236.70 with HTTP; Tue, 8 Dec 2015 15:50:35 -0800 (PST) Received: by 10.31.236.70 with HTTP; Tue, 8 Dec 2015 15:50:35 -0800 (PST) In-Reply-To: <2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im> References: <20151208110752.GA31180@amethyst.visucore.com> <5666FD8D.8050201@openbitcoinprivacyproject.org> <2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im> Date: Wed, 9 Dec 2015 00:50:35 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Jonathan Toomim Content-Type: multipart/alternative; boundary=001a1140f52cdf739805266ba350 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham 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: Tue, 08 Dec 2015 23:50:37 -0000 --001a1140f52cdf739805266ba350 Content-Type: text/plain; charset=UTF-8 On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > I also think that a hard fork is better for SegWit, as it reduces the size of fraud proofs considerably, makes the whole design more elegant and less kludgey, and is safer for clients who do not upgrade in a timely fashion. I agree, although I disagree with the last reason. > I don't like the idea that SegWit would invalidate the security assumptions of non-upgraded clients (including SPV wallets). I think that for these clients, no data is better than invalid data. Better to force them to upgrade by cutting them off the network than to let them think they're validating transactions when they're not. I don't undesrtand. SPV nodes won't think they are validating transactions with the new version unless they adapt to the new format. They will be simply unable to receive payments using the new format if it is a softfork (although as said I agree with making it a hardfork on the simpler design and smaller fraud proofs grounds alone). > > On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > If such a change is going to be deployed via a soft fork instead of a > > hard fork, then the coinbase is the worst place to put the segwitness > > merkle root. > > > > Instead, put it in the first output of the generation transaction as an > > OP_RETURN script. > > > > This is a better pattern because coinbase space is limited while output > > space is not. The next time there's a good reason to tie another merkle > > tree to a block, that proposal can be designated for the second output > > of the generation transaction. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a1140f52cdf739805266ba350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <bitcoin-dev@lists.lin= uxfoundation.org> wrote:

> I also think that a hard fork is better for SegWit, as = it reduces the size of fraud proofs considerably, makes the whole design mo= re elegant and less kludgey, and is safer for clients who do not upgrade in= a timely fashion.

I agree, although I disagree with the last reason.

> I don't like the idea that SegWit would invalidate = the security assumptions of non-upgraded clients (including SPV wallets). I= think that for these clients, no data is better than invalid data. Better = to force them to upgrade by cutting them off the network than to let them t= hink they're validating transactions when they're not.

I don't undesrtand. SPV nodes won't think they are v= alidating transactions with the new version unless they adapt to the new fo= rmat. They will be simply unable to receive payments using the new format i= f it is a softfork (although as said I agree with making it a hardfork on t= he simpler design and smaller fraud proofs grounds alone).

>
> On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org> wrote:
>
> > If such a change is going to be deployed via a soft fork instead = of a
> > hard fork, then the coinbase is the worst place to put the segwit= ness
> > merkle root.
> >
> > Instead, put it in the first output of the generation transaction= as an
> > OP_RETURN script.
> >
> > This is a better pattern because coinbase space is limited while = output
> > space is not. The next time there's a good reason to tie anot= her merkle
> > tree to a block, that proposal can be designated for the second o= utput
> > of the generation transaction.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a1140f52cdf739805266ba350--