Date: Fri, 11 Dec 2015 21:13:48 -0800 (PST)
MIME-Version: 1.0
Message-Id: <1449897228198.c655b3ae@Nodemailer>
In-Reply-To: <CABsx9T0nxcqAkEt7+pVm9oZEZH_HCJ9D3J00v0bKJYeUcDv1hQ@mail.gmail.com>
References: <CABsx9T0nxcqAkEt7+pVm9oZEZH_HCJ9D3J00v0bKJYeUcDv1hQ@mail.gmail.com>
From: digitsu@gmail.com
To: "Gavin Andresen" <gavinandresen@gmail.com>
Content-Type: multipart/alternative;
	boundary="----Nodemailer-0.5.0-?=_1-1449897228528"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list

------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
<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.....=

> --=20
> --
> Gavin Andresen
------Nodemailer-0.5.0-?=_1-1449897228528
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


<div>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</div>
<div><br></div>
<div class=3D=22mailbox=5Fsignature=22>
<br>=E2=80=94
Regards, </div>
<br><br><div class=3D=22gmail=5Fquote=22><p>On Sat, Dec 12, 2015 at 1:43 AM=
, Gavin Andresen via bitcoin-dev <span dir=3D=22ltr=22>&lt;<a =
href=3D=22mailto:bitcoin-dev@lists.linuxfoundation.org=22 =
target=3D=22=5Fblank=22>bitcoin-dev@lists.linuxfoundation.=
org</a>&gt;</span> wrote:<br></p><blockquote class=3D=22gmail=5Fquote=22 =
style=3D=22margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
=22><div><div dir=3D=22ltr=22>
<div class=3D=22gmail=5Fextra=22>
<div class=3D=22gmail=5Fquote=22>On Fri, Dec 11, 2015 at 11:18 AM, Jorge =
Tim=C3=B3n <span dir=3D=22ltr=22>&lt;<a href=3D=22mailto:jtimon@jtimon.=
cc=22>jtimon@jtimon.cc</a>&gt;</span> wrote:<br><blockquote =
class=3D=22gmail=5Fquote=22 style=3D=22margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex=22>
<p dir=3D=22ltr=22>This is basically what I meant by</p>
<span class=3D=22=22>
<p dir=3D=22ltr=22>struct hashRootStruct<br>
{<br>
uint256 hashMerkleRoot;<br>
uint256 hashWitnessesRoot;<br>
uint256 hashextendedHeader;<br>
}</p>
</span><p dir=3D=22ltr=22>but my design doesn't calculate other=5Froot as =
it appears in your tree (is not necessary).</p>
<p dir=3D=22ltr=22></p>
</blockquote>
</div>It is necessary to maintain compatibility with SPV nodes/wallets.=
</div>
<div class=3D=22gmail=5Fextra=22><br></div>
<div class=3D=22gmail=5Fextra=22>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.</div>
<div class=3D=22gmail=5Fextra=22><br></div>
<div class=3D=22gmail=5Fextra=22>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.</div>
<div class=3D=22gmail=5Fextra=22><br></div>
<div class=3D=22gmail=5Fextra=22>Plus, it's just weird to have a merkle =
tree that isn't a binary tree.....</div>
<div class=3D=22gmail=5Fextra=22><br></div>
<div class=3D=22gmail=5Fextra=22>-- <br><div class=3D=22gmail=5Fsignature=
=22>--<br>Gavin Andresen<br></div>
</div>
</div></div></blockquote></div><br>
------Nodemailer-0.5.0-?=_1-1449897228528--