MIME-Version: 1.0
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Mon, 8 May 2017 19:42:23 -0300
Message-ID: <CAKzdR-qojNn8OtUTPbxa0JauK9nmo2ZGm4ihKuyzsz_FAgokDw@mail.gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114670904fed79054f0af6e8
Cc: hello@p2sh.info
Subject: [bitcoin-dev] Some real-world results about the current Segwit
	Discount
Precedence: list

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

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.

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

<div dir=3D"ltr">I have processed 1000 blocks starting from=C2=A0Block #461=
653.<div><br></div><div>I computed several metrics, including the supposed =
size of witness data and non-witness data (onchain), assuming all P2SH inpu=
ts/outputs are converted to P2PWSH and all P2PKH inputs/outputs=C2=A0are co=
nverted to P2WPKH.</div><div><br></div><div>This takes into account that ot=
her types of transactions will not be modified by Segwit (e.g. OP_RETURN ou=
tputs, or P2PK). This analysis doesn&#39;t take into account that LN transa=
ctions may affect the current state, =C2=A0increasing the segwit/nosegwit r=
atio.</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>acMainChainS=
pace =3D352608924</div><div>acSegwitSpace =3D599400403</div><div>Ratio segw=
it/nosegwit=3D1.6999</div></div><div><br></div><div>This implies that the 7=
5% that discount is not 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-o=
f-4-why-not-2-or-8-bbcebe91721e">https://segwit.org/why-a-discount-factor-o=
f-4-why-not-2-or-8-bbcebe91721e</a>.</div><div><br></div><div>The non-witne=
ss data weight factor should not be 4 but 2.35. The closest integer value i=
s 2, which leads to a 50% witness discount.<br></div><div><br></div><div>Th=
e Bitcoinj source code is available for anyone to review. I encourage anyon=
e to re-compute this with another utility to cross-check. Maybe Antoine Le =
Calvez (<a href=3D"http://p2sh.info">p2sh.info</a>) would like to double-ch=
eck.</div><div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div><br></div></div></div>

--001a114670904fed79054f0af6e8--