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 13A0FDE0 for ; Sat, 12 Dec 2015 15:18:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5987131 for ; Sat, 12 Dec 2015 15:18:47 +0000 (UTC) Received: by iouu10 with SMTP id u10so157712422iou.0 for ; Sat, 12 Dec 2015 07:18:47 -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:date:message-id:subject:from:to :cc:content-type; bh=l9YhbBg2U56VKmcp32YjNELHe9qk0Fj77TN96nHt2Ec=; b=hCRCfwz6g/Fh9qD4kQMYVyblyo7fqUMCeGnGNZJh98IUMfjsvheOAMwdbu+w6bxByK bZxBzZZZoEkT0asf52R6rUZHqGCnrmWB2ZHclS5O0jAMkvd6MtnUEyk00nQTL6ZjKtfN 7mLEZAGVGiwDs/enplACXglV0l9RNRWhNlpLqnPGEuV4OVkeripubWe+8KLlBZwFLlhY v5amn1n5zQLnr72DgHNbrM+D/UvJyLyozWl68SVfL1+FU8xLjo7Js0HJSVT5nm7xTraP 4pcWnKlR52JwUbj93wDUQl3t8s6BYbmu88Yer72YxmaCiBOHDbm05XAVnL2aVcG9vdeq RKLw== 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=l9YhbBg2U56VKmcp32YjNELHe9qk0Fj77TN96nHt2Ec=; b=JM49lczxg2K6hoP0hrek7DSb2yZJQ86Ifu743q4Ke9HPFwFwuFCrhCmwfaKVikl8LN AGZDXsjXQTI92UFrobLPp3SYEjcCp3XTXSV9QuX6d+cFkE98I08+9BAuBAVRPfQeifVY zjbND7e50/XeSIMreYwxDieY5Z3PdRdm0Ul/+8dDz4vKolFrYpaCh3fIK308r93/RLVR aLrPvEzemy5PPTDWjjrjJo+6tiruROmX9MIIf//H/xueHa4/YCrcENZ9oabfARYcrWQ3 HSzUepndn4aUjdvxz8ZeP6U54kj/1YO/Ao2wqzz46yfCEsX7jVVJ/dkj7Bw+3VEF51Zh wGtw== X-Gm-Message-State: ALoCoQlsaEezJGr4QRKM9QVJ8wF7w/Q6DB+J+j0HVv4XhMryzFqwcZbzSRe68Dqvbk6OyQ/r8cQX284QYPDcMoROB9OMeogt5A== MIME-Version: 1.0 X-Received: by 10.107.44.81 with SMTP id s78mr25054266ios.159.1449933526954; Sat, 12 Dec 2015 07:18:46 -0800 (PST) Received: by 10.107.133.217 with HTTP; Sat, 12 Dec 2015 07:18:46 -0800 (PST) X-Originating-IP: [172.56.7.157] Received: by 10.107.133.217 with HTTP; Sat, 12 Dec 2015 07:18:46 -0800 (PST) In-Reply-To: <1449897228198.c655b3ae@Nodemailer> References: <1449897228198.c655b3ae@Nodemailer> Date: Sat, 12 Dec 2015 23:18:46 +0800 Message-ID: From: Mark Friedenbach To: digitsu@gmail.com Content-Type: multipart/alternative; boundary=001a11397160d294c70526b4f424 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 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 15:18:49 -0000 --001a11397160d294c70526b4f424 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A segwit supporting server would be required to support relaying segwit transactions, although a non-segwit server could at least inform a wallet of segwit txns observed, even if it doesn't relay all information necessary to validate. Non segwit servers and wallets would continue operations as if nothing had occurred. 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. =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 wro= te: > >> This is basically what I meant by >> >> struct hashRootStruct >> { >> uint256 hashMerkleRoot; >> uint256 hashWitnessesRoot; >> uint256 hashextendedHeader; >> } >> >> but my design doesn't calculate other_root as it appears in your tree (i= s >> 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 hav= e > 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 ste= p > deeper. > > Plus, it's just weird to have a merkle tree that isn't a binary tree..... > > -- > -- > Gavin Andresen > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --001a11397160d294c70526b4f424 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A segwit supporting server would be required to support rela= ying segwit transactions, although a non-segwit server could at least infor= m a wallet of segwit txns observed, even if it doesn't relay all inform= ation necessary to validate.

Non segwit servers and wallets would continue operations as = if nothing had occurred.

If this means essentially that a soft fork deployment of SegWit will r= equire 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 s= afer 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, Gavi= n Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfou= ndation.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_root 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 t= he block header would have to change if the structure of the merkle tree ch= anged 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


____________________________________= ___________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a11397160d294c70526b4f424--