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 1FCEFDDD for ; Sat, 12 Dec 2015 05:13:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 771BBE0 for ; Sat, 12 Dec 2015 05:13:50 +0000 (UTC) Received: by qgz52 with SMTP id 52so26103845qgz.1 for ; Fri, 11 Dec 2015 21:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=VByX4tj4HJ6EEYMS6IVX/RXKFR0QyUXGFkd3YbwK4tY=; b=D/8xTjdQKybfE5Pin2BiTlBWkBShxuDB67sP1ZxVl1jEZZoHjWEh2jaZL53dNcwKmL Mzhe8EpBudeJ2pZ+MvsCF9nPpxOwv9B8phr8q7P8d8+nJJ6u7cvkn4i9PMsEPhVVrhXf Ci4BYEvOo6TI03mGrsqV+6pzcezL8sDqqeXuU4nUQXNXaSL1kvK4vKB1TvA1HaOE5oWg MyS/U3Y+Kto7uohtbCCpDxFxwWnTxZsR7E1mbi1aVTmw0bU5qzcNdp6NZjdtvna+JE7P +eC5yP7aGe5BP17pm4Nq4NkUQS4HkOB6JcoZi3/kvzyyIhraxRW1cgw94S6NjBCk6t/e EaKg== X-Received: by 10.140.102.226 with SMTP id w89mr29383099qge.44.1449897229678; Fri, 11 Dec 2015 21:13:49 -0800 (PST) Received: from hedwig-18.prd.orcali.com (ec2-54-85-253-144.compute-1.amazonaws.com. [54.85.253.144]) by smtp.gmail.com with ESMTPSA id g132sm9557676qhc.46.2015.12.11.21.13.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Dec 2015 21:13:48 -0800 (PST) Date: Fri, 11 Dec 2015 21:13:48 -0800 (PST) X-Google-Original-Date: Sat, 12 Dec 2015 05:13:48 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1449897228198.c655b3ae@Nodemailer> In-Reply-To: References: X-Orchestra-Oid: F9030F7F-8DFF-4397-9509-CB9B5351DB32 X-Orchestra-Sig: 3c9a5768451461b5f125bd2bc8428c2156ef916b X-Orchestra-Thrid: TD56C876D-E76D-40BE-ACDA-81C322724964_1519937925061843681 X-Orchestra-Thrid-Sig: 039320e413e349a882eae29b1df68b722d8b9658 X-Orchestra-Account: e2bf1027582c408be0fcf2c03a2d2c11442d6c5e From: digitsu@gmail.com To: "Gavin Andresen" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1449897228528" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 12 Dec 2015 06:02:40 +0000 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: Sat, 12 Dec 2015 05:13:51 -0000 ------Nodemailer-0.5.0-?=_1-1449897228528 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If this means essentially that a soft fork deployment of SegWit will = require SPV wallet servers to change their logic (or risk not being able to= send payments) then it does seem to me that a hard fork to deploy this non= controversial change is not only cleaner (on the data structure side) but = safer in terms of the potential to affect the user experience.=C2=A0 =E2=80=94 Regards, On Sat, Dec 12, 2015 at 1:43 AM, Gavin Andresen via bitcoin-dev wrote: > On Fri, Dec 11, 2015 at 11:18 AM, Jorge Tim=C3=B3n = wrote: >> This is basically what I meant by >> >> struct hashRootStruct >> { >> uint256 hashMerkleRoot; >> uint256 hashWitnessesRoot; >> uint256 hashextendedHeader; >> } >> >> but my design doesn't calculate other=5Froot as it appears in your tree = (is >> not necessary). >> >> It is necessary to maintain compatibility with SPV nodes/wallets. > Any code that just checks merkle paths up into the block header would = have > to change if the structure of the merkle tree changed to be three-headed = at > the top. > If it remains a binary tree, then it doesn't need to change at all-- the > code that produces the merkle paths will just send a path that is one = step > deeper. > Plus, it's just weird to have a merkle tree that isn't a binary tree.....= > --=20 > -- > Gavin Andresen ------Nodemailer-0.5.0-?=_1-1449897228528 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If this means essentially that a soft fork deployment of SegWit will = require SPV wallet servers to change their logic (or risk not being able to= send payments) then it does seem to me that a hard fork to deploy this non= controversial change is not only cleaner (on the data structure side) but = safer in terms of the potential to affect the user experience.=C2=A0


=E2=80=94 Regards,


On Sat, Dec 12, 2015 at 1:43 AM= , Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= org> wrote:

On Fri, Dec 11, 2015 at 11:18 AM, Jorge = Tim=C3=B3n <jtimon@jtimon.cc> wrote:

This is basically what I meant by

struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
uint256 hashextendedHeader;
}

but my design doesn't calculate other=5Froot as = it appears in your tree (is not necessary).

It is necessary to maintain compatibility with SPV nodes/wallets.=

Any code that just checks merkle paths up = into the block header would have to change if the structure of the merkle = tree changed to be three-headed at the top.

If it remains a binary tree, then it = doesn't need to change at all-- the code that produces the merkle paths = will just send a path that is one step deeper.

Plus, it's just weird to have a merkle = tree that isn't a binary tree.....

--
--
Gavin Andresen

------Nodemailer-0.5.0-?=_1-1449897228528--