MIME-Version: 1.0
In-Reply-To: <CAAt2M1_Ac4or_awrGTuYGEwLsJLP+_LBCsu2SubaJGr-f0BkoA@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
	<1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com>
	<CAD1TkXse5O6nEw9-EPsNp4c56YJ+OnM=F1uf8w+tyB=_+hFzFQ@mail.gmail.com>
	<CAKzdR-rFJNOZ856rA_q8C=zEUj_X561OSOwW+KZr4nRJ51w3HA@mail.gmail.com>
	<CABm2gDrAHo2P7t6SjituURqMUqs_=Lbp7X=g_j8nGoNKMKCRKQ@mail.gmail.com>
	<CAAt2M19PvHLY0PA6iy+wiPg10vqONDApTLDuxzEcte=KUZLoaQ@mail.gmail.com>
	<CABm2gDqw2TayGvaH_nz3jrF8Cz2V=SbB4begD6+K=Ye=Msw4mg@mail.gmail.com>
	<CAAt2M1_gDzEuDLSvVsJARvdCAtUyM3Yuu7TT25sbm3L-Zi6+0Q@mail.gmail.com>
	<CAAt2M18=Tjw+05QCv6G7Abv=idB6ONgU9xvtrR=fn731452_mg@mail.gmail.com>
	<CAAt2M1835S3YYJ_p0_zvDR9U6EfYAt7SWTAEPNHnNfgstKpgMg@mail.gmail.com>
	<CABm2gDqMGBiwZppcyt6yF2sMJVs=nCr0M8u4H_22QDMR3wCFxQ@mail.gmail.com>
	<CAAt2M1_Ac4or_awrGTuYGEwLsJLP+_LBCsu2SubaJGr-f0BkoA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sun, 2 Apr 2017 13:43:54 +0200
Message-ID: <CABm2gDpHKpU_nF_-7V59YhwqGnUc=2pXQNU9dDUq7wOvd7Uyyw@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>
Content-Type: multipart/alternative; boundary=f403045e33b2be6e1b054c2d8e07
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For
	Comments
Precedence: list

--f403045e33b2be6e1b054c2d8e07
Content-Type: text/plain; charset=UTF-8

Just saying that we can talk in terms of weight alone after segwit. 8 mb
weight is much more clear than 2 mb size to me. 2 mb size seems to
obfuscate the actual new limit with the proposed hf, which simply 8 mb
weight.

On 2 Apr 2017 12:03 pm, "Natanael" <natanael.l@gmail.com> wrote:

> My point, if you missed it, is that there's a mathematical equivalence
> between using two limits (and calculating the ratio) vs using one limit and
> a ratio. The output is fully identical. The only difference is the order of
> operations. Saying there's no blocksize limit with this is pretty
> meaningless, because you're just saying you're using an abstraction that
> doesn't make the limit visible.
>

--f403045e33b2be6e1b054c2d8e07
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Just saying that we can talk in terms of weight alone aft=
er segwit. 8 mb weight is much more clear than 2 mb size to me. 2 mb size s=
eems to obfuscate the actual new limit with the proposed hf, which simply 8=
 mb weight.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 2 Apr 2017 12:03 pm, &quot;Natanael&quot; &lt;<a href=3D"mailto:natanael=
.l@gmail.com">natanael.l@gmail.com</a>&gt; wrote:<br type=3D"attribution"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"auto">My point, if you missed it,=
 is that there&#39;s a mathematical equivalence between using two limits (a=
nd calculating the ratio) vs using one limit and a ratio. The output is ful=
ly identical. The only difference is the order of operations. Saying there&=
#39;s no blocksize limit with this is pretty meaningless, because you&#39;r=
e just saying you&#39;re using an abstraction that doesn&#39;t make the lim=
it visible.=C2=A0</div>
</blockquote></div></div>

--f403045e33b2be6e1b054c2d8e07--