path: root/ae/7aaac5d51e7b04e59fa857e0cc0cbe638d5d99

Return-Path: <mail@albertodeluigi.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4E993CCD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 16:40:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail8.dominiofaidate.com (mail8.dominiofaidate.com
	[212.35.195.17])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B0982456
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Dec 2017 16:40:08 +0000 (UTC)
Received: from bto20160722
	(host37-187-static.103-195-b.business.telecomitalia.it
	[195.103.187.37]) by mail8.dominiofaidate.com with ESMTPA
	; Mon, 18 Dec 2017 17:40:03 +0100
From: "Alberto De Luigi" <mail@albertodeluigi.com>
To: <bitcoin-dev@lists.linuxfoundation.org>
Date: Mon, 18 Dec 2017 17:40:08 +0100
Message-ID: <003c01d3781e$dda115f0$98e341d0$@albertodeluigi.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003D_01D37827.3F67C7E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdN4GlzdacPQd1hIQO+3VMTcs3pyrA==
Content-Language: it
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 18 Dec 2017 16:41:53 +0000
Subject: [bitcoin-dev] Clarification about SegWit transaction size and bech32
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Dec 2017 16:40:12 -0000

This is a multipart message in MIME format.

------=_NextPart_000_003D_01D37827.3F67C7E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello guys,

I have a few questions about the SegWit tx size, I'd like to have
confirmation about the following statements. Can you correct mistakes or
inaccuracies? Thank you in advance.

 

