MIME-Version: 1.0
In-Reply-To: <1449897228198.c655b3ae@Nodemailer>
References: <CABsx9T0nxcqAkEt7+pVm9oZEZH_HCJ9D3J00v0bKJYeUcDv1hQ@mail.gmail.com>
	<1449897228198.c655b3ae@Nodemailer>
Date: Sat, 12 Dec 2015 23:18:46 +0800
Message-ID: <CAOG=w-t=+0Zdoy+d4Y2t9nbRkyO30N_Az9kbRarGo69yHCpSwA@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: digitsu@gmail.com
Content-Type: multipart/alternative; boundary=001a11397160d294c70526b4f424
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list

--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 <jtimon@jtimon.cc> 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

<p dir=3D"ltr">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&#39;t relay all inform=
ation necessary to validate.</p>
<p dir=3D"ltr">Non segwit servers and wallets would continue operations as =
if nothing had occurred.</p>
<div class=3D"gmail_quot&lt;blockquote class=3D" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div>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</div>
<div><br></div>
<div>
<br>=E2=80=94
Regards, </div>
<br><br><div class=3D"gmail_quote"><p>On Sat, Dec 12, 2015 at 1:43 AM, Gavi=
n Andresen via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfou=
ndation.org</a>&gt;</span> wrote:<br></p><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v><div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Fri, Dec 11, 2015 at 11:18 AM, Jorge Tim=C3=
=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_b=
lank">jtimon@jtimon.cc</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<p dir=3D"ltr">This is basically what I meant by</p>
<span>
<p dir=3D"ltr">struct hashRootStruct<br>
{<br>
uint256 hashMerkleRoot;<br>
uint256 hashWitnessesRoot;<br>
uint256 hashextendedHeader;<br>
}</p>
</span><p dir=3D"ltr">but my design doesn&#39;t calculate other_root as it =
appears in your tree (is not necessary).</p>
<p dir=3D"ltr"></p>
</blockquote>
</div>It is necessary to maintain compatibility with SPV nodes/wallets.</di=
v>
<div class=3D"gmail_extra"><br></div>
<div class=3D"gmail_extra">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.</div>
<div class=3D"gmail_extra"><br></div>
<div class=3D"gmail_extra">If it remains a binary tree, then it doesn&#39;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"gmail_extra"><br></div>
<div class=3D"gmail_extra">Plus, it&#39;s just weird to have a merkle tree =
that isn&#39;t a binary tree.....</div>
<div class=3D"gmail_extra"><br></div>
<div class=3D"gmail_extra">-- <br><div>--<br>Gavin Andresen<br></div>
</div>
</div></div></blockquote></div><br><br>____________________________________=
___________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></div>

--001a11397160d294c70526b4f424--