MIME-Version: 1.0
In-Reply-To: <CAKzdR-qojNn8OtUTPbxa0JauK9nmo2ZGm4ihKuyzsz_FAgokDw@mail.gmail.com>
References: <CAKzdR-qojNn8OtUTPbxa0JauK9nmo2ZGm4ihKuyzsz_FAgokDw@mail.gmail.com>
From: Alphonse Pace <alp.bitcoin@gmail.com>
Date: Mon, 8 May 2017 18:47:32 -0500
Message-ID: <CAMBsKS_j7Lso6fHoMPkrQ7UFwKfxOERAAqL=aUF83O4CqL+iFg@mail.gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c1b49b6eae949054f0bdcbe
Subject: Re: [bitcoin-dev] Some real-world results about the current Segwit
	Discount
Precedence: list

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

Sergio,

I'm not sure what the data you present has to do with the discount.  A 75%
discount prevents witness spam precisely because it is 75%, nothing more.
The current usage simply gives a guideline on how much capacity is gained
through a particular discount.  With the data you show, it would imply that
those blocks, with SegWit used where possible, would result in blocks of
~1.8MB.


On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have processed 1000 blocks starting from Block #461653.
>
> I computed several metrics, including the supposed size of witness data
> and non-witness data (onchain), assuming all P2SH inputs/outputs are
> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>
> This takes into account that other types of transactions will not be
> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
> take into account that LN transactions may affect the current state,
>  increasing the segwit/nosegwit ratio.
>
> Among a lot of information, I've got the following real world results...
>
> acMainChainSpace =352608924
> acSegwitSpace =599400403
> Ratio segwit/nosegwit=1.6999
>
> This implies that the 75% that discount is not the best option to prevent
> witness spam in a block of 4 MB, as stated in https://segwit.org/why-a-
> discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>
> The non-witness data weight factor should not be 4 but 2.35. The closest
> integer value is 2, which leads to a 50% witness discount.
>
> The Bitcoinj source code is available for anyone to review. I encourage
> anyone to re-compute this with another utility to cross-check. Maybe
> Antoine Le Calvez (p2sh.info) would like to double-check.
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">Sergio,<div><br></div><div>I&#39;m not sure what the data =
you present has to do with the discount.=C2=A0 A 75% discount prevents witn=
ess spam precisely because it is 75%, nothing more.=C2=A0 The current usage=
 simply gives a guideline on how much capacity is gained through a particul=
ar discount.=C2=A0 With the data you show, it would imply that those blocks=
, with SegWit used where possible, would result in blocks of ~1.8MB.</div><=
div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via =
bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I hav=
e processed 1000 blocks starting from=C2=A0Block #461653.<div><br></div><di=
v>I computed several metrics, including the supposed size of witness data a=
nd non-witness data (onchain), assuming all P2SH inputs/outputs are convert=
ed to P2PWSH and all P2PKH inputs/outputs=C2=A0are converted to P2WPKH.</di=
v><div><br></div><div>This takes into account that other types of transacti=
ons will not be modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This =
analysis doesn&#39;t take into account that LN transactions may affect the =
current state, =C2=A0increasing the segwit/nosegwit ratio.</div><div><br></=
div><div>Among a lot of information, I&#39;ve got the following real world =
results...</div><div><br></div><div><div>acMainChainSpace =3D352608924</div=
><div>acSegwitSpace =3D599400403</div><div>Ratio segwit/nosegwit=3D1.6999</=
div></div><div><br></div><div>This implies that the 75% that discount is no=
t the best option to prevent witness spam in a block of 4 MB, as stated in =
<a href=3D"https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbc=
ebe91721e" target=3D"_blank">https://segwit.org/why-a-<wbr>discount-factor-=
of-4-why-not-<wbr>2-or-8-bbcebe91721e</a>.</div><div><br></div><div>The non=
-witness data weight factor should not be 4 but 2.35. The closest integer v=
alue is 2, which leads to a 50% witness discount.<br></div><div><br></div><=
div>The Bitcoinj source code is available for anyone to review. I encourage=
 anyone to re-compute this with another utility to cross-check. Maybe Antoi=
ne Le Calvez (<a href=3D"http://p2sh.info" target=3D"_blank">p2sh.info</a>)=
 would like to double-check.</div><div><div><br></div><div><br></div><div><=
br></div><div><br></div><div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--94eb2c1b49b6eae949054f0bdcbe--