In general, SegWit tx costs more than legacy tx (source
https://bitcoincore.org/en/2016/10/28/segwit-costs/):

 

*	Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the
scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.
*	Compared to P2SH, P2WSH uses 11 additional bytes (6%) in the
scriptPubKey, and the same number of witness bytes as P2SH scriptSig.
*	Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes (11%), due
to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig than in P2PKH
scriptPubKey, and the same number of witness bytes as P2PKH scriptSig.
*	Compared to P2SH, P2WSH/P2SH uses 35 additional bytes (19%), due to
using 24 bytes in scriptPubKey, 11 additional bytes in scriptSig compared to
P2SH scriptPubKey, and the same number of witness bytes as P2SH scriptSig.

 

But still it is convenient to adopt segwit because you move the bytes to the
blockweight part, paying smaller fee. In general, a tx with 1 input and 1
output is about 190kb. If it's a Segwit tx, 82kb in the non-witness part
(blocksize), 108 in the witness part (blockweight).

See source:

4 bytes version

1 byte input count

Input

36 bytes outpoint

1 byte scriptSigLen (0x00)

0 bytes scriptSig

4 bytes sequence

1 byte output count

8 bytes value

1 byte scriptPubKeyLen

22 bytes scriptPubKey (0x0014{20-byte keyhash})

4 bytes locktime

https://bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactio
ns-what-would-be-the-max-number-of-transaction-confi

 

Which means, if you fill a block entirely with this kind of tx, you can
approximately double the capacity of the blockchain (blocksize capped to
1mb, blockweight a little bit more than 2mb)

 

My concern is about segwit adoption by the exchanges. 

SegWit transactions cost 10bytes more than legacy transactions for each
output (vout is 256 bits instead of 160). Exchanges aggregate tx adding many
outputs, which is of course something good for bitcoin scalability, since
this way we save space and pay less fees.

But when a tx has at least 10 outputs, using segwit you don't save space,
instead:

- the total blockweight is at least 100bytes higher (10bytes x 10 outputs),
so the blockchain is heavier 

- you don't save space inside the blocksize, so you cannot validate more
transactions of this kind (with many outputs), nor get cheaper fee

- without cheaper fees exchanges have no incentives for segwit adoption
before they decide to adopt LN

 

In general we can say that using SegWit:

- you decrease the fee only for some specific kind of transactions, and just
because you move some bytes to the blockweight

- you don't save space in the blockchain, on the contrary the total weight
of the blockchain increases (so it's clear to me why some time ago Luke
tweeted to not use SegWit unless really necessary... but then it's not clear
why so much haste in promoting BIP148 the 1st august risking a split)

 

If it's all correct, does something change with bech32? I'm reading bech32
allows to save about 22% of the space. Is this true for whatever kind of tx?
Immediate benefits of segwit for scalability are only with bech32?

 

Bech32 is non-compatible with the entire ecosystem (you cannot receive coins
from the quasi-totality of wallets in circulation), I would say it is a hard
fork. But the bare segwit is really so different? the soft fork is "soft"
for the reference client Bitcoin Core, but outside you cannot know what
happens, there are plenty of implementations (especially frontend
customization) which don't work with segwit and need to upgrade. To upgrade
takes a lot of time, especially when services are so crowded and so many new
people want to step in. At this point, if bech32 brings only efficiency (but
correct me if it's not so) and it is well planned, it could be a consensual
upgrade, maybe together with a 2x blocksize? Is there a specific plan for
some upgrade in 2018? I personally think it is far easier to reach consensus
on a blocksize increase una tantum rather than a dynamic increase. You
cannot predict the technology growth: will it be linear, exponential, or
suddenly stop for a while, maybe right before a huge innovation? I think a
hard fork bech32 upgrade + 2x could help a lot in scalability while we test
LN, and it might be the only way to effectively promote (or should I say
enforce?) SegWit adoption.

 

thank you,

Alberto De Luigi

(.com)


------=_NextPart_000_003D_01D37827.3F67C7E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;
	mso-fareast-language:EN-US;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 2.0cm 2.0cm;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:420375297;
	mso-list-type:hybrid;
	mso-list-template-ids:218638452 1757808178 68157443 68157445 68157441 =
68157443 68157445 68157441 68157443 68157445;}
@list l0:level1
	{mso-level-start-at:4;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Calibri",sans-serif;
	mso-fareast-font-family:Calibri;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DIT =
link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p =
class=3DMsoNormal><span lang=3DEN-US>Hello guys,<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>I have a few questions about the =
SegWit tx size, I'd like to have confirmation about the following =
statements. Can you correct mistakes or inaccuracies? Thank you in =
advance.<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>In general, SegWit tx costs more than legacy tx (source <a =
href=3D"https://bitcoincore.org/en/2016/10/28/segwit-costs/">https://bitc=
oincore.org/en/2016/10/28/segwit-costs/</a>):<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><ul =
style=3D'margin-top:0cm' type=3Ddisc><li class=3DMsoListParagraph =
style=3D'margin-left:0cm;mso-list:l0 level1 lfo1'><span =
lang=3DEN-US>Compared to P2PKH, P2WPKH uses 3 fewer bytes (-1%) in the =
scriptPubKey, and the same number of witness bytes as P2PKH =
scriptSig.<o:p></o:p></span></li><li class=3DMsoListParagraph =
style=3D'margin-left:0cm;mso-list:l0 level1 lfo1'><span =
lang=3DEN-US>Compared to P2SH, P2WSH uses 11 additional bytes (6%) in =
the scriptPubKey, and the same number of witness bytes as P2SH =
scriptSig.<o:p></o:p></span></li><li class=3DMsoListParagraph =
style=3D'margin-left:0cm;mso-list:l0 level1 lfo1'><span =
lang=3DEN-US>Compared to P2PKH, P2WPKH/P2SH uses 21 additional bytes =
(11%), due to using 24 bytes in scriptPubKey, 3 fewer bytes in scriptSig =
than in P2PKH scriptPubKey, and the same number of witness bytes as =
P2PKH scriptSig.<o:p></o:p></span></li><li class=3DMsoListParagraph =
style=3D'margin-left:0cm;mso-list:l0 level1 lfo1'><span =
lang=3DEN-US>Compared to P2SH, P2WSH/P2SH uses 35 additional bytes =
(19%), due to using 24 bytes in scriptPubKey, 11 additional bytes in =
scriptSig compared to P2SH scriptPubKey, and the same number of witness =
bytes as P2SH scriptSig.<o:p></o:p></span></li></ul><p =
class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>But still it is convenient to adopt =
segwit because you move the bytes to the blockweight part, paying =
smaller fee. In general, a tx with 1 input and 1 output is about 190kb. =
If it's a Segwit tx, 82kb in the non-witness part (blocksize), 108 in =
the witness part (blockweight).<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>See source:<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>4 bytes =
version<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>1 =
byte input count<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>Input<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>36 bytes outpoint<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>1 byte scriptSigLen =
(0x00)<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>0 =
bytes scriptSig<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>4 bytes sequence<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>1 byte output =
count<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>8 =
bytes value<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>1 byte scriptPubKeyLen<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>22 bytes scriptPubKey =
(0x0014{20-byte keyhash})<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>4 bytes =
locktime<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US><a =
href=3D"https://bitcoin.stackexchange.com/questions/59408/with-100-segwit=
-transactions-what-would-be-the-max-number-of-transaction-confi">https://=
bitcoin.stackexchange.com/questions/59408/with-100-segwit-transactions-wh=
at-would-be-the-max-number-of-transaction-confi</a><o:p></o:p></span></p>=
<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>Which means, if you fill a block =
entirely with this kind of tx, you can approximately double the capacity =
of the blockchain (blocksize capped to 1mb, blockweight a little bit =
more than 2mb)<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>My concern is about segwit adoption by the exchanges. =
<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>SegWit =
transactions cost 10bytes more than legacy transactions for each output =
(vout is 256 bits instead of 160). Exchanges aggregate tx adding many =
outputs, which is of course something good for bitcoin scalability, =
since this way we save space and pay less fees.<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>But when a tx has at least 10 =
outputs, using segwit you don't save space, =
instead:<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US> =
<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>- the =
total blockweight is at least 100bytes higher (10bytes x 10 outputs), so =
the blockchain is heavier <o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>- you don't save space inside the =
blocksize, so you cannot validate more transactions of this kind (with =
many outputs), nor get cheaper fee<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>- without cheaper fees exchanges =
have no incentives for segwit adoption before they decide to adopt =
LN<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>In general we can say that using =
SegWit:<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>- =
you decrease the fee only for some specific kind of transactions, and =
just because you move some bytes to the =
blockweight<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>- you don&#8217;t save space in the blockchain, on the =
contrary the total weight of the blockchain increases (so it's clear to =
me why some time ago Luke tweeted to not use SegWit unless really =
necessary... but then it's not clear why so much haste in promoting =
BIP148 the 1st august risking a split)<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>If it's all correct, does something =
change with bech32? I'm reading bech32 allows to save about 22% of the =
space. Is this true for whatever kind of tx? Immediate benefits of =
segwit for scalability are only with bech32?<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US>Bech32 is non-compatible with the =
entire ecosystem (you cannot receive coins from the quasi-totality of =
wallets in circulation), I would say it is a hard fork. But the bare =
segwit is really so different? the soft fork is &quot;soft&quot; for the =
reference client Bitcoin Core, but outside you cannot know what happens, =
there are plenty of implementations (especially frontend customization) =
which don&#8217;t work with segwit and need to upgrade. To upgrade takes =
a lot of time, especially when services are so crowded and so many new =
people want to step in. At this point, if bech32 brings only efficiency =
(but correct me if it&#8217;s not so) and it is well planned, it could =
be a consensual upgrade, maybe together with a 2x blocksize? Is there a =
specific plan for some upgrade in 2018? I personally think it is far =
easier to reach consensus on a blocksize increase una tantum rather than =
a dynamic increase. You cannot predict the technology growth: will it be =
linear, exponential, or suddenly stop for a while, maybe right before a =
huge innovation? I think a hard fork bech32 upgrade + 2x could help a =
lot in scalability while we test LN, and it might be the only way to =
effectively promote (or should I say enforce?) SegWit =
adoption.<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US>thank you,<o:p></o:p></span></p><p =
class=3DMsoNormal>Alberto De Luigi<o:p></o:p></p><p =
class=3DMsoNormal>(.com)<o:p></o:p></p></div></body></html>
------=_NextPart_000_003D_01D37827.3F67C7E0